There is a built in driver, and there is also a user-contributed driver by Denny Page (see my post above for a link). No driver is needed to make it function as a repeater, but a driver is needed so a Rule can detect power fail and also to refresh the status of the power status after a power restore. As I noted in my post above, the Refresh in @dennypage’s driver seems to work from my testing. Also from my testing, the Refresh in the built in driver does not work and has not worked in at least a year, so the systemStart rule’s Refresh will not work at present if you use the built in driver.
Yep, yep. Admittedly, the Ring Extender can be tricky to pair, you may have to try a couple of times. I have always had success using the Classic Inclusion. There’s a thread here in the forum with a post or two from Bryan Copeland about pairing the Ring Extender with pointers and tips.
Ok, you asked. It takes a few rules and a Hub Variable for each Ring Extender (I have 6). If you only use one Ring Extender, you could greatly simplify the Rules, would not need the Hub Variables, and would not need the pair of Rules for each Ring Extender; you could strip everything out and just have a power fail rule triggered by switch to battery of that Ring Extender, and that rule would shut down the Hub after a few minutes delay (before the Hub’s UPS dies) so that, if power fails and restores during that delay, the hub doesn’t shut down.
My rules are a bit more complex, and implement a voting decision by the Ring Extenders, only deciding to begin the shutdown sequence if some fraction (I chose more than 4 of the 6) of the Ring Extenders indicate power fail. This design was chosen to handle the case of a Ring Extender being knocked out of the receptacle when we vacuum or move furniture, or if a circuit breaker trips on one of the circuits, or if one of the Ring Extenders develops a dead battery and doesn’t report power status change. The internal Ring battery is charged while plugged in, but I guess it could fail.
The Rules also handle the case where power flaps up and down as the local utility tries to bring the power back up and attempts to heal the grid by re-routing power around a failed substation or section of power lines. There can be a lot of concurrent re triggering of the power fail events, which is why the Rules are designed the way they are, so that one Ring Extender’s flapping doesn’t affect the logic of another Ring Extender’s flapping.
I use a Custom Action to Dominick Meglio’s Hubitat Hub Controller driver to do the actual shutdown.
Rules
The Power Fail rule handles flapping of the power up and down before the final fail. I've put a lot of thought into the concurrency issues, and none of the power fail rules have conditionals, and can handle retriggering.
There is a pair of similar rules for each Ring Extender to maintain the state of each Ring Extender for the voting power fail:
Here are the Hub Variables that are used by the voting power fail:
And here is the System Start rule that initializes everything:
Now that I look at the power fail voting test months after writing the Rule, I realize that the “IF failedRingExtenders > 4” conditional, which enters the power fail section, should probably also have an OR to test if the Ring Extender on the Hub’s mains circuit has failed so that the power fail section is entered, regardless of voting, if the Hub’s mains circuit has failed. I will have to fix that when I return to town next week.
Enjoy.
