Wondering if anybody has found a fix to this yet? I’ve been fighting this just about every time I restart. Getting between 1 and 10 devices showing as “unavailable”. There’s a few devices that seem to be repeat offenders but for the most part it appears completely random. I’ve got a fairly strong zwave network with 64 nodes, all but 2 being repeaters.
Re-interviewing OR manually toggling the device allows me to control them again.
I am experiencing the same. This is a pretty big negative in the move from ZWave classic to ZWave JS as I never saw these issues with ZWave classic. I am on the same hardware - the biggest change is ZWaveJS. I am good with managing my own home automation system, but redoing the same work regularly is maddening.
core: core-2021.12.5
supervisor: supervisor-2021.12.2
zwavejs: 0.1.50
There’s a thread on the inovelli community forums with others running up against the same issue as well. Sometimes, just restarting zwavejs is enough to get the devices back online.
I’m thinking I may have to do an automation that detects when a device goes unavailable and then automatically re-interview the node. I’m just thinking of the amount of traffic it will put on the network and how it can slow things down to a crawl at times.
You should not have to re-interview nodes when the Z-Wave JS container restarts. Are you running HA OS/HA Supervised, or running the container separately? If you’re having to re-interview it sounds like your cache file isn’t being persisted properly. Z-Wave JS also works a little differently than the old Z-Wave integration, and entities are marked unavailable if the node isn’t in a ready state.
If this is a consistent problem, please open an issue so any bugs can be addressed, as this definitely should not be happening.
During the last week I’ve had 7 devices going “not ready” to a total of 14 devices of 45 (I do have some without power that is expected to be in not ready at the moment).
I’ve tried healing devices, re-interviewing devices, restarting the host and reload the z-wave integration without any effect this time. After the healing process finished I now have 6 devices in not ready, so it seems to have corrected the issue on the devices that went offline recently.
Are there any logs that can be collected that could make it possible to track down this issue via a bug-report? If so, I can try to collect it next time devices go offline.
I’m on a raspberry PI4, 64bit install on SSD currently on 2021.12.7
Aeon Gen5 stick
Z-Wave JS:
Driver version 8.9.2
Server version 1.14.0
Edit:
Z-Wave JS dump data from one of the devices in “not ready” before heal. Could it be a problem where devices are unable to change ready state to “true” once they are in “ready”: false unless the heal function is used?
Before heal:
"nodeId": 70,
"index": 0,
"installerIcon": 1792,
"userIcon": 1792,
"status": 0,
"ready": false,
"isListening": true,
"isRouting": true,
"isSecure": true,
After heal:
"nodeId": 70,
"index": 0,
"installerIcon": 1792,
"userIcon": 1792,
"status": 4,
"ready": true,
"isListening": true,
"isRouting": true,
"isSecure": true,
Before heal:
"values": [],
After heal:
"values": [
{
"endpoint": 0,
"commandClass": 37,
"commandClassName": "Binary Switch",
+++
Update: There seems to be something seriously wrong with my system now. After a host reboot almost all my z-wave devices are offline. This number will decrease for a while, then I need to Heal the network to get the remaining devices to come online. Sometimes the heal process never finishes, so I cannot re-initiate another heal even if it was started several days ago.
Inerestingly for single devices see this post for how to automate “z-wave ping” for devices that are offline:
My logs are full of error messages now, so I have to figure out this one out first:
CNTRLR [Node 046] refreshing neighbor list failed: Timeout while waiting for a callback from the controller (ZW0200)
CNTRLR The controller response indicated failure after 1/3 attempts. Scheduling next try in 100 ms.
DRIVER Dropping message because the driver is not ready to handle it yet.
DRIVER Dropping message with invalid payload: 0x01060004004300be
When I started to get logs like that, I replaced my Z-Stick and they all went away.
Also running into this issue. Are there any solutions to this?
When a node goes offline I find a ping is enough to bring it back. Of for switches, manually turn on/off. It is annoying.
I recently had one of my Z-wave plug-in modules show up as “unknown” for manufacturer and model. I can ping it, re-interview it, etc. and it shows as normal. However, it won’t turn on/off with HA. I’ve healed it without success.
Any tips how to recover it?
I have my Home Assistant server on a UPS so in the event of a power failure it does not go down. I am finding that when the power comes back on there are several ZWave devices that to not reconnect and become unavailable.
Rebooting home assistant works but is not really acceptable. Re-interviewing the nodes also works but I am not sure how to do that automatically.
Do you need to re-interview or would a ping work? I now have automations like this to help spot poorly nodes and try to bring them back to life. Even with this I find that some nodes need more help.
alias: Ping Garage Lights when Node 38 dead
description: ""
trigger:
- platform: state
entity_id:
- sensor.node_38_node_status_node_status
for:
hours: 0
minutes: 1
seconds: 0
to:
- dead
- unavailable
- unknown
condition: []
action:
- service: button.press
data: {}
target:
entity_id:
- button.node_38_ping
mode: parallel
I’ve been having this issue for over a year, sometimes once or twice a week but lately just 2 or 3 times a month with mostly kitchen blind 2 and 3. At first, I was taking the drastic step of removing & re-including the problem node(s). Then I discovered that a simple interview would fix it. I’ve been doing that manually for several months now. This morning it was blind 3 and garage door lock & a re-interview brough them back. I grown tired of this and did a different google search and ended up here. I’ve set up your automation to ping the problem node and we’ll see how it fairs. Unfortunately, there’s no Z-Wave service call to execute a re-interview…
alias: Z-Wave - Ping when node is dead
description: ""
trigger:
- platform: state
entity_id:
- sensor.kitchen_blind_2_hidden_node_status
id: Kitchen Blind 2
for:
hours: 0
minutes: 1
seconds: 0
to:
- dead
- unavailable
- unknown
- platform: state
entity_id:
- sensor.kitchen_blind_3_hidden_node_status
id: Kitchen Blind 3
for:
hours: 0
minutes: 1
seconds: 0
to:
- dead
- unavailable
- unknown
- platform: state
entity_id:
- sensor.garage_door_lock_node_status
id: Garage Door Lock
for:
hours: 0
minutes: 1
seconds: 0
to:
- dead
- unavailable
- unknown
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: Kitchen Blind 2
sequence:
- service: button.press
data: {}
target:
entity_id: button.kitchen_blind_2_hidden_ping
- conditions:
- condition: trigger
id: Kitchen Blind 3
sequence:
- service: button.press
data: {}
target:
entity_id: button.kitchen_blind_3_hidden_ping
- conditions:
- condition: trigger
id: Garage Door Lock
sequence:
- service: button.press
data: {}
target:
entity_id: button.garage_door_lock_ping
mode: single
Hi Team
I have some nodes Aoetec GPO’s and a few of them end up with weird/extra power entities and the primary entities start reporting crazy numbers. eg. My office desk reported I used 120,000kW/h yesterday. :\ It breaks the energy dashboard pretty hard. 
I find to resolve it I have to reinterview and then the new weird entities disappear and the primary ones start reporting properly again.
So, I wanted to put this into an automation and found this thread but I pushed on and I found a way to do it if you are using ZWave JS UI (formally ZwaveJS2mqtt) and have a MQTT server setup.
Go into the UI and turn on the MQTT server:
Once you hit save it will restart ZWaveJS, watch it logs and you will see the API topic string you need to send messages to hit the ZwaveJS API.
2023-02-17 16:04:33.184 INFO MQTT: Subscribed to zwave/_CLIENTS/ZWAVE_GATEWAY-zwavejs2mqtt/api/#
As per the ZWaveJS documentation to send a reinterview/refresh the command is:
https://zwave-js.github.io/zwave-js-ui/#/guide/mqtt?id=refreshinfo
or more simply (I am using mosquitto) and the node I wish to reset is node 31.
mosquitto_pub -u <user> -P <password> -p 1883 -t 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwavejs2mqtt/api/refreshInfo/set' -m '{ "args": [ 31 ] }'
Victory!!! This took a bit of trial and error for me having never used MQTT in such a fashion before:
So, lastly let’s run it in an automation!
- alias: reinterview jurgens desk zwave node
trigger:
- platform: time
at: '3:30:00'
condition:
- condition: state
entity_id: input_boolean.zwave_up
state: 'on'
action:
- service: system_log.write
data:
message: 'zwave reinterviewing jurgens desk'
level: warning
- service: mqtt.publish
data:
payload: '{ "args": [ 31 ] }'
topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwavejs2mqtt/api/refreshInfo/set'
I hope this helps you all!
I’ve seen some elements of this also, there is a nasty bug somewhere. This really shouldn’t happen.
I just double checked, the reinterview worked over night.
I don’t even care if the device has gone offline - I know it will every day or so - I just want to automate a re-interview but it’s not an option. I can automate a ping, but that doesn’t fix it
I have the same recurring problem. After every update to HA, one or more Z-Wave devices needs to be re-interviewed to get its correct state. Have to do it manually which is time consuming.
Home Assistant 2023.4.2
Supervisor 2023.04.0
Operating System 9.5
Frontend 20230406.1 - latest
I am trying the solution in this thread: ZWave JS not updating state of devices - #6 by dzonn. Not sure it will work but it applies more to my problem than the solution given by jurgenweber here since I am mainly concerned with updating a state and not actually losing a device completely. In other words, my thermostat is turning on and off but not telling Home Assistant when it does to activate an automation to turn on or off a fan. I know I said it had gone offline - my mistake. Not sure if the solution in the other thread will work for you, but it might
I have the same issue which has plagued my HA for a while now. Every HA or Z-Wave JS update and 16 of 66 nodes go down and I have to re-interview them one by one.
I went searching for a fix as this process is getting old and came across this thread. Subscribing in the hopes a fix, or at least bulk re-interview option, show up one day. Thanks to anyone looking into it!