The most widely available chip used in Z-Wave Controllers is the so-called 700 series chip. The Zooz ZST10-700 is an example USB controller using this chip. This chip is known to be unreliable, often causing Z-Wave devices to become unreachable by the controller, turning the whole ZWave network to be highly unreliable.
The best workaround for this is to create an automation that discovers “dead” zwave devices and uses zwave pings to revive them. This automation was introduced and experimented with in this thread:
It would help likely many Home Assistant / ZWave users if this automation would be included by default to be easily enabled. It would also be great if it could be enhanced to automate the steps necessary to make the automation work:
enable node_status entities of devices, required for the automation to discover the status of devices
verify that the names of the node_status and ping entities for devices match up, else the script does not work.
This would be a blueprint, which people can already make. I suggest you request someone in that thread to make the blueprint for you if you’re having trouble editing the automation.
You could well be right, but i do not know if all the steps necessary to create this automation in an automatically working fashion (enabling the entities, matching entity names) is even possible in yaml. And ultimately i think the automation would ideally be added automatically when a 700 series zwave controller chip is used.
I have left a breadcrump to this WTH in the thread about the discussion, i can not do more posts on the thread in a row due to forum rules.
Historically, we do not add any automatic automations. That’s one of the reasons why blueprints were added. You download the blueprint, configure (through the UI), then the automation is created.
I am just arguing from the perspective of a user. zwaveJS for example also tries to make it much easier now to upgrade firmware of zwave devices. The goal here is to overcome the (IMHO) broken firmware of the #$&^%$&^ ( ) 700 series zwave controller chips.
I am sure that a good blueprint and mentioning it in the readme for zwaveJS as well would be a great start!
I echo @raidboy here. I think any formal-sense of assistance beyond parsing massive threads regarding this issue is a positive for end users.
I can’t believe how much of a PITA this would be for a newly adopting Z-Wave user, and I’ve been along for this ride back when I had to open up the ZST-10 to see what chip was on it for the community to get 7.17.2 flashed. Still, I’ve never had an integration require so much hand holding and band aids to maintain reliability.
I’m grateful that the ZJS slack channel is so helpful, but the general consensus is that any ping to fix device automations are outside the driver and ZJS-UI level (which I understand) - so that puts any band-aids on HA integration layer here.
A blueprint would be great - expecting users to YAML-foo their way to a workaround with a template sensor and a coinciding automation is a bit too much of an ask for an issue as systemic as this one.
) 700 series zwave controller chips.