I know that the zwave.me controllers support bridge mode, and even specify that they support Z/IP.
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
@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 
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 
and the time (and patience) required to do it 
@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?)
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.
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
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.
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.
Thats totally tolerable and easy to get a backup of if needed. Thanks for the confirmation.
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
At this time you need to have a MQTT broker already setup but when we move towards official inclusion we will take care of that in some automagic way 
2 Likes
I think it’s only a matter of time until Z/IP will also be supported. In an ideal world you will have just one Z-Wave component in HomeAssistant and it will take of handling the correct “route” for your situation. Our current route with detaching the hass component from the actual controller is preparation for that…
1 Like
I am actually glad you guys are working on this and cannot wait to see it released in HA stable. Well done and thank you!
Is there any chance whatsoever that this will finally support the Enewrwave zwn-sc7 seven button scene controller? It has been supported by Vera for years and it is the only holdout I have for keeping the old Vera Plus running. I would love to finally get everything all under one roof…
That seems to be up to the openzwave developers. Ask them.
EDIT: which I see you have already done.
Forgive me if it’s been answered, but I didn’t see as I scrolled through.
Will this new and improved Z-Wave system (working with OpenZWave Daemon), allow us to have the Z-Wave controller on a physically different computer?
I have a Razberry GPIO module set up on a Raspberry Pi 3 in one part of my home, but am running HomeAssistant on a Raspberry Pi 4 in a different area. The Pi 4 has a case on it for cooling and mounting, but while it has a GPIO extender built in to get around the fan and heatsink positioning, I’d rather not have the card poking out into the open, especially with 2 curious cats around 
Yes.
It communicates over MQTT. The Z-Wave controller can be anywhere on the planet (or off of it, if you have access to a handy space ship) that you have connectivity to.
So looking forward to this
1 Like
Yeah since long time Z-wave user, this is what i look most forward to in Home assistant
Just got the new z-wave system up and going to test it out, and noticed that it is starting to get merged into the core repo! Thanks for all your work everyone!
Wanted to encourage @mickeprag to continue your work! A future where the one HA integration can work with either the OZW or Z/IP backend would be awesome! You might consider putting a MQTT frontend on your pyzwave work to leverage the work being done on the new HA zwave stuff. I wish I had the bandwidth to help out. Adding ZIP Gateway -> pyzwave -> MQTT broker -> HA would be awesome.
2 Likes