Not natively. The best you can currently do is described in that issue, by this comment.
1 Like
I just started using qt-openzwave. I am running HA supervised on a NUC ā a mix of supervisor installed docker images and hand-spun images via docker-compose.
Here is the compose that I use for qt-openzwave:
ozwd:
image: openzwave/ozwdaemon:allinone-latest
container_name: "ozwd"
security_opt:
- seccomp:unconfined
devices:
- "/dev/serial/by-id/usb-0658_0200-if00:/dev/zwave:rmw"
volumes:
- /home/nfs/docker/ozwd:/opt/ozw/config
ports:
- "1983:1983"
- "5901:5901"
- "7800:7800"
environment:
USB_PATH: "/dev/zwave"
MQTT_SERVER: "<HA IP>"
MQTT_USERNAME: "<redacted>"
MQTT_PASSWORD: "<redacted>"
restart: unless-stopped
High points: the z-wave thermostat that never worked in vanilla z-wave works!
Low points: the GE (Jasco Products) in-wall smart dimmers work, but in a wonky way. If I turn on the light from home assistant, what it seems to do is start a countdown on the topic /OpenZWave/1//instance/1/commandclass/38/1407375030976531, posting a new message every 1.5s or so, with the Label of āDimming Durationā, and the value starting at 128, counting down to 0. About half way through this countdown, the light will turn on. When the countdown is finished, home assistant will finally register that the light has turned on. Is this a known bug?
Known bug with how HA handles the changed dimming intervals. Fix already done and was hoping to have it in todayās 113.2 release, but it looks like weāll have to wait a few days longer.
Fixed in 0.114.
but if you guys want to loadāer up now hereās the steps:
- Download dev branch from github
- Extract github zip file to a temp directory
- Find components/ozw copy this to your 0.113.x installās /config/custom_components/ozw (this will override the built in ozw)
- Restart HA
- Rejoice!
2 Likes
This works perfect!
Didnāt work for meā¦ Still having issues with most of my GE dimmers not updating and the ones that are working I have to toggle a few times to get them to turn back offā¦
Works fine for me to!
Iāve got a problem with HA not being up-to-date with the physical status of two switches this morning when the outdoor lights turned off. For two of them HA still shows them as being āonā.
I canāt even turn them off in the GUI - the button goes back to the on position after ~2 s. I see the following MQTT messages when attempting to turn off:
command: OpenZWave/1/command/setvalue/ - {"ValueIDKey":323567648,"Value":false}
event: OpenZWave/1/event/setvalue/ - {"TimeStamp":1596210090,"status":"ok"}
Is this a problem in HA, OpenZWave or something with my setup or hardware?
Are they dimmers or just switches?
Both are switches
The status should reflect as soon as the status is updated in MQTT
Yes, of course. Just wondering how I can help. Havenāt dived into the code yet, but maybe I will. But for now Iād just want to help by providing all the information I can give - logging etc.
When you say that the status should reflect as soon as the status is updated in MQTT, what exactly do you mean? Which message (topic etc) will update HA?
the status of the valueID that for the binary_switch command class.
hard to explain, if you look at it in MQTT-Explorer youāll see it easier.
Thanks @firstof9 for the instructions. That worked! Does anyone know how I can force remove dead nodes from the controller? I have a few nodes that I know are dead and the controller wonāt let me with the remove failed node command. Gives an error stating itās not able to. Also, does anyone know how I can grab the entire OZW log for debugging?
Can someone suggest where/how I would start with low-level diagnosing of how HA 113.3 and OpenZWave v1.6.1207 / qt-openzwave v1.2.0 / QT v5.12.8 communicates with my HAB iblinds? Iāve created a device xml for them and can gingerly control the tilt level from ozwdaemon but not so from HA. They seem to not like being talked to while the motor is operating. They worked fine in Homeseer as long as I did not poll the multilevel device for status update too quickly after the on/off switch was changed and vice-versa or they would require a power-off-on/reset/re-calibration. I was triggering a poll as the child device does not update a status change when itās partner changes. In OZW, an on/off kills the device as does sending another tilt command less then 10 seconds after the first. In HA both tilting and on/off kill the device.
Hi @troy . Iām in the process of trying to implement what you have (separate machines for HA and OZW) and that is how I ended up here. One thing I havenāt been able to figure out -and Iām not sure how to search for it- is how to make the two setups work. For example, letās say system A (SysA) and system B (SysB):
- SysA - [FreeNAS/venv] | HA Core
- SysB - [RPI/Docker] | QT-OZW
What I donāt get is how to get both systems to ātalkā to each other. I have (the equivalent of) SysA up and running), Iām about to follow your minimal step to setup RPI for SysB. But, once I have it ready, how do I āconnectā it to SysA? MQQT? Some other way? Could you point me to documentation/guides you used to get your system running?
Appreciate any help you can provide. Thanks!
Yes. You need an mqtt-broker (a mosquitto docker is really easy to set up).
1 Like
@Olen - Thank you. So, would it be something like the config below?
- SysA - [FreeNAS/venv] | HA Core | mosquitto
- SysB - [RPI/Docker] | QT-OZW | MQ publisher&listenner
Yes.
You can install the MQTT-broker (mosquitto) whereever you want (even in a 3. system, or somewhere on the internet), but it proably makes sense to put it close to HA. You can then add lots of different services that sends MQTT-messages (including QT-OZW), and they can all be added in HA after you enable the MQTT-integration.
The MQTT-broker is a middleware that only receives and sends (MQTT) messages to whoever listens for them.