Can we revisit the move to qt-openzwave?

While your back and forth is entertaining, let me interject another perspective. I run the beta and have since the beginning of 2020. For the most part it works fine for me but I have modest needs (no locks, e.g.). I had a lot of issues with dimmer refresh early in the year and worked hard at looking at code and generating logs and experiments to try to track all that down. It isn’t clear to me that any of that work was utilized despite back and forths with the developer and others. Since I run this in a seasonal home, I ultimately found kludges to work around the issues and left for the season. So I now in the supposed silent majority that is successfully running the beta. BUT - big BUT - this doesn’t leave me comfortable about where we are. Despite being away from this house until the last month, I have closely followed updates/fixes in the system to see if things were moving forward and watching these has left me quite concerned. Yes it works for me at the moment with my hacks. But the lack of tangible fixes (mostly beyond translation updates) does not make me comfortable that I should be relying on it. At the conference there was a clear statement that this was/would be the official path forward. I’ve good with that - but I would feel a lot better if I saw that long standing bug reports that may impact me going forward were getting some attention/fixes. There are some folks here who have created alternate images with patches. Great effort but these need to get turned into the real release. The statement at the conference was that this was coming out of beta in Q1. Unless there is some progress on the issues pending in GitHub I don’t see how this can be possible. I think all you are seeing here is a level of frustration with apparently contradictory statements and evidence. Surely that is worthy of civil discussion.

7 Likes

But you have already stated what the problem is, we’re waiting on fishwaldo. So you’re coming here banging down the door asking the wrong people for answers. I feel like I’m taking crazy pills.

Works on my local, so it must work for all

4 Likes

Thank you for this response and insight. I find it very informative.

2 Likes

To be honest, HA has reached a size and user base mass where a simple ‘be patient and wait for some guy to react’ is not an appropriate answer anymore. There has to be a plan B.

9 Likes

HA doesn’t manage openzwave. Would you run to Apple to complain about the Microsoft excel iOS app?

I assume that someone somewhere has a relationship with him and the ability to contact him. That’s my point and purpose.

Discord and GitHub is how we communicate with him.

That is apples to oranges. I certainly would run to apple if a critical bug in the BSD kernel was making osx unstable. The official path is built ON the software. It isn’t an accessory.

4 Likes

As far as I can tell, zwavejs is a single person.

3 Likes

And so why do HA state quite publicly that openzwave is the way forward for Zwave support in HA ? I don’t understand…

5 Likes

As far as I can tell, zwavejs is a single person.

This is true, mostly. There is one very active developer at the moment and the author of the underlying zwave-js is also pretty involved. I also find that problematic, not going to lie, but not much we can do about it. They started out much further ahead than qt-openzwave. They started with a UI and top-end and swapped the backend from ozw. Fishwaldo is starting with a whole new setup built on top of 1.6 which is also in fairly early development.

1 Like

No it’s not. The docker image is managed by openzwave. Not HA.

1 Like

Yes I would complain to Apple if a core component they actively endorse is malfunctioning and nothing is done to fix it. Whether or not that component is developed and maintained by them or if they outsourced or sublicensed it is irrelevant. If you know it doesn’t work, then don’t endorse and actively push users towards it. Sorry for being so blunt, but at some point one has to be.

10 Likes

When your doctor says we’re switching your medication to X and you can only buy it at Y, and Y stops responding…do you call the doctor back and ask why you’re switching and if there is an alternative?

9 Likes

And so why do HA state quite publicly that openzwave is the way forward for Zwave support in HA ?

Because nobody else has stepped up to write another integration. The new OpenZWave integration came first, HA’s core folks talking about it as the way forward came after the integration was already mostly developed.

It’s “the way forward” because its the only integration people have contributed so far and the old component is forever stuck on OZW1.4 which is outdated.

Whelp I’m done here. If you can’t be patient and wait for fixes then I don’t know what to tell you.

Look into alternatives.

1 Like

That’s the wonder of open source. The choice is yours.

1 Like

Because nobody else has stepped up to write another integration. The new OpenZWave integration came first, HA’s core folks talking about it as the way forward came after the integration was already mostly developed.

To be clear, I’m fine with that being the path. But the communication has been that the new ozw integration is THE path forward. When the official path, promoted in the documentation, is flaky, the entire project suffers. As an example, if someone made a js integration would it receive equal billing in the documentation? The zigbee way works because they are presented as alternatives to each other. Not this is the official one, and over here is another option some people created. Which will new users try and on that basis form an opinion of HA?

4 Likes