I have noticed that after restoring my hub from a backup that a lot of rules in Rule Machine stop firing.
I have to go into each rule and select done and then they work fine.
There is no indication that they are paused so there is really not way to tell if they have stop working.
Also other apps like ecobee and IFTTT have to be re-activated as well.
Which in turn will cause other rules not to fire unless they get reactivated.
Again there is no indication they are not working unless you open each of them up.
ok with everything working correctly I first did a hub reboot (without restore) to check it was not the reboot that caused the issues and everything continued to work fine.
Then created a good clean working Hub backup.
Then I did the restore (with rebooting and without rebooting it did not matter) and was able to duplicate the above issues.
I was able to narrow down some causes.
When the restore file was created some devices were in different configurations.
The SmartThings Arrival sensors (2 of them) were present when I created the good clean working backup but when I did the restore the 2 Arrival sensors were not present and did not update to departed.
Thus when they did arrive the rule did not fire.
So really an issue with some devices (maybe be limited to SmartThings Arrival sensors) do not get updated after hub restoring is done. It was 4-5 hours when I noticed it so likely never if not present to send an update like battery status but should really timeout just like when they leave.
So really all comes down to devices not updating correctly after a hub restore.
Devices don't do things on their own, and the hub doesn't either. These automations are driven by events. So if the device changed state compared to a restored db, how is that supposed to be detected? The device doesn't know it, the hub doesn't know it. The next time the device changes state something will happen, a rule may not fire for the obvious reason that wrt to the rule truth, nothing changed.
Such is life when you restore a database that doesn't reflect the current real world situation.
how does the hub know the Arrival sensor has left in regular use?
Does it simply not sense the signal and after a set time set it's status as departed?
If so then after the restore and it has not sensed the senor after a set period then it should change to departed.
Again, the hub sees events. The Presence sensor ultimately tells the Hub, Arrived or Departed, whichever is true. Between, there is nothing. If you leave and return once a day, two and only two events occur. depart & arrive.
The critical word is "ultimately".. because the sensor is based on a technology and that tech may listen or it might transmit. That's up to the "inventor" of the sensor.
The physical device presence sensors all work the same way, they send a message to the hub every x seconds (usually 15 to 20), the driver resets a timer on each one of these events, when that timer expires (due to no incomming events) presence is set to departed.
When the driver sees new messages comming in, it sets to arrived.
That's how it works, however the timer only restarts it self when the device checks in, as there is no need to run it or restart it again while the device is away.
Based on your description the devices shoud have checked in, if they were away when the database was backed up, the restore would have been away in the restore, the devices would check in and change to arrived.
If they didn't do this, then they weren't able to communicate with the hub.
Ah, seems I have the scenario backwards, we will have to think about how to fix this, however whilst probably doable for the presence sensors, it still doesn't account for many other states that were restored but are now not reflective of the current device states.
exactly it would maybe have to be worded
departed x time after (system startup time or last device report time)
So that all arrival sensors did not go to departed immediately after a hub restore.
They would still show present after initial restore of hub but then would time out and go depart if no checkin.
From you initial suggestion (reboot after a restore) could this be the solution to needing to open each Rule and click done? I think that was the original complaint.
My router has the same requirement (that is reboot after updating).
thank you @JohnRob the rules not firing after system restore may have always been simply the different current states of devices vs the state they were in the restore file.
