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

Blog
30

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
31

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

1 Like
32

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

33

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

and

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.

1 Like
34

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

35

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.

36

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.

2 Likes
37

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?

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

1 Like
38

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

39

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.

40

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

41

Z-Wave is now implemented in hass by leveraging a python wrapper around OpenZwave, this leads to multiple issues, most important that the python wrapper can’t cope up with changes in the (O)ZW specs. And there’s also usability. The Z-wave mesh takes a little time to start as it needs to interview all nodes. Because OZW is the controller and it’s directly attached to Home Assistant, restarting Home Assistant leads to restarting the Z Wave mesh.

What we want to do is detach the OZW Controller/mesh from Hass and that’s where the OpenZwave Daemon jumps in. It’s maintained by the developers of OpenZwave itself so directly at the source. It “translates” the Z-wave mesh (serial API) to deliver it to connected clients (such as Home Assistant). It uses MQTT as the transport protocol because it’s well known and easy.

So the new Home Assistant implementation is just one of the clients for the OZW Daemon, there will also be a control panel etc. Or attach OZW Daemon directly to other platforms like Node Red.
So you can see this OpenZwave Daemon as an alternative to the Z/IP specification, living in the open source/community world.

Zwave2mqtt is a node wrapper around the OpenZwave library, translating the mesh and it’s devices into MQTT topics. It’s goal is to use MQTT to communicate with Z Wave devices while in the OZW Daemon approach (where we’re working on), MQTT is only used as transport between clients, no translation happened yet.

Z/IP is the closed source approach but would require special hardware/hubs or additional software licensing costs. See it as a proprietary hub and OZW as the opensource software hub. It can also be implemented into Hass, just like other hubs like Hue, vera and such.

To sum it all up:

Current Z-Wave component in Hass: openzwave 1.4, wrapper around ozw. Will most likely be phased out once new implementation(s) are better.

Zwave2mqtt: NodeJS wrapper around OZW libs, very actively maintained and provides full functionality. Translates Z-Wave mesh with all it’s devices to MQTT world, to be used by every platform that understands MQTT, including Home Assistant offcourse.

New Z-Wave component (as discussed in this post): Will be an official homeassistant component to replace the current Z-Wave component and translates Z-Wave mesh/devices into something HomeAssistant can understand. It’s talking to the Z-Wave mesh through the OpenZwave daemon using mqtt as the transport protocol.

Z/IP: Is not supported yet by Home Assistant but in theory the new Home Assistant component should be able to also talk to Z/IP gateways instead of/in addition to the OZW “gateway”.

14 Likes
42

@marcelveldt Thanks, that’s very informative.
So I was wrong when I told @zacs 'there was no mqtt in the “HA New Z-wave Implementation” ’
To be honest I’m not sure why it’s there as the MQTT structure doesn’t extend into the mesh (but then it’s a closed proprietary system, so maybe it does ! ) and I suppose any wrapper needs “A” protocol. and mqtt is a common open standard.
Given this, it sounds like the “HA New Z-wave Implementation” will be the one containing the extra layer and the Z-wave2MQTT one ‘more native’ - that is unless mqtt itself is a layer on HA itself so mqtt translated in, processed, and then translated out again.

This is all quite confusing :crazy_face:

Given that I generally run “as vanilla as possible” and as the statement by Fishwaldo and others that future ozw upgrades will be modular and transparent, I think I’ll stick with that.
Further, when the standards are ‘opened up’ then there will be ‘something’ put in the ozw slot so it will probably be rewritten as needed or as an ‘official core’ dropped in (with suitable modifications around it to accommodate it).

@Tinkerer given the current explanation of Z/IP, the avoidance of discussing cost and (to be honest) my conceptual usage scenarios … I don’t see what benefits Z/IP would bring me. So again I’ll be taking the vanilla route.

Thanks to all for educating me :+1: and the time (and patience) required to do it :smiley:

43

@marcelveldt - Thank you. This is a very helpful summary (and overview of the alternatives). I think it would be useful if this (or something like it) made it into the HA Z-wave docs at some point.

I have a question about topology:

For the new Home Assistant Z-wave component that uses MQTT as the transport to talk to the OpenZwave Daemon, is an MQTT broker required in the middle between the OpenZwave daemon and HomeAssistant?

(Or will the OpenZwave daemon essentially be it’s own broker to simplify deployment?)

44

I didn’t see an answer above, but perhaps I just overlooked it. Would there be a possibility of migrating our existing zwave devices to this new configuration or will this require rebuilding our zwave network? I like this idea as this is a common pain for me to deal with, but I also don’t want to rebuild my network again as its always such a PITA to redo everything.

45

Hopefully, other options will be taken into account too. I see a benefit that Z/IP would bring to me, such as the latest functionality not relying on “reversed engineering” and, also, implementing S2.

2 Likes
46

Yes, you’ll need an MQTT broker you run. If you use Hass.io Home Assistant you’ll be able to install the Mosquitto add-on. If you use another install method just install Mosquitto.

47

The inclusions are stored on the stick, so as long as you use the same stick there’s no issues. I know the dev is looking at what they can do to migrate all the existing entity_ids so that you don’t have to change anything, but I don’t know what the state of that is.

Worst case, you’ll have to rename some things.

48

Thats totally tolerable and easy to get a backup of if needed. Thanks for the confirmation.

49

Anyone have tried and managed to use the set_config_parameter service call? I can’t seem to format it the right way.
Edit: I tried to do something else than what I thought :smiley: