Well, I think that's the key phrase. What is appropriate for one user isn't appropriate for another user. Maybe that's where the $20/mo comes in - having someone remotely setup what "appropriate" is on their individual hub based on their needs :).
Outside of trivial functions like "re-poll all mains powered devices on power restore" (which can be done in RM or a simple app - in fact I think there is already a user app out there that does this) this is not an easy thing to do in a universal way.
It sounds like a cool application for one of the community developers to write. A power recovery app that could be configured with check boxes and pick lists and an endless plethora of suggestions of what "needs" to be added. It could make a developer "famous" LOL
1... 2... 3... NOT IT!
lol
A clear example of PEBCAK!
More or less. “Problem Exists Between Chair And Keyboard.”
Interesting thread, thanks for all the posts. As a long time HE user (2+ years) and as a user who lives in an area that gets 2-3 power outages a year, I don't understand what is happening with the hub after the power is restored that is undesirable. I have 100 plus devices (Zwave, Zigbee, and Lutron) and many automations (35 RM, 8 SA, 7 BC) and I never have an issue after the power is restored. Obviously my hub doesn't work when the power is off, but it works great once the power is restored. What type of automations are people running, where a power failure causes undesirable effects once the power is restored?
Don't knock those 
. I have a whole bunch of those powering USB repeaters. (I don't have bulbs/plugs in HE and use HE almost exclusively as a sensor/end device hub and to run quite a few, but not all, my automations) This allows me to keep all (or as many as possible) those sensors that don't play well alive, as well as continue to have the security part of HE going or as long as possible if there is no power.
That said what would be nice is a piggyback UPS/battery backup that uses the same case as the hub that the hub can sit on top of. It's not to difficult to make one my own but having one with full software integration would be great.
I'm less concerned with device states (mostly as I don't have that many devices to control, relatively speaking, as I see no need to automate everything in sight, have no need for scenes, etc.). Worst case I can use my dashboard to reset any errant lights.
Always a risk, although with google I would never go all out with them (being notorious for discontinuing products with little notice/regard for users or making changes that completely break functionality (and ignoring user feedback)). We've all seen when google buys something what's likely to happen.
You already have one - it's called a key 
.
Actually in all seriousness I have considered a UPS for only 1 external device and that's for instant gas hot water heaters. In a power failure, no electricity = no hot water = no shower. 
I don't think the problem is exclusive to HE. Any hub that loses power is going to experience problems. My "tested" solution comes from using two Hubitat hubs. One for critical devices that must function regardless of power conditions. That hub has no repeaters. All devices are sleepy end devices. Less critical devices such as lighting are on the second hub which have repeaters. After power is restored all secondary devices usually all come back without intervention within 5 minutes or so. Once in awhile a zigbee light may need to be power cycled. All minor problems. Anyone that uses their hubs for security related operations should consider a two hub approach.
For Zigbee, power outage may cause issue involving Zigbee mesh consist of Zigbee router which is not power backed up (majority of Zigbee router is main powered) and a lot of battery powered sleepy end device.
In the event that you have power outage, all your sleepy end device (mostly will be battery powered) will hunt for a new parent. In Zigbee, a sleepy end device require a parent which is either a hub or a router. All sleepy end device that can reach your hub will try to associate to the hub since they will still run on battery. This can easily fill up the hub with the assumption that all your router is down at this point. Remember most of Zigbee routers are main powered. Some of Zigbee end device will just loose out.
The question is what happen to the devices that cannot find a new parent. In some of Zigbee stack, a sleepy end device will try to hunt a new parent for only a period of time (not forever). Hunting (re-joining) for a new parent is expensive for power consumption. That timeout is there to conserve battery. For these Zigbee end devices, they will not re-connect when the power is (or your zigbee mesh) back up. You most likely to press some kind of button to reconnect your impacted device. Some will want you to unplug and plug back the battery. In very rare occasion, some device need to be repair. In my observations, this scheme is neither majority or minority.
Personally, I also own device that will re-attempt with out any timeout. This is not a prudent approach as it will drain the battery during the power outage.
I think if you are running something critical with Zigbee it would be prudent to make sure some of your Zigbee router is backed up as well especially in large Zigbee mesh. This issue, in my opinion, is not limited to specific brand of hub. It is more of an implementation issue.
As a note, this is not an issue when you have short term power outage. Most implementation with time out is quite generous. It is not an issue for a power blip. This issue is typically when you are experiencing power outage in hours or days.
Now that's an answer I can respect and appreciate.
Meanwhile, back at the ranch...people continue to construct a diverse array of "trusting applications" for your box and its' supported devices (whoops dating myself again, I mean "Use Cases" ).
Take this one for example. A noble goal to avert water damage including from residual pressure in the line IF I read it right.
Again, if i understand it correctly, ....it very much seems this configuration could cause a whole heap of trouble if "states somehow got lost" for whatever reason. Negative Outcomes: valves opened when they were supposed to be closed, etc.
EDIT: OK, Chub elaborated so I retract this case-in-point. Single valve in play here. Nevermind kids. Keeping the post in place so y'all can beat up on me
Just sayin - I didn't see a warning label when I unboxed my HEs. What was in the box was a whole lotta excitement for what folks can achieve in their environment under some presumption of functional reliability. And then you gradually learn the tenuous nature of that assumption.
The valve that dumps the water pressure is the same as the valve that shuts off the water.
As you turn it, it goes like this:
So, worst case, I lose 5L of water in the pipes of my house. If it keeps see-sawwing back and forth, I'll keep losing 5L I guess. Anyhow, at present, this valve isn't even installed anyways (kindof explained what it will EVENTUALLY do). The old Leaksmart is soldered in place good.
Perhaps you should define terms here.
The power goes out while a time-critical action is pending (did the power going out represent a failure of functional reliability?). Just what does reliability mean in this context? When the power returns, should the hub perform that pending action (whose time has long past)? What if performing that action past its time is exactly the wrong thing to do then? Does reliability mean the hub should gracefully figure all of this out, when whoever designed the automations failed to do so?
From the beginning, this topic has rested upon flawed logic, and then built on it.
The simple fact is that there are problems for which there are not simple, convenient, "obvious" answers. There is non-determinism in the universe, and it affects everything based on some form of deterministic logic. How to recover from a power outage in a home automation system cannot be determined without the insights and automations a user puts in place to do so, and that fact does not represent a lack of "reliability". It's amazing how expectations of this hub can be so unfettered from reality. If wishes were horses...
I'll admit I am responding without having read most of the posts here.... but hey, that shouldn't stop me should it? 
I see my HE hub as a tool in my HA setup, yes it may currently be the "brain" in that setup and so has a heightened level of importance, but it is still part of a larger set of hubs and services that contribute to automating my home.
As one "tool", I expect the Hubitat platform should keep it's own house in order when things go wrong, but anything I have setup or configured (including Community apps or drivers) are my responsibility when ensuring they resume in the state I want. That responsibility may extend to asking the developer of some custom code to ensure their code handles particular situations that can occur for me.
Another consideration is that incidents that can occur for me may not be common amongst other HE users, so requests for Community developers or Hubitat staff to accommodate these may not always be the highest priority when looking across the entire user-base.
I would suggest being mindful of how much emphasis you place on HE (or any hub for that matter) to handle things like a power outage. Wherever you can, I think it is wise to make any IT setup nimble and able to respond to change. While we all want to promote the use if HE and their services, as the architect of a HA system you want to make sure you can easily transition even small parts of your system to an alternate solution if it is a better solution or a better fit for your situation. This is a large can of worms with so many different topics inside....
The last point I would make is to pay credit to @jshimota, we all have moments where we want to post our frustrations, bright ideas or something in between. Kudos to you for taking the time to reconsider your position from the OP and take on board the points raised in the initial posts.
Simon
The one thing that HE could do that would go a long way to making things easier for the end user to set up their own restoration implementation would be to add an internal battery backup. Depending on the power requirements, I’d assume a couple AAs or a 9v should be able to power the hub for a decent amount of time, possibly under a “power saving” mode that would limit certain features (allowing shutdown option, RM to run, but not be editable, disable adding devices/apps, etc.).
This would eliminate the need for external components to manage a power outage, the hub would know when the (assumed) power outage occurred, and how long it lasted. It would know how much power was available in the batteries so it could estimate how long it would be able to run until it needed to shutdown (and could alert the user when they need to be replaced). Add a trigger to RM, and possibly a built in shutdown/restore app that the user could configure to handle the power outage separate from a normal shutdown/startup, including saving a current backup and allowing the user to authorize a restore from that backup in case something went wrong. If the power is restored during this event, it would reset and continue as if nothing happened.
This would most likely change the footprint of the hub, I have only used a C7, so I don’t know if this is a design constraint to keep them the same size or not.
You're right, the circumstances, assumptions, and intentions may be more complicated as time passes after that power outage. And yes, designing your application without thinking how to bolster reliability by considering the "what ifs" is a recipe for disaster. Lest we forget that these relatively low priced devices often don't help things.
Aside: ( Maybe it would help if every device design allowed for an unmistakable parameter available in every driver called, hummmm how about, "Fail-Safe Mode(State)" whereby the implementer could configure device behavior for/when/if/after everything it normally depends on has gone awry and it otherwise feels lost & lonely. And maybe if HE can't figure out where things should pick up after some event, maybe it tells everything, or some things to go to Fail-Safe if the devices don't go there on their own. And maybe that should have been apart of the ZigBee/Z-wave spec. I donno.)
I guess at the end of the day there are reasonable and market leveraging ideas that could improve your part of the reliability factor, however one defines it. But you are ultimately right, without a lot of redundancy and intentional design on the part of all of the working parts ...the road from 89% to 99% is a long and expensive one.
We know you guys are constantly mindful of what can be done to improve on this within the context of your platform, and the response is getting better when your supporters offer some (often reasonable) contributions to the brainstorming. While some of the ideas might not have been a direction you had wanted to go, some of it might actually help you expand the market for this box.
Once people are beyond the "gee whiz" phase of Home Automation I think they WOULD pay more than what this HA hub is currently priced at.... IF..... it's advantage over the competition included a lot of what we've been talking about in here; including battery, power sense hardware, and software facilitating Fail-Safe configurations as you have done for yourself.
And we know the $100 scale UPS is not necessary, and yes the subscription would likely be acceptable but only if it expanded on and included everything else Hubitat just offered in the way of improving reliability.
Recollect one of those rare times in electronics history where you've opened up a device, used it for a little bit, and gone...."wow, they really thought of everything in designing this" (even though that is never the case). But yeah, that feeling.
Just as an aside, are we in the Lounge ? Eh, I'll say it here anyway: I am increasingly astounded at how often people consumed with other things in life & occupation will hire out/purchase/or otherwise avoid rolling up their sleeves to do/make some of the seemingly simplest of things. I'm not talking labor intensive as much as just taking a little time to figure out that A+B will result in just what you want to do. It seems time is the most valuable commodity, and perhaps a concern that you won't do it as well as somebody else in the time you spend. Not exactly the same context, but, can you imagine trying to explain "the market" for a cookie delivery service to your Great Grandmother. Dare I say Apple would not get to charge what they charge for their devices and at the same time have the market share they have today if there was not truth in this.
I'll be the weird voice here.... My Samsung hub had battery backup.... I never even put batteries in it though, as I prefer to use an external UPS that I can monitor the status of. I don't like "idiot lights" in cars either, though.
I'm not interested at all in a hub having built-in battery backup any more than I would be a desktop computer or server or router. Some things are simply better served with purpose built devices.
And since I don't like paying for features I don't use, any more than I have to, I would obviously prefer they didn't add this unless it was a bolt-on / plug-in module that I didn't have to buy/pay for if I didn't want it.
Anyway, we are in the land of opinions now. And there is room for multiple of them that are different. I'm not trying to change anyone's mind, just providing another data point.
But your solution to this situation offers options, which is my point as well, I don't mind having options, even within a product that may be part of a larger setup requiring protection, but if it was all I had, then having an option to protect it alone, then it would make sense for me, but like you I don't want to pay for it unless I need it.
I agree.... however, there is one exception IMHO... I would really like for the next iteration of the Hubitat hub to have a battery backed up clock, just like my PC motherboard. It would be nice if the hub was able to boot up from a power failure and already know the correct date and time, without the need to perform a NTP time synchronization immediately at boot.
Download the Hubitat app
