Zwave & Home Assistant Overview

petro · February 5, 2021, 6:12pm

Introduction

Currently, there are 3 different ways to integrate a ZWave network . This is a broad overview of each method.

Zwave JS Addon & Zwave JS Integration (Websockets)
ZWave JS UI & Zwave JS Integration (Websockets)
ZWave JS UI & MQTT Integration (MQTT)

Note: The legacy Zwave 1.4 and OpenZwave (Beta) integrations no longer exist and are not covered in this overview.

Glossary

Addon - Click on the link for a description.
Integration - Click on the link for a description.
Zwave JS Driver - A device driver that interfaces directly with your Zwave USB Stick.
Zwave JS Server - A server that bridges the information from the Zwave JS Driver to a Websocket connection.
Zwave JS Integration - The Home Assistant integration that communicates with the Zwave JS Server through Websockets.
Websockets - A method of communication over a single TCP Connection.
MQTT Client - A client that sends & receives topics to/from a MQTT Broker.
MQTT Broker - A “Server” that contains all MQTT Topics.

Zwave JS

If you’re just starting out, this is the method you probably want to use. With a fresh setup, you’ll be up and running quickly.

Zwave JS Addon is an addon that runs next to home assistant. This means, if the home assistant container unexpectedly shuts down, your Zwave network will still run.

The Zwave JS Addon has the Zwave JS Driver and the Zwave JS Server built into it. The Zwave JS Driver controls the USB Stick, and the Zwave JS Server handles the communication with home assistant’s Zwave JS Integration through Websockets.

Communication Flow

Requirements: Home Assistant Core (Comes with HomeAssistant OS), Zwave JS Addon, and the ZWave JS integration.

ZWave JS UI (formerly ZwaveJS2MQTT, Using Websockets)

ZWave JS UI is an container/addon that runs next to home assistant. This means, if the home assistant container unexpectedly shuts down, your ZWave network will still run.

The ZWave JS UI Addon has the Zwave JS Driver , the Zwave JS Server, an MQTT Client, and a Graphical UI built into it. The Zwave JS Driver controls the USB Stick, and the Zwave JS Server handles the communication with home assistant’s Zwave JS Integration through websockets. The MQTT Client is unused, but can optionally be turned on. The Graphical UI can be used to perform various actions that the home assistant Zwave JS Integration cannot perform.

Communication Flow

Requirements: Home Assistant Core (Comes with HomeAssistant OS), ZwaveJS2MQTT Addon, and the Zwave JS integration.

ZWave JS UI (formerly ZwaveJS2MQTT, using MQTT)

ZWave JS UI is an container/addon that runs next to home assistant. This means, if the home assistant container unexpectedly shuts down, your ZWave network will still run.

The ZWave JS UI Addon has the Zwave JS Driver , the Zwave JS Server, an MQTT Client, and a Graphical UI built into it. The Zwave JS Driver controls the USB Stick, and the MQTT Client handles the communication with home assistant’s MQTT Integration through the MQTT Broker. The Zwave JS Server is unused, but can optionally be turned on. The Graphical UI can be used to perform various actions that the home assistant Zwave JS Integration cannot perform.

Requirements: Home Assistant Core (Comes with HomeAssistant OS), ZwaveJS2MQTT Addon, MQTT Broker, and the MQTT integration.

Migrating Guides

OpenZwave (beta) → ZWave JS UI

OpenZwave (beta) → Zwave JS

Zwave 1.4 → ZWave JS UI

Zwave 1.4 → Zwave JS

FAQ

See the official FAQ

CO_4X4 · February 5, 2021, 7:10pm

Not having played with ZWaveJS yet, would it be recommended to use the MQTT version of it or does the non MQTT version have the tools needed to manage Z-Wave that the original 1.4 had?

sender · February 5, 2021, 8:06pm

Idea: you made some article on how to switch/migrate. But I tend to not easily find them… maybe you can add the entry links in this first topic for ease?

123 · February 5, 2021, 8:43pm

Although I don’t use Zwave, this is a very helpful comparison of the available means to integrate Zwave devices with Home Assistant.

Would it be useful to mention how each approach handles a restart of Home Assistant Core?

For example, perhaps on startup the first one initiates a discovery to acquire all devices and their states. The second one would not need to do that because the devices and states are retained on the broker (I’m assuming the payloads are stored as retained messages).

I don’t know how the other three behave on startup but my guess is that ZwaveJS2MQTT (MQTT) will instantly provide devices and states when Home Assistant Core re-connects to the broker.

Mariusthvdb · February 5, 2021, 10:32pm

Very nice indeed Petro, great work, and o so clear. As I suggested here, where I found this same picture, it would be good to add some extra info on the difference between using an external Mqtt broker and the config using only the Zwavejs2mqtt add-on.

