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.
1 Like
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.
There’s a user created stop gap until the UI’s completed.
1 Like
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
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.
1 Like
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.
4 Likes
Yea, really scared since they seem to be pushing back against any formal alternatives https://github.com/hassio-addons/addon-zwave2mqtt/issues/70
@johntdyer Seems a bit out of character? Why?
Current path is not moving forward presently, it appears.
Would like some clarity on the path forward as well.
@Dansker are you asking me why ? because if so then i have no clue 
i’m just concerned that the powers that be seem to be doubling down on ozw as the "one true path ". However i think we’re all concerned with this given the apparent state of that project…
1 Like
I don’t like when someone closes down a legitimate discourse on a technicality without at least acknowledging the concerns raised. Reading that thread does not make me feel better about the future of ZWave in HA, or the overall direction of HA in the first place. Frenck needs to at least acknowledge the current state of the OZW project.
1 Like
I also have to agree that the development (at least the visual/usable one) is at least bumpy…
Edit: although I am overall very happy with what is there now!
I have about 60ish devices total including 2 Schlage smart locks. Schlage locks are known to not be the greatest Z wave devices, so they have some issues, OZW or not. For me, they randomly dont report when they’re locked locally at the lock itself (button or manually). Ill get a notification that my door is unlocked, even though I know its locked, then have to “lock” it again from HA to get it to change state. Since upgrading to OZW a few months back, this issue is more regular than before.
As for scenes in Node Red, you will have to modify your flows a little, but the functionality is still there for all of my devices. I can’t speak specfically about WD200 switches.
I have a similair setup. 60ish devices. Schlage lock (be469 and fe599), but I’ve found them to be very stable. No issues, so it just might depend on your lock and your firmware? I have a lot of older and some newer GE switches and dimmers. All work well. I did have some issues with losing double tap on some of the newer GE switches, but there was a workaround to get it working. (posted somewhere in the community) Other than that I am very happy overall. I love that it’s seperated out from HA, makes reboots a breeze for zwave. I’ll say twice in the past few months, I’ve had OZW crash twice. Just randomly. I restarted the docker and HA and all was good again.
I moved to ZWJS this week, it’s stable, has responsive developers, and allows me to take advantage of newer device profiles (that OpenZwave 1.4 didn’t support). It’s noticeably more responsive than than HA built-in zwave to issue commands. In an open source world go with what’s being actively supported and developed. That’s not OZW right now.
5 Likes
Cross-posting for visibility / break-out discussion:
2 Likes
Ouch, that thread got ugly. It does seem as though HA doesn’t realize that Zwave is truly at the core of many users’ setups. It certainly doesn’t make me feel good about the project at the moment.
10 Likes
Hi Foxy82,
Did you find a solution for your Fibaro Roller Blind issues? I am experiencing problems as well.
I also tried OZW Beta 1.6 Z-Wave integration and my Fibaro Roller Blinds worked inverse.
On the old 1.4 standard Z-Wave integration I could Invert these in yaml;
zwave:
usb_path: /dev/ttyACM0
device_config: #!include zwave_device_config.yaml
cover.cover_kitchen:
invert_openclose_buttons: true
invert_percent: true
don’t know if you can also do something similar in the openZwave 1.6 beta.
Standard 1.4 Z-Wave integrations works the most stable and got the most Z-Wave devices connected.
Also keymotes like Fibaro & WallMote works if you add scene codes in ZwConfig file.
My chinese unknown PIR sensors are also recognized.
With the OpenZwave & Zwave2MQTT they all sucked. Were not detected, did not work, wrong type of variabels (ex. Boolean for dimmer value of Fibaro Dimmer, …).
I did the test 6 month ago and tried 2 days ago again and these beta Z-Wave integrations still suck big time. I’ll stick to the old default Z-wave 1.4 which is most stable. (works far less than my old FHEM Z-wave integration system).
Hi Monty,
Did you get the old default Z-Wave 1.4 to work with the latest Home Assistant OS & Core?
