Update on the Z-Wave integration · Home Assistant dev docs

Is there any way for the non-hassio ( :wink:) users who run HA in Docker to easily get the OpenZWave daemon? Is there a Docker image already set up for it outside of the add-on?

Is there any way of seeing what the network contains? I can see in the mqtt messages that I have a node 1 and 2, but no other info, and I don’t have any entities in the integration.
I would really like to just reset everything and start over, but I don’t know if the messages are retained and that’s what I’m seeing.

edit: As a second thought I think I could disable this, start up the regular z-wave and check there maybe?

1 Like

I removed everything and reconfigured from the beginning instead, and now I do see a sensor in the integration! However when I try to add another one I can see in the mqtt that it is discovered but it’s not present in the integration and it’s not showing the same information in the mqtt message as the first one (both are aeotec door/window sensors). Am I missing something maybe? Restart required?

How do you pair & manage new Z-Wave devices using this method?


Maybe I am late to the party by we have been working on an integration using Z/IP Gateway from SiLabs rather than OpenZWave. Using this approach it may be possible to use more advanced Z-Wave features not yet available in OpenZWave such as S2 and SmartStart. This solution could also be certifiable since Z-Wave alliance only allows using Z/IP gateway rather than direct access to the Z-Wave chip.

The project is available here:

If anyone is interested in helping out integrating this into Home Assistant, please contact me.


Pyzwave looks like an official and much better way to integrate Z-Wave. It would be able to support all current features lacking today and all upcoming features.

1 Like

Can someone point me to a thread about what is going on with z-wave? All of the newer builds leave my 30+ nodes unavailable. I rolled back to 103.6 and some nodes work sometimes. This is really a bummer as z-wave has been stable for so long.

Nothing to do with the new integration that’s being worked on - I’d start a separate thread.

1 Like

@marcelveldt and @Tinkerer, forgive what may be a stupid question, but how does this differ from zwave2mqtt? I only ask as I am about to ditch my Vera and was planning on using zwave2mqtt until I saw this.

The zwave2mqtt implementation is communication from HA to your zwave hub (the message protocol within the zwave network will not change, it can’t) For most people who run the zwave stick on their Pi’s this is a VERY short journey.
If you have a LOT of mqtt stuff going on anyway, then you might prefer to keep a standard look and feel to your config, in which case mqtt is the way to go.
If you read this whole thread it will give you an idea about why’s and wherefore’s.
The mqtt otherwise adds another layer to communication.
Both the standard zwave implementation AND the zwave2mqtt implementation are being updated to OZW 1.6 (any following upgrades (OZW 1.8 is being talked about) will be transparent given the new implementation methods). Both will run in their own docker.
It is likely that the zwave2mqtt version will get/has got it’s dockerised version first.
I’m going to be hanging on for the straight zwave version

You pays your money you takes your choice :man_shrugging:

1 Like

Great! Sounds like the way to go instead of the MQTT way mentioned in this thread. Much closer to the source

1 Like

Awesome. I just need some help from someone with experience with Home Assistant development since I have no experience there.

I’m not sure I understand your response. I’ve read the thread but Both the OZWDaemon and zwave2mqtt implementations integrate with the core OpenZWave (and thus the USB stick), and according to the blog post, the OZWDaemon implementation also uses MQTT to communicate with HA. So in my head it seems like the software stack of the two are:

OpenZWave -> OZWDaemon -> MQTT broker -> HA


OpenZWave -> zwave2mqtt -> MQTT broker -> HA

I’m guessing that I am misunderstanding something, and of course that final arrow of getting the data into HA would be different for each approach, I’m just curious what is functionally different between the two.

I read the front page of the attached link you gave to the github repository but I’m not sure I understand.
As I explained just a few posts above this one ‘we’ (as in HA users) will soon have a different access model which will allow a clearer modular api so that future zwave versions can be upgraded seemlessly.
Our upcoming implementations with both run dockerised and you will have options on the standard HA message structure (to communicate with the hub) or an mqtt’ised version for those who have extensive iot device landscapes.
From what it says on the link, it does not yet support unsolicited reports which may be an issue for many users, so I’m at a bit of a loss as what this brings to the party (excuse my ignorance).
I’m guessing from the name that you will be offering access to the zwave hub via an ip (network) port on the hosting machine. So continuing to follow this supposition, I’m assuming you could place the device central to the service area and access it from a remote location (say from HA) via tcp/ip ?

Edit: the link page talks about the api being subject to nda’s as a proprietary standard. Where will this lead you when the standard is to be opened up later this year/early next ?

Sorry if I’m being stupid

There is no mqtt broker in the first option

The major difference is to how people like to construct their code, in mqtt style or vanilla HA format.

That’s my current understanding at least from ALL the posts I’ve read and the news from other sources.

I’m always open to correction but I’m pretty sure this is the case.

Same, but different.

Ultimately the official integration should end up with a UI for managing things in HA, where Z2M won’t. That’s probably going to be the main difference.


It is correct that this is an issue that must be solved. But it is certainly solvable! It “just” needs the listening dtls socket setup correctly. The rest of the logic for receiving the frames is already implemented.

Yes, it could be setup like that. In many cases it will be the same machine.
What it brings to the table is that is does not use the reverse engineered OpenZWave for communication. Instead it uses the official implementation released by SiLabs. This has some benefits and mainly:

  • It could support all latest Z-Wave functionality from day one. Since this uses the reference implementation from SiLabs, and no reverse engineering. The current code already supports both S2 and Smart Start.
  • It’s the only allowed approach for implementing Z-Wave, if anyone wants the product certified by Z-Wave Alliance. This means that, theoretically, Home Assistant could be Z-Wave certified if using pyzwave.

One of the drawbacks is the the Z-Wave USB adapter must be running a specific firmware version, so not all current adapters will work. That’s the comment about NDA. Because it is possible to make it work with any existing adapters but that will require work that I (and the company I work for) cannot release currently. If this may change when Z-Wave becomes fully open source then I will happily release it. And this “add-on” will require that S2 is implemented separately since the software from SiLabs will not be used at all. I hope this makes it clearer?

Using compatible adapter => all bells and whistles will be available.
Using older adapter => all newer functionality must be implemented by the community.

1 Like

Thanks a lot clearer.

Would it be possible to provide a list of currently certified adapters ?

Given that you say ip access would be available over ip to a device with a certified adapter attached how would this device look ? Hardware, OS, any software layers, device integration layers ?
I assume costs for such would just be time of the Tinkerer (pun as one of our moderators is called that too)

Thanks in advance

I am not sure that exists currently. That’s up to the community to test, I guess. The firmware for the Z-Wave chip comes in different “flavors”. For Z/IP it needs the one called “Bridge Controller”. Some may have “Static Controller” that will not work (but could be reflashed).

Some more clarification.
Z/IP = Z-Wave over IP. This is a specification from SiLabs on how each Z-Wave node can be accessed over ip.
ZIPGateway = The software from SiLabs that implements Z/IP. This software exposes an API that is accessible over ip. This is what pyzwave connects to.

ZIPGateway could be running on the same machine as HA or it could be running on a separate. This is up to the user but I guess in most cases it will be the same.

ZIPGateway must be running on the same machine as the USB adapter is connected to. ZIPGateway will do the communication with the USB adapter.

I (and pyzwave) is not behind neither Z/IP nor ZIPGateway. Both is what SiLabs offer and the only allowed approach for implementing S2.

I know that the zwave.me controllers support bridge mode, and even specify that they support Z/IP.