And if it’s not too onerous for you to do it I would switch to zwavejs2mqtt. It gives you such more fine grained control/info about your system that you can use for troubleshooting.
I started using zwavejs2mqtt from the beginning (I don’t use a Supervised system so never had the option - not that I would have anyway ) and I’m not sorry at all.
Yep, I swapped multiple times back when this was first rolling out before it was released. If you swap the cache file, home assistant doesn’t even see any change and you don’t have to reinterview. The only reason I haven’t written a guide is because I don’t use HassOS and I don’t know the file locations on HassOS.
I’ve created a guide for switching between the add-ons, while preserving the cache files. If you can handle using 7-Zip to modify some some backup tarballs, then it may save you some time.
A lot of my confusion comes from terminology. Experienced HA people probably don’t realize that users like myself don’t understand why there’s both an “integration” and on “add-on”. And when you say “driver”, is that synonymous with “integration”?
Also, I was never a Linux guy so I don’t know what “Docker” or “container” mean. I think that’s because I’m not using either. Of course it’s my responsibility to learn enough about linux to manage HA, but that’s a long term goal and as Don Rumsfeld famously said, we don’t know about the unknown unknowns.
Docker is a containerization (like virtualization) engine that allows you to run apps in their own environment to ease deployment and maintenance. It runs on pretty much any OS (windows, linux, etc)
Containers are the things that run in Docker.
If you are running any version of HA besides Core in a python venv (if you were you would know) then you are running Docker and using containers for your HA stuff. including all add-ons.
No.
the driver is what actually communicates with your zwave controller device.
the integration is what allows HA to communicate with the driver.
zwave controller ↔ driver (now zwavejs or zwavejs2mqtt add-on) ↔ zwavejs integration ↔ HA
It has become more confusing since the add-ons seem like they are part of HA but they aren’t. they are external apps running in their own docker containers but managed by the HA Supervisor. You have to actually install those by telling the Supervisor to install them.
integrations are normally built right into HA itself (unless you run third party custom integrations but we will leave that out) and they are all installed when you install HA itself.
When you configure an integration you aren’t actually installing the integration since it already exists in the code of HA. You are just telling HA to start using it.
Add-ons don’t exist anywhere in HA until you tell the Supervisor to install them. And the they are available to configure.
Add-ons are additional standalone third-party software packages that can be installed on Home Assistant OS. Most of these, add-on provided, applications can be integrated into Home Assistant using integrations. Examples of add-ons are: an MQTT broker, database service or a file server.
Integrations connect and integrates Home Assistant with devices, services, and more. Such an integration contains all the logic that takes care of vendor- and device-specific implementations such as authentication or special protocols and brings those into Home Assistant in a standardized way. For example, the Hue integration integrates the Philips Hue bridge and its connected bulbs into Home Assistant, making them available as Home Assistant light entities you can control.
There’s a Z-Wave JS add-on because it’s a separate software application. There’s a Z-Wave JS integration so that HA has a way to talk to the Z-Wave JS application.
Sort of hanging on by my fingernails here, but it sounds like HA included a component that interfaces with the driver for a ZWave controller stick and yields some degree of ‘integration’ with HA, but not enough to actually do anything - that requires an add-on. And now I’m confused again because both the integration and add-on have some UI for interacting with the Zwave network and devices.
But I don’t need to understand all this, and that was never my intent. I just wanted the additional management of the MQTT add-on because it should help me deal with some problems I’ve been having with my ZWave devices and network.
The new guide helps a lot. Here’s my takeaway - I could move to ZWJSMQTT and let the interviewing proceed on its own. The ZWJSMQTT UI would show me the progress, and a lot of other things about my network and devices. So if my past issues were due to lack of range, I’d now have some information to go on. That re-interviewing might all succeed, but if it didn’t, I could still do the thing with substituting cache files in backup archives, restore from a modified backup and get it all back the way it was. There’s apparently no way I’d lose the mesh itself - the included devices, their identities and routes.
Longer story - it’s a bit scary, so read every line of that procedure before starting. I didn’t do the ‘time saving’ modification of the backup archive, because I didn’t need to: the new round of interviews completed in a couple of minutes without issue.
There’s one minor oversight in the procedure at Step 10. I noted the details in a comment on the page for the guide.
So far, so good and the network diagram displayed by the JS MQTT add-on has already shown me what I think is the source of the range problems I’ve had - the first hop from my controller is to a device in the basement, and everything else links to that device. I don’t think this makes sense and I may try to change it.
Last I checked in 2021.3, there was less than 0.1% (~110) of installations using Zwave 1.4 on the analytics with about 11% (~12500) using ZwaveJS. I.e. most people have migrated and gotten what they need out of it. The remaining people who are switching as we speak are the very last (few) people to make the migration.
FYI, don’t trust that graph in ZwaveJS2MQTT to be your routing table. It’s just a pretty graph. Last I checked, the links it make do not necessarily match the routes things take. Many people have complained to ZwaveJS2MQTT about this.
EDIT: When I say “last I checked”, I looked into it about 6 months or so ago. It could have changed since then.
Yes it would be even nicer if this great information was actually correct. But how does anyone know? What other means does any non-developer have to see the routes?
Unfortunately, that’s beyond my knowledge. I vaguely remember that it would need to be built into the server (z-wave js) in order for it to be available in zwavejs2mqtt with proper routes.
EDIT: Well, looks like it’s on the roadmap. So that’s a plus.
And of course, I just took myself off of that roadmap by switching to JSMQTT. I guess I’ll see what turns up in ZWaveJS and hope that switching back - if necessary - is a possiblity.
) and I’m not sorry at all.
