In the state of the union 2019 presentation there was a brief update on the path to Open Z-Wave 1.6.
Short mention of it can be found here.
This sounds like a great path forward. There will be a separation between Home Assistant and Z-Wave meaning that restarting HA will not result in a restart of the Z-Wave network. My initial guess is this will be in a separate docker container like a Hassio addon.
It will then by connected to HA via MQTT. I am unsure how this differs from the existing ZWave2MQTT project but decoupling OpenZWave from HA and from Python will only be a good thing.
Agreed would be good to get some clarity on the difference - I started with Z wave in home assistant but suffered the problem of restarts of Home assistant wrecking the network. I’ve started to use zwave2mqtt but the fibaro roller bllind isn’t working perfectly for me under that.
Probably a stupid question, but when you say “it will be in a separate docker container like a Hassio addon”, do you mean that those don’t get restarted when I restart HASS.IO? I never realized that…
Restarting HASS.IO only restarts the homeassistant container, not even the hassio_supervisor container gets restarted.
Thanks for the info! It would indeed seem to be simplest way to implement what they said in the speech and should hopefully make for a much more user-friendly ZWave experience.
In your opinion (all 3 of you) do you think this will be a breaking change ?
The z wave protocol can’t change, the message structure is part of that protocol so I’m assuming that the MQTT is actually just how they will talk to the z wave hub ? (deliberately provocative to elicit a more detailed explanation)
Thanks in advance
Uh yes… Right now the official zwave is built into the system. This would separate it entirely. People would have to fix a lot of things. The first thing that comes to mind is that you’d have to remove zwave from your configuration and add mqtt.
It’s probably preference by the devs. And it might be easier to use. Who knows, either way, if you’re using zwave2mqtt i don’t think there will be much that you would have to change. It’s all the users who are using the built in version that will have a wake up call.
I would not expect this to be a breaking change. It’s still open-zwave so I would assume that database formats will be the same and everything can be migrated. The issue is then matching up existing entities with their new mqtt equivalents. It sounds like this might be a separate mqtt system so with the tighter control over it, matching up the entities will be doable.
Would it be advantageous to switch over to ZWave2MQTT right now to mitigate the effect of any breaking changes in the future when the switch does happen? Native zwave has always worked well enough for me so I’ve never really given it a close look.
qt-openzwave is written by the OZW developer. zwave2mqtt is part of the OpenZWave organization on github, but it is written by another developer.
As I understand it, qt-openzwave will be more general purpose than mqtt, it will also replace the OpenZWave Control Panel (nothing to do with the HA zwave control panel). MQTT will be (one of?) the way(s) of providing an external API.
Both will have the same benefit of de-coupling the z-wave network from HA, so restarting HA will not take down your network, and you could locate the z-wave “hub” anywhere you want.
At this point, I’d go with a “wait and see” approach. For all we know, the official migration could be as simple as pointing a container to the existing db and letting it migrate itself. Unless you are having issues with your existing setup, you could end up putting in a lot of effort into something you don’t need to do.
Depending on whether or not the HA devs will be able to transition existing native z-wave users to the mqtt version could be a reason (or not) to switch to zwave2mqtt now. But I do not think zwave2mqtt will be compatible at all with qt-openzwave, so you’ll need to choose one or the other, or transition again later.
I will wait for the natively supported solution. qt-openzwave is written by the OZW dev and uses the C++ API directly, thus it is less immune to breaking API changes. zwave2mqtt is written using the NodeJS wrapper library. It suffers the same problems as the python library, which is breaking changes to the API need major changes in the wrapper libraries (it’s the problem we have today). If the node-openzwave-shared developers and/or the zwave2mqtt developers dissappear one day, you are in the same predicament as HA is today. In fact, it is unclear to me how much support zwave2mqtt has for OZW 1.6 at the moment.
No offense to the zwave2mqtt dev, who is doing great work, but the OZW dev has much more experience with z-wave in general, and more experience with a broad range of z-wave devices. I trust that will reflect in the quality of the qt-openzwave project.
I feel more confident that the qt-openzwave project will be maintained along with the OZW library in the future. I think it’s the whole point of HA going with this approach. Another benefit is that by going with MQTT, it has a much lower barrier of entry to other HA devs. Instead of having to know the intricacies of the OZW C++ API, wrapping it in a python API, and then understanding the wrapper, you are mostly dealing with MQTT. I’d reckon there are many more devs who can deal with MQTT and the topics qt-openzwave is providing than there are who understand the OZW APIs.
I’m very excited about this move. Moving Z-Wave to MQTT was a project I planned to take on over the holiday break due to the many issues in current form (restarts, new devices not fully recognized without extra effort). Now I’m wondering if it makes sense to do that or wait it out.
@cgarwood might we be able to get a timeline on the move to qt-openzwave? And is there anything those of interested in tinkering/testing a bit can do today?
No time estimates yet… I’d love to have something functional by the end of the year but I’m not sure how realistic that timeframe is yet.
The two GitHub links in the OP will get you the qt-openzwave docs and docker image and the current state of our Python wrapper (takes the mqtt messages from qt-openzwave and converts them to python objects). Don’t have much to show yet from the HA component side. Hoping to get that hashed out more this week.
@freshcoast hit the nails on the head with his post. The qt-openzwave route has a few less layers involved to get to MQTT compared to zwave2mqtt and it’s maintained by the core OZW dev, so it should maintain compatibility with OZW changes a little better or quicker.
I’m hopeful we’ll be able to provide a migration path from the old component to the new one for the majority of entities and devices.
