If you’d like I can share the logs here from z-wave js. I am looking through and seeing a lot of errors like this. Failed to execute controller command after 1/3 attempts. Scheduling next try in 100 ms. I assume this is in relation to the missing devices. I just noticed that more than just window and door sensors are missing, a few light switches are as well.
I do not see anything in the logs about entities, though I am not entirely sure where I would look. This is what one of the device pages looks like for a device that is actually showing up in zwave js.
I switched over a few hours ago in an attempt to migrate my home assistant install. I am reading that it could take over night for some items to show up. I have tried to wake them up and it still isnt adding. Should I just wait on these?
How can I debug the lack of entities under my devices? There is no way to turn this bulb on. It is a Go Control brand Z-Wave bulb. Shouldn’t there be an entity for the light? I feel like I missed a crucial step in the setup somewhere since none of my devices have entities.
The critical step is that you need to wake each battery device until they are interviewed properly. Unfortunately, you may need to exclude and include some battery devices because they do not wake long enough. That is rare though. So typically what you should do is keep performing the wake command. While awake, perform the reinterview.
I have woke every device, switches and door sensors were all toggled manually. They still are not showing up in the z-wave js. I can wait, it is no big deal.
The larger issue is why are there no entities for devices that have been completely interviewed? Is this something that I just have to wait longer or is there something else that is wrong? I am looking at my DSC26 and there is no way to turn it on/off.
I can’t stress this enough, you have to keep them awake. Watch the zwave logs, if the device goes to sleep during the reinterview, it will fail. Some devices have a 10 second wake window where reinterview takes longer than 10 seconds.
Got it. Thank you for your help. I will just give them a few days, the windows and door sensors are not part of any mission critical automations. I am running HA in a container inside of unRAID. I rebooted my unRAID server and suddenly the missing switches were showing and everything had their entities. Not sure why that helped, I had restarted the containers multiple times. Just tossing this here in case someone else has the issue.
What are these entities? All I want to do (except one) is to turn the light on or off, which I figured out with trial and error. Can I simply disable the “extra” entities in Configuration/Entities?
Just so you are aware that actually cycling the device (opening & closing the door, etc) won’t necessarily wake them up. they can still report status changes but not “wake up” for interview purposes.
A lot of times there will be a button (usually the same button that you use to include them on the controller) that needs to be pressed in order to wake them up and then maybe keep pushing that button until the interview process is complete.
but also be aware that the button is also the button to remove them from the controller or to do a factory reset on the device so make sure you follow the “wake” procedure exactly and not the “factory reset” procedure.
And again, if the device doesn’t wake up for long enough to do the interview it may never work.
you may have to physically wake the device up as decribed above for it to be successfully interviewed
I’m not sure what most of those are and don’t use them on my devices.
However I’ve found the node_status entity to be useful to indicate that a device is or isn’t functioning correctly.
I use the following sensor in an automation to notify me if a device goes down for some reason:
sensor:
- platform: template
sensors:
zwave_failed_nodes:
friendly_name: "ZwaveJS Failed Nodes"
value_template: >
{% set dead_count = states | selectattr("entity_id", "search", "node_status") |
selectattr('state', 'in', 'dead, unavailable, unknown') |
map(attribute='entity_id') | list | count %}
{{ dead_count }}
attribute_templates:
dead nodes: >
{% set dead_list = states | selectattr("entity_id", "search", "node_status") |
selectattr('state', 'in', 'dead, unavailable, unknown') |
map(attribute='name') | list %}
{{ dead_list }}
I think if you go to the drop down menu for the device and click the “advanced” button you can remove the dead node from there.
At the risk of waking up an old thread, I just wanted to thank Pedro for the excellent instructions. After an unsuccessful automatic migration, I did some more research, decided that ZwaveJS2MQTT was a better match for what I wanted to do, then took the plunge.
It all went well. I even took the opportunity to do a better job naming my Z-Wave entities.
Very happy overall. Thanks so much for pulling this together.
Yes I followed this guide. There were some slight differences between the current GUI and the screenshots. I don’t remember what they were, but it was minor.
As far as the renaming is concerned, I just did that manually. The naming of many of my devices was bad (defaulted when I added them to HA), so I took the opportunity to use better and more consistent names.
I found that if you rename the device, it would give you the option to also rename all the entities. I used that option and it provided sensible results. But it also appended an unnecessary number at the end of the entities (like ‘_1’) where the number for same typed devices incremented. I removed these numbers from all the entities.
Yes, I did have to change the lovelace config and automations to know about the new names of my switches, but I didn’t have many of them so it wasn’t difficult.
I was worried about our smoke alarms (we’ve got 12 of them), but it was fairly straight forward. Luckily I had templates in place that interpreted sensor values, translating them into sensible states. This was needed before because our smoke alarm model was not directly supported by the legacy Z-Wave integration.
After updating, I did have to rework the templates, but it’s much cleaner now because the entities provided by the new integration are much better. No manual sensor value translation needed. I barely had to change my NodeRed flows because they referenced the templates, not the entities directly. That “one step removed” design made this update simpler than it might have otherwise been.
So yes, there is manual work to do here. But it wasn’t that bad for me, and the end result much nicer than I had before. Also, the admin GUI for ZwaveJS2MQTT blows the doors off the old legacy integration. This was all well worth the effort.
I was postponing this migration from OZW forever but started Friday night. Within a few hours was up and running again. Took the opportunity to clean up my zwave network as I had quite some dead nodes after several years of usage.
Of the +50 nodes there was only 1 I could not wakeup but that has always been an annoying sensor.
For renaming I was a bit more pragmatic; Renamed most of the back to their original names which limited my need to change templates & automations etc.
Network is way (!) faster
My original config had no network keys, also not for legacy/s0 so my config looks like below. Can I generate keys for these and save the config without breaking anything?
