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.
This also results in the conversion being performed when the
ActionCallback is instantiated instead of when it is called, this should
make it easier to catch errors.
The environment variable `AUTOMATION_CONFIG` has been renamed to
`AUTOMATION__ENTRYPOINT` and can now also be set in `automation.toml` by
specifying:
```
automation = "<path>"
```
Directly accessing the environment variables in lua in no longer
possible. To pass in configuration or secrets you can now instead make
use of the `variables` and `secrets` modules.
To set values in these modules you can either specify them in
`automation.toml`:
```
[variables]
<name> = <value>
[secrets]
<name> = <value>
```
Note that these values will get converted to a string.
You can also specify the environment variables
`AUTOMATION__VARIABLES__<name>` and `AUTOMATION__SECRETS__<name>` to
set variables and secrets respectively. By adding the suffix `__FILE` to
the environment variable name the contents of a file can be loaded into
the variable or secret.
Note that variables and secrets are identical in functionality and the
name difference exists purely to make it clear that secret values are
meant to be kept secret.
The function `new_mqtt_client` was the last remaining entry in the
global `automation` table. The function was renamed to `new` and placed
in the new `mqtt` module. As `automation` is now empty, it has been
removed.
Previously the fulfillment config was set by setting
`automation.fulfillment`, this will no longer work in the future when
the global automation gets split into modules.
