Zwave 1.4 missing after update to 2021.2.3

Hi, just wondering, where the fuck is ZWave 1.4 control panel ?
For some reason, since the update to 2021.2.3, my ZWave 1.4 network, which was functional, does not start automatically with Home Assistant anymore… Instead of the ZWave control panel (which could have been helpful to start the network manually), I have a message inviting me to upgrade to another deprecated installation: OpenZWave :frowning:
I don’t want to migrate to this new ZWaveJS thing right away, so looking for any tip.
Thanks for your help.

Check your logs and verify that everything else is starting up properly. I’d be willing to bet you have a issue elsewhere that’s causing home assistant to stall on start up and zwave is not really your problem.

Thanks Petro, indeed I’m wondering what’s blocking the process. On the web UI, I have messages saying that “HomeAssistant is starting, etc…” instead of the ZWave values/widgets. It lasts forever. Anyway, the fact that the ZWave control panel disapeared is a problem for ZW 1.4 users (unable to heal, or restart network anymore)

Yes, then check your logs and see what errors you have.

Was it working on a previous 2021.2.x version?

I’m running v2021.2.2 and I still have my control panel (along with that silly “migrate to OZW” invitation too).

Hi, I downgraded to HA 2021.1.5 in order to get a working system. By the way, I couldn’t do it with command line :thinking:

ha core update --version 2021.1.5

The reason, is a task (I couldn’t find which one) was pending and lasting forever. Probably related to ZWave integration start failure, and Supervisor rejected the downgrade task.
So, I had to shutdown homeassistant and force the downgrade manually as root, by tweaking the conf :face_with_raised_eyebrow:

docker stop homeassistant && sed -i "s|2021.2.3|2021.1.5|g" homeassistant.json && sed -i "s|2021.2.3|2021.1.5|g" updater.json

Then, the supervisor restarted automatically homeassistant to version 2021.1.5 and it was all fine. Control panel was there, and everything working as expected. :slightly_smiling_face:

This morning I decided to give it another try, and decided to upgrade to 2021.2.3. I figured out something:
My ZWave 1.4 setup was originally defined in configuration.yaml and this is probably the source of the issue. I removed integration from configuration.yaml in order to add it through the administration interface. Before restarting, I also removed ozwcp addon (which was not used at all, and which helped me once to debug my network)
After restart, ZW 1.4 was surprisingly still present in the HA integration panel, and good news is the ZWave control panel is also back.
I don’t really understand why the ZWave integration is still here, as it is still commented in my configuration.yaml but it’s working anyway.

I think I will try later, when I have a moment, to follow the tutorial from Switching from Zwave 1.4 (Deprecated) to ZwaveJS2MQTT

I have the same problem here. Running homeassistant in Docker. When I upgrade to 2021.2.0/1/2/3 the zwave control panel is missing along with all of my zwave devices. Commenting out zwave in configuration.yaml along with the security key and usb device path after downgrading to 2021.1.5 and zwave network starts up and works fine. The security key and device mapping must have been pulled into some other part of homeassistant since it works without it in configuration.yaml. The forced move of configuration parameters out of configuration.yaml and into other parts of hass really ruins one of the main things I loved about hass to begin with.

However, even with zwave commented out, an upgrade to 2021.2.x results in a non-existent zwave network.

There is some kind of undocumented breaking change with zwave 1.4 as it was deprecated. The release documentation lists zwave as a breaking change but does not describe any breaking change behavior.

Curious. I am on core-2021.2.3 and seem to have the traditional control panel with z-wave 1.4.

I am running Home Assistant OS on ESXI.

My Home Assistant instance is running on supervised docker. Hardware is an Odroid-U3 powered by ArchLinuxARM


I had issues while updating 2021.1.5 to 2021.2.3, it stuck on boot never finished. UI did open, but always notification on bottom after refresh about “not all…”

Thanks for this thread, I deleted all Z-wave related (had only 2 nodes) integrations etc and run update. After this update finished ok and not errors on log files, so something on previous Z-Wave integrations were not compatible.

Would be nice to have pop-up during update… “hey, you have still incompatible integrations, you should remove them” “Do you wan’t to proceed?”

In my case, snapshots saved my life.

I tried again to upgrade to 2021.2.x tonight and it didn’t go well.

