Closed robertsLando closed 3 years ago
We are moving forward on the qt daemon, so not interested at this point.
Why not have two alternatives? Development of qt-openzwave has been stagnant for months with critical bugs unaddressed. Nothing is getting fixed and the maintainer has barely been active since July.
This is not just the qt-openzwave project, this is about the Home Assistant project building the new OZW integration, which replaces the Z-Wave stack for Home Assistant.
As for this add-on, it was created at a time that wasn't decided upon. Now it has, and the experience at this point is great. I'm not planning on confusing our users more than they already are.
If another project would implement a compatible layer between qt-openzwave and another implementation, I might reconsider. For now, that isn't the case.
This is not just the qt-openzwave project, this is about the Home Assistant project building the new OZW integration, which replaces the Z-Wave stack for Home Assistant.
As for this add-on, it was created at a time that wasn't decided upon. Now it has, and the experience at this point is great. I'm not planning on confusing our users more than they already are.
If another project would implement a compatible layer between qt-openzwave and another implementation, I might reconsider. For now, that isn't the case.
That’s the point though. The experience isn’t great for many people. There have been critical bugs with qt-openzwave for months. One that takes the cpu to 100% and requires a full restart, plus dropping ozwcache and rebuilding, has been open since July. A PR to fix a network flooding but with Leviton devices stayed open for months before it was merged. And the maintainer is MIA. I think the question is whether the stack should be changed altogether and, indeed, whether fishwaldo will maintain it at all going forward. He’s only taken action a handful of times since July.
Sorry to hear you are not happy with that solution. However, that does not mean I have to build and support multiple things at all.
Feel free to build and support your own.
Furthermore, this discussion is no longer related to an issue with this add-on at all. So closing the conversation on this over here.
As for this add-on, it was created at a time that wasn't decided upon.
When, where, and who made this decision? Can we revisit it? Is there a roadmap? Where can people get support (since as @blhoward2 points out, it's not happening on GitHub)
We are moving forward on the qt daemon, so not interested at this point.
The general community feeling is that there is no momentum on it and there is a lot less interest in the qt daemon. This thread is very long, but nearly every comment is struggling to see that this will ever come to fruition.
Sorry to hear you are not happy with that solution. However, that does not mean I have to build and support multiple things at all.
Feel free to build and support your own.
Furthermore, this discussion is no longer related to an issue with this add-on at all. So closing the conversation on this over here.
It’s not that I’m unhappy, I ran the beta for four months and submitted numerous bug reports (none of which have been fixed). I finally switched when it started crashing randomly and taking the whole system down with it. I’d LOVE for it to work, it just doesn’t right now and seemingly no one is working on it.
Nor do I mean to imply that you should have to do anything. I think at this point we’re all just confused about why the decision to place it all on qt-openzwave was made and what happened to development on that project. Since no one knows who made that decisions or why, we’re left to seek out any avenue that we can.
I told above that this thread is out of line here. I have no interest at this point, nor is this the right place to discuss any of this.
Locking thread.
Happy new year
Hi @frenck ! I have started a new project and I plan to archive zwave2mqtt once that will become stable enought. GIve it a look:
https://github.com/zwave-js/zwavejs2mqtt