Yep. That’s also the reason why many open source projects eventually fail, when the upper echelon loses touch with their base. Anyway, no point in discussing this further I guess. Right now I’ll stay with the old integration.
Sure. My point was one cannot deride open-zwave because there is a single owner, and at the same time prop up zwave-js, when the same as true. It just so happens the latter is trending at the moment. Who knows, the zwave-js maintainer may disappear next month, especially if more HA users show up.
Out of curiousity, what is the state of cloud-less integration of commercial Zwave hubs (like Fibaro’s HC) into HA at the moment ? Could this be an alternative to OZW or ZWaveJS ? Or is it even worse ?
I’d agree if that was the basis of the objection. It isn’t that there is only one developer, it is that development has stalled because that one developer is absent. Obviously with more developers that would be less likely.
I don’t see why not.
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.
It’s hard to present multiple Z-Wave integrations as alternatives to each other when they don’t exist.
Again, the new integration came first. The “official” messaging you’re referring to came much later, and after nobody else stepped up to write another integration based on another backend.
Those are all fair points. I have no idea what making an integration requires. zwavejs2mqtt already has a well-developed web frontend. Is it as simple as linking that into HA formally? Discovery happens through MQTT so I’m not sure what more would be required. The current web frontend has more functionality than even the old one with the ability to modify the sensors created and such.
By the way, I appreciate your hard work on the ozw integration. I’m sure that this is all frustrating for the maintainers of that integration as well.
In fact, I challenge anyone in this thread to provide us with more than these two open source implementations of Z-Wave (that are even usable by HA). You are either beholden to OpenZWave, or now zwave-js.
On a related topic…
I found the github for zwavejs2mqtt but is there a forum thread dedicated to it that I’ve missed?
Where, how, what?
I need to say… there are “some” people here that run separate in docker being very positive about updates etc.
But tbh I think the majority have the addon installed…
Yep, I’m using the addon with my production system. 70+ devices working great.
I have an old zipato zipabox. It runs locally (but writing automations etc is done in the cloud). My z-wave devices are integrated with that device and the zipabox exposes everything using mqtt. That way I was able to get my z-wave devices in home assistant.
So yes there are alternatives. But I actually want to move fuly towards home assistant so purchased a z-wave USB stick.
I must admit I’m very confused about what solution I should be using right now:
- QT-OpenZwave
- the current native Z-wave integration
- zwave2mqtt
- zwavejs2mqtt
I want to go to the most future-proof solution so that I don’t have to spend time to migrate to a different solution in one or 2 years time. Officially that means I should use QT-OpenZwave, but as others in this thread, I have some hesitations.
Having been monitoring the development of QT-OpenZwave for a couple of months, I agree that it would be great if fishwaldo (I hope he’s doing OK!) could give an indication about his intentions.
Is there any way that you could start an info thread on zwavejs as you seem to know a bit about it?
At least way more than I do…
Yep, me too. But:
- It hangs frequently.
- I can only properly include/exclude/config via the windows client (not vnc and not browser).
- It does not properly support to easily add new zwave device config (it’s the best hidden container)
- There’s no clear strategy in naming conventions. Try adding 10 equal devices and you search yourself a handicap.
- Its not stable and troubleshooting is VERY hard (where to properly find logging?).
- I think 5 is enough for now to demonstrate the discussion
Just want to reiterate, I never intended to say “we should move to zwavejs2mqtt” or any other project. I wanted to start a discussion about what was can do. Yes, that’s one possibility. As a few people have pointed out, that project also has an issue that there is 1 core maintainer and we would be stuck if something happens to them as well.
That being said, I would like to say that I like the idea of zwavejs & zwavejs2mqtt. JS is a MUCH more friendly language than C++ and Qt. I’m going to start looking at it this month while I have some time off from my day job to see if I can contribute anything useful. Maybe we can get a discussion with the maintainer about getting more than one person with access rights for merging PRs, publishing builds, etc.
There’s also the issue, as has been state multiple times, HA core team has repeatedly said, OZW/qtopenzwave is “the future”, but the communication sucks. @sender listed issues that all mirror some of mine. qtozw “works”, but there are a bunch of annoyances that aren’t being fixed, don’t have any responses, and have no forward plan in the open.
So, again, we could go the route of zigbee and maybe update the docs to say, “here are the zwave options, all maintained by the community”. But we’d have to remove the qt-openzwave addon from the “official” addon repository, and for that, we need HA core approval. Unfortuantely, HA core, like the moderator in this thread, have been dismissive and continue to just say, “keep waiting”, nothing else.
These are just a few options that I can think of, all with pros and cons. What others exist? (edit: other than “just keep waiting”)
Do you have alot of polling devices? I’ve purposely moved away from devices that require polling. Zero hangs on my end.
You can add through the UI. COnfiguration → integrations → click configure on the openzwave integration, then click on add node or remove node.
Yes these 2 issues are waiting on a addon change (that will affect all home assistant addons) that allows addon configurations to be presented in a root folder to users. Unfortunately, the openzwave addon has to wait for this change in order to expose the logs & hardware configs.
Not sure what you mean by this. Assuming you mean entity_id, yes this is a problem. But this is a problem for every integration, not just zwave. Blaming this on openzwave is just miss direction. The problem here is in bulk naming in general across home assistant.
Not sure what you mean but I tend to say no…
Some devices require polling, if you enable polling on a device, every event loop the network will poll said device. This will cause hangs in your network because the event loop is polling instead of listening to your devices.
And yet this works perfect in the built in HA Zwave?
Any yet this works perfect in the native ha z-wave
Nope, built in has the exact same issue.