I tried reading many post but couldn’t find answer so asking here and not sure it’s valid question?
Zwave JS (and zwavejs2mqtt) is using which ZWave version like OpenZwave Beta was based of 1.6? Or this question doesn’t apply here to Zwave JS?
Thanks to all very fast progressing community!
It’s using zwave js, a different software
1 Like
@petro this is a good reference on the various components - having done the migration i wish i had spent more time to understand this before i started although i ended up fine.
One thing though - i believe you have a typo of sorts in the requirements paragraph of the ZwaveJS2MQTT (Websockets) section - i think the last few words should be “and the ZWaveJS integration” - if i understand correctly, there is no ZWaveJS2MQTT integration - only an add on. (& the pic is consistent with ZWaveJS integration)
2 Likes
@yajrendrag I was about to post the same thing and saw your reply - I think you’re correct there.
Could probably also point out that if using ZwaveJS2MQTT, that you don’t need to necessarily be using MQTT - you can run use it for the config GUI and the websockets gateway only
1 Like
I’m happy to report on Friday, I successfully migrated to ZWaveJSMQTT. Because my Home Assistant runs on a Virtual Machine, running ZWave directly on the host has always been too much of a pain to bother with, so my AEOTEC stick is actually plugged in to a Raspberry Pi running Portainer and was running the Docker image for the ZWave Beta (called allinone:latest). I have long had the issue that my Domitech Smart LED bulbs when told to go off, dim to off, and Zwave and thus Home Assistant would report that the light was still on when it was now off.
I did not follow any guides to migrate, because for some reason the Beta of ZWave had suddenly stopped working, no matter how many times I restarted Home Assistant or the ZWave docker image. It took me 10 minutes to get ZwaveJSMQTT up and running on the Pi, and the control panel is very very nice.
It took me about 4 hours to figure out what each node referred to, but had I not stupidly removed the ZWave integration from Home Assistant - I could have just referred to what nodeid was for which device…
Anyway it’s up and running. I’m not using the MQTT portion, I opted to use the Websocket method instead. I can report that the network actually feels faster than it did with the Beta, and it correctly reports my Domitech bulbs as off when they have been switched off.
My Hank Motion sensors were a headache to get working, because they sat on “ProtocolInfo” for hours, and I’m still not entirely sure which of the billion times I woke them got the system to correctly interview them. I don’t think it is a ZWave problem though, my Everspring Door Sensor was recognised instantly after waking it up once.
The Network map, is fantastic.
2 Likes
I am running Home Assistant Container so no add-on as such in this case.
If I run ZwaveJS2MQTT in another container, am I right in assuming it will be totally equivalent to ZwaveJS2MQTT (MQTT) ?
Depends on what options you run in the GUI for zwavejs2mqtt. If you turn off the mqtt communication, it’s like running zwavejs2mqtt (websockets).
Thanks. I was (kind of) confused by the use of the term
instead of just ZwaveJS2MQTT container
The addon is just a container with specific settings for hassos.
Which is more stable and more likely to be the final system. I’m trying to migrate an indigo system to HA and am finding zwave to be rather intractable and scary.
Any of the Zwave JS ones have the best outlook at the moment.
What is the advantage of using zwavejs2mqtt with websockets vs mqtt? Isn’t mqtt a very lightweight protocol vs a full tcp communication to pass the info?
I’ve migrated this week-end form OpenZWave 1.4 to ZWaveJS2MQTT.
I have first tested through websockets, it worked but I had disconnexions, I don’t exactly what but I didn’t have any statut update from ZWave entities in HA, every few hours I had to restart either ZWaveJS2MQTT or HA.
I then activated the MQTT Gateway and disables websockets. And everything has been working fine since.
I guess an advantage of using websockets is that it will be easier to move to the official ZWaveJS addon when it will be a little bit more mature. Websocket are maybe the same in both addons ? and so HA entities created with ZWaveJS2MQTT will be directly usable by ZWaveJS ?
Using MQTT currently, I might have again a few hours of work to rename all my entities in HA when I will switch to ZWaveJS I guess. 
Yes, I can see your point from the user space perspective. But from the developer’s point of view, why choose websockets over mqtt in ZwaveJS? I thought it was a brilliant MVC implementation using mqtt. Is the change to websockets related to HA topology (you get smother/ more complete integration into HA).
I guess (juste a guess again) that websockets are embedded in ZWaveJS addon and do not require another external addon for a MQTT broker.
Using MQTT forces the user to use MQTT discovery in HA which is limited. And for specific devices, it requires more work for a user if MQTT discovery does not support the device. Where as websockets (Long term), everything will transfer via discovery without any work. Also, you don’t have the MQTT middle man and it’ll require less setup and use less resources.
6 Likes
Should zwavejs in the start topic also have (Websockets) behind it?
Not really. Since zwavejs in and of itself can only communicate over websockets.
zwavejs2mqtt has both mqtt and websockets functionality.
So you confirm its websocket…
yes…(10 char min)