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 helperdevice_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?
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.
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:
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).
I implemented this today, but it did not work until I changed the sensor’s state value to include a “default”. Until I did that, the sensor was always “unavailable”. Thanks to Rob C. for the fix!