finity · February 5, 2021, 10:56pm

There is no broker integrated with the zwavejs2mqtt add-on. you have to configure a broker separately.

GrizzlyAK · February 6, 2021, 12:09am

This is great @petro! Thanks for putting it together. It does help alleviate much of the confusion that was swirling around the forums a bit earlier. Cheers.

PARitter · February 6, 2021, 12:16am

I asked this in the other thread and got an answer of “should be the same” - but I wanted to confirm with you @petro.

In your examples above, is the ZwaveJS component and the websockets interface the same whether you install ZwaveJS Add On server or ZwaveJS2MQTT (Websockets)? In other words, other than details of the wrapper its running in, is there any functional difference between these two options?

petro · February 6, 2021, 1:07am

They might have slightly different versions but they should be functionally the same. ZwaveJS2mqtt has a different release cycle than HA.

sender · February 6, 2021, 2:22am

So, there are 2 flavours running over websocket? What is the most preferred and future proof?

Zwave JS
ZWAVEJS2MQTT (Websockets)

I think 1. But 2 has

Idea: to facilitate a better way of discussing the options give them a letter: A B C D E.

Mariusthvdb · February 6, 2021, 9:35am

You’re correct, I misworded that. Corrected my post above.

Considering people having the Mqtt Broker installed from before, it won’t be an uncommon architecture. Since these users will most likely also have the Mqtt integration installed.

The latter is missing in the pictures above.

Is the Mqtt integration fully redundant if one uses the zwavejs2mqtt add-on, (as in: can the latter also publish/subscribe to non zwaveJs events)?

petro · February 6, 2021, 11:09am

Picture 4 is without the broker picture 5 is with the broker…

Mariusthvdb · February 6, 2021, 12:58pm

sure.

The combination of the zwavejs integration and add-on and a mqtt broker, but without the zwavejs2mqtt integration isn’t there though.

I do understand this is not the simplest of setups, but as said, many HA users will already be using an Mqtt broker, so would need to see the options available to them.

If only to be able to decide on the last question I posted above.

finity · February 6, 2021, 3:49pm

But the point you seem to be missing is that there literally is no difference. as a matter of fact, there can be no difference. If you use zwavejs2mqtt you have to use a broker. which zwavejs2mqtt doesn’t provide.

Whether it is an external broker or the broker offered by HA (does HA even offer a built-in broker anymore?) makes literally no difference in how this system works.

No, the zwavejs2mqtt platform can’t be used to publish any mqtt topic on demand. And it only subscribes to its own topics. And it shouldn’t be used for those other purposes. the only thing it should do is handle the interface communication between the zwave network and the broker.

And it shouldn’t be.

It has nothing to do with the state of the system that we are discussing.

If someone needs an MQTT broker apart from needing it for zwavejs2mqtt for use in another context then I’m sure the explanation of the broker/client relationship will be done there in that other context.

Mariusthvdb · February 6, 2021, 3:56pm

why to both should’s? I mean, if it’s designed like that, it could be explained better. But for all we know, it could just as well be designed to encompass the full mqtt integration. There’s no place this is explicitly mentioned.

your:

is the first explicit mentioning of that fact. And I am glad you did. thanks.

all, as always, ymmv. In my setup, this was one of the major questions to be answered. As I am sure it will be for other users of the mqtt add-on (broker) or integration…

there’s no such thing as an isolated integration issue.

finity · February 6, 2021, 3:57pm

I just edited my post above. see the edit please.

Mariusthvdb · February 6, 2021, 4:07pm

yep, I did read that. the thing I didn’t see was what you answered here:

Not that I need a Broker to do so.
Still feel not mentioning this variant in the possible configs is leaving out essential information. Guess that is only felt in certain conditions (which I believed to be wide spread amongst the HA user base already using the mqtt integration and add-on).

Glad you filled the gap in what I missed in the explanations up to now. Bookmarked the post. Again, thanks.

finity · February 6, 2021, 4:13pm

not to beat a dead horse here…

But, yeah, you kind of do.

Of course you could, i guess, technically, publish to some topic without a broker receiving it but without that broker to handle the publish command it will literally go nowhere and do nothing. It’s a complete and total waste of time.

Mariusthvdb · February 6, 2021, 4:16pm

I meant:

I didn’t miss that I need a Broker to do so… the sentence was supposed to be attached to the one above the quote…

petro · February 6, 2021, 4:18pm

I’m not creating another image that is identical with 1 word changed. It’s an MQTT broker, wether it’s external to HA or an addon the picture literally doesn’t change, which is why it says “MQTT broker” not mosquito addon.