ZWave JS to ZWaveJSMQTT

You do not have to rebuild the z-wave network. That was one of my main fears also. That said, if you start doing random stuff - you may find yourself doing this. Hence the purpose of the migration guide I’m starting on.

If you are running on dedicated hardware (like a pi), my first recommendation is to get another one as you’ll need that to stage your test system while working through the migration process. You’ll move the zwave stick carefully from one system to the other and back as you work through the process steps on your own time. While I’m on docker the same principals apply. I’ll switch the network over to the test system, work on the current process step for an hour or so, then switch back to the existing system.

EDIT - I’m on the wrong topic here. I’m talking about zwave deprecated to zwave_js migration. This topic is about zwave_js to zwavejs2mqtt migration - which I have no experience with. Apologies for the off topic content.

Like it, as you know I found functional differences on devices like motion sensors, water sensors and switches that have required application rework. Since I don’t like surprises, the parallel system approach that @finity brought to my attention has allowed me to work through these issues one by one on my own time and switch back to the working system in between. If I had just migrated as documented, I would have been in a world of hurt with sketchy supervisory control on the HVAC and water systems, alerts not occurring, etc.

I’m not casting any criticism on your guide, it’s just not really relevant to this discussion, which is switching from the Z-Wave JS Add-on to the ZWaveJS2MQTT add-on. Switching add-ons is much different, and simpler, then migrating from Legacy Z-Wave to Z-Wave JS. There is no behavior change from the perspective of HA.

there was a post made by petro in one of the guides on switching from the old zwave to the new zwavejs that talked about how to switch from the zwavejs add on to zwavejs2mqtt by copying the zwavejs database from one addon to the other.

I can’t find it easily tho so you will need to read thru those if you want to find it.

I haven’t ever done it myself so I have no experience with it.

Yep I’m on the wrong topic. Apologies.

The official documents say this:

"
How do I switch between the Official Z-Wave JS add-on and Zwavejs2Mqtt?

Switching does not require renaming your devices.

Disable the Z-Wave JS integration. Do not remove the Z-Wave JS integration or you will lose all device and entity naming. This will automatically stop the official Z-Wave JS add-on.

Note your network security keys from the official add-on.

Install and configure the Z-Wave JS to MQTT add-on, including setting the location of your Z-Wave device and the network security keys.

Add the Z-Wave JS integration again (even though it is still installed), and uncheck the “Use the Z-Wave JS Supervisor add-on”. Enter the correct address for the community add-on in the URL field in the next step.

Uninstall the official Z-Wave JS add-on.

Enable the Z-Wave JS integration.

"

Just in this topic is posted this:

According to that, the guide is incomplete and will likely fail.

I CAN’T try this just to test in a house, where everything is hanging on HA. Do you hear the family members already:
Is it failing again? Why do i have to poop in the dark?

And I can go like this for a while. I’ve seen many different topics about this and every topic says something else and everywhere I see problems passing around.

I can’t migrate ZWaveJS to ZWave2MQTT without a guide, that assures me of being safe.

Actually I still hope, that ZWaveJS will be updated according the roadmap, but it is told me already, that no one knows, when it will be done.

Hopeless, that’s the only state, I’m in now. How more I try to find the needed info, how more hopeless it make’s me…

1 Like

I’m not 100% sure of that.

the post I was referring to was made a long time back around the time that zwavejs was being introduced.

Maybe things have progressed since then or maybe more knowledge has been attained on how to do the switch.

It is very possible that since the controller software runs the same on both add-ons when the database is created on the new zwavejs2mqtt server HA won’t see a difference and just pick up the old names for the new server.

I know that is a lot of “maybe” but that’s the best “hope” i can give you.

Copying the cache files from one add-on to the other just saves you time. In that case there’s no need to re-interview the devices.

Either way, nothing is lost in the network (that’s stored on the controller) or nothing is lost in HA. As long as you follow the instructions.

I’ll ask again, what part of the official instructions is not clear? There has been no concrete answer to that, only hand waving and references to out of date guides, experiences, or here-say. Perhaps the docs for this FAQ could be improved, but not without some input.

I’m the OP and these are my feelings exactly.

Every discussion on this seems to go off the rails into ‘legacy’ Zwave. Let me try to clarify my situation.

I have the Zwave JS integration AND the Zwave JS add-on. I run Home Assistant OS. I want the additional features of ZWave JS MQTT, like network diagnostics, backups and firmware updates. I don’t actually need MQTT.

The mesh network data is in the controller - so why do I need to worry about a “cache file”? . I don’t know where the HA namespace live - in the integration?

If all I need to do is replace the add-on, does that guarantee - in blood - that the existing network and namespaces will not be affected?

When replacing the add-on, what exactly must I do with - or to - the integration?

1 Like

Copying cache files as possibility is not mentioned in the guide.

If you don’t do it, you need to re-interview device’s, i see. It is not mentioned in the guide. So if I did not read it here, i will end up with unforeseen problems, that I can not address.

That are only two things, i get out of one sentence in this conversation.

How many of such unforeseen possibilities are still hidden from my eyes and i will find them on moment supreme, not being ready to deal with it?

That’s what I mean. It all is confusing…

Hardly any of my z-wave devices were successfully interviewed on the first attempt. Or the second. Some required a full-factory reset right out of the box, which was some combination of hold-this-push-that-wait-30-seconds. Many had to be explicitly removed, and some even made that a struggle. Eventually I got them all working and by then I already wished I’d never heard of z-wave.

So anything that might require me to re-interview everything is a total non-starter. I’d rather just sell all the z-wave and start over with wi-fi.

I’m trying to get to ZWaveJS MQTT so that I can deal with problems - not just create new ones.

Step 3. in the guide says:

Install and configure the Z-Wave JS to MQTT add-on, including setting the location of your Z-Wave device and the network security keys.

configure. OK. What questions I can expect? do I need to prepare something? As I can’t see the configuration window anywhere, it is a step in the dark… Maybe to get stuck with questions, I do not have ready answer. Nice, half way of a migration.

Copying cache files is out of scope of that document. It involves using undocumented/debug functionality to access the add-on containers. Or, you can make backups, modify them, and re-upload them. If the guide as-is is not understandable, adding this information would make it even more difficult.

What some seem to be saying is that we don’t need to “re-build” the network in the sense of doing inclusion on every device all over again - but we may need to get them all re-interviewed. Because apparently there’s a cache file containing all that.

Having said that, I’m sure someone will jump in an say I’m wrong.

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…