The Future of Z-Wave in HA - QT-OpenZWave

joachimmg · December 18, 2020, 1:24pm

And I will say it again; I’m surprised that HA is building their future on something that is broken.

gcoupe · December 18, 2020, 1:33pm

For the moment, I’ll give them the benefit of the doubt - I prefer to think it is simply a beta, rather than broken.

firstof9 · December 18, 2020, 1:42pm

Working fine here.

sender · December 18, 2020, 1:52pm

For me it is now also running fine for around weeks…

It’s just a matter of time and it crashes again… see my previous posts… it crashed for a week or so every evening… and nothing really changed…

I have a very little suspicion that "widening that network number is culprit

firstof9 · December 18, 2020, 2:41pm

I’m pretty sure the low mqtt keepalive timeout plays a role it the problems experienced.

srwhite · December 18, 2020, 2:46pm

I too find it curious… There have barely been any commits to the repo over the past few months, aside from some XML device profile updates. It doesn’t look like anything has been done on the core in a long time.

That said, it works well for me, until it doesn’t. My implementation (120 devices) is pretty stable unless I’m adding or removing a device, or trying to refresh one. Then in each case it crashes and requires a full restart.

ZWaveJS is looking very interesting. If I were the HA team I would be looking at supporting both.

paulstronaut · December 18, 2020, 3:03pm

Sometimes, nothing is needed. As a software developer, I’ve seen people make this mistake many times. Just because something hasn’t been changed, doesn’t mean it’s not maintained or still a great solution. Often times it means that there are just no problems that need fixing immediately. Sometimes, some core architecture is also too monolithic to change quickly, and so it’s being worked on in a separate branch.

For me, aside from the lack of UI in Home Assistant and needing to use Qt (which doesn’t work on latest OS X) are the only issues I’ve faced with the OZW-beta addon and integration.

All that being said, as a JavaScript dev, the zwavejs project does seem very interesting and promising

firstof9 · December 18, 2020, 3:35pm

I had this issue with refreshing my lock, utilizing a tweak that adjusted the mqtt keep alive timeout solved the issue for me.

I have made the docker image available:
https://hub.docker.com/r/firstof9/qt-ozwdaemon

and the repo it’s built from:

srwhite · December 18, 2020, 4:15pm

Unfortunately I don’t have a stand-alone docker setup at the moment. I’m using OS in virtual on my home server. I will be replacing my home server after Christmas and will be sure to take a look at this.

Thanks!

firstof9 · December 18, 2020, 4:29pm

I have a repo for that as well:

sender · December 18, 2020, 5:06pm

Given the amount of troubles and people reporting issues “sometimes” is not now

joachimmg · December 18, 2020, 5:14pm

I know what you mean, but I feel that everyone have some problems and all of them narrows down to the issues that have been registered and discussed in the repo at github for months. I mean months, for maybe half a year. One of the last feedback from the developer is «should be an easy fix»… But everyone is left in the open, without any feedback/roadmap for what we can expect.

Yes, we know HA is planning to make the move - to a project with an unknown future.

Moving an entire setup of hundred +/- devices is cumbersome and time consuming.

paulstronaut · December 18, 2020, 5:29pm

7 pull requests to the open-zwave repository were merged just yesterday.

Most of the issues seem to be specific to particular devices and lack of easy-to-use UI (which, again, is coming). I haven’t been following very closely and this thread is over 800 messages long. Is there a particular set of issues reported that someone can look through?

sender · December 18, 2020, 5:40pm

Sorry I am not going to make a summary of this and other threads.

paulstronaut · December 18, 2020, 5:41pm

Are they getting reported to the appropriate repositories? They’re all very disparate and developers can’t do much if they’re not actually reported.

joachimmg · December 18, 2020, 5:45pm

As I wrote, they are, and most of them boils down to the issue where the feedback (months ago) was «it should be an easy fix». I recall many of the users in here from the issue tracker at github.

firstof9 · December 18, 2020, 6:25pm

There’s a user created stop gap until the UI’s completed.

gist.github.com

https://gist.github.com/firstof9/7baaa51c047b43e43b87f5149187a528

ozw_beta.yaml

## Created by @steve28
## Binary Sensor toggles once the network is ready (zwave.network_ready event)
binary_sensor:
  - platform: mqtt
    name: ozw_network_status
    state_topic: OpenZWave/1/status/
    value_template: >
      {{ "ON" if value_json.Status in ["driverAwakeNodesQueried", "driverAllNodesQueriedSomeDead", "driverAllNodesQueried"] else "OFF" }}
    json_attributes_topic: OpenZWave/1/status/
    device_class: "connectivity"

This file has been truncated. show original

crzykidd · December 31, 2020, 4:48am

I am close to jumping over as I have some devices that require 1.6 now… However there are a few things that I can’t lose support for, can someone confirm that these devices will work:

Schlage Zwave Locks? (Any issues with these)
Using the WD200+ switches we use scenes everywhere (Double tap and triple tap)
- Does full scene support work? Any issues?
- If I am intercepting Zwave scene in Node Red will that code change at all?

Any other major gotchas? I have about 100 ZWave devices and going to reprogram from scratch as I need a good cleanup of some devices etc.

I am running an all docker config, and MQTT is already setup and running with security.
Thanks

blhoward2 · December 31, 2020, 5:34am

There have been critical bugs unaddressed since July. PRs have taken months to be merged. It is in beta but with no development to fix bugs.

blhoward2 · December 31, 2020, 5:50am

Not only reported, even PRs have been sitting for months to be merged. At this point he hasn’t even commented on critical bugs that have been open for months. By critical I mean crash the backend, take the cpu to 100%, require a restart, delete and rebuild the cache, see you in an hour level bugs. On my setup this was triggered by toggling the same switch on and off a few times in quick succession, refreshing a node, deleting a node, etc.

A PR for a simple fix to a critical bug causing all Leviton devices to flood the network sat uncommitted for so long that people had to build custom docker images to run in the meantime just to stay up. This also caused the whole backend to go down with the network saturated and the CPU at 100%.

The MQTT timeout issue has been open since July. A good number of people have to delete the ozwcache file and rebuild it on startup to get it going…that has been open for months and a PR has been pending for sometime to adjust the timeout setting. Just go to the issue list on qt-openzwave and look at how many have been closed since July.

Here is fishwaldo’s github activity across all projects this year:

Clearly he owes us nothing and is free to cease development. I wish him well (and hope he’s ok!) and appreciate all of his work, but this has all of the hallmarks of a dying project not one in beta being pushed for more widespread testing. As others have said, why this is the committed path forward when he is the sole maintainer and one of the only people contributing code is an odd choice if he has other things going on. The maintainer of zwavejs2mqtt seems to have been pushed to create that because of a lack of support for the ozw 1.6 backend on which his prior project, zwave2mqtt, was also built.

@martinhjelmare any comment or insight? Your presentation suggests this will exit beta the end of Q1 but at this point many people have given up and switched back or switched to zwave2mqtt/zwavejs2mqtt. There has been practically no progress since July, at least no public progress.