2021.10.0: Z-Wave S2 support, Tuya, secure ESPHome and 400 new icons

Unfortunately, it appears the migration (as well as the zwave js integration) just isnā€™t ready for primetime. I went ahead and just manually renamed my devices after the migration, since it didnā€™t actually migrate anythingā€¦

I basically just wrote down the node numbers and their associated names, then I did the migration, and I fixed the names after. It was a little bit of a hassle since it took me a few hours to rename everything and make sure Iā€™d found it all properly, but itā€™s done now.

The downside is that there are still A LOT of things missing from zwave jsā€¦ so Iā€™m not quite sure why theyā€™ve marked the old zwave as ā€œdeprecatedā€ā€¦ it just makes it more confusing for users, and frustrating when things donā€™t work properly after a migration. My biggest issue with zwave js is that most of the UI configuration is completely missingā€¦ so I have to manually set things via service calls, rather than just being able to handle device configuration changes via the UI like I used to be able toā€¦ so Iā€™d suggest waiting for that to be available before migrating. For the time being, I am staying on zwave js and just hoping the UI configuration gets implemented soon.

Edit: Apparently the UI config does exist, but only if you re-add devicesā€¦ so the migration is totally worthless since I have to manually remove and re-add all my devices anyway. Iā€™ve tried re-querying the devices and that does nothing.

Itā€™s already there, been there for quite some time now.

I stand corrected, I noticed that options are there for newly added devicesā€¦ so the only way for me to get the UI config is to manually exclude and then include the devices one at a time. So my point still stands that the migration is completely worthless since I have to remove and re-add everything to actually get the configuration options.

Probably because the developer of it has taken timeout supporting it and it cannot be maintained anymore.

Incorrect.

I am using the official ( non-HA) zwavejs2mqtt with HA and the zwavejs integration. That UI reads the network from the controller and shows the devices and their configuration, I believe. I understand the HA zwavejs & zwavejs2mqtt just wrap the official stuff anyway after it is released.

Nope, go into your devices, find the device you want to configure, click it. Then click on configure device. If it doesnā€™t have a configure device, then that device has nothing to configure. The configuration for devices only shows you zwave configurations i.e. command classes that change how the device behaves. If you want to change the name or things like that itā€™s all done through the device page.

Itā€™s deprecated because itā€™s from 2014 and the maintainer is gone. Old ZWave is use at your own risk. It will work until it stops working. When that happens, it will be removed.

Really?! This type of response is totally unhelpful, donā€™t try to be a know-it-all. Iā€™m happy to share pics and video showing exactly what Iā€™m seeing. After the migration nothing showed configuration options, BUT if I manually remove and then re-add devices, I get configuration options to show up. I know what Iā€™m seeing, so donā€™t tell me Iā€™m incorrectā€¦

Iā€™ve done exactly what you described, and Iā€™m telling you, after the migration nothing that SHOULD have configuration options is available. However, if I exclude and then include the same device, the configuration options then show up. Iā€™ve tried forcing the re-interview process on existing devices but it solves nothing.

Iā€™m simply stating a fact that the migration process did not work for meā€¦ maybe itā€™s buggy and sometimes works and sometimes doesnā€™t. Either way, I have to manually do everything because the migration didnā€™t actual migrate anything for me.

Letā€™s see the video then, maybe we can see whatā€™s going wrong. No one else has reported issues like this, so thatā€™s why everyone responding to you finds it hard to believe. The negative reaction your getting from people is because of the the way youā€™re delivering the information, and these latest responses certainly donā€™t help.

2 Likes

Please just read what I originally posted and the responses I gotā€¦ I originally simply stated what I am seeing and how things are working for me, and I immediately got told I was wrong. I mean, I doubt I am the only one having the config problem after a migration, but there are definitely plenty of other people in this thread mentioning having general migration issues. Software generally has bugs. I simply shared my experience with bugs I was seeing. To then be told my reality is ā€œincorrectā€, is a little bit surprising as a response.

Iā€™m not sure there is any real way to resolve this other than the method I mentioned (excluding and re-including each device with missing config options), but here is a video I just took to show whatā€™s going on so you guys can at least see it.

I have two locks. The first I show is straight from the migration. The second I show is an identical model lock that I excluded and re-included. The first is missing a lot of information and config options, but the second has them after the exclusion and inclusion.

The video:

Those are battery devices, did you wake the device when re-interviewing? Battery devices require the user to physically wake the devices. This is required during the migration process. If you donā€™t do this, they will never re-interview and they will be missing command classes. Secondly, some devices (like locks) require a long wake window during the re-interview process, meaning you need to keep it awake for an extended period. If the battery device only stays awake for 10 seconds, you need to continuously keep the device awake by performing the wake action constantly.

Locks are exempt from this rule as they use FLiRS.

This is correct, my 910 took about 2-5 mins to fully interview.

Iā€™m still having this issue, tooā€¦

Locks must be included securely. Did you migrate the encryption key? It is stored in the binding.

Yes, I added the same key I previously had during the migration.

Now thatā€™s where something may not have worked as I expected. I assumed I could flip the lock every few seconds to keep it awake during the re-interview. Is there another, better way to do this?

But as an added data point hereā€¦ I had the same problem with re-interviewing my multi-relay that powers my garage doors. That is a hard-wired device, so shouldnā€™t have the issue of sleeping during the interview process. I re-interviewed it multiple times over the course of a few days after the migration and never got any config options to show up (same situation as the locks).

Finally, I just went ahead and excluded and included the device again and now all the config options show up.

You are correct, hard wired devices shouldnā€™t act that way. But zwave is the wild wild west of devices and every device behaves differently. Typically wired devices are always awake, but you should always consult the manual of the device.

How do I upgrade a HASS installation to 2021.10.7? In the supervisor it only has the option to upgrade to 2021.11.0. Thank you!