Well that explains it. I donāt know how I missed that part of the announcement. I know I read it but I guess since they call it ābetaā I never realized it was actually in core now.
Never mindā¦
It happens, we skim over bits weāre not that interested in 
1 Like
I have an interesting situation using the new qt-openzwave in HA that has popped up a few times now over the past weeks, most likely because my configuration is a little bit different then most.
I have a macmini running Ubuntu 18.04, docker, and containers with HA Core, MQTT and some more unrelated stuff.
I have a raspberrypi running docker with just one container: qt-openzwave.
When I reboot my macmini (so, HA and MQTT are unavailable for some time), qt-openzwave loses connection to MQTT (obviously), but it doesnāt seem to reconnect itself if the mqtt server is back online.
Only after I also restart qt-openzwave things start working again. This is exactly what Iām trying to avoid: I only want to restart qt-openzwave if I update qt-openzwave and not for any other updates.
Is there something Iām doing wrong? Or can the qt-openzwave docker-container not handle getting disconnected from the mqtt broker?
Correct it doesnāt like MQTT going away.
On my instance it crashes when MQTT broker goes down, but having restart: always in my docker-compose.yml makes it go back up automatically.
Iām a little bit afraid to put "restart: always" in my docker-compose file, what if ozwdaemon is restarted before my mqtt broker is available again? Will it crash immediately again or in that case, wait for connection and continue starting up just fine?
It is coded so that if the MQTT broker isnāt available it exits.
Thatās not a very resilient implementation.
Configurable retries delays and timeouts would be nice.
Itās not crashing. Itās exiting orderly. If the ozwdaemon tries to start and cant contact the broker, it will exit. If you have restart: always or restart: unless-stopped then it will just keep trying until the broker comes back. Itās not like it will āwear outā 
Yes, it would be better if it was robust to mqtt outages, but for now it isnāt. What you could do is run the broker on the same pi as ozwdaemon. Then you can reboot your mac/HA all day, no issues. MQTT broker is super lightweight.
1 Like
Iād suggest running a seperate MQTT broker on the qt-openzwave host and bridge it to your main broker. My bridging config looks something like this:
connection main-broker
address main-broker.example.com
remote_username pi-username
remote_password pi-password
cleansession false
topic # both 2
You should be able to change the # to be OpenZWave/# if this additional broker is only used for proxying qt-openzwave.
2 Likes
Letās see if I have some time next week, I may have a look at it. My profession is enterprise application integration, so why not at least give it a shot 
Thatās actually a really good idea! Thanks! I think I will try this out.
I have to say, Iām relatively new to HA and started with the normal z-wave integration. I finally got everything setup and then saw the news of the new component and wasnāt looking forward to migrating in the future if I wanted OZW 1.6. I bit the bullet this weekend due to various things not working in regards to devices not being in 1.4 and my new locks having issues. I have to say, Iām impressed even with this being a beta. It works so much better with my locks and with the various devices. I knew nothing about mqtt and with some research and tinkering, I was able to figure it out. Just wanted to say Iām excited for what the future of this integration will bring and wanted to thank the developers for the hard work they have put in so far. Thank you.
3 Likes
I have a quick question. I have two instances of HA, my primary usage instance, and a testing instance. I have the older 1.4 ozw running on my primary, because it works fully for me at the moment. I am definitely interested in checking out the ozw beta. If I plug my zwave controller (using same network key) into another computer (my testing instance), and dont add/remove any devices, just do some testing, will it make changes on my controller that will cause issues when I put it back into my primary instance.
I was thinking I could see what works/does not work, learn a few things for a few hours at a time, and then put it back when done until I was ready to dedicate the time to making the official plunge.
Anyone else done this?
Nothing gets changed.
Nope I went full beta after cover support was announced, but found it was only for blinds/roller shutters 
Garage door support is merged in the latest dev version.
I will tell you what doesnāt work off the top of my head, no light RGBW color support as of yet, no usercode support for locks yet (PR pending), no set_config_parameters support yet for changing LED indicators (PR pending).
Ok, since a while (I think since update to 0.112 I have this weird issue I never had before.
zwave stops responding. In home assistant I do not see anything happen. via VNC I do not see any zwave logging.
I have:
it might also possibly have to do with an update of hassos (4.10 --> 4.11).
I see in logging:
And when I restart the openzwave addon it starts working instantly. I have had this now for the 3rd day in a row at the end of the day/begin of the eveningā¦
Help!?
Iāve been experiencing similar issues, but I just went from āoldā v1.4 to this beta 3 or 4 days ago. So Iāve just been chalking it up to the beta tag. Iām approaching 80 nodes and was also thinking that perhaps my network was far too congested.
I believe you can configure docker with some restart policies. (retry timeouts etc).
If you want something more - Patches welcome 
1 Like
Unfortuantly - Not enough logging is enabled to see whats going on there and why it stops working. I believe the addon configures a very minimal logging rules so I canāt deduce much of anything.