HomeAssistant components are maintained by many different people. The person whom maintains this for HA is @Fishwaldo I believe
The addon doesn’t need to be updated for that.
What do you mean? The addon use not the latest ozw qt container…
The implementation of cover support is in the OZW integration. I assumed you were talking about covers since that was the comment you replied to, if that’s not the case then you can ignore.
I asked about OZW cover implementation which got merged today and hopefully be part of the next version of HA,
Cover.py was missing from the ozw and therefore was not supported
That cover PR will be in 0.113 - until then you could just set-up the mqtt cover for it:
cover:
platform: mqtt
name: "Cover"
command_topic: "OpenZWave/1/command/setvalue/"
set_position_topic: "OpenZWave/1/command/setvalue/"
set_position_template: "{ \"Value\": {{ position }}, \"ValueIDKey\": 105480209 }"
position_topic: "OpenZWave/1/node/6/instance/1/commandclass/38/value/105480209/"
value_template: "{{ value_json.Value }}"
position_open: 99
position_closed: 0
payload_open: "{ \"Value\": 99, \"ValueIDKey\": 105480209 }"
payload_close: "{ \"Value\": 0, \"ValueIDKey\": 105480209 }"
The ValueIDKey is specific to your situation - as is the digit after node.
Kudos to someone else - let me try to find who helped me with this. @balk77:
1 Like
well, that was confusing as hell…
Why are we discussing a PR for the built-in zwave integration in the thread for the new ozw beta integration?
We are discussing the beta integration.
There are two major components at play here, 1) the OpenZWave Daemon and 2) the beta integration. They are developed by two different groups/people. The daemon is what actually runs the open z-wave, handles communications with all of the devices, etc. The daemon publishes information it gets from the devices to mqtt.
The Integration (which is what is in beta) takes the information from mqtt and turns it into entities in HA.
To-date, the integration did not know how to support cover devices, even though the daemon publishes the info to mqtt. That is why, if you know how to do it, you could an mqtt cover and still use it by publishing to mqtt directly.
The PR in discussion is to add cover entity support to the beta integration
But the PR link says it is for HA Core not the ozw beta integration. At least I assume so since the ozw beta integration hasn’t been incorporated into HA core yet. Or has it and I missed something major?
The ozw beta is part of core.
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