Zwave JS versus ZWave JS MQTT

I have a number of Z-wave devices running on the ZwaveJS integration. I have no need for MQTT but I’ve become aware that ZwaveJSMQTT adds a useful control panel, which I’d like to have.

However, despite a fair amount of Googling and reading old posts here, the relationship between ZWaveJS and ZWaveJSMQTT is not clear to me. I can’t find out whether, or how, to ‘add’ ZwaveJSMQTT to my installation without having to rebuild my Zwave net, or rename entities, or patch names in all my automations and scripts. Maybe that’s not even possible.

Another thing that’s not clear is the development roadmap. Is the future ZWaveJS, ZWaveJSMQTT, or some combination? Is this a fork, or is a merger planned?

If I just do nothing and wait, will ZWaveJS eventually get the capabilities of ZWaveJSMQTT?

Supposedly that is where they want to end up but there is no definitive timeline on when they will get there.

there was a recent discussion of that here:

Thanks @finity. I skimmed the thread you referenced and it convinced me I should have just stuck with wifi and never set foot in ZWave :slight_smile: Obviously I’d need to learn quite a bit about it to make a switch at this point and be confident I could unwind anything that went wrong.

ZWave is great because you don’t need another blo0dy proprietary app with a cloud logon whenever you buy a new device, and the traffic stays off your router. Other than that, it seems to be an ‘interesting’ way to do things, meaning it’s a source of problems.

I should probably invest some time in actually learning about Zwave and how these integrations work, and maybe I will at some point, but for now I’ll just wait for ZWaveJS to be developed further.

I have 25 or so zwave devices and I have almost no issues with them at all. So i dont see them as a source of problems in the least.

But I also have around the same number of zigbee and wifi devices as well so im not married to any one protocol either.

Everything has its use.

Z-wave / Zigbee is not perfect. Neither is WiFi. I have both (89 z-wave and 10 wifi devices). Someone while I was using Homeseer always said: “There is limit to the damage a bad z-wave node can inflict on your system because all the powered nodes can talk to one another.” Wifi has more safeguards.

Have you looked at shelly? I find myself using more and more of them. Just handy. They are inexpensive and they just work. I use mostly ubiquity for my routers and switches. At 4gb throughput I don’t see much load on router or switches. Maybe 30% cpu max. They are getting an ever larger product line as well.

There are some thing that are just plain nice with z-wave. The n-way light switches/dimmers are just superior to shelly. The big reason is flexability in utilizing wiring. Most time in the US the wiring excludes shellies at least on newer homes based on how n-ways are wired. Power comes in one box and load goes to the light out the other. It makes sense when the electrician are installing as you are working from start to finish and the home run/in line is easy to track.

Z-wave js is an incredible upgrade from OZW. My hat is off to the people who wrote and are maintaining it. They have come a long way in a very short time. I am optimistic that they will deliver on what they have said is in the pipeline. It may take time but they will get there. It has come so far already.

Hey - I’m on board! My ZWave devices are all working reliably and I’m not getting rid of them. I’m just not going to install more, until there are some useful diagnostics in the integration - any network needs them. And I need a practical way to upgrade the firmware on my ZWave devices.

Things would be better if I were running HA on my PC, where I could use existing ZWave utilities. But it’s on an RPi4.

I’ve been into HA for about a year, and it does many nice things for me. There’s just a limit to how much time I’ll spend on it, and how deep I want to go.

Not bashing you in any way - sorry if that was the tone!!! Have you thought about shutting down your pi and using the stick on the pc where you have access to the utilities? A pain but it might let you accomplish things until z-wave js has the capability.

Yes, I could move the controller over to my PC temporarily and use something there. Right now I don’t have any problems so I’m not doing anything that might (even possibly) ‘disturb’ my z-wave net and cause HA to start renaming things. I need to move up the learning curve.

As I understand it, knowledge of the intstalled z-wave devices, and the mesh, is partly in the controller’s NVRAM and partly in HA configuration files.

ZwaveJS is a server that runs and talks to your USB zwave stick. This is a privately owned software unaffiliated with home assistant. However Home Assistant and these guys are buddies.

Zwave JS Addon runs the ZwaveJS server. This is an addon created by/for home assistant.

ZwaveJS2MQTT Addon runs the ZwaveJS server. This is a privately owned addon/software unaffiliated with home assistant. However Home Assistant and these guys are buddies.

Zwave JS Integration Connects to a Zwave JS Server. This is managed by home assistant.

You do not want to run 2 servers, i.e. Do not run Zwave JS Addon AND ZwaveJS2MQTT.

Zwave JS is in a much better state than Zwave (legacy) and Zwave (OpenZwave). I’m not sure why you would stay with the old version. Everything mentioned in that thread is basically people not knowing how things are named under the hood and them switching between zwavejs2mqtt and zwavejs addons. Which is doable, however you’ll basically have to Resetup your whole network in between. Which they do not do. And then it doesn’t work and they get upset and create a post like that.

So TLDR: Switch to ZwaveJS2MQTT and you’ll be happy. You won’t lose names either. Unless do things in an odd order.

  1. Switch to zwaveJs2mqtt
  2. Reinterview each node until zwavejs2mqtt shows all correct information on each node.
  3. Rename things in home assistant.

If you do half of step 2 and half of step 3 throughout the process multiple times, you’ll have a bad time. This is EVERYONES mistake. They add and rename at the same time. Add first, reinterview first. Then rename when everything is complete.

And if you’re having issues with a specific node and it does not want to interview yet the device still works. Stop reinterviewing. Just keep it as is and move on. It won’t hurt anything being an unknown device / unknown manufacturer.

I’m already on ZWave JS, not the older Zwave or OpenZwave. ZWave JS has been working well enough for me.

So my interest is in switching from ZWave JS to ZwaveJS2MQTT. Your summary of the architecture is very helpful, thanks.

What I’m unsure about is this: You first say “you won’t lose names” if switching to ZWaveJS2MQT, but then your step #3 is “rename things in Home Assistant”. I have a bunch of ZWave devices, and automations and scripts that use them. Renaming all the entities, or (alternatively) patching up all the scripts and automations, is not an inviting prospect. That’s why I’m going to just stay with ZWave JS and hope diagnostic and management capabilities are added in time.

Ah yeah, then just stay on what you got unless you want help moving to ZwaveJS2MQTT.

If you can move the cachefiles from ZwaveJS to ZwaveJS2MQTT, nothing will change.

If you switch without moving the cachefiles, all bets are off. You may have to reinterview and rename. This purely depends on how far you got on ZwaveJS. If you interviewed everything on zwaveJS and they came through properly, and you did the same thing with zwaveJS2mqtt, they will have the same names as well.

So “cachefiles” are where the mappings from z-wave devices to HA device/entity names are stored?

they are the “mappings”