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.
I too am having the same issue where the migration wizard says no devices can be migrated. Is there no hope of getting the wizard to work? Has anyone found a solution?
I, too, ran into nothing but trouble with migrating - 3 different times. Very frustrated over the whole thing, but in the end, after recovering from backup 3 times, I’ve decided to remain on 2022.3 for the time being. I have about ~30 nodes on my network. Rebuilding it would be a multi-day operation that I frankly don’t have the energy to fight with it. Migration should be a relatively simple, bundled-in, process. Not all these hoops to jump through. I love HA and appreciate all the hard work the developers have put into it, but this, quite frankly, and lack for a better word, sucks.
I sincerely hope others who choose to go down the migration path have a better experience. If so, I might give it another go sometime down the road.
1 Like
Reinterviewing didn’t work. still one channel of the double switch is missing and as no corresponding switch entity.
Edit: Finally got that beast up and running. I had to disable and enable the switch entity.
I hear you. I’ve been working on a parallel system for 4 weeks (swapping the zwave stick between them), I think I’m actually close now to having all my issue resolved, the entity mapping perfected in excel and ready for a cutover. The nice thing about doing it parallel, is I’m under no pressure - work on the new system for an hour or two make some progress, then switch back. Don’t feel like battling it today…no worries 
.
so after migration I’ve noticed that in my case uwagę js is not reliable for production:
Some covers won’t report their position.
One qubino node is marked dead after a while and the only thing that helps is to restart Home Assistant.
Never had any issues with ozw. So even if the nodes have some bady implementation of zwave protocol, it was handled better by the old integration. that’s to bad that we were sort of forced into the new z-wave-js integration.
Respectfully disagree with your assessment. z-wave js is reliable for production. I have been using it since it came out and it keeps getting better. I started with a clean slate and removed and re-added all my nodes (89 devices in total). Yes it is a pain to remove and re-add devices but it has just worked so I consider the pain of removing all the devices worth it. z-wave js is also being actively maintained so that alone makes it worth it.