The new system is slightly less flexible, but the code and lua
definitions is now a lot simpler and easier to understand.
In fact the old lua definition was not actually correct.
It is likely that existing configs require not/minimal tweaks to work
again.
It now has to be called 'setup', this makes it possible to just
include the table as a whole in devices and it will automatically call
the correct function.
Instead the client is now created on the rust side based on the config.
Devices that require the mqtt client will now instead need to be
constructor using a function. This function receives the mqtt client.
In preparation of changes to the mqtt client the config is rewritten to
use a device creation function for devices that need the mqtt client.
This also fixes a but where hallway_top_light was not actually added to
the device manager.
Due to changes made in mlua the new scheduler is much simpler. It also
had no real business being part of the device manager, so it has now been
moved to be part of the returned config.
The automation:mqtt module now gets loaded in a similar way as the
automation:devices and automation:utils modules.
This leads to a breaking change where instantiating a new mqtt client
the device manager needs to be explicitly passed in.
Instead of being a function it now expects a struct with the
PartialUserData trait implemented. This in part ensures the correct
function signature.
It also adds another optional function to PartialUserData that returns
definitions for the added methods.
Depending on the implemented traits the lua class will inherit from the
associated interface class.
It also specifies the constructor function for each of the devices.
This enforced the idea that all generics must be specified for the type
when using the device macro. It will also come into play later when the
Typed macro gets introduced, as the name will be used when generating
definitions.
Instead of one function that contains all the device types available in
`automation_devices` a global registry is used were each device can
register itself.
Instead of having to call all the module registration functions in one
place it is possible for each module to register itself in a global registry.
During startup all the all the modules will be registered
automatically.
This does currently have one weakness, to need to ensure that the crate
is linked.
Previously this could only be done by implementing a trait, like
`AddAdditionalMethods`, that that has an add_methods function where you
can put your custom methods. With this new attribute you can pass in a
register function directly!
