The rational is so that the home assistant team doesn’t need to support openzwave in the backend. Home assistant will maintain the simple integration that connects to qt-openzwave. That means openzwave and home assistant can update independently without anything breaking. Also, the BEST outcome out of this is that zwave network restart is not tied to home assistants restart. You can restart home assistant over and over again without waiting for the network to initialize, reducing the chance for ozwave.cfg curruption.
There is no way that home assistant would consider this option and I would personally argue against it because of the reasons listed above. The new path is a much better solution in the long run for all parties involved, including users.
EDIT: I forgot to mention, seeing that qt-openzwave is managed by the openzwave team, users will get constant updates/fixes.
The new component actually started out trying to track an updated version of python-openzwave (by a different author than the original python-openzwave), but we gave up on that project after there were multiplebugfix updates to python-openzwave that also included unnecessary unrelated API breaking changes. I probably rewrote portions of our component 3 times trying to keep up with the API changes. The author that was updating python-openzwave has since abandoned their update and deleted their repo.
qt-openzwave was already in work by Fishwaldo (lead OpenZWave developer), I believe they plan to use it as the basis for their new control panel. Fishwaldo added MQTT output to it for us and was super receptive to requests we had regarding data structure. qt-openzwave has a number of benefits that @petro touched on, namely that it stays running regardless of HA restarts, which speeds up HA restarts significantly, you can now run multiple Z-Wave sticks on separate hardware from your HA machine, and it’s maintained by the core OZW team, so it should follow along with OZW core updates a lot better.
It adds a lot of flexibility for minimal overhead.
Thanks, i guess this shows that I fundamentally misunderstood what the python integration does. I thought it was also possible for that integration to run separately and it was a design choice to not do that for Home Assistant.
So basically, a well defined API was missing and is now being defined and implemented through mqtt? So in the future other ways of API communication could be possibly added (Say a websocket interface with a python package around it)?
I’m just worried that mqtt will have too much latency I guess, since you’d need mostly packets with qos 2 I’d assume.
Have you actually run MQTT and measured the latency? I haven’t measured, but it seems very fast. There is no reason why it should take more than a few ms across a network. If openzwave, broker, and HA are all on the same machine it might be only 1 ms. But even if it’s 10 ms, that’s tiny compared to zwave latency.
To me, the huge advantage of mqtt besides separating upgrades is that it’s easy to put the zwave gateway someplace else than the HA server. The downside is just the effort to configure a broker, which I should suggest is lower than the effort people go to with the current zwave system to keep it running.
I haven’t switched yet, but I’m really looking forward to this.
I haven’t no, but I am using mqtt quite a bit and it has at times been unreliable for me. To be fair, these seemed to be bugs in mosquitto and I haven’t had problems lately, but it is still a reason to be apprehensive for an ‘unnecessary’ protocol in between.
I guess you are right, in practice it shouldn’t be slower than a rest api such as deconz uses AFAIK.
I’ve been running the beta for a while now and there are no speed issues from MQTT. The beta (as one would expect) has some issues and isn’t function complete at the moment, but the speed is definitely not one of them. If you want to do the separation of function to allow the 2 subsystems (which are built by entirely different groups) to easily evolve and want to avoid the needless restart of the zwave network when HA updates, you will need some protocol between the two subsystems. Realistically, MQTT is about as light a protocol as will do the job and you certainly wouldn’t want to invent a new protocol for no real reason.
This is great stuff! I’ve got a setup going with the new openzwave integration.
I have a question. Previously I would set the node name in OpenZWave which got stored in the xml cache file. This would cause home assistant to see the device as that name and also appropriately name all entities based on that. This doesn’t seem to work anymore. What’s the best way to name devices in this new setup?
I’ve never really warmed up to HA’s GUI based entity renaming as it’s hard to identify which entity is what and also save these settings.
I had a look at trying this new Zwave Integration.
Unfortunately it won’t allow me to add it. I am using a Raspberry Pi 3B+ and it says the add-on is not available.
Is this purely because it is on a Raspberry or could something else cause this?
The integration is called qt-openzwave for now (I think), until it replaces the build in z-wave integration. And it uses qt-ozwdaemon, and this is what you see in supervisor as an add-on.
