remove the commas in addition to the ‘0x’ from the beginning.
so “0x34,0x4A,0x7C…”
becomes “344A7C…”
No. Both servers can’t access the same controller device at the same time.
1 Like
ah thanks! and, sounds logical about the controller
Same issue here, I waited this long to migrate thinking all of the bugs would be worked out by now, but the migration wizard said it could not migrate any of my 60+ nodes. Has anyone figured out a solution? Do bugs need to be filed? My feeling is that manual renaming of an entire network of nodes and entities is not an acceptable migration path. There’s got to be a better way…
1 Like
I too waited this long to migrate hoping the bugs would have been worked out. It seems that is not the case.
I did the upgrade and am actually surprised there was no warning message considering the consequences are pretty well known. Maybe something like, “there are 25 scripts and 50 automations totaling 175 different entities that will be affected by this upgrade” would have been helpful.
And then like many others, the majority of the devices did not migrate. The worst part is going to be the renaming of all of the entities to work with all of the old automations and scripts.
I don’t have a day+ to devote to that in the near future, so I have rolled back to the prior backup.
1 Like
Ok, so I finally solved a way to make a backup of ha on my unraid server and tested it out yester day. After that it was time to make a try with the migration. And I have to say that it went very good despite the circumstances. I only have 17 devices and after filling out the legacy s0 key the wizard migrated everything. All my entitynames were lost as I suspected. What took the longest time for me was actually figuring out which device was which. But as soon as I found my system it went pretty smooth. The most important thing was that I never had to re-import any of my devices, even the danalock worked instantly as soon as I found the entity.
Luckily I had a wattage-card that sorted every device from most to least in a list and I knew which most of those devices were. I could rename them from there and afterwards go to the entities page through zwave js integration and find the device and rename its other entities. Also another tip is to just go each physical plug/device and put them online manually (if you have something like the tellstick slim plug that has a button on it), then you can easily find the one that turned on in the entities list and rename it. Or even easier, just turn on the device behind the plug and look for the change in power. And make a copy of all the text on the developement tools page (entities) before you start so that you know all the old entitynames
My 17 devices took me 3-4hours to fix but now its working
PROS:
-The network seems way faster, the danalock reacts way faster now, could be due to removel of dead devices mabye
-I can finally update ha again
-I could remove old devices that I could not get rid of before
-less entities (no zwave. and no “previous_reading”) and a more modern gui with its icons and design in the entities area
CONS:
-It takes TIME to migrate, be sure to have a tested backup
-Cant do much from the integration, its very basic and I’d love to see a separate area for all the zwave nodes/entities and not have to filter the “zwave js” in entities tab
-cant see average round trip time anymore, I had a card that sorted the longest zwave RTT device, nice to have for troubleshooting and knowing where to place your network nodes
one weird thing afther the update of ha is that zwave thinks that my entity sensor.z_stick_gen5_usb_controller_node_status is dead. The network seems to be working though.
Yes, the prior set of node stats was very helpful.
I just completed migrating a house. I’d been using a parallel system for testing for last 4 weeks during my own time (and swapping the zwave stick to it) - to work out the bugs, automation issue and gaps in entity ids and functionally. I highly recommend this approach. Did the cutover in about 1 hour following a 35 step migration process…
Anyways I started creating a tutorial but haven’t seem a lot of pickup so it remains unfinished, glad to work on it if someone wants it,
Update on my migration. I left the migrate window open while waiting for all my nodes to be interviewed. It was updating live for a while but eventually stopped updating the status and timed out. However, I watched status in another window and once all nodes were alive (some I had to intervene and wake manually), I clicked Migrate and it seemed to work for about 90% of nodes and entities. Just had to clean up a few things. Happy to finally be migrated! Now on to research moving to the ZwavejsMQTT version to get the new control panel UI!
From the migration guide:
- Once a node is ready, the entities will be created. Only at this point, is it safe to rename the device (and so its entities). This is actually the only real hard part of the migration as you will need to name all your devices again.
Not cool. Not cool at all. I only have 30ish devices, but I see people here with 100 or even as many as 300.
Why the hell didn’t the Home Assistant crew write a tool to migrate the metadata from .storage/zwave.legacy_zwave_migration into the new database? The data is right there with all of the unique IDs to be able to map them out.
1 Like