I am wondering the same thing.
1 Like
Everytime I update my HA version (monthly) and restart I have to re-interview my Z-Wave devices one by one to make them available again. This is only for the devices I’ve included since switching from legacy Z-Wave to Z-Wave JS so it seems like either I didn’t check a necessary option in Z-Wave JS or I needed to delete and recreate some database file. There must be a way to perform this re-interview process that I am just not engaging.
1 Like
i am having the same problem
1 Like
I have the same issue but automate re-interview will not resolve it as I have secure devices which requires to have them in close distance in order to re-interview (eg. smart lock).
Hello all
I have this post posted also in the configuration thread
I’m fairly new to home assistant. I am trying to automate my HVAC environment. My requirement are
Turn heat on
If the room temperature is below 21 deg. C and the time is after 7:00 every day of the week
and an additional automation
Turn heat off
If the room temperature is above 24 deg. C or is after 23:00 every day of the week
Seem simple enough
I am running a z-stick v 7 and the switch on the pellet stove is a fibaro double switch FGS232 and an aeotec multi sensor 6
I built my automation with the following parameters
name: heat on
mode: single
enable/disable automation: on
trigger: numeric state
trigger id: sensor
entity: sensor.living_room_sensor_air_temperature
attribute: unit of measure
below:22
value template: C
Conditions
Type:and
configuration type: fixed time
after 7:00
before: blank
selected every day of the week
action type: device
device: pellet stove
action: turn on pellet stove
If i run this automation manually it runs. This means that I bypassed the trigger and condition and the action worked.
However if the automation tried to run as scheduled It does not.
I get an erro in the logs as follows
Logger: homeassistant.components.homeassistant.triggers.numeric_state
Source: components/homeassistant/triggers/numeric_state.py:113
Integration: Home Assistant Core Integration (documentation, issues)
First occurred: 07:57:40 (8 occurrences)
Last logged: 08:01:56
Error initializing ‘heat on’ trigger: In ‘numeric_state’ condition: entity sensor.living_room_sensor_air_temperature state ‘°C’ cannot be processed as a number
Error initializing ‘Heat off’ trigger: In ‘numeric_state’ condition: entity sensor.living_room_sensor_air_temperature state ‘°C’ cannot be processed as a number
Error initializing ‘heat on’ trigger: In ‘numeric_state’ condition: entity sensor.living_room_sensor_air_temperature state ‘C’ cannot be processed as a number
what am i doing wrong in my configuration
New insert
I have since deleted the time condition and the automation does not work
It seems to me that my automation is not reading my aeotec multi sensor 6. In ypour opinion am i configuring the trigger of my automation incorrectly?
thank you for your patience and help
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.
1 Like
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
1 Like
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!
1 Like
I’ve seen some elements of this also, there is a nasty bug somewhere. This really shouldn’t happen.