How I reboot my Z-Wave radio remotely (Since the Hubitat lacks this capability)

Maybe someone will find this helpful. The Z-Wave radio on my Hubitat C8 Pro fails once a month on average. It does this without any logs showing that it is down. There is no way to reboot the radio without power cycling the Hubitat. I think this is just a terrible oversight in the design of this product, but that discussion is for another day.

My solution: I installed Hubitat Hub Controller (you can find it in package manager). I purchased a wifi smart powerstrip that connects to Alexa directly via WiFi. I then created a virtual switch on the Hubitat which Alexa can control. I wrote a simple Rule Machine rule that is triggered if the virtual switch turns on. That rule then sends a shutdown command to the Hubitat Hub Controller. I had set the switch to automatically turn itself back off after 1 second, but this doesn't seem to work after the hubitat gets the shutdown command, so instead I wrote another rule that turns that switch off when the hubitat boots up. I'm sure there's a more elegant way to do this. I then created the following routine in the Amazon Alexa app:


I deliberately obfuscated the name of the switch in the Alexa app so that it can't be accidentally triggered if Alexa mis-understands something (this has been a problem in the past).

3 Likes

I got around the switch reset thing by just telling the rule to wait for it to turn back off. My rule is a little bit different though because I have a multi-hub setup, so this is installed on my C-7.

2 Likes

Brilliant! Thank you, I am going to implement that.

1 Like

I think you can also use the location event: Z-Wave Crashed to trigger your rule.

I am planning to setup a rule that will do this, and then my main hub will pick-up the virtual switch to reboot the Radios hub. The first half is done, and I will likely implement a copy of your rule for the second…:

1 Like

This is another great idea, thanks. The only potential issue there (in my case anyway) is that very often my mesh will go down, but the Hubitat will pretend that it didn't :stuck_out_tongue_winking_eye:. I'm not sure if the blame for that goes to my mesh, the Z-wave standard, or Hubitat.

1 Like

That might be a problem then! I wonder if @thebearmay’s Hub Information Driver would detect it if that happens?

Will be giving this a try… Note that I didn’t enable the automatic reboot yet - will first want to see if and how this works. :blush:

2 Likes

These are great suggestions. I have a matter smart plug inside Apple Home but was doing this in two steps (manually shutting down Hubitat and then manually power cycling the smart plug). This is so much better. Although in my case I had to split the automation into 2 (the Hubitat shutdown sequence in Rule Machine and then a power cycle automation in Apple Home) but it works.

I use this for zigbee. It's not the real solution however. The real solution was to find the errant device that causing the crash and replace it. I had this rule because of bad plug causing the crash. Once I located it and removed it, this rule never triggered again.

3 Likes

This ... :point_up:

@acr2001 - subject for another topic, but have you ever engaged the community or HE staff about solving your repeating issue?

Yes, I have engaged both the community and the HE staff multiple times. They have been helpful, and I have done many things to reduce the terrible bugginess of Z-Wave. For example, I was able to remove ghost nodes with a z-wave stick since Hubitat couldn't handle that (this was at the very start years ago), disable encryption on my S0 devices, and so on. At this point it's pretty solid except when I have a power outage. I have over a hundred z-wave devices, so I wonder if it's just too much chatter when they all lose power and come back online. The Hubitat is on a battery backup along with my network, cameras, etc.

I think this needs some logic to prevent a reboot loop from potentially occurring. Otherwise looks like a good idea!

Just add a delay as the first action to provide time to disable the rule if necessary.

That's too easy. I like to make my life complicated :sweat_smile:
Maybe set a boolean variable to 1 if rebooting due to one of those failures, and then a delay to reset variable to 0. If it reboots and it's still a 1, it could avoid a reboot and just send a notification saying the error persists. I'm sure there's an even better way.