I’m not migrating anything, just starting a zwave network. But I’m completely baffled. All these Zwave JS programs seem to conflict with each other!
I installed Zwave-JS integration, which automatically installed Zwave-JS broker service.
But the integration front-end is too raw; you can only add/exclude zwave nodes. But it allows you to directly add entities to lovelace, which is nice.
So I installed Zwave JS to MQTT for a better front end, which is GREAT. But it seems to conflict with Zwave JS broker.
What am I doing wrong? Do I uninstall Zwave JS broker service, and is Zwave JS built “INTO” Zwave JS to MQTT?
Thanks petro-
Now I’ve lost those zwave entities in lovelace though. “Entity not available”.
What is the function of the zwave js integration? I assume the zwavejs2mqtt is now the broker to the zwave stick AND the front-end, but I don’t know what the integration is for?
"By default the Home Assistant Z-Wave JS integration will try to set up the official “Z-Wave JS” add-on from the official add-on store.
It is recommended to use the official add-on instead of this one!
However, this add-on will provide an add-on UI and has the ability to send/receive data over MQTT as well. So, if that is your thing, this add-on might be for you."
It seems like they want you to KEEP the official add-on that you say I should remove?
Thank you. It directly contradicts the docs in the Zwave2mqtt addon (I show abve) though. So who is right and who is wrong?
My lovelace is broken using the flow chart overview…
this is one of the issues i have with HA as a new user. there are so many ways to do things, half of them are old methods that are no longer valid. Not specifically talking about this one but it just seems all over the map.
i get it and it updates so frequently. I find myself always watching Youtube videos and looking at the date. Anything more than a few months old is probably useless and not the right way to do things anymore.
Seems like there’s a naming problem here; while you might not want/need the MQTT capability with zwavejs, many/most people probably want the management UI that it contains. Seems like that ought to be the default choice, with the MQTT bit turned off if not needed.
The problem with that is that the zwavejs2mqtt container (not add-on) pre-dated the new zwavejs HA integration.
THen at some point the zwavejsmqtt add-on was made from that container.
Then at some point the decision was made to make zwavejs the “official” new way forward for zwave.
Then the zwavejs add-on was created along with the zwavejs integration.
I personally think that the “official” add-on should have been the zwavejs2mqtt add-on and be done with it. With instructions on how to disable mqtt if you don’t want it. It already had everything needed to run zwavejs in HA with the integration including a UI.
The way this was rolled out has created nothing but a mass of confusion on what does what and what is needed.
That’s currently the preferred choice, even from the devs. We all run zwavejs2mqtt for the time being. I’ll make the switch to the lightweight zwave js when all the functionality is available in the integration. Until then, zwavejs2mqtt
Then that would have been a nice bit of info to put out to users.
Right now the seemingly “preferred choice” for everyone is to use the zwavejs add-on without mqtt. And it’s further reinforced by the integration suggesting to install the non-mqtt add-on.
I fail to see why the devs always seem to overly complicate things to the detriment of new/inexperienced users.
And having another zwavejs add-on apart from the mqtt add-on serves to do nothing for them but spread already thin resources over two add-ons instead of focusing their efforts on one really good one.
There was way too much time spent re-inventing the wheel and what’s worse is the new wheel ended up not rolling as well as the previously invented one.
If they decided later to make one that was more “lightweight” then they could have done that then after the initial dust had settled.
But the damage is done. Time to get back to answering the same “what’s the difference between these?” and “why is there no UI?” and “which one should I install?” questions that have been answered hundreds of times already.
HA can’t just go to the devs of zwavejs2mqtt and say “we’re taking over this project”. And it’s only the preferred way for right now, until the other functionality returns. The official docs even recommend it for the time being. Not to mention, the zwave_js python server is a bare bones container, it’s not really reinventing the wheel. All the work is going into the integration for the added functionality.
If a new user uses the ZwaveJS2mqtt addon, without following instructions - then ZWave will magically start working, BUT - because they haven’t followed the instructions to the letter and actually turned OFF the mqtt section, then all their ZWave devices will be duplicated in Home Assistant. Thus “officially” pushing people to install the addon that doesn’t include mqtt, means that the chances of the support channels being flooded with people wanting to know why they have copies of their devices is lessened.
Which is my point. Imagine how many forum posts we would get daily from people wondering why they have a copy of every ZWave device.
EDIT: For an idea how how frequently we would see that question, pop along to the Chromecast reddit and see how often people complain that their Chromecast has vanished, and they are told - to try rebooting the router, and lo and behold, it fixed the problem.
I’ve been spinning on trying to get things working with all the different approaches for zwave-js for months now. I’m very detailed oriented and apparently didn’t get something precise at the beginning. There are just too many pathways explained in different places, and terminology is clear to those who wrote the guidance but not so much to people who try to follow it.
So add one more thing to all the repeat questions: How do I clean up so that I’m at a valid starting point for trying again?
I love the design of the HA system, but zwave-js has been a massive disaster for me, and evidence shows, for many other people.
