I tried that but unfortunately it didnt work 
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.