OK so we agree it won't be possible to have everything be perfect after power is restored. Perhaps it could at a minimum at boot time run the transition from the previous mode to the current correct mode based on time of day. That would probably set the system up in the correct state for a large percentage of devices and cases? im probably hugely generalizing and will no doubt get shot down, but something needs to be done so human intervention is not needed.
I have read all of this posts and I ask myself.
What we are really looking here is in fact a simple thing. No?!
When there is a power outages all my rules work as expected except the sunset/sunrise for a couple of hours
So it seems yo me that the really issue here is basically because there is a need for the hub to due a validation check routine on boot. Not on what it should had run or not but rather on:
- what timestamp is now. Is my timestamp correct? No then update.
- is my sunset/sunrise definition correct based on the updated timestamp and location? no, than update.
- is my modes set correctly based on timestamp and sunset definitions? No, than change to appropriate mode.
- Are there events that require to run on boot? Yes, than run.
Thats all is needed to fix this discussion IMHO.
I just have a small doubt what happens to the hub internal clock in the event of a power out does it have a battery built in for the clock or it will loose the time definitions?
2 Likes
I'm looking at a pressure mat under the mattress for this.. just got a mat and will test over the next few days 
2 Likes
I completely disagree with your point and stance.
Automation during normal operating regimes and recovery from abnormal operating modes are not the same thing, the same discussion, or even the same actions (for many people).
I do industrial automation for a living, and have for decades. I know first hand the unintended consequences of automation gone wrong during abnormal operating scenarios, and the security and safety of failing to a known safe position while waiting for a human to verify and reset states.
I guess we will agree to disagree. I hope the system can meet your needs in the future.
If every automation was as simple as do this at that time then you'd be right, but many users have rules that do something at a specific time based on some other condition.
If that other condition uses devices and the state of those devices is out of sync, executing the action at that time could cause new problems.
Completely agree on that.
If pre-conditions are not met than the rules will not run.
My suggestion are NOT the holy grail are suggestions that will return most use cases to normal operation conditions.
After a power outage in an ideal world the hub would notify the user on boot.
This can be easily achieved. By logging every last shutdown/reboot issue through the system and removed after the hub is online.
The only thing that you would need to do after is a double check. At the start of initiate you would check to see if the shutdown flag is present if it is run as normal and at the end of the bootup sequence remove it.
If it is not present after the boot up notify the user through SMS of pushover that an abnormal power cycle occur and that admin intervention is required to perform a health check on the system.
1 Like
Was not aware of this...
WOW! I used the information provided, cranked up a Trigger. On system boot, turn on "normal", a virtual switch with auto off set. Hit the settings page, safely rebooted the hub, and as far as I can tell, the system went back to where it should be. The biggest indicator was that the wife had just told Alex to "go Bright" so she could open a bag of cat food and feed the cat. Reboot occured, and the lighting levels all went back to where they should be during the "evening mode". It is my belief that if the hub knew what mode it should be in, then all other automations that I have created in RM would be able to restore the house to it's proper STATE.
I should mention that the normal switch existed prior, and exists in 4 states, day,night,evening and away to set things as they should be per mode and time of day. (and temperature, etc... sort of, well, normal!)
2 Likes
Another thing to keep in mind ...
After a power outage your hub will probably start up faster than your devices.
In my house after a power outage my ZigBee devices alone take a while to connect back and fix the mesh. The hub boots faster than my wifi switches, blinds and outlets too. I never looked at how zwave reacts.
That being said, if it were to try recover after a power outage it would probably fire off a bunch of commands to devices that are not yet ready.
I thought about doing this too but the logistics just got to be a pain.
it was a logic check, I learned something. I do not expect my telcom stack to suffer from a power outage. APC UPS 650. If it dies, so be it, it is already at least 10 years old. I had one that was hooked to my house batteries (fork lift batteries, charged by a 10kw NG generator controlled by a Trace 4024 inverter, with no grid intertie) and the P3/1000X2 with quad LCD monitors showed at least 2.5 years of up time between reboots. It did make me question if it was going to work, as it took a long time to reboot and complete the "normal" Rule. The rule included 1) directly connected Hue Bulb, 1) Inovelli dual switch, 3) channels of a Zooz power strip V2, 2) Lowe's iL03 Zigbee switches, off of the top of my head. How does one keep track of the logic of the system? Seperate topic to be sure.
Long thread just for a power outage 
Some good ideas here. I'm sure some good options could come from them. I do agree that they should be options though. If the power goes out, I think it's perfectly reasonable that the hub should continue on at the next event based on whatever trigger is responsible for that. And for sure, I don't personally want the hub to try to pickup on some event that's already past, such as, my phone has arrived (when it's already there) so unlock the door. Please don't.
In regard to no means of physical control. Wow, I couldn't disagree more with that concept. Manual overrides are very important. How you choose to do that is up to you, but the best design should include them in some form. In my home, Zigbee lights are controlled by Lutron Connected Bulb remotes (which pair directly with the bulb, but the Hue bridge can still control them), or via physical control of a smart switch. The one set of lights that are controlled by a Hue dimmer are on occasion an issue when the Hue Bridge is unresponsive. Rare, but I definitely hear loud and clear when it's not working. I do have a Pico on that same fixture, but if the Hue bridge is not working, there's no way to turn them on (other than unscrew the bulb and screw it back in). I live with the consequences of that decision for the convenience it provides.
All other lights in my home are controllable by physical interaction with the smart switches. I do have one floor lamp that is on a smart outlet, but it has load sensing capability. So even if I can't control the outlet with the hub, I just have to rotate the lamp switch off and back on and that turns the outlet on. The one lamp that I have on a plugin module isn't a primary source of light, but if I want to manually override, there's a switch on the module. Of course you can always plug lamps into a socket directly. This works regardless of whether or not the bulb is smart.
4 Rules, all triggered by the VS, restricted by mode as to what one actually runs.
After getting through most of this thread and how it has moved to different flavors of topic I would have to agree overall that Mode Manager on initializing should attempt to determine what mode it should be in. Keep in mind only if time based then determine based on the time parameters.
1 Like
