So there’s a necessary step that’s “out of scope” for the “guide”?
Just when I think I couldn’t be any more confused…
If re-interviewing gives you so much trouble, then absolutely, the official docs’ guide is not going to be a great experience for you. For most people, that’s not a surmountable problem. For you it sounds like it is.
I hope you have good backups. If your HAOS goes poof and you need to re-build, it’s the same scenario.
No one has created a guide, AFAIK, that includes transferring cache files. You’ll either need to wait for someone to do that, take the plunge and accept the consequences, or cobble the instructions from this forum. Unfortunately there’s no easy way to get the files.
Let’s say I decide, against all odds, to go ahead. And I skip the cache file. That means every device has to be re-interviewed, right? Does that happen on its own or do I have to go into the integration and manually do every device? And unless everything goes perfectly the first time, won’t that turn my existing namespace, automations etc into hamburger?
No, copying the cache files is not a necessary step. It only speeds up the switch. I’d say most people do not have too many problems re-interviewing devices.
Yes. That’s usually not a problem. It may depend on your network. It’s the same as if your cache file was lost.
Mains-powered devices are interviewed automatically. Battery powered devices need to be woken up. You do not need to initiate any interview because that’s already started. The first step of the guide is to disable the integration, so you can’t interact with it. You have zwavejs2mqtt’s UI for any interaction at this time.
And unless everything goes perfectly the first time, won’t that turn my existing namespace, automations etc into hamburger?
No. Nothing happens in HA if the integration is disabled, which was the first step. Even if the integration is enabled, nothing will happen. It’s just feels safer to keep it disabled while things churn.
Well, it is not my favorite business, getting a 3 meter ladder from the shelter, stepping on it to reach all the motion sensors hanging under the roof, but I will manage that, AGAIN.
But it still bothers me, that no word about it is said in the guide. If you did not tell me now, I was stuck at the migration, NOT KNOWING, what the problem is…
I can understand, manually waking some devices is a pain. There is a note in the very first section about re-interviews:
This note really applies to any situation where you are switching software. Whether it’s migrating from another driver implementation, or switching applications. The “additional metadata” here is the driver cache files.
freshcoast, thanks for the replies. I’ll re-read all of this a few more times, then I may decide to go ahead.
Also considering plan B, which is putting all these Z-wave devices in one big lot on E-bay. 
I’m going to say this and will (unintentionally…) add fuel to the fire…
I did have one device that I couldn’t get switched to zwavejs2mqtt. BUT I was switching from the old zwave so that might have been the issue.
All I needed to do was exclude and re-include that one device and everything was OK after that.
So there may be pitfalls.
And just to be aware you don’t have to manually wake the device. You just have to wait for it to wake up on schedule and hope it stays awake long enough to complete the interview (I had to manually keep my First Alert smoke alarms awake for several minutes until the interview completed). It’s just usually faster if you wake them up manually.
I even changed the wake-up interval on my devices so they would wake up every hour to speed things up.
So only the device numbers and mesh routes are stored in the controller - all the actual device identity and capabilities obtained by interview are considered “metadata” and are stored in a “cache”?
Yes, this is all true, some devices are hard to re-interview. Because of that, the experience of switching will definitely vary from person to person. This is something no guide is going to help with.
My original point was that switching will not remove or change anything about the Z-Wave network, or the HA entities and devices.
Of course, having the ability to copy over the cache files from add-on to add-on would eliminate any of these issues, unfortunately that’s a guide of its own and not something I have experience with.
Yes, this is correct.
One point I’m still not getting - if the integration does the interviewing, and owns the metadata cache file… and I’m not replacing the integration, just the add-on… why is all the metadata lost?
I still feel like names are going to change.
An this? the last thing, that is really unclear to me…
The integration does not do the interviewing. If you’re referring to the quote above, “When the Z-Wave integration starts up the first time, it will interview your entire Z-Wave network.”, than I can see how that’s confusing. That’s not quite an accurate description. The zwave-js driver does the interviewing. The driver is part of the add-ons.
Nothing will change, especially if the integration is disabled.
The config for the integration is based on the Z-Wave Home ID and device IDs and driver Value IDs (internal representation of devices). When the integration receives the node information it restores everything based on those properties. When you switch add-ons, none of those change.
Prior to 2021.12.10, you could lose your device customization if you did this process while the integration was enabled. That has been fixed since then.
1 Like
There are add-on docs if you want to read ahead. I posted them here:
Without seeing a block diagram of this add-on/integration/driver/controller architecture, it’s tough sledding here.
After interview, I get device and entity names. I’ve changed some of those names to make them useful. Where is that namespace? How do I know MY names will still be associated with the right devices? If not, my automations and scripts break.
UPDATE - I think our posts just crossed. My names are bound to something analogous to a device MAC address?
There are some diagrams here: core/README.md at d54cb49f3284ee1f7013b35073b6896340deab7e · home-assistant/core · GitHub