Thanks @petro, I have had some problematic nodes in the past which has shown as “dead” in HA, but it never stopped my network from showing anyway. There may be some kind of problem in my zwave mesh, because it has been rather slow at times and occassionally nodes have died or not reported back. That is why I would now like to rebuild my whole zwave network, but it seems hass.io won’t let me do that easily. Maybe it will be easier in the end to just do a fresh install of hass.io (or upgrade to hassos) to make sure I get rid of every remnant of the old zwave network. Or, will it suffice to just remove the core.device_registry and core.entity_registry let hass.io rebuild them?
I am starting to feel that maybe zwave isn’t the way to go with lights and switches in the future because of some of its inherent weaknesses. But I have invested a lot of time and money to make it work with a large number of entities in HA, so I am reluctant to invest in something else unless it proves to be really superior to zwave. Unfortunately I am now at a point where my whole HA setup seems like a big mess because of a zwave network not working as it should.
I will look into getting a proper neighbor map of the mesh when I have the time. I have seen posts about it, but not found any easy to implement solution to it yet.
How many nodes do you have? I’m running 55+ and it works great. Your zstick might be the culprit.
EDIT: As for redoing the network, you’d need to exclude and reinclude.
Re-adding the devices (without excluding or including) in to HA should just be as simple as deleting the openzwave.xml file and removing all traces of the entities from the core.entity_registry files. This wont fix the communication issues as it’ll just recreate the interface from openzwave to ha.
About 30 nodes. I just did a wipe restore of my config from Oct 10. While it didn’t revert to the hass.io version in the backup (it stayed on 0.84.6), all of my z-wave nodes except one (which is reported as dead) came back up. Hopefully I can restore my newer config with lovelace without breaking the network again.
I will see if there is any difference in the zwave network speed or if it works more as expected. Still seem to have some nodes (mostly outdoor) that doesn’t report their state properly all the time though.
I have one zwave range extender on the porch, but the zwave controlled sockets in the yard may be to far from the house, some of them 10-15 meters. I know these may also not function optimally when it is cold outside as it is now.
I have added a few more entities since I did this map.
Well, you can pretty much assert that battery powered zwave devices will not act as repeaters so your problem in communication will lie in the green dots. Id say you have one of 4 possible devices that are causing the issues
I would say that 2 out 3 work most of the time. They are for my outdoor lighting. The fourth one (the one farthest from the house) is rarely used, mostly just sitting in the state it is in.
Thanks, I think I have seen that thread, but never attempted to add it to my setup. I will revisit this when I have enough time to figure out how to install it in hass.io.
I too would like to add my frustration. Previously when adding new z-wave devices I did the “rename-deleteRegistry-restart” method which resulted in the zwave entities being called “zwave.kitchenlight” and the individual elements being called “switch.kitchenlight” and “sensor.kitchenlight_power”, “sensor.kitchenlight_energy”…etc.
I’ve just added 5 new Z-Wave devices and named them. The rename of the zwave element doesn’t propogate down to the individual sensors/switches:
(note that for example, these nodes all have a “correct” zwave.some_real_name, but all their sensors are named with an increasing number. Worse, if I lose my entity_registry (or whatever it is in the storage), the numbers will all change.
Each node has 13 individual elements. Now, I get to edit 65 elements by hand…
I’m not sure how I can help fix this, but man this is broken and needs a fix
Will join the choir of "not very happy about this solution "…
Have six Greenwave Powernode 6 - including one results in 31 new entries - and due to the way it’s coded in OZW the naming is awful - and if you delete the entity registry and all six are “re-included” in Hass, it’s absolutely impossible to gain any kind of overview…
My workaround:
Z-wave devices are always included via OZW Control Panel - and renamed there.
Afterwards, names are further edited in the xml-file - that leaves only some 15-20 minutes of hard work for each (editing the registry file still, though)…
A “rename all” function would really be a giant leap forward…
Rename using the Service Dev Tool (i presume it gets changed in the zwave DB), delete the zwave_*.xml and the core.config_entries, core.device_registry and core.entity_registry files (might not be all needed, just to be sure) and reboot. All the files get regenerated and now the naming of the zwave device and all the sensors get a new name. BREAKING if you have automations, etc.
I had a corrupt SD card, tried to get a backup restored but that failed. Copied over the config files but that renames most of my zwave devices. Some with a given name, some with the default name. As you might guess that breaks the GUI and all automations. Hope this fixes that for future migrations.
a year in to the new “entity registry” system and we are still dealing with this issue by manually editing and deleting system files. looks like the new system is working great.
I have a HA system with 10 zwave devices. They have been happily running for almost six months. After a restart I could not find any of the devices in the configuration/Z-Wave Node Management/Nodes list. Restored an old zwcfg file, and got some back. Funny part here is that some of the entities of the devices that I actually got back is missing…
From the logs(OZW_log) I can see that all the missing z-wave devices is communicating with the stick.
