What does this refer to?
This comment is helpful. I’ve never (believed I) needed to use MQTT because I’m currently running HASSOS on a single RPi4 for everything, and only to control a BUNCH of zwave devices. Although I dug into it a little, I never really understood why or how one might choose to use MQTT in HA. I get the idea of using it to synchronize multiple instances of ‘systems’ on different HW, with publish/subscribe, but it never made sense for a single instance, as you appear to be pointing out. That always made me wonder why, other than to avoid network restart with HA, OZW chose to use MQTT, which did seem to only addl complexity and delay for a single instance. Perhaps I’m missing other benefits that are obvious to others. I’d love to find a resource that could help me put MQTT in perspective in relation to HA, if you know of any.
Ah ok, I see. I don’t use a docker install, but the supervisor version. So, I guess I have to wait for a fix then.
It’s good to know it’s not just me then. 
THAT sounds interesting. 
I’d be interested to learn more about how all of that works, and is set up.
zwavejs2mqtt is also available as a Home Assistant Community add-on available in the add-on store:
Which work fine with HA zwave-js integration
Home-Assistant uses Integrations to talk out. So your options are either MQTT or the ZWaveJS Integrations (Web Socker).
If you want to use MQTT you need to use ZWaveJS2MQTT. That is hosted in docker.
If you want to use WebSocket you can use any one of the four options. But only The Home-Assistant Z-WaveJS Addon will work inside of HassOS.
Just guessing here, but that almost sounds like a truncation issue with the value. 100 → 10. whereas, everything else works fine, up to 99. 
This little tidbit, if it is indeed a requirement, should probably find its way either into the documentation for zwave-js integration, or built into the code to force it in the UI (for HASSOS users), before this knowledge gets buried in this thread. 
1 Like
Can someone please help me answer this question:
Do the “official” Zwavejs container and Zwavejs2mqtt use exactly the same underlying Zwavejs code? If so, is there any downside to installing Zwavejws2mqtt in a container, enable the Websocket interface and connect that websocket to the new ZwaveJS integration in HA?
I see two advantages to doing this: you get the control panel from Zwavejs2mqtt and you retain the possibiliy of publishing zwave events using mqtt to other (non-HA) subscribers.
As long as the back-end code is identical - which it appears to be - then the only real downside the extra code. I know the HA devs are going all-out to bring the tools you need to the integration. And that they want an “all HA” frontend experience. But for me this seems like the best approach, at least for now and for more “tech savvy” users.
Thoughts?
1 Like
If you don’t have to use mqtt then there really is no benefit to running a broker.
If you have only one piece of hardware that runs all HA related stuff, and none of the integrations require you to use MQTT then there really is no benefit.
As far as I know that is true.
and I agree with the advantages you state.
I’m running zwavejs2mqtt in docker and it appears to work fine. But I’ve only got one node for testing before the full switchover…
Thank you @JumpMaster.
While the OFFICIAL/default Z-WaveJS add-on is not up-to-date with the current state-of-the-art on the ZWave2MQQT this is for me the best solution available.
I’ve read HASS team wants to bring default ZWJS up to speed and catch up with ZW2MQQT and I really hope they manage to do it as it is always better to have it all integrated under one single roof IMHO, but till then this is perfect.
I’ve been running the ZWaveJS2MQTT container for a week and updated it 3 times already. That’s not a good thing! What you guarantee with the Home-Assistant add-on is it will be fully compatible with the Home-Assistant Integration.
I’m fully aware that I might upgrade and find that Home-Assistant does’t work with it anymore and I need to roll back. But it updated some critical database and I didn’t take a back. So I’ll have to wait for the next HA release before my lights work again.
Knowing what I should do vs “it’ll probably be fine”
I don’t think that’s right. Isn’t Home Assistant OS the NEW name for HASSOS?
#1 Requirements : Home Assistant Core (Comes with HomeAssistant OS)
#2 Requirements : Home Assistant Core (Comes with HomeAssistant OS)
#3 Requirements : Home Assistant Core (Comes with HomeAssistant OS)
#4 Requirements : Home Assistant Core (Comes with HomeAssistant OS)
#5 Requirements : Home Assistant Core (Comes with HomeAssistant OS)
I believe am running what you’re calling HASSOS…
Or do I have it all wrong??
yes. you are correct.
I just thought of another possible useful feature that could be added by separating the server from HA.
We could actually use HA to control two zwave js servers. that way if you needed to you could have two physically separated zwave networks and be able to control them from one HA instance as long as they were accessible over the same network. it would just require HA to allow multiple zwave js integrations.
Does anyone know if that’s even feasible and if so if it’s in the roadmap or how the best way to suggest it if not?
I could do a FR but we all know how much attention those tend to get…
1 Like
Thank you!
1 Like
Secondly, if I understand correctly, there are two incarnations, and isn’t the underlying code for Z-Wave JS currently different from what’s in ZwaveJS2MQTT and that there is a desire for them to be merged &/or to merge the ZwaveJS2MQTT Control Panel into the core add on?
or
1 Like
I guess what should really be added in a nice graphical way is that the MQTT broker also handles other Mqtt events, than only those events coming from and going to the ZwaveJS Add-on. It is after all the main distinction between this 2 architectures, and does make the world of difference.
Like this stuff?
Maybe depending on your use case.
But in this discussion it only would tend to confuse things even further.