Last night as I degraded my hub in an attempt to solve a newly induced problem - I did a restore of the hub DB to a previous version.
To my surprise - the Mode was wrong and said 'Day'. This could be a bug or problem.
obviously I manually changed the mode and went on my merry way but I felt it might be important enough to report. maybe the beta test team could check it and add to their QA test set.
What mode was the hub in when the backup was taken?
5 Likes
To @marktheknife's question... when you do a restore the mode will be what it was at the point the backup was taken.
2 Likes
The mode at time of back was indeed Day. The restore time was 'Night'. My expectation is once a database is restored, a step of the restoral process would be to run the internal rules and checks.
I've watched HE staff describe the recovery from a power outage - I expected the restoral process to use the same validations - like checking the date / time etc.
I can confirm from being tripped up by that many times that it does not do any re-validation. You'd think I would learn. Nope.
2 Likes
From what staff have said, the hub does not “look back” to see what it has missed in the event of a power loss. And the logic here is the same, I believe.
Mode changes are driven by events, like anything else in the system. So the hub knows what time it is when you restore from a backup, but whatever event would have changed it to night mode, it can’t do anything about, because that event occurred after the backup you took. It doesn’t know it missed the event.
2 Likes
Perhaps as a work around, you could have a startup rule that selects the proper mode.
2 Likes
Oh I like that idea.
I have created a rule that runs actions for a few rules that I want checked to ensure they in the correct state on a systemstart event.
Mode check is one of them. (I do not use mode manager BTW).
1 Like
@didymus it's a logical workaround. But I don't think it really speaks to the point here. We, as the community, provide feedback on things that trip us up so as to help HE make the world a better place. Expecting ma and pa kettle to write a rule after installing their HE hub seems to be a big ask - when it seems obvious that after a DB restore you validate certain critical functions such as mode, date, sw/firmware version variables, date of last restore/date of DB etc etc.
Not everyone is a programmer - I know, I know. This is DIY and not ready for the real world but it's getting close!
1 Like
@bobbles
wow. okay. thats interesting! do you set your own variables? can you screen cap your actions so we can see?
I have lighting variables that are set depending on what mode the hub is in.
As said above I also use RM to set my modes as I just find it easier that Mode Manager.
On system start my RM rule checks a few rules to ensure heating is in the correct state, modes are correct and lighting variables are correct.
I also have another rule that checks and sets NTP.
1 Like
I believe the response to this would be similar to what staff have said before re: power being restored after a blackout.
How can they decide for each user what the hub should “catch up” on vs. not?
My automations based on mode changes aren’t the same as yours, or @bobbles. Maybe I don’t want the hub to update its mode automatically, triggering all manner of automations inappropriately, even if you do.
2 Likes
I see your point MTK but again - I say - somethings need to be reviewed. Modes are an HE internal function- not rules. Rerunning rules after a reboot may or may not be smart but checking the mode should be a default.
By your logic, setting the date and time is wrong too.
Heck no.
That only works if your modes are based on time of day or some type of periodicity. I have modes like:
Visitor
Housekeeper
Cat Sitter
I don’t want my Hubitat to decide what mode it should set upon restoration of a backup.
4 Likes
interesting - aren't those 'Scenes'?
No they are not scenes. They are modes that determine a variety of things:
- Which rooms respond to motion lighting and which ones don't
- Lighting level during motion lighting
- Thermostat comfort profiles
- The sensors used to determine thermostat set-points
And a multitude of other things. Each of us uses modes in a different manner - there is no one shoe fits all ....
3 Likes
I disagree. I can’t think of a rationale for the hub to keep an incorrect time after it boots up (whether from a prolonged power outage or restoring a backup).
Modes are different, and as I (and @aaiyar) are trying to stress, entirely individualized to each hub owner.
If you want your hub to always check and update mode on hub startup, @didymus’ suggestion makes sense.
2 Likes
Any rule you write you need to think about what happens if the hub is rebooted or shut down. Some it doesn't matter but some it does.
For example we had a power outage that lasted several hours on Thanksgiving. The power went out at around 2:30AM and came back on around lunch time that day. I have my hub on a UPS but it ran out because it was off so long.
After things started back up I kept noticing my outside lights coming on when motion was detected on the cameras. The hub lost power when the expression was true and came back online after it should have been set to false. Since it missed the sunrise change the rule to turn on outside lights at night was still running.
3 Likes
