My 3 zwave controllers running zwave-js running over a network from HA can report dead nodes when mass events fire. These are likely do to either controller firmware or something with zwave-js.
Zwave-js will issue commands anyway if requested but Home Assistant marks it dead and will not allow operation. Automation events will not fire for those devices even though if it simply sent the command it would work 99.999% of the time except, for example of a door lock is not responsive due to battery drain.
It could be a system wide setting and device level setting. I hear there are other devices that also don’t report state. If the device fails ping events after 300secs (make this adjustable), then declare it dead. But it would be nice to be able to declare a device always alive too no matter what zwave-js thinks.
I really don’t believe this is a valid Feature Request.
No project would spend resources or approve a patch that created a work around for the likely valid function of another integration or of someones network. There is likely a reason nodes are dead and should not be talked to.
I suggest collecting actual data and try to diagnose if you have a network problem running 3 separate controllers. If there is a zwaveJS problem you have identified you should pursue proving that and fixing that with that team.
Agreed. There are also multiple automations available to automatically ping dead nodes (which if it’s the common stall issue. They pop right back)
Fix/optimize the network, apply your own workarounds. Ignoring errors and pushing ahead anyway isn’t something I want the ZWave dev team to do. Fix the issue, yes. Workaround. No.
Seems like a valid request to me. I’d even call the current behavior a flawed design and hence a bug.
The decision to make entities go unavailable was not without debate, and the results have certainly validated it was the wrong choice. At any rate, users have differing opinions on the correct behavior, so adding this as an option would help many users suffering from intermittent failures.
Devices may go dead even if you have an optimized network. It’s not necessarily an issue. It could be a one time blip caused by RF interference. On the extreme end it could be controller SDK bugs. The current solution requires users to implement rube goldberg-like automations to work around it. In many cases, an automation controlling a device would work just fine, as the device would revive as a result. Forcing a ping beforehand is just pointless (and cruel).
Z-Wave JS never suggested implementing this behavior, and is more on the opposing side of HA. It’s caused more pain to their project, as they have to deal with misplaced support requests coming from HA users.
@freshcoast yeah I re-read what I wrote. You’re correct… I’m totally for the devices to not ever get marked dead in the first place if it’s a bug. Fix bugs.
I had issue with this part ^^ No setting just let the system handle it… Stalled controllers and dead nodes… Well.
Fair enough.
Write it up as a bug then, it’s still not a Feature Request…
My guess it you will find that that behavior is required in the Zwave certified test list as required behavior, part of the certification behavior list to become platinum certified as I believe ZwaveJS is
I could be wrong, but they are building this to the standard, and a major behavior like that I have to believe is intentional.
