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!
This time with a bit more though put into the design of the code, as a
result the macro should be a lot more robust.
This did result in the macro getting renamed from LuaDevice to Device as
this should be _the_ Device macro.
The attribute also got renamed from traits() to device(traits()) and the
syntax got overhauled to allow for a bit more expression.
These wrappers can be moved up to where the callback itself is defined
instead of having to wrap the call manually. This also works a lot nicer
now that it is possible to provide multiple callback functions.
ActionCallback now only has one generics argument that has to implement
IntoLuaMulti, this makes ActionCallback much more flexible as it no
longer always requires two arguments.
This can be very useful if you want to convert a data struct to a lua
table without having to write the boilerplane (however small it may
be).
It also adds the macro on several state structs so they can be
converted to lua in the upcoming ActionCallback refactor.
