Regretfully, I could not agree more. Response time with Vera Edge turned out to be much better that Zwave dongle.
Been watching https://github.com/OpenZWave/qt-openzwave/issues/60, but I’m unclear: are double-tap events (via the Basic Command Class) still not supported? I have lots of GE switches and being able to double-tap them in a way that HASS recognizes is the final things standing in my way of a full cutover to OZW.
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