The Future of Z-Wave in HA - QT-OpenZWave

johntdyer · December 31, 2020, 5:55pm

Yea, really scared since they seem to be pushing back against any formal alternatives https://github.com/hassio-addons/addon-zwave2mqtt/issues/70

Dansker · January 1, 2021, 7:24am

@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.

johntdyer · January 1, 2021, 2:49pm

@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…

srwhite · January 1, 2021, 4:21pm

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.

sender · January 1, 2021, 4:28pm

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!

gregg098 · January 1, 2021, 4:53pm

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.

ptdalen · January 1, 2021, 5:07pm

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.

decairn · January 1, 2021, 6:27pm

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.

paulstronaut · January 1, 2021, 6:57pm

Cross-posting for visibility / break-out discussion:

murphys_law · January 2, 2021, 6:28am

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.

mny · January 4, 2021, 9:37am

Hi Foxy82,

Did you find a solution for your Fibaro Roller Blind issues? I am experiencing problems as well.

monty_burns_007 · January 4, 2021, 10:06am

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).

mny · January 4, 2021, 10:20am

Hi Monty,

Did you get the old default Z-Wave 1.4 to work with the latest Home Assistant OS & Core?

monty_burns_007 · January 4, 2021, 10:29am

yes the default (old?) standard Z-wave integrations works perfectly:

afbeelding

See below my devices : Fibaro, Zipato, Qubino, Fake? AeoTec Wallmote & Sirene.

foxy82 · January 5, 2021, 4:00pm

I moved to OpenZwave which works for open/close and a percentage. The only thing that wasn’t working last I checked was the “Stop” button (although I’ve seen some issues/fixes/discussions around this recently so might be fixed now). The stop button wasn’t really a deal breaker for me as I’d just set a percentage or use the on wall control if I wanted to stop it at a certain point.

OpenZwave has worked perfectly for me and closes my windows every night for me.

mny · January 5, 2021, 4:46pm

Ok, and whenever manually changing the percentage at the fibaro - will the value be updated in Home Assistant?

basti4k · January 5, 2021, 6:09pm

RAZBERRY2 professionals here?

panteragstk · January 6, 2021, 1:11am

A little late, but I have a similar issue.

I have multiple GE/Jasco dimmers/switches including a 3-speed fan controller. These are all non zwave plus and they aren’t sending a refresh so that when I manually use any of these switches, they don’t send their state back to OZW/HA. These can be controlled with HA without issue including automations. Manual operation is the only issue. Without the devices reporting their state, some of my automations have stopped working.

My newer zwave plus switches/bulbs do not have this issue.

Anything that can be done about this? Is it just me?

petro · January 6, 2021, 1:21am

Add polling, but it can slow down your network if you poll to aggressively. I only poll devices that are frequently used. I have the same switches and dimmers and have been slowly replacing them throughout the years.

blhoward2 · January 6, 2021, 2:16am

You all see this?

github.com/home-assistant/architecture

Move Z-Wave support from OZW to zwave-js

opened 11:14PM - 05 Jan 21 UTC

closed 03:05PM - 11 Jan 21 UTC

marcelveldt

## Context Currently a new Z-Wave integration is in the making, based on Open…Zwave 1.6, using the "OpenZwave daemon" as intermediate bridge with mqtt as communication protocol. While development had a flying start we're at a point there are multiple issues why I'm proposing to revisit the choice for OpenZwave(QT): - We ran into several mysterious issues because of the fact that mqtt is used as protocol, mainly unpredictable results in fetching the (startup) state from retained messages. - Added complexity of an MQTT broker and the OZW daemon for both users and developers. - Stability issues with the OZW daemon, not starting at all or sudden restarts, not so pleasant for user experience. - Device/Z-wave compatibility issues that need to be fixed upstream (meaning: OZW). - While OpenZwave is a very popular opensource project and many people rely on it, it's main development is driven by one developer. In all the past years he did not have much help from other contributors to the project. One reason is that it's written in the programming language C++ which is just not so popular by nowadays young developers in comparison to e.g. python and javascript. Because this programming knowledge is also missing at the Home Assistant devs, there is a long queue of getting issues fixed. - The above mentioned core developer of OZW has given a statement just recently that he's taking a break from OZW and all it's demanding users which gives a bit of a dark future at this time for OZW unless (finally) some people step up and help out coding C++ with him. There's a lot of reason to doubt if we're betting on the right horse with OpenZwave (daemon) for what's supposed to be the "shiny new" Z-wave integration for Home Assistant that should finally make the Z-Wave experience rock-solid. This leads to frustration both with the devs actively working on it and the community. There must be an evaluation of alternatives and that's where this proposal is all about. ## Proposal For implementing Z-wave there are unfortunately limited options. The only opensource library that ever existed was/is OpenZWave, except that it's python wrapper has gone stale. Really the best option would be to create a Z-wave driver completely written in python but that will require a busload of developers and time to pull off. Recently a new opensource Z-wave implementation has seen the light: Zwave JS. A driver written from the ground up in javascript/typescript gaining a lot of traction: - It has good documentation and a good codebase. - As the language is more popular, code contributions are more likely. - It has given thought about easily exchanging device-specific configs. While this project is (just like OZW) also primary developed and maintained by a single developer (Al Calzone) it is more likely that others will help out. Even most of the Home Assistant devs/contributors know their way in some javascript/typescript. A few members of the small team that was/is actively developing the new OZW integration for Home Assistant has explored options the last couple of days and exchanged thoughts with the developers of Zwave-JS. Even though it means that we will have to smash 70% of our work from last year in the trash, we still think we should make the switch (now we still can) to Zwave-JS instead of OpenZwave, how harsh this may be for both Fishwaldo (developer of OZW) and everyone contributing to the new integration. ## Consequences PRO: The actual interaction with the Z-wave stick/device will still be detached from Home Assistant but this is a good thing as this will not restart the Z-wave mesh while Home Assistant is restarted, so that will stay. PRO: Instead of talking over MQTT to the OpenZwave MQTT daemon, a "ZWave server" will be written which can be fired up in it's own process (as docker image, addon etc.) and it will be the bridge between Z-Wave hardware and Home Assistant. In fact this bridge will serve any client interested in utilizing the Zwave mesh. For example Zwave-to-mqtt and Home Assistant can be used **side by side**. PRO: because of the above mentioned an MQTT broker is no longer a hard requirement which reduces the complexity, especially for new (less tech) users. we can manage the entire path automatically. PRO: As we have the ability to actively work with the developers of Zwave JS and we have knowledge of the upstream code we can actually contribute in fixing stuff upstream. PRO: Zwave JS has some features that are not supported in OZW such as firmware updates. Also from a first impression it seems to be a bit faster and stable. PRO: No more instability issues with the zwave daemon that was haunting many users. CON: Zwave JS is still missing support for a few command classes/devices such as garage doors but this could be easily added by us or any contributor. CON: A fully automatic migration of legacy/current ZWave in HA to this new implementation will be more complicated because of the fact that the internals are handled differently. I'm for sure missing a few points here but the bottomline is that the overall feeling by me and a few others is very solid to make the switch. read all about Zwave JS here: https://zwave-js.github.io/node-zwave-js/#/README