Hi all,
I’ve been experiencing some pretty bad delays and general instability on my Z-Wave network using the stock HA Z-Wave integration. Most of my Z-Wave devices are newer than the openzwave 1.4 device database. Anyway, my issues are starting to negatively impact my SAF (spouse approval factor). I guess I’m just looking for general advice from someone with maybe a bit more insight into what’s going on with HA Z-Wave development. Do you think I should take the time to switch my Z-Wave integration over to ZWave2MQTT with openzwave 1.6, or should I sit tight and wait to see what happens with QT-OpenZWave in the next month or two?
I would be curious what the actual issues are. I also have devices newer than 1.4, and do not have issues. Is it possible there are other issues with your network?
I came up to this thread due to z-wave issues in HA. I will try zwave2mqtt on the secondary controller to check since HA does not recognize it as secondary controller at all
I jumped from SmartThings over to zwave2mqtt.
I wanted to try out OpenZWave1.6+, so I built both from their source. ZWave2MQTT requires NodeJS in order to build it from source (as well as run it) and this takes a bit of work. I moved over all my devices from ST to z2m. I’m happy with it . But I would say z2m is not for everybody as I mentioned it takes a bit of work to get z2m going w. 1.6.
I can’t really comment as to whether z2m will help you out as my ST based system did not have instability problems. ST did have a few quirks in implementations to bridge over to HA and it did have delay problems but that was due to going to the ST cloud and back too many times which was my main motivation for changing.
Z2m is constrained by using a interface that is generic and not Zwave specific. It has to adhere to those rules. That being said, a lot of users have success, but it’s still not fully 1.6 compatible- the author doesn’t have a mountain of devices to test with so users have to chip in with testing. (I understand some challenges with RGB bulbs and locks/user codes still persist), and in some cases - it requires additional configuration file updates per device to help with that mapping).
The new native integration (qt-OpenZWave is only 1/2 the puzzle) will not be hindered by using the existing mqtt based interface and eventually be feature parity with the existing integration. We are using mqtt as the transport, but the payloads are Zwave specific.
Additionally, one advantage that a few people have raised (more pressure on me tho) is that I’m maintaining now both the main OZW library, and qt-OpenZWave. - Let’s call it ozwdaemon). The previous python wrapper was maintained by another person who’s had some challenges in his personal life, and so far, no one was able to step up to maintain it in a compatible way with HA.
The Z2m solution currently has 2 layers on top of OZW. The node-shared library wrapper, and the actual Z2m software. If either of them move on and no one else can continue- then same fate as pyozw.
On the flip side though - more choices for everyone. A little friendly competition in the open source world never hurts anyone.
Thanks for the update Fish, as always more information is always welcome.
There’s not much meat on these bones however in terms of making a decision.
You say z2m has 2 layers ontop of OZW
I presume the native (to HA) implementation, will be a direct interface ?
So presumably ‘may’ be better ???
Though if you are using MQTT for ‘other’ stuff the z2m layer may make for a more ‘consistent’ approach ?
Sorry, I know this is more questions and that you can not foretell the future, but your “Guess’s” will have far more insight than our well researched speculations.
(Pulls the pin out, drops the handgrenade and runs for the nearest cover … )
Edit: I see you are replying now, so thanks in advance for your time in answering my stupid questions (I specialise in stupidity )
The new implementation (on the OpenZWave side - I’ll let others provide details on the HA side). Is written/maintained by me. That project has other goals beyond just HA integration - so as long as I’m active, it’s active.
Z2m has to “map” things from Zwave to the generic mqtt interface and adhere to the “discovery” protocol of that generic interface. That means people testing and submitting requests for their devices to “map” to the correct interface (thus something akin to a “shadow” database) see here for example: https://github.com/OpenZWave/Zwave2Mqtt/issues/199
related to above, specific management functions can’t be performed in Z2m. (Or are hacked in). Some notifications (say outdated config file for your device) would be sent to HA. So it’s only exposing values but not state or management (without additional scripts/hacks etc).
I’ve been working with the HA guys to expose the full capabilities of OZW via this new integration- one of these features revolves around further discover of a devices capabilities in a easy to understand form. For instance - a lot of users interpret Alarm Type Notification via some “random - vendor defined integer: Alarm_Type and Alarm _Level values, but that was version 1 of the specifications. The alarm command class is now upto version 14 (from memory) and is standardized for 99% of all devices/vendors. So you get a list of all possible values for a particular alarm type - and the currently “active” value. (Both as a label you can read and a value you can use in a script).
the new integration will allow you to run multiple networks out of the box. I don’t believe the Z2m can do that natively with HA. (I could be wrong).
ozwdaemon (as I’m calling it) is a multi-protocol bridge (currently a QT technology called remoteobjects and MQTT). The MQTT part is designed in collaboration with the HA devs in particular ballob. Z2m is a generic interface that “grew” the HA discovery capabilities but also tries to be a GUI and so forth.
I will, but at a bit of a slower pace - release a new admin GUI that talks to ozwdaemon as discussed in 6. This can run in parallel to HA so no need to start stop things. Advanced features/functionality/management and even diagnostics (like the log analyzer on the OZW homepage) will be part of that, and even editing/creating new config files for devices in a GUI.
As the specifications continue to evolve and I implement them in OZW, they will be immediately available to HA (but may require HA enhancements to take care of them).
as much as possible - new major releases of OZW (1.8 for example) will also immediately be available to HA. No more stalemates like we have now with 1.4.
S2 and SmartStart are coming after I’ve stabilized ozwdaemon.
TL;DR: verbose birthday message to sync config to avoid pilot errors?
I hope a side goal or heuristic of this includes fewer config, or the ability to somehow detect or avoid mismatches in HA config vs Z2M config.
Things like “home-assistant” vs “homeassistant” due to misleading examples and whether to keep the discovery prefix (yes) were confusing for me as a newb, and see others confused. A “green button” (like on digital cameras) where the z2m config is written for you by HA, or z2m gets written a config over mqtt, or some other magic avoids this. A low-risk way of pushing a config from HA might be a verbose HA birthday message to accomplish this.
My focus tends to be automation and control planes, so willing to go into more detail and coding if it helps a smooth adoption for new users
So I’ve been on the fence for a while, and off the strength of this thread, I decided to go with openzwave beta. For the most part the experieced has been great (2 weeks thus far).
The only thing I seem to be primarily missing are devices that have seen buttons don’t work in openzwave. For that reason, I’m thinking of going with z2m for now until ozw leaves beta.
. But I would say z2m is not for everybody as I mentioned it takes a bit of work to get z2m going w. 1.6.
)
Thanks