I previously used SmartThings but plan to switch to OZW (beta). I am trying to figure out if ZWave is worth reinstalling with my current home renovation. So I setup a test harness for experiments.
QT C++ will be very hard to find contributors/maintainers
C++ hard to add/modify features, for example this issue
Clunky user experience overall
I recognize things are beta, some of this will get better, and some of this is subjective, but long term I think life may be easier with wifi/bt/other. For the record, the hass integration side seems pretty good.
My code is around 300% faster and more deterministic. Next experiment, can we make it plug and play using same strategy as ESPHome using the existing protocol buffer API?
From my experience, in practice, the OpenZWave (Beta) using MQTT is really pretty fast, and at its best it is way faster than the old integration. And MQTT being a standard protocol, and Mosquitto being very easy to get up and running, I don’t think it is very hard to set up today.
I do have some issues where the ozwdaemon seems slightly worse than the old implementation (sometimes lights are not turned on or off as they should, and sometimes the state is not correctly reflected in HA) - which I never experienced before switching to the new integration. But I blame that on the beta state for now.
But if this can help the Zwave-implemetation in HA become even better, that is really great.
your thouts are similar to mine when I had a look at the code.
I would love to contribute to OZW, but it’s been years since I wrote C++ for the last time and QT is a bit niche. For me the code was quite hard to digest.
I wonder what fishwaldos motivation is to use QT for that.
While I do not mind MQTT, actually liking it a lot to decouple things, I would love to write my own code for ZWave. Which library did you use? thats .NET, right?
@balk77 The code is simply turning on all the lights to compare with turning on all the lights from hass. The experiment was to prove to myself that open-zwave>qt-ozwdaemon>mqtt>zwave-mqtt-python>hass complexity isn’t necessary.
@bernhard Yes, the 35 lines of code is cross platform .NET core using ZWave4Net.
@firstof9 Yes, the underlying library open-zwave is easier to follow but it is still way more code than expected. For example: compare these files:
No, it runs on both my ubuntu and raspberry pi. I never even tried it on windows. .NET core is cross platform and System.IO.Ports is cross platform. It just works.
There’s nothing really inherently wrong with using MQTT as a transport as it’s a popular standard for IoT already. It does, however, add complexity to getting things set up and keeping things running. Essentially we go from running Home Assistant to running Home Assistant + MQTT Broker + OZWDaemon. Each + is a future breaking point due to version incompatibility and the lack of dependency management.
It seems like a decision was made a while back to go this route though rather than update the existing Python integration, but it’s not very clear to me what the benefit of the added complexity is.
My plan so far is to wait for the new integration to leave beta and then go set it up and hope that my Pi 3 can handle the additional overhead. I can’t really dive in and start contributing until then.
There is a gigantic thread that discusses this, feel free to go back and peruse it if you’d really like to know the details.
I’d say the main reasons for this approach are to decouple the two processes to avoid Z-Wave network restarts, and to allow the Z-Wave controller to reside in a separate physical location from the HA host.
If you’re using Z-Wave you should be familiar with the cost (downtime) of restarting HA, unless you have a very simple network. For those with medium or large networks, the cost of shutting down Z-Wave to upgrade HA is just too painful. Once ozwdaemon is stable (it’s not) you would expect to leave it running and only upgrading when really necessary.
Of course, it didn’t have to be MQTT, but that’s what was chosen for the reasons you mentioned, among others.
From my own personal experience, restarting HA has gone from several minutes to tens of seconds (time for Z-Wave to be functional), and I have quite a small Z-Wave small network.
I am using a Pi3 and the cost of adding an MQTT broker (mosquitto) and the ozwdaemon docker container has been insignificant compared to the previous configuration. I definitely don’t recommend it if you aren’t able/willing to troubleshoot eventual problems.
OZW issues a Get after every Set (unless you configure it otherwise). So your test program is not exactly comparable. It would be interesting to see if you have the same results by adding the Gets.
You didn’t mention which version of ozwdaemon you’re using, and the kind of switches you’re using. The latest version currently has some issues with certain switches that could be causing unexpected results. If you’re not using version 0.150.0 then my initial reaction is to be suspect of the results.
I’ve heard people mention the fabled build 150 for a while. I was pinned to that version when the transition change broke everything, but the fix has been applied in home assistant. Are there other reasons to stay with 150?
I noticed that ZWave4Net does not (yet) support the command class “basic window covering”. I guess that means controlling roller shutters is not supported yet?
That makes a lot of sense. I really only have 3 Z-Wave devices on my network, so I’ve never noticed any kind of performance issues myself. It seems reasonable to use some kind of daemon that is communicated to in order to avoid this. Using a message based API (eg. MQTT) vs an HTTP one seems like a reasonable choice given the prevalence in home automation, being able to handle one end or the other going down, and the need for two way communication.
Good to know. I’ll probably move Node Red off to free up a few cycles anyway.
Hopefully the willingness to troubleshoot eventual problems becomes less necessary as time goes on. From reading the blog and following new feature roadmaps, it appears the goal is to simplify things and move away from YAML to point and click.
and yes it works on my Zooz stick.