I may have some code laying around that could be adapted fairly quickly… 
1 Like
Oh... that's not what I had in mind at all....
2 Likes
Thinking that the flow would go something like:
- capture crash event
- send push notification
- call external hub endpoint (RM or ??) - which should have a 3-5 minute delay built in - to cut / restore power
- send shutdown command to hub
Or just flick a switch in the first instance, others can deal with it how they wish, or a separate app (that you could develop if you want) can deal with the switch turning on however it chooses.
2 Likes
That’s even easier, as the switch could be the trigger to both the hub shutdown and be monitored by the external hub to initiate its actions.
Edit: Code to set switch assuming it’s a location event:
Code
/*
*/
static String version() { return '0.0.0' }
definition (
name: "Zwave Crashed Switch",
namespace: "thebearmay",
author: "Jean P. May, Jr.",
description: "Logic Check .",
category: "Utility",
importUrl: "https://raw.githubusercontent.com/thebearmay/hubitat/main/apps/xxxxx.groovy",
oauth: false,
iconUrl: "",
iconX2Url: ""
)
preferences {
page name: "mainPage"
}
def installed() {
// log.trace "installed()"
state?.isInstalled = true
initialize()
}
def updated(){
// log.trace "updated()"
if(!state?.isInstalled) { state?.isInstalled = true }
if(debugEnable) runIn(1800,logsOff)
}
def initialize(){
}
void logsOff(){
app.updateSetting("debugEnable",[value:"false",type:"bool"])
}
def mainPage(){
dynamicPage (name: "mainPage", title: "", install: true, uninstall: true) {
if (app.getInstallationState() == 'COMPLETE') {
section("Main")
{
input "qryDevice", "capability.switch", title: "Switch to use:", multiple: false, required: true, submitOnChange: true
if (qryDevice != null) {
unsubscribe()
subscribe(location,"zwaveCrashed", "setSwitch")
}
}
} else {
section("") {
paragraph title: "Click Done", "Please click Done to install app before continuing"
}
}
}
}
def setSwitch(evt){
qryDevice.on()
}
def appButtonHandler(btn) {
switch(btn) {
default:
log.error "Undefined button $btn pushed"
break
}
}
def intialize() {
}
1 Like
How much of a coincidence is it that we have at least 3 Z-wave crashes within a few days? Read here: Z-Wave Lock Stopped Talking to Hub Suddenly
There are known bugs in the Silicon Labs Z-wave firmware/SDK that has been plaguing all 700 series controllers (not just Hubitat.) SiLabs recently (last few days) released a new version that is rumored to address many of these issues. Hopefully a fix will be forthcoming, but probably not in the next Hubitat release as SiLabs just released the new version. The Hubitat team will want to do a lot testing, I am sure.
6 Likes
It quite likely is a coincidence. Z-wave being a local wireless protocol and all.
4 Likes
I’ve visited this community every single day for ~3 years. Zwave “crashes” are extremely commonplace. They almost invariably result from poorly constructed messages, chatty devices, or ghost/stranded nodes.
Having 3 such incidents within a few days is not coincidental at all. As @ogiewon pointed out earlier, one underlying issue for 700-series controllers is buggy firmware from SiLabs.
3 Likes
Indeed, also seen my fair share of issues. Regarding the buggy FW, that is exactly what I was thinking, that perhaps there was a built-in timed bug causing the issues. Perhaps a bit far fetched 
In any case, hope the new Silabs FW will finally solve the issues for good.
3 Likes
Unfortunately the zwave controller crashed again last night.
The idea of rebooting the Hubitat each night failed miserably because despite an orderly shutdown, one minute power off, each time the Hubitat came back up it ‘Lost’ Hubitat Mesh, losing the Temp Sensors running on the Zigbee Hubitat.
I am about to move to a new home, will use another home automation hub to control zwave and keep Hubitat for zigbee and put Node Red over the Hubitat and the new zwave controller.
Forgive me if we’ve covered this before, but did you ask support to look at the engineering logs, and since I see we were talking about coding a work-around above was there a zwaveCrashed event captured? Any other events logged that could point to a cause (low memory, high cpu, etc.)?
1 Like
Can you post your z-wave settings page?
1 Like
Yes the firmware is buggy. But it appears to me only in certain cases ie s chatty device causes it to delay acks for the rest of the devices and they also get too chatty and the net crashes. I have had one crash too and tracked it down most likely to a bad device. Not to say it doesn't needs to be fixed but my guess is you have something going on with your mesh/ devices to aggravate the issue. Definately reach out to support.
1 Like
It is the same issue as reported to support previously so have not reported again as it is a known issue.
Not sure what specifically you want me to post, can you be more specific please?
I am radically reducing the number of zwave devices so it should help to relieve the issues.
I will move zwave devices to a gen 5 controller and watch out for Hubitat zwave controller updates, if that seems to work, then I can return to using zwave on Hubitat.
Go to Settings tab, Zwave Details. Screenshot that page. It should have a table of your Zwave devices by number, name, etc.
2 Likes
