Years ago I set up my zwave stick on a rPi, running USBIP software to basically pass it over IP to a fake serial port in my Home Assistant, which runs on HyperV as a VM. VM’s there cannot “see” a USB. I would prefer not to change the HA set from the HyperV.
I see more and more information on migrating to Zwave JS, and I suspect my current implementation will not work much longer.
What I would like to do is map zwave to MQTT, then HA can consume the MQTT data. I do not think I even need HA involved in that aspect. Right?
Is the right too ZWaveJS2Mqtt?
And not integrated, maybe in Docker or just NodeJS (I’ll have to check Docker support in rasperian, which I look at only once a year or so).
Anyone doing this? ZWaveJS2Mqtt on rPi, tied to HA elsewhere? Any advices, hints, etc?
Definitely not looking forward to migration, fortunately not that many zwave devices. Any chance that the stick maintains enough of a database so it will be magic?
The stick stores the whole zwave network. The trick will be knowing/copying security keys so your securely included devices can continue working with new software. Without the keys they would need to be excluded/factory reset then included over again.
I started doing this, hit a small question and talked to some of the developers on discord, and offer the following feedback.
The mqtt bridge aspect of this is “practically deprecated” to use their words. not the zwavejs portion however, and they suggested turning off the mqtt portion and using the Home Assistant “WS Server” portion instead (Settings, Home Assistant). Then you install the zwavejs integration in HA, do NOT select supervisor (as it requires a usb), and then point it at this server node/port.
That does an immediate and complete connection, all the interviewed entities come up quickly, no issue. I then disabled a bunch, renamed, and all was well.
MQTT actually seems to work as well, but introduces the broker in the middle. More to the point, they cautioned that the mqtt side of it does not get much testing for new versions.
This is the way I run it too, but there are a couple situations mqtt might work better for some.
One would be you need mqtt outside home assistant. It’s a very light weight and standard protocol that is used by many different home automation services.
This poster makes a good case too that since mqtt is a bit more universal, you don’t have to worry as much as version api schema conflicts between the home assistant integration and the zwave js addon.
Recently, there was a version conflict where the addon and home assistant weren’t updated at the same time, causing users to lose control of their zwave devices. Those using mqtt were not impacted by this.
The nice thing is that even if you dont need mqtt now, it’s a click away from enabling it in the future if you need it.
The nice thing is that even if you dont need mqtt now, it’s a click away from enabling it in the future if you need it.
Well, except I bet they get slightly different entity id’s, especially the ones I renamed (basically all of them). So hardly one click.
I do use MQTT elsewhere, but not for these entities. I like MQTT. I didn’t like hearing it was not likely to get long term support. I’ve never seen so many direction changes, this zwave/ha stuff, since Windows Vista.
Yeah I’m doing this. In my setup zwavej2mqtt and HA run on the same Pi, but it’s all connected over IP, so it could run anywhere on a separate device if you want. Both services run entirely separately, HA doesn’t even know that a zwave network exists (nor does it know about zwavejs). I don’t use the Supervisor, nor do I use Docker. I run HA core in a venv and zwavejs2mqtt runs with Node.js through yarn (it was also built with yarn). All on Raspberry Pi OS (ex Raspbian).
Not only zwave, but my entire home automation setup runs on MQTT, it’s the backbone of everything in my house. This approach decouples all subsystems from each other, connecting them over an industry standard protocol. Each subsystem (including HA) becomes easily exchangeable if needed. While this might be a little less convenient to setup, I’m completely unaffected by HA updates, breaking changes, etc. In fact, the only device integration I use in HA is MQTT.
Nonsense. Sometimes it seems that some devs think that HA is the center of the home automation world zwavejs2mqtt existed before zwavejs was even integrated into HA and is extensively used outside of the Home Assistant ecosystem. zwavejs2mqtt has nothing to do with Home Assistant, it’s an entirely separate project that just happen to have added some HA compatibility.
Maybe they referred to the MQTT autodiscovery part of it. I don’t use that one either, it would yet again introduce a dependency on HA and create problems with updates and breaking changes. I just define the MQTT topics manually and set up the corresponding entities in the HA configuration yaml. This gives me total control over what HA can (and can’t !) do with my zwave devices.
Yes, the conversation was in that vein, the statements were:
HASS discovery in zjs2mqtt is practically deprecated. Not formally but when it breaks we don’t know until it’s reported. And it’s not a priority to fix. Zero developers use it to recognize a breaking change
and also:
The z2m developer even recommends using the zwave-js integration. You can use both if you want, just disable the HASS discovery in that case.
But without HA discovery from MQTT, which is what I think they say do not use, then it becomes pretty tedious to set up.
Probably like many things more work upfront yes, but much less work to maintain down the road and far more future proof. I wonder how much time I waste backing up, updating, dealing with breaking changes, and configuring updates all the time.
Don’t know how often you add new devices to your zwave network, but it’s not something I do every day. And if a new device is added, it’s basically just a copy and paste job in the configuration, editing the entity names to match the new device topics. A couple of minutes top.
But sure, using the built-in zwavejs integration is ‘easier’. In return you tie yourself to them and their update schedules. If you’re ok with this and your main concern is to run your zwave stick on another system, then you can route the websocket connection over the network instead of using MQTT.
Yeah pretty much. As much as I like to tinker sometimes, the main idea behind home automation is to make life easier and not ending up in a perpetual chase up after updates, change logs and adjustments to keep the system working. Now that we’ve come to rely on it, breaking is not an option anymore.
I wanted to get back to this as well after the discussion from yesterday. I try to avoid renaming entities after the integration pulls them in, since it will lead to endless problems with renaming them again and keeping track of it all if you have to reinstall the integration.
One of the annoying things about the zwavejs integration is that when you initially include a device, it immediately comes into Home Assistant with the node name - ie “Node19” and that is the name of all the related entities. It doesn’t update the entity names when you go in and name the device after inclusion.
What I do as a workaround, I leave zwavejs2mqtt running and actually shutdown Home Assistant when I include a new device. I do all the inclusion through the zwavejs2mqtt control panel, then most importantly give the device a “friendly name” so instead of Node19 it is “Entry light” or something like that. After getting it properly included and working, with the name I want, then I start Home Assistant back up and the name of all the entities created are based on the friendly name instead of the nodeID number. Instead of shutting down Home Assistant, you probably can do the same thing by just disabling the zwavejs integration temporarily until the device is properly included with the name you want it to have. I never manage any of the zwave network through the zwavejs integration in Home Assistant, and use the zwavejs2mqtt control panel for everything instead.
If using the MQTT and creating your own templates, that also works around this problem with entity naming because you are creating and naming each entity yourself with an MQTT template.
What software were you using within Home Assistant to provide it the fake serial port which it was able to consume? I want to do something very similar, but I can’t figure out how to add the linux package(s) necessary within home assistant to “receive” the network-passed USB/serial port. Your post has revived my hope that I can do this!
To be clear, my HyperV-hosted VM is running Home Assistant OS.
zwavejs2mqtt existed before zwavejs was even integrated into HA and is extensively used outside of the Home Assistant ecosystem. zwavejs2mqtt has nothing to do with Home Assistant, it’s an entirely separate project that just happen to have added some HA compatibility.