Automate ZwaveJS Ping Dead Nodes?

Occasionally I have a few powered zwave nodes go dead. For what reason I don’t know, the device going dead seems to vary. It’s not often but a simple zwave ping is enough to fix the device.

I created this automation and its working fine to trigger on dead sensors (e.g sensor.downstairs_light_node_status = dead). However the zwave ping service is expecting the parent device so the action doesn’t work. Does anyone know how to relate back to the device from a triggering entity to call the service with the right device?

alias: Zwave - Ping Dead Nodes
description: Try to ping a node if it goes dead to bring it back up
trigger:
  - platform: event
    event_type: state_changed
condition:
  - condition: and
    conditions:
      - condition: template
        value_template: '{{ trigger.event.data.new_state.domain == "sensor" }}'
      - condition: template
        value_template: '{{ trigger.event.data.new_state.state == "dead" }}'
action:
  - repeat:
      until:
        - condition: template
          value_template: '{{ trigger.event.data.new_state.state == "alive" }}'
      sequence:
        - service: zwave_js.ping
          target:
            entity_id: '{{ trigger.entity_id }}'
        - delay:
            hours: 0
            minutes: 1
            seconds: 0
            milliseconds: 0
mode: parallel
max: 5

Thanks!

6 Likes

So you have a series 700 stick then. :slight_smile:

(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
13 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 :frowning:

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 :smile: 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

Hi,

all of them have Node status enable:

what you think it is?

regards