ZWave JS to ZWaveJSMQTT

No, you wont a have to switch back. Both Zwave JS addon and ZwaveJS2MQTT use a ZwaveJS server.

1 Like

Yes, it’s complicated. But ZwaveJS is the driver that runs the zwave stick. ZwaveJS addon is a “environment” that just runs the ZwaveJS driver and passes information to a websocket. ZwaveJS2MQTT does the same thing, but has a nice interface paired with it. ZwaveJS integration talks to the ZwaveJS server through the websockets.

ZStick ← → Zwave JS Server ← → Zwave Integration in Home Assistant.

There are 2 addons that host a zwaveJS server. ZwaveJS Addon and ZwaveJS2MQTT

So, these are the 2 ways to run it:

ZStick ← → ZwaveJS Addon (w/ Zwave JS server, the driver) ← → Zwave Integration in Home Assistant.

or

ZStick ← → ZwaveJS2MQTT Addon (w/ Zwave JS server, the driver) ← → Zwave Integration in Home Assistant.

1 Like

No switch back needed, you can kind of glean some of the route data if you look at the debug level logs of zwavejs, you may see some bits in there about RSSI and if it routed via another node.

Example:

2022-04-11T00:00:04.524Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            51
                                    transmit status:        OK, took 10 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    ACK RSSI:               -31 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0

Obviously, a nice graphical map of the mesh and its devices (with HA names, not just node numbers) overlaid with things like signal strength, error and retry counts, would be great and would also sort of fulfill the original promise of ZWave.

Without this information, the answer to every problem seems to be to just keep buying and adding more ZWave devices until they all work reliably.

1 Like

Update: having accomplished the switch, now I need to go back - from Z-Wave JS MQTT to Z-Wave JS. Because with the MQTT add-on, my network has become totally unreliable.

The pattern is this: I notice a device has stopped working; I check the Z-Wave JS MQT web UI and see several Z-Wave devices with a Status field showing the angry-red-face icon. I manually restart the add-on, instantly the status is ‘good’ again and the devices are working.

This has happened at least 3 times in the few days since I made the switch. Before that, things had been stable and reliable for months. I guess all I can do is go back to the standard add-on.

So… essentially the same steps to switch FROM Z-Wave JS MQT back TO Z-Wave JS?

Basically, yes.

Did you revert back and did it resolve your issues? I’m not seeing the troubles you spotted, but am curious about how one add-on can have this effect versus another when it’s the Z-WaveJS server underneath that’s actually responsible for doing all the work.

I told myself I’d make the switch the next (third) time this happened - but it hasn’t happened again and it’s been about a week.

Happened again. This time, just one device went ‘unavailable’. As before, I restarted the ZWaveJSMQTT add-on and the device immediately came back.

For now I may try to go back to the other add-on and see if that helps.

But I think that eventually I’ll have to bite the bullet, replace all my ZWave devices with WiFi equivalents - and forget I ever heard of ZWave.

QUESTION: Does anyone have a ZWave network that’s really, truly 100% stable long term?

They both use the same brains. Switching back isn’t going to do anything. Post your logs so we can see what happened.

Yes, I haven’t touched my zwavejs2mqtt since I set it up. zero problems, multiple upgrades, ~100ish nodes. Set it up January 2021.

I do

Yes. My zwave network is the only part of my entire home automation setup that I would really consider 100% stable without any upkeep or occasional tinkering and which I can blindly rely on. If home automation was purely about reliability (rather than fun of tinkering around), zwave is the only thing I would keep.

Using zwavejs2mqtt (but without the HA zwavejs integration).

1 Like

Just when I thought I couldn’t be any more confused by the architecture of Zwave in HA.

How is it possible to do anything without an integration? Isn’t that the part that creates the devices and entities?

Over MQTT (everything in my home is over MQTT). My HA doesn’t even know the zwave network exists, everything zwave is exclusively managed by zwavejs2mqtt. I create the entities manually as MQTT entities in configuration.yaml.

I do not recommend this method if you’re not a technical user, it’s considerably more complex to set up.

I suggest you take a look at the overview. It’s much simpler than people make it out to be.

I just update the overview to hopefully shed more light onto the situation.

Link? Don’t make us hunt for it.

Look 1 post above my last one…

I looked at the overview. I get it, sort of. I don’t know anything about what’s going on at driver level; but apparently, reloading the add-on (driver and server) causes the controller stick to do something that brings back my offline device(s). And if that’s the case I agree that changing add-ons would not be expected to help this problem, and it may be that it’s sudden occurrence after moving to ZWaveJSMQTT is just coincidence.

Of course none of that helps with my problem of devices becoming unavailable.

I’m forming a theory that my problems revolve around Leviton devices - they seem to be the ones becoming unavailable. I’m not certain of this, but getting there. The other devices seem solid.