Yes I agree but I needed a bit of housekeeping as it was a bit messy so good opportunity.
I was waiting for sunset to see if some of my most used automation’s worked and found a few bugs and now the main one that triggers lights to run on when a PIR detects movement in my foyer.
Had enough for today 
More debugging tomorrow
1 Like
I have tried this migration several times now, since the deprecated warnings seem pretty ominous. So far I’ve spent around 4 hours trying to get my devices to work, and am about to restore from a backup. This is the third time I’ve tried a migration from the old system, and while this new system is so awful, I think the HA team needs to think a little harder about deprecating the old one.
There are a lot of issues with the new one, and it doesn’t import almost anything from the old one.
edit
I’m giving up. After leaving it for several hours, none of my devices become ready. Several nodes in the logs report this error:
[Node 023] in the process of replying to a NonceGet, won't send another NonceReport
Just goes of forever like that (with different node numbers)
1 Like
what sort of ZWave stick do you have?
Do you have it on a USB extension lead to get it away from computer as suggested?
It’s on a hub away from the raspberry pi. It works flawlessly with the OpenZWave. It’s a HomeSeer SmartStick+.
From what I read the Wizard was not designed for OpenZWave on the old ZWave.
From the doco
There is no automatic migration wizard for the ozw integration. Please follow the manual migration path below if you want to migrate from ozw to Z-Wave JS.
I am using an AEOTEC Gen 5 stick.
Right on the OZW integration page. If this is not appropriate to run the wizard for OZW, then the link shouldn’t show on that page:
I’m using the Z-Wave integration, which uses OZW under the hood. Are you referring to another integration that uses OZW directly?
EDIT
I’m going to try the instructions here and do it manually: Switching from Zwave 1.4 (Deprecated) to ZwaveJS2MQTT
Interesting step in these instructions that seems important about rebooting between removing the old integration and new one.
yes I was using the really old ZWave and did not go to the openZW.
I suggest that you have a good read of the doco as there are some good tips in it.
I am running a NUC i3 with 8GB RAM and 256 SSD on Ubuntu and docker.
Thanks for the suggestions. I’ve used the ZwaveJS2MQTT and followed the instructions. The UI for that method is MUCH nicer, and all my devices have been contacted successfully. Thanks for poking my problem and pointing me in the right direction.
Just as a follow-up - There are some subtle differences between the way the old integration reads some devices versus the JS version. The one that just caught me and made a bunch of my automation go haywires was under thermostats, the old integration called fan state fan_action, and the new one calls it fan_state. This is also inconsistent with itself in that for havc_modes, the corresponding state is called hvac_action, for for fan_modes, the corresponding state is called fan_state and not fan_action as it previously was. Why the inconsistency? You can’t change it now, since it’ll break people who’ve already implemented using the new, inconsistent attributes.
Compatibility with Legacy Z-Wave was never a goal with the Z-Wave JS integration, so some things will be different, either from developer design choice, or constraints from the driver API and design. Some of these differences may just be due to individual developer preference, perhaps this is a case of that. Or it could just as simple as because the Z-Wave specification and the driver call it “fan state”.
In fact, in Legacy Z-Wave the attribute was originally also called fan_state, then it was removed entirely in the climate platform refactor, then the removal was reverted and it was renamed fan_action, probably to align with hvac_action. fan_action (or fan_state) never became an official attribute.
I think that’s totally reasonable. I think it would just be nice to point out those types of incompatibilities a little more prominently in the migration guide.
The problem is that most of those changes are not known as there are thousands of zwave devices. While that change may be known on device XYZ it may not be known that it also impacts ABC. This is ultimately due to issues with the underlying original zwave. It has many paths, specific to devices that were added, all of which were added as band aides fixes in the early days of home assistant.
My migration failed too. With this in mind, it was too early to deprecate the old zwave integration. zwave js is part of home assistant so I’m stuck on 2022.03 and cant install any updates with newer z-wave.js as this will break my current stable z-wave.
It was not to early. You’re missing a critical step. Most likely the part referencing waking up your battery devices. The migration only helps you link previous entities to the newly created entities. Everything else requires you to manually wake devices. This means you’ll have to get the device manuals out and follow their wake procedures or wait until the devices wake up naturally. Waiting for the devices to wake up naturally and perform the interview can take days.
I don’t have any battery devices. They’re all wired. Mostly switches.
Ok, then where did it stall? Any errors in the logs? Did you start the addon? Which route did you go, zwaveJS or zwavejs2mqtt?
After I was able to restore from my backup, I tried again. The reason for the first fail was due to me not removing zwave: from configuration.yaml. Unfortunately this wasn’t mentioned by the wizard.
So with the second attempt, some of my fibaro covers showed multiple times after the migration. Don’t know why. Also the names of the devices where not fully migrated.
Also for my fibaro double switches, only one channel has been migrated so that its not longer possible to turn on/off the 2nd channel.
I restored the backup again as I didn’t have more time to dig into the issue. Any ideas what went wrong with the double switches and the cover-devices?
Yes, that’s expected because zwave js actually follows the zwave standards and some entities are not a 1 to 1 relationship.
If the cover fails an interview it will show up as unknown/unknown. Once it passes an interview, it will then sow up as the proper product. Remove the one that has a red exclamation. Home assistant (not zwavejs) is holding on to a non-existing entity.
That means it’s not fully interviewed. Reinterview the device.
Yes, everything comes down to interviewing. All zwave networks are only as good as the hardware that you’re using. If you have hardware that’s finiky, it will appear as if zwave js is at fault. It’s not the case, it’s always the hardware.
I have the devices you speak of, and what i’ve noticed is that fibaro devices are just a pain in the butt sometimes. You have to perform the interview task multiple times because the devices don’t want to play nice. I recommend keeping the logs open and watching the interview process in the logs when you reinterview. It will tell you what might be going wrong with the device. Worse case scenario is that you have to exclude and include again. I only had to do this once, ironically, it was a fibaro device.
1 Like
I’ve been using a parallel migration strategy - e.g two different Home Assistants and switching the zwave network between them. This way I can switch back and forth. Once I get the new zwavejs working I’ll do a cutover. I’ve been drafting out the procedure here.
1 Like
I do wonder if having a inventory of devices and known issues / workarounds would be helpful? Would also help folks with selecting new devices.