From 2021.1.5, with zwave configuration commented out in configuration.yaml, I pulled and started a new container tagged at 2021.2.3. Just as previously, the zwave network fails to start and appears to not exist at all. This time I tried removing and re-adding the zwave integration from the UI using the USB device path and security key that I previously had defined in my configuration.yaml and restarted homeassistant.

The zwave integration now appears to start up correctly and my zwave devices are there, however, all of the associated entity IDs are now wiped out and restored to defaults, which breaks basically everything. I have over 60 zwave devices in my network so this is not a viable upgrade path for me. Thankfully I was able to restore a backup and fall back to 2021.1.5.

edit: I am pretty well convinced that this is at a minimum an undocumented breaking change, I have opened an issue against home-assistant core here:

1 Like

Just commenting to add in that I ran into the same issues (and have similar Z-Wave device count). Upgrade to 2012.2.x means HA never finishes starting due to some Z-Wave change. Tried multiple times and ended up having to restore my HA VM from backup each time. Running 2021.1.5 until issue is resolved.

Error from logs (not much else besides this): “Received invalid command: zwave/network_status”

I’m not positive, but I think that what we are seeing here is actually the deprecated zwave integration never loading during initialization. I think the “Received invalid command: zwave/network_status” log line you see is actually from a service call to a domain that does not exist (because zwave is not loaded).

I have a few ideas about how to work around this by hacking around in .storage stuff… Will post back if I find something that works.

I think I’ve isolated the issue down to something in core.entity_registry in .storage but not sure exactly what.

If I upgrade to 2021.2.3 with zwave commented out of configuration.yaml, delete the zwave integration through the UI, restart HA then re-add the integration zwave starts up fine, but all new entity IDs across 60 zwave devices = ~245 entities with now broken entity IDs.

The zwave integration configuration is stored in core.config_entries and has a unique ID that is referenced by devices in core.entity_registry to map to its zwave controller device. I had hoped I could simply take a working copy of core.entity_registry from 2021.1.5 and replace the unique ID in the newly created zwave entry in core.config_entries to match the mapping in entity IDs and be back in business.

However, once I update core.config_entries with the matching ID, zwave again fails to start.

I noticed when I re-add the zwave integration in 2021.2.3, prior to swapping IDs around that only 54 devices show re-imported to HA whereas I have 60 in 2021.1.5. I suspect these may be orphaned z-wave devices or something like that so this is my next area to explore. I’m still stuck on 2021.1.5.

I was able to get upgraded to 2021.2.3, but I’m not 100% clear on what finally fixed the issue, I think it was removing the unused openzwave integration.

It could have also been related to removing a few dead devices from my zwave network, but I don’t think this is the case.

I think that the changes in this commit (specifically is now importing zwave configuration parameters to openzwave which I have installed but am not using. My guess is that openzwave loads first, binds to the USB device and makes it unavailable to the zwave integration loading later. Simply removing it seems to solve the problem.

I have removed zwave: from my config, uninstalled the openZwave add-on (integration was never installed), and several other tests with no success. I did run through the process of removing the Z-wave integration, restarting, and readding under 2021.2.3. This does get the integration running again but as you said, all new entity IDs. I did notice that I also had 89 devices on 2021.1.5 and now 88 on 2021.2.3.

@sbruggeman: How did you go about identifying which devices were orphaned and how did you remove them? I guess thats my next step to try as I am not renaming 369 entities :grimacing:

I didn’t have a great way of identifying potentially broken z-wave devices. I basically just went through the entity states in developer tools and filtered the status for “un” this shows unavailable or unknown status devices. I then looked through this and tracked back to any zwave devices that may have been dead and deleted them. Strangely enough, even after getting everything back up and running I still show 60 devices when a wholesale re-import of the zwave component comes back with 54.

Hmm, well I don’t have any Z-wave devices that are unavailable or unknown except a plug that is currently unplugged. Guess I will just hang out on 2021.1.5 until the new Z-wave JS is more polished and I can jump to it easily.

I made a comment on the bug and what is causing it. I will look at putting in a PR if someone doesn’t beat me to it. :slight_smile:

Submitted PR for this issue and asked the questions if the original PR that caused this issue should just be reverted.