Actions accidentally triggered on Hub reboot

Hi,

I have some actions accidentally triggered from Rule Machine by the reboot of Hub, or the reboot of my PI server.

  1. 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 ?)

  2. 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 ?

Rebooting HE should not generate false status/attributes updates from the devices.

If there are any Tuya or Aqara drivers that behave like this, let me know and I will check.

I'm assuming they are WiFi or LAN devices?

Some Zigbee and Z-wave device drivers may also improperly declare the Initialize capability and may misbehave after a hub reboot.

1 Like

they are not zigbee/zwave.
Mostly custom drivers working on IP.
My question is not about fixing drivers/apps.
I'm asking if there is a way to ignore the "hub restart" case on Rule machine.

1 Like

Rule machine doesn't just run on hub restart unless you specifically ask it too.

So you question is actually about this. You must have a rule which lets say fires on a "ON" event and the driver or app is incorrectly calling that when the hub reboots and the IP connection is made.

So you need to look at the rule which is being called, look at the trigger and then look at the driver or app and see when that is being called.

2 Likes

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.

3 Likes

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)

4 Likes

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.

4 Likes

I was asking a generic question but when I ask it that way, it is not understood correctly , so let me explain with a specific and real example:

I am using the following integration with my PI server and a UPS:

This driver has several states for the UPS.
Online and "On Battery" are specific states.
But when the PI is rebooted, Hub can not reach the app on PI.
So the driver reports state as "unknown"

I have 2 rules on Rule Machine.
One is for when the UPS is activated (state != Online & state!=unknown)
The other rule is for when the UPS is deactivated (state==Online)

The second rule is activated when state comes from "unknown" to "Online"
But I don't want this case to be reported.

How can I check the previous state of the UPS in Rule machine when state has changed to Online ?

Local or hub variable? Could store the state of the device in a variable then next time it runs use it as a condition before it gets updated.

1 Like

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.

No even less than changing a device from X to Y.

There is a option of "stays for X" would that work?

yes that works for going to off.
But does not handle the case where a notification is triggered on going from "off" to "on"

anyway, I'll use a variable then.

thanks.

There is a better way, I believeā€¦. See the RM documentation section below, about using a required expression.

Your Required Expression would be ā€œNot ā€˜Unknownā€™ā€

3 Likes

ok but I don'T see any place to put that. Where is "required expression" ?

4 Likes

thanks. got it.
well I don't understand why I didn't even see it.

1 Like