So you have a series 700 stick then. 
(nodes randomly dropping, ping bringing them back is a known issue with 700 sticks)
1 Like
The ping service allows any of entity ID, device ID, or area, as described in the docs. Have you tried manually using the ping service with the entity ID to see if it’s working or not?
You can get the device ID via the template helper device_id(entity_id), but that shouldn’t make a difference.
Yes a 700 series stick ZST10 700. Does that work for the sensor._node_status entities? I assume for switch. entities would work?
I guess my problem is I am detecting sensor.downstairs_light_node_status is dead but switch.downstairs_light is the entity I need to send to the service?
Are you aware of the known bugs with 700 Series controllers? Silicon labs is looking for a solution,
1 Like
The node status sensor is the only entity that will be “pingable” when a node goes dead. All other entities will be removed (unavailable), and won’t be usable with service calls. So either the device ID or node status entity will work with the service.
1 Like
Ah ok good to know… hope a true fix comes soon. However, not sure why my automation isn’t restoring nodes for me?
Hi! I have a temporary solution which acts as soon as a node dies. Pinging it brings it back to live within seconds in 99% percent of the cases. Happens many times each day, but this ping-automation makes it work pretty ok in the wait for a downgrade to 500-chip or a new firmware from SiLabs
First i create a sensor which lists an array with dead nodes as soon as one dies:
#Sensor for dead Z-WaveJS nodes
- platform: template
sensors:
failed_zwave:
value_template: >
{{ states | selectattr("entity_id", "search", "node_status") |
selectattr('state', 'in', 'dead, unavailable, unknown') |
map(attribute='entity_id') | list }}
Secondly I have an automation which kicks in the ping and also notifies me so I can se how often it happens:
- id: '1640883970815'
alias: Alert on failed Zwave Nodes
description: ''
trigger:
- platform: state
entity_id: sensor.failed_zwave
condition:
- condition: template
value_template: '{{ states.sensor.failed_zwave.state != "[]" }}'
action:
- service: zwave_js.ping
target:
entity_id: '{{ states.sensor.failed_zwave.state }}'
- service: notify.mobile_app_xxxxx
data:
message: Pinging dead nodes
mode: single
14 Likes
Amazing, thanks so much for sharing!
1 Like
Thanks for the auto-ping trick, here is the sensor in the updated format:
- sensor:
- name: "Dead ZWave Devices"
unique_id: failed_zwave
state: >-
{{ states | selectattr("entity_id", "search", "node_status") |
selectattr('state', 'in', 'dead, unavailable, unknown') |
map(attribute='entity_id') | list }}
3 Likes
Great workaround. But which sensor or Templat should I take now?
Sensor in updated format?
Is this issue where zwave devices are marked dead and simply pressing a button on them, or restarting the zwave js addon gets them back? If so, I have the issue too 
My zwave controller is an Aeotec Stick 700 series and was running 7.15 of the SDK (firmware). I just updated it to 7.17 that I found in the latest update from SiLabs and for now everything is running. I am hoping that 7.17 fixes the issue but I did not see anything in the changelog for 7.16 and 7.17 that would indicate it did (but I am not an expert either). Please note that the latest firmware Aeotec has on its site is 7.15 however they said the firmware is part of Simplicity Studio so I found the updated version and tried it. I also read on another forum that all 700 series stich use the same firmware (true? no idea). A different file in the same Simplicity Studio SDK folder was also accepted (wrong file seems not to load) by the Zooz Stick 2 700 series… I have not tested it after the upgrade but it seems to be fine (works in Zwave PC Controller).
Devices could be dead for multiple reasons, but usually it’s an indication of an unhealthy network. The buggy 700 controllers is another possibility. Not everyone has problems with the 700 controllers. The only way to know for certain would be to downgrade to a 500-series and compare.
Firmware 7.17 does not fix this problem. The cause and solution are still under investigation.
The Aeotec and Zooz use different Z-Wave chips, so they use different firmware files.
I will try to do a network heal but they never seem to complete and take over 24hrs.
I believe I read that the current issue with the 700 series includes network heals not finishing in certain circumstances (and/or with heavy traffic) so I might have that issue. I’ve done my best to tone down the traffic but sporadic issues I have seem to point to traffic issues.
Yup, as mentioned above I used the firmware for the different chip in the Zooz stick. After doing so I found a Github ticket that confirmed what I did was ok.
Interestingly enough I have this problem with a Aeoteck Stick 5 controller and I’m waiting on a 700 series but it’s not in stock anywhere near me.
It seems heal fix many devices, but not all, so I’m slowly accumulating more and more dead devices. Will see if the script in this thread will fix it. Heal sometimes gets stuck (running for several days without finishing) on my system as well (PI4).
Just a quick note - SL dropped an updated firmware for the 700 series sticks today (.17) a few have started testing.
1 Like
Hi all,
I have the same issue and these solutions seem to work for many
Given I am a newbie any step by step device whre this code is meant to be entered
Any details - I am not totaly incompetent 
but very new to HA and this programing lingo
Thanks a million
Vas
Hi,
i copy your automation, but i get a error with entity ID:
What do i need to do? this entity don’t exist.
i’m new with HA and lerning every day.
i have a Zooz ZST10 700 and have dead node problem.
thanks for your reply.
regards
Hi Patrick!
The first thing you need to do is to enable the node status entity on every node. These entities is disabled by default.
1 Like
i think it is working now, after change my sensor to:
let me test it
regards