How Could A Spare Hub Be Used For Graceful Shutdown And Power Cycle?

I just had a brainstorm about using my spare C7 hub to do a graceful shutdown and power cycle on my 'production' hub.

If the main hub senses a problem that it can react to, like a Z-wave crash or permanent Zigbee outage, or whatever, it could tell the 'backup' hub to shutdown power to the main hub after it gracefully shuts down, and power it back up after a minute via a Zigbee or Z-wave smart plug.

Would hub mesh have to be used for the main hub to tell the backup hub to run the power cycle rule?

If that would work, I'd have to figure out how to safely run two hubs at a time: reset radios, soft reset, different channels(?), etc.

My hub is running off a battery. I'd have to figure out a Zigbee or Z-Wave arrangement for that. I wish they made one in the WIFI form factor little plug that is available, but alas, I think not.

Not sure you would need to design such a system, rather than trying to make the system itself more resilient, but I guess everyone's setup is different...

You may strike problems using a Z-device if it is that mesh network that is having the problem. The Kasa kp115's are a relatively slim model, though I expect now you will need to find a tapo equivalent.

3 Likes

How do the two hubs that are 'meshed' communicate with each other? Wouldn't be over the lan vs zigbee or zwave? If the smart plug was paired to the backup hub, it would be immune to issues with the main hub. As long as it wasn't messed up enough that it could get a message out.

Then again, couldn't the backup hub monitor the main hub's vital signs in some way, and act accordingly, as in power cycle the main hub, if the main hub wasn't able to do a graceful shutdown?

My battery is currently powering the hub via a USB cable. I have a WIFI smart relay already, that is USB. It looks like the picture below. I'd like one in Z radio.

Implementing such measure can create more problems in the long run, especially with devices that may be on the outer edge of your either mesh.

When the hub comes back online, devices will scramble to reconnect. Some weaker devices may not be able to reconnect at all, so your rather healthier mesh could behave worse.

A different approach could be to isolate the troublesome devices and either stop using them or move those on the spare hub.

That way your production will continue to run happily uninterrupted for many weeks and months, while the spare can have hiccups without bringing your FAF* down.

*family acceptance factor

4 Likes

Well, stopping using the offending devices would mean stopping cloud backups. Just kidding, but that caused the only Z-Wave crash I've had.

Graceful shutdown and power cycling of a hub is the generally accepted gold standard. Merely rebooting doesn't make it in many cases.

If the main hub is still coherent, like one or both of the Z-radios crashed, or memory got super low, or some other malfunction, it could easily be made to reboot itself. But not power cycle.

Autonomous power cycle with graceful shutdown is what I'm trying to achieve.

No no no. Can not change it from WAF. I resist. Lol.

2 Likes

WAF here is inversely proportional to KEN (kids emitting noise). So FAF accounts for that anomaly. :slight_smile:

4 Likes

:crazy_face:

1 Like

Everyone's been very helpful.

I think I found a way.

I broke out the old C-7, assigned an address in router, reset radios, soft reset, assigned zigbee channel to 25 (other hub is 20).

(Side note: It's kind of fun playing with what feels like a new hub. Plus no consequences on a screw up.)

Added a Z-wave smart plug.

Created a rule on the C-7 to toggle the smart plug with a cloud end point as the trigger. Copied the url.

Created a RM rule on the C-8 to perform a GET action on that url.

Ran action, and it worked! It toggles the switch.

I can't use this capability, yet, because I have to switch the 5volt usb feed from the hub's backup battery, but I don't see that as insurmountable.

This would be good to go if I didn't have a backup.

The initiating rule on the C-8 could be Z-wave crash, permanent Zigbee radio outage, etc; anything where the C-8 was still 'conscious' and communicating. It could send out Pushover and Chime/Siren notifications, send a command to the C-7 for its own delayed power cycle, and then perform a safe shutdown.

I don't know how to have the C-7 ping the C-8 for signs of life, but maybe I'll find out about that too.

edit: Plus I have a nearly cherry hub to play with.

I changed it to Local End Point, which makes more sense.
No cloud involvement, plus faster.
I don't know what I'm doing. :slight_smile:

1 Like

I figured out to test for a ping=false on the C-8 from the C-7.
I think I could figure out how to send a shutdown command similarly with a GET, in an opposite direction to the previous. Only now, things could get dangerous, lol.

How about that, I shutdown the C-8 with a POST command with private Boolian related to PING set to FALSE to test. Pretty wild.

Now I have to power cycle the little WIFI plug. Again, sure wish it came in Zigbee flavor.
Tuya, are you listening? :slight_smile:

I wonder how often it should ping the C-8?
I have no idea. Don't want to get too chatty.

I'd look at the once every 5-10 minutes range

1 Like

Thanks.

Would something like this Repeat action work?

Do you ever set the boolean to True?

I refreshed the page after removing the Set Boolian.
Nothing happens when True, which is a good thing.

You are sending the shutdown when the boolean is false, which is currently the state of the boolean, i.e. the (T) [TRUE]

That's true, but it doesn't make sense to me.
I'll have to ruminate on it.
Hopefully the 'production' hub won't get shut down, lol.