I made a community guide, you’re welcome to add this information to it
2 Likes
They were named “Product” “Current Value”
1 Like
Installed zwavejs2mqtt 0.3 today for the web interface. It runs fine.
However, after the update to 0.3, I noticed that all my zwave devices were not available in my ui anymore. I had to restart HA to see them them again.
Anyone else experiencing this too?
1 Like
Yes it seems that whenever zwavejs restarts that HA restarts. I use docker for all of mine so I told HA that it depends on zwavejs so this way when zwavejs gets an update and restarts it will force HA to restart. If I have to bounce zwavejs manually I’ll just have to remember to bounce HA at the same time.
position & up & down arrows work. But mine needs to be inverted. In the old zwave 1.4 integration you could add something like this to the yaml file :
cover.rolluik:
invert_openclose_buttons: true
invert_percent: true
Is this already possible with the new ZwaveJS integration ?
3 Likes
Hi all,
I think I’ve found an implementation bug in Z-Wave JS, where is the right place to notify the developers team about it?
Cheers,
-jprates
@JumpMaster, thanks for this. This level of detail and delineation between the two efforts has helped me tremendously to understand what the options really are, and what each piece of the puzzle plays.
Just so I’m clear, in your final comment above, the first of the three options is NOT available to those of us running HASSOS, right? That is, we can either choose #5 to interface to #3 (either using MQTT or sockets) OR #5 to interface to #4, since if I understand it correctly, #4 is needed to interface #5 to #2 in the HASSOS environment. Do I have that right?
GitHub
1 Like
Thanks, it seems someone beat me 2 days ago, glad it is a closed ticket already.
I’ll repost here my question that I already asked on GitHub:
The latest available version I can see of the Z-Wave JS to MQTT add-on is v0.2.3 and it still is not working.
@DelusionalAI mentioned the docker image v1.0.5, any correlation to the standard supervisor add-on?
Trying to get an ETA here…
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.