Can we revisit the move to qt-openzwave?

Tags: #<Tag:0x00007f32650ba4c0>

I was talking about the ozw-daemon vnc ui that’s provided by the addon, which is what I thought you were referring to (the zwavejs2mqtt equivalent). The UI from the integrations page would be handled by the integration, I agree.

The equivalent of the VNC part is done and is already a website. Since it is already a website there is no need for two separate controls. That’s only necessary with ozw because of the odd choice to require a qt interface. It looks much like what the built-in one looked like but with more control/features.

This is already running fine in Lovelace. I have it setup as a panel. And unlike the current vnc ui, you can change association groups, modify sensors, create custom sensors, hard and soft reset the stick, create and change scenes, etc.

2 Likes

It seems that, in a perfect world, HA developers would define what they want the MQTT API to look like, and then zwave backend developers would implement it.

But I take it that horse is already out of the barn, and the approach was “we’ll work with whatever qt-openzwave is sending us,” which you are suggesting is not a particularly implementation agnostic protocol. Oh well.

3 Likes

What is non-compliant about ozwdaemon? None of my brokers or clients have had any issue with it.

Non-compliant may be a poor way to explain it. It can connect to the broker fine, in that way it is compliant. What I mean is that, from my understanding, it puts more of the zwave stack onto the topic than is ordinary versus creating separate endpoints for each device as is normally done with mqtt. That is why it is needs it own integration vs using the standard mqtt integration that can just pick up the discovery message and work with it. Instead of endpoints it seems to put command classes onto the broker.

1 Like

You’re missing the point of how MQTT is used for OZW. We want to talk directly to OZW directly over mqtt. We don’t want to have another representation of the data between OZW and HA. The same would be done when integrating ZwaveJS. We would want to get the messages the lib produces, not the MQTT project. Things will otherwise get lost in translation.

3 Likes

I never said there was anything wrong with doing that, nor did I attempt to address why it was done, just that it means you will never have both ozw and zwavejs2mqtt sharing the same integration.


It is perfectly feasible to try all the options.
Use your preferred one.

1 Like

I’m a programmer. I don’t have time to contribute. I also I don’t really like Python, so while I can make my way though it I’m never going to develop anything complex in Python. Instead I pay for a Nabu Casa subscription and hope it goes towards development.

2 Likes

1.4 (built in) and 1.6 (qt-openzwave addon) are built on the same main loop… the polling is identical. Go check out the history on github if you like.

Also, here are the docs for the MQTT commands where you can adjust the polling frequency.

Judging by what some devs(Nabu/HA employees) have said, they don’t have time to build a Z-Wave stack. This sucks because I think they truly do not realize how central to many setups that Z-Wave truly is.

5 Likes

Possible to migrate from1.4 (built in) to 1.6 (qt-openzwave addon) and keep entities names?

The migration process is being actively worked.

Absolutely agree. Workable ZWave support is absolutely vital in my setup. As much as I love HA, this is a make or break thing I just can’t afford to lose functionality on.

I feel that in terms of RF networks, HA has really been shifting heavily towards the tinker-and-DIY-with-cheap-stuff-from-Ali side of the spectrum. ESPs running on wifi, cheap Zigbee stuff from China. There’s nothing wrong with that per-se and being a free open source platform it makes sense to support this approach.

But I think that the devs tend to forget that HA also appeals to a different type of user. Of course HA is not a commercial product, etc, etc, but with the current very low priority approach to things like ZWave, they’ll progressively lose this crowd.

11 Likes

I tend to be testing technologies and try to have stability while making big changes. With a history of Commercial (zipabox, fibaro hc2 and zipatile) but also opensource (Openhab, Home assistant).
And in home assistant alone using z-wave 1.4, ozw 1.6 (with qt or z2m) and now finally moved to zj2m (shortcut for zwavejs2mqtt). I want to add my experience showed from both ozw and openhab z-wave driver, maintained software limits to small amount of people tend to have long lasting issues which are slowly or almost never been solved.

I’ve been for months on OZW. I never found logical the structure of qt-ozw as it gave me some more work to “guess” mqtt topics! but this is personal preference.
What strikes me mostly is the issues I found with S0 and OZW, which I never found on any other driver.

  1. Encryption with newer devices (Doorbell 6) is broken! you cannot even fully include a device
  2. similar to previous, Association 1 or 0, when supports multiple associations also breaks, giving you a Double notifications for the same event.

I cannot accept the answer: it is always a device firmware issue. After months of having issues which I believed where device related. I moved to another driver. Which magically took away all these issues.

Looking at the PRs of ozw, It scares me to even use it these days, Yes it is a stall project or almost stall!

If users are silent with problems, or use alternatives. Does not mean problems do not exist. Maybe most of people are like me. try to fix it and find a workable solution. As not many probably complain?

@petro adding to other users issues. I have 40+ devices, I have a lot of small issues here and there with ozw

Problems:

  • mentioned above encryption
  • random miss on devices next to controller
  • OZW cache, becomes huge and makes the whole driver slow!
  • exist in two different z-wave controllers. always with same software involved

Is it my setup? a powerful intel NUC backed by a fully up to date kubernetes cluster with clustered mqtt in two “datacenters” and local locations.

So I agree with @paulstronaut an addon is needed as an alternative choice. With this stall ozw option, I would say supported by HA will help people switch on their own choice.

2 Likes

I think this topic raises several important issues and I’d like to thank the OP for bringing it up.

I’d also like to make sure that we remember that @Fishwaldo is not an employee of Nabu Casa and is an actual volunteer doing this work in his free time. Nabu Casa has taken that work and is selling it to their users, while deflecting the blame for any problems back on the volunteer who is doing all the hard work for them.

Keep in mind that none of this is @Fishwaldo’s doing, the decision of how to handle ZWave lies with Nabu Casa alone, and they have proven time and again that they aren’t interested in any outside input (exhibit A: this entire thread ^^^) . They will deflect responsibility when it suits them and collect your money each month all the same. Unless some of that money is being sent to the source projects they’re pulling from, 100% of this issue (and others like it) can be traced directly back to decisions being made by the Nabu Casa corporation.

If it isn’t working right, that isn’t @Fishwaldo’s problem to solve.

7 Likes

So I guess I should chime in with whats going on my side:

What Happened: Unfortunately, a Lot:

  • I had a power spike that killed all my PC’s/Servers/Laptops at home back in July. It took me a good 3 months with COVID slowdowns and so forth to rebuild/purchase a new server/laptop etc.

  • I have a real time Job managing a large team in Asia Pacific - And I got promoted in October where I am now also managing Europe side of the business (I’m based in Asia so the timezones is not kind to me)

But these are minor compared to the real reason I’m not so active anymore. Unfortunately its the wider OZW community. Not just the HA community, but a large number of users here. I do this in my own time, its a passion and it was enjoyable. But Please scroll this thread - Only a few people here actually understand what its like to volunteer to maintain a project that is used by >100000 users (if anybody is questioning the stats - I can infer the number of users of OZW 1.6 based on the DNS queries to check the latest revision of config files).

It has been a very toxic enviroment for me to work in - I approached this eagerly as I knew the old integration was stale and had lots of short comings. But the “demands” by some users. The criticisms of the project, my work, how fast I work, how good my code is, why we don’t support xyz device, why we don’t support S2, why this, why that. My discord was flooded with PM’s till I turned it off, my email I’m still getting rude or demanding messages every week.

All along - I’ve asked for help - none has forth come. I’m sick of users making demands upon me when i’m doing this in my own free time and for my own itch.

Is OZW Dead - No. I’ll tinker with it, i’ll make changes as time allows, but it will be at my own pace, to scratch my own itches now. if people step up and offer to help maintain the code, or vet through config files (like Nechry does on Github) and they show they have some knowledge about Z-Wave in general and at least adhere to some sense of backwards/forwards compatibility - I’ll happily add them as maintainers - But in the 10+ years i’ve worked on that, most people will last at most 6 months and then also disappear).

Sorry for those that have supported me one way or another. For everybody else that is critical of my work or OZW - all I have to say to you is “Show me the code or STFU” - Sorry to be blunt - But thats how much this community has tarnished my view of OSS work.

85 Likes

Congratulations!

5 Likes

Sadly, this is the inevitable result of the issues I outlined above. Nabu Casa has setup a system whereby they get paid off the backs of volunteer work, the volunteers are left holding the bag to support the code, and eventually the bullshit that comes with that overrides any benefits they may have gotten from contributing to the project.

@Fishwaldo I’d like to personally thank you for all the effort you’ve put forward to this point, it has benefited us all and you’ve asked nothing in return. I, and I’m sure several others, sincerely appreciate it. I also 100% understand why nobody in their right mind would continue working on the project for all the reasons you’ve mentioned. We, the users of Home Assistant owe you much, you’ve done so much up to this point and you don’t owe anybody anything. Glad to hear things in “real life” are going well and I hope that continues.

Meanwhile… Nabu Casa collects another month’s rent and nothing will have changed.

6 Likes

I’d like to add - I have nothing against @balloob or the Nabu Casa team at all - I started this full well knowing that I wasn’t going to get paid for it (Correction - They do donate via the Github Sponsors system) and I know they were paying (or intended to pay) people to work on the HA side of the integration.

Also - There are some people here that I acknowledge have tried to help me - kpine and so forth (sorry if I can’t remember all your names) - So despite my post its not all bad.

Its just maybe the minority are more vocal than the majority and makes it a very unpleasant experience for me.

28 Likes