When it’s ready.
2 Likes
It looks like it will be replaced with a newer MQTT based system that will be able to tracker closer to OpenZWave.
Yes, I have the same configuration, and it’s indeed buggy, but still way better than before.
To use ozw 1.6 with Ha I switch to zwave2mqtt. The latest version can be find in docker version and use ozw 1.6. An auto discovery feature for HA can be enabled.
1 Like
Could you give some details on your setup? This sounds like it might help with restarting and having to modify the ozwcache file all the time and the zwave startup delay.
2 Likes
Also curious how to do this… Steps?
I tried the setup for z-wave to mqtt, and found it less than desirable. It was much slower than having ha communicate directly to my devices over z wave. Lights that were being turned on/off through this method would occasionally not respond. Also when the lights responded correctly, more often than not the state of that light was not being reported correctly in HA.
I rolled my setup back to remove the z-wave/mqtt addon.
1 Like
Same here. Play with it often to check if it get’s any better after an update, but I always turn back to the default installation. Also have the problem with zwave2mqtt that when I need to restart HA, my z-wave devices don’t show up for a long time. So, I basically can not control any z-wave device after a reboot for 10 to 15 minutes.
1 Like
If you are looking for official OZW 1.6 integration in Home Assistant, 0.110 will be very promising.
Check the thread @jumpmaster posted on 27 Jan that links to the topic “The future of Z-Wave in HA”
In case you miss it - link here The Future of Z-Wave in HA - QT-OpenZWave
When completed, it looks like it may be a step ahead of zwave2mqtt.
1 Like
Folks wanting to upgrade today… please read this before you delete your zwave integration and pledge time to renaming your entities!
Yeeeeup, and sometimes much, MUCH longer than 10min…
…but the current lack of a cache file is still going to be a big problem for most users of the addon. I had to learn the hard way when I tried upgrading too early:
Today’s current addon release doesn’t have a cache file. So if you reboot host, you’ll have to stick paperclips in your aeotec gen5 recessed sensors, wait up to 4hrs for your ecolink sensors to come online, etc. This behavior will effectively break zwave dependent automations for most use cases. You’ll have to redo the old integration and rename everything a second time just to get the lost WAF back, LOL.
I have faith it won’t be long before the next release of the ozw addon brings the cache file. Other than the cache file, transferring over to ozw was relatively painless to configure. I’m sure before long, ozw will easily eclipse zwave for HA users, but at the moment it is safe to say it shouldn’t be used on anything but ‘experimental setups’ where failed automations won’t have an affect on the WAF. 
That’s the risk you take if you you use beta on a production system. 
Many run it well and it just works with the components it supports, others have issues.
The cache file shouldn’t be such a drama as the OZW container should keep running when HA is restarted. It just speeds thing up at startup on the initial startup. 40Mins and pins in devices sounds a bit odd though. Under 1.4, one of the fixes for weird issues was deleting the cache. There could be other issues causing your mesh to be a bit unstable?
I had very few issues with the new Beta with lights and switches, no delayed start and no reset needed. I went back to the prod integration because of limited component support and some issues with ozwadmin.
I am able to utilize all my devices after restarting HA as soon as the UI loads them in 0.111.
Why will this be a problem? Nevermind I see in the other thread you have many battery devices.
I’ve had to stop the ozwdaemon container today to utilize the all-in-one container, my network came back online super fast.
At the end of the day, HA is technically beta as well… LOL! ;D
Such is the landscape of open source software we play in… no software is ever ‘done’. It is fine and I enjoy playing with software in development, and I even enjoy partaking in development when my skills apply. I think my problem was caused by lots of what I call ‘cross talk’ in the forums… in this case led me to believe devs were ready for a more large scale testing effort with ozw (including newbs like me etc). I know they are working hard on it and have made lots of progress, but yeah no cache means issues with sleeping devices. Maybe a more bold warning about this? No, I don’t think that would help either… let me explain.
There are deep dev discussions that require lots of skill to grasp, along side newb q/a in these forums. Compare this to like 3d printing, where newb q/a stuff is limited to some forums (like tv, etc), and the dev discussions are separeted and almost exclusively done on github. This means if you read across it on TV, it’s probably ready for the newbs at large to start playing with, but if you start digging into stuff on marlinfw github bugfix, you know to expect a rougher ride. Compared to this, the HA forums have lots of ‘roadmap’ and deeper ideas being discussed, all on the same site even same section where newbs do q/a. So it’s easier for a newb (like myself perhaps) to stumble upon some ‘dev discussion’ and interperet the ‘it works well’ comments as ‘ready for newbs at large to test’. I know there are grey areas in between ‘alpha’, ‘beta’, and ‘release’, and I don’t care to resolve such lines… just communicating an observation I had about where the seemingly repeated confusions among newbs (especially myself) may be stemming from.
One thing in general that could help in this regard, is when a dev (or other important member) posts one of those ‘important feature’ threads where lots of active discussion happens about testing/fixing something new and popular in HA… the top post could be updated with some important notes for those who aren’t keeping as close a pulse on the development (ie, newbs like me). For example, we all love reading the latest state of the new ozw integration, and wonder if it’s ready for our setup to test. We read through and it all sounds great, then find out the cache thing. Probably, those folks discussing things in the thread already knew this isn’t ready for battery devices yet (other than testing/experimenting anyways). That is an important fact, that could be tracked in bold on the first post, so as someone ‘checks in’ on the state of ozw on the thread, they know “ok, still not ready for me today, hopefully tomorrow”.
Just want to Clarify a few things and add my points as the OZW developer:
but yeah no cache means issues with sleeping devices. Maybe a more bold warning about this? No, I don’t think that would help either… let me explain.
So that was a implementation error in the container released by HACS. That container isn’t managed/maintained by me. While I fully appreciate the ease of installation HACS gives users, its always going to lag behind in terms of features/functionality from the official source and when there are issues, the only thing I can do is say “please use the ozwdaemon container” till the community behind HACS get around to updating their version.
interperet the ‘it works well’ comments as ‘ready for newbs at large to test’.
As for the “Beta” status - and newbies - I’m speaking from the OZW side perspective only, but since 0.110 landed, the feedback from everybody has been incredibly useful to me. Not just the bug reports and “things don’t work” but also the questions about how to do things. Its this feedback from newbies and experts alike that’s directing my efforts right now - either (obviously) fixing bugs, but also with regards to how users are actually using it, the confusion they are facing and how I can make things easier (e.g. AllInOne Container for ozwdaemon, which was copied by HACS quickly!)
the top post could be updated with some important notes for those who aren’t keeping as close a pulse on the development (ie, newbs like me).
On my side, Development and Bug fixes are happening on a daily basis, with new releases almost every day. So saying something is broken today may not be the case tomorrow (from purely a OZW perspective - obviously the HA side of things moves at their predefined release cycle). If we don’t have a bunch of people at least trying and testing, the Beta status will take longer and it may end up released as “stable” due to low bug reports, only for then others to jump on it, and find out something is broken or not working quite right, and then complaining its not “ready” either. its a Chicken and Egg Problem.
they know “ok, still not ready for me today, hopefully tomorrow”.
Final point - A lot of users are very quick to jump on and say that HA or OZW is broken with their devices. In reality, there are 3000+ Z-Wave devices on the market, with maybe 1/3 of that “community tested” in OZW. A LOT of issues reported recently are due to “quirks” in the way some vendors have implemented Z-Wave (I wont call all of them bugs, so lets say some non-standard, or very old implementations) and we have to update config files to get OZW to manage and interpret the way they work correctly. I am just saying this, as I want people to understand that the Z-Wave Vendors, despite its certifications and testing - have bugs and the only way we find them is via testing.
(and if people jump on to say it works in OZW 1.4 and not in OZW 1.6 - I’d like to point out, OZW 1.4 was done on reverse engineering the protocol - OZW fixed a lot of issues were it was not compliant after the specifications were released. This means some changes in 1.6 may impact some devices and again, the only way to know if for users to try!)
Just my 2c - As as user, i’m sure its frustrating, especially when you need something to just work (due to WAF or the $$$ you paid for Z-Wave etc) and I try to prioritize fixes for bugs that affect a larger group of users, but without your testing, OZW and the HA integration will not mature quickly and we will forever be stuck on the old integration with all its issues.
13 Likes
Cheers to this, and I am happy to post relevant logs on github to that end. I understand the breadth of zwave devices and the quirks required to ‘support everything’, and that is the place where my logs and experiences are likely to help the most. As freshcoast mentioned in another thread, my setup may be experiencing other issues that could be explored as well (WRT responding to sleeping nodes after reboot).
I’m really confused by this.
It is my understanding that HACS only provides the custom integration. It doesn’t provide the “ozwdaemon container”. The thing provided by HACS wonb’t work until you have a “container” (qt-openzwave) already running.
I assume you are actually referring to the Add-on Store and just misspoke and called it HACS?
Ya justin and petro worked it out in another thread.
1 Like
Not quite. Fishwaldo publishes a docker container… Home Assistant developers take that container and uses it as a basis to construct the add-on container you see in the store. The purpose of that container is to publish topics to MQTT, which are then picked up by the new (beta) integration.
So you have two choices for the container part. You can use the one in the add-one store (which is based on the one released by Fishwaldo) and is a one-click install, or you can use the one released by Fishwaldo directly (but requires knowledge of docker among other things). The latter will always lead the former.
One of the things that is done in converting from the directly released one to the one you see in the store, for example, is bind-mount directories from the home assistant ecosystem into the container so that things like the cache file is stored outside of the container and persist across new version installs. This was not done (or done incorrectly) by the HA team.
So two things have to happen for the add-on store version to update:
- Fishwaldo releases new version of qt-openzwave container
- HA developer build a new version of the add-on based on (1)
Bugs can be introduced in step 2