BTW, that configuration option would be a good candidate to become a BitSet value type.
Thank you!
don’t curse at me 
FWIW, I just upgraded to 0.5.2 and everything lined back up for me.
I haven’t set custom names or anything (yet).
This upgrade was actually pretty smooth for me compared to previous versions as I didn’t have to mess around with a bunch of restarts of MQTT and OpenZWave.
Update - my Ecolink motion sensor (non plus) seems to no longer be communicating. But my Honeywell thermostats appear to be communicating without issue.
Well it was a blissful 12 hours, but my network is belly up again. This has unfortunately gotten to be more than what I can handle. I’m going to have to resort to either HS4 or an old Vera Edge I recently discovered at the bottom of a drawer for my Z-wave duties for perhaps the next year or until things smooth out a little.
Because the cache file versioning changed, so the entire thing is re-generated. Losing the cache file means losing the names. A good reason to stick to HA for naming. https://github.com/home-assistant/core/issues/38068#issuecomment-663305036
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.