I have some actions accidentally triggered from Rule Machine by the reboot of Hub, or the reboot of my PI server.
Reboot of Hub:
when hub reboots, some devices' status are reported as if they were not "on", and just became "on" after hub reboot. This is a false trigger. How can I prevent it ? Any best practice ? (like checking the hub uptime ?)
Reboot of PI server:
I have some custom device drivers whose status is received from a custom app on my PI server. Each time my PI server is rebooted, they go down and up and I get false notifications.
Is there a best practice to prevent such false alarms ?
This really is a driver issue, and can usually be fixed very easily in the driver code.
This might be challenging to achieve within Rule Machine. You might be able to use the hub “startup” location event for a RM trigger, and the capture the start up time into a hub variable. Then use that variable in every other affected RM rule as part of a comparison to make sure enough time has passed since the last “startup” to prevent those those rules from running. But, this approach might not work if the device driver are creating events too quickly, before the hub variable can be populated with the data.
When the hub restarts apps initialize functions run and if a device has the initialize capability it’s initialize function will run. If there is code there forcing updates to values of these devices via isStateChange property the issue you are experiencing will happen. From the docs: * Boolean isStateChange- set totrue to force an event to be generated even if the new value is the same as the old value (optional and usually omitted in favor of default platform filtering; button events are one case where it is often needed)
Question - shouldn't initialize only be run on adding a new device? I recently spent nearly 2 months going up and down - and while reviewing logs every day I could see a flurry of Inits right after I unplugged and replugged my hub. Invariably I would get certain devices to start in a state different than prior to the crash. Since the Controller left the building, the mesh, depending on the amount of time passed would go into beacon mode... but the device shouldn't need an Init IMHO. IP devices potentially require new IP's via DHCP, but zw and zb devices ... I can't think of a reason.
As @ogiewon and @ritchierich have pointed out the initialize method is called when the device receives a start up notification and it has instantiated the Initialize capability - it may also be called from another method via code; apps must subscribe to the startup event to receive the notification. Apps and devices have a built in method called installed that is only executed on the creation of the app/device.
that's one way I thought of. But I also thought there might be a better way (like an already known value at trigger time, "value before change")
I understand from your response that this is not available.
So I have to store it myself., OK
one question: does storing a variable have any affect on performance of the hub ?
I'm asking to prevent any unnecessary use.