Choosing ZwaveJS2MQTT or ZwaveJS?

I’m prepping for OZW to the new zwave integration. I have 79 devices & >400 entities so not looking forward to this task.

Is there any advice on what version to migrate to? Directly to ZwaveJS2MQTT or ZwaveJS? I have read that the ZwaveJS interface has some limitations (to set parameters etc) but not sure if that is still the case.

I’ve been very happy with zwavejsmqtt. Just completed migration of 2 houses. The approach I used was developing on a parallel system and swapping the zwave stick between them. This way I could work on the port for an hour or two and then switch back to the old system. Once I worked through all my issues over a 4 week period, I was able to execute seamless cutovers in 30 minutes on both systems - with all automations, template, history and displays working. As part of it I created scripts to help with mapping. Anyways, if your interested I can provide more details.

I’d personally go ZwaveJS2MQTT addon as it has more functionality than the ZwaveJS addon. Which version are you migrating from Zwave 1.4 or OpenZwave (beta)?

zwavejsmqtt for me also.

@petro OpenZwave (Version 1.4.3469). Does this change your opinion? On the MQTT version; Would the broker in-between not pose an extra element of possible failure? What are the core differences in functionality between the 2?

@PeteRage Been following your posts on your methodology and your extensive write up. I’m using hassIO on an intel NUC running smoothly for years now. Don’t want to play around witch docker etc. A potential strategy could be to take a spare RPI (or spare laptop) and use that to gradually upgrade (swapping the zwave stick in between) and then restore that backup -when finished- to my production environment. Not sure of this would work though.

No, I was only asking because there are migration guides and they differ depending on what you’re currently using.

I would still use ZwaveJS2MQTT. I have a feeling you’re thinking that the ZwaveJS2MQTT version uses MQTT, it does not. It can use MQTT, however you don’t have to. You can use it with websockets so it behaves exactly the same was as the ZwaveJS addon, but you get a nice interface with it and extra functionality.

There are too many to list. Keep in mind they both have the exact same functionality, zwavejs2mqtt has added benefits. It would be like owning a car’s base model vs the fully loaded model. Same car, extra functionality.

There’s no reason why that would not work. I would just be careful to stop the zwave network before removing the USB stick.

As pointed out, there are a lot of differences to list, some not being a big deal (just different UI options to add/remove a device for example, but basic functionality to perform that is there with both). Others for me are deal breakers - The biggest difference between the two I’ve found is that, currently at least, only zwavejs2mqtt can perform zwave device associations and firmware updates. Those reasons alone are why I would recommend it over zwavejs.

Tanks for the input. Seems I will be going with the MQTT version then.

Other question:

I just realize I actually have a second identical Aeon labs Zwave stick gen 5. I can clone that. If I have two identical systems (one production on QZW until ready and one to migrate to JS), would the zwave network automatically connect to the system I would be working on (the other would be switched off) so I can contiguously switch between them for a few weeks so I can do the migration in my own pace?

I have not tried that, but it seems like it should work.

You can do that without cloning it as long as you don’t change exclude/include any nodes. You should be able to switch on the fly in the older versions with backups. If you plan on changing the nodes, then yes, you’d want to clone your current setup.