function: variable_set
parameters: service (string), variable (string), value (string), device (string or number), [startup (bool)]
returns: nothing
The UPnP service+variable will be set to value for device, which if it’s a string, is interpreted as a udn, and if it’s a number, as a device id. If there are events or notifications tied to the variable they will be fired.
Optionally, you can add an argument ‘startup’. If startup is true, this change will be considered a startup value, and if the variable is set to it’s existing value, events and notifications will not be fired.
So when setting variables (like armed state) during plugin initialization the startup-parameter should be set to true. This will supress notifications to get fired.
This has been noted before in the context of other plugins. Contrary to the documentation, the extra parameter to luup.variable_set() doesn’t prevent the repeated-event situation; it only serves to delay the repeated event until you inevitably later call the function with false for that parameter.
TL;DR: repeated events are sometimes unavoidable. Where possible, make your scenes idempotent so that the repeated event doesn’t matter.
That is not good. So there is basically no way of initializing variables without triggering events tied to them?
Will the event fire twice the next time the variable changes or what do you mean by “later”?
If it fires twice (when it should) I still think this is a better behavior than fireing the event when vera restarts which could be at a random time of day.
It could be hard to make some scenes idempotent in some cases:
A scene runs when house is armed which turn off all lights.
At sunset some lights is turned on automatically.
VERA RESTARTS
Now all lights will be turned off because scene (1) will run. I could of course check that it is before sunet in scene(1) but in more complicated cases this could be hard to do.
There is nothing ‘faulty’ or ‘buggy’ about this. It works as designed and according to the API.
What happens at a restart is that a download is started on the panel. This changes the DetailedArmMode from ‘Disarmed’ to ‘NotReady’. After the download completes it becomes ‘Disarmed’ again. Just look at your log.
If you want to check whether the panel is armed or disarmed use the ‘Armed state’ notification (ArmMode variable).