ozw: Homeseer HS-WD200+ dimmer status is not updating when toggling the dimmer #36616
Comments
|
ozw documentation |
|
I would recommend you attach two MQTT dumps to this issue. Replace The first dump would be the entire node, so The second dump would capture the activity while you toggle the switch, This would show whether the Target Value is being published by OZW or not. For that, you could dump You could also turn on MQTT debug logs but it gets busy quickly. Question for the developers, the light component is checking for a target value, but the discovery schema does configure it, is it necessary to add it to pickup the Target value? |
|
Yes, I think we need to add it to the discovery schema. If I get a dump from the device I can try to fix it. |
|
Initial dump: mqtt_dump.txt I only triggered the dimmer once and not twice to get it in the right state.
Right now I only have two light switches using the entire system so I can do this if the info isn't in the dumps. |
|
I don't see anything in the second dump file that shows the light switch going from on to off, maybe I am missing it. It looks like you selected the entire OpenZWave topic instead of concentrating on the values for the SWITCH_MULTILEVEL command class for the specific node, which makes it difficult to follow. If you dump using the topic I posted the results will be filtered to the ones that are important. Maybe you can get another one? If you want to use debug logs, here's a configuration, restart after enabling. You might be able to enable it at runtime with service calls. logger:
default: info
logs:
homeassistant.components.ozw: debug
homeassistant.components.mqtt: debugYou can also use "DevTools -> MQTT -> Listen to a topic" to subscribe and watch changes to the dimmer values, which is basically the same as what the dump does, but slightly more accessible. Again, you'd want to subscribe to topic Or, if you have access to $ mosquitto_sub -h mqtt_broker_hostname -R -t OpenZWave/1/node/8/instance/1/commandclass/38/value/#The dump and "Listen to a topic" show retained messages. That command will ignore retained messages and print only newly published messages, so it will be a little easier to follow. I also find it easier to read on the terminal, instead of in HA. |
Sorry i missed that in your previous post. Here is seems the Target Value is retained and not being updated? Here is watching the topic with And here i trigger the dimmer to off again to get it back in the right state Back on And retriggered to match the correct state |
|
Even when setting the ramp time to 0 on the dimmer config itself the problem is still there. I don't have a different branded dimmer to compare with so I am not sure what is supposed to be happening. From what i can tell there is no target value being sent to mqtt. I also noticed the value field for my switch goes from 0 - 99. If i set to 255 then it will automatically update back to 99. Is there some debug values to pull from the ozwdaemon? |
That has never worked for me. Even assigning the ramp config values to be as quickly as possible, the GET after the SET always reports the wrong value.
0-99 are the valid brightness values. 255 means toggle the last value.
You should be able to follow the logs and see the interaction between the OZW library and the switch. You'll see logs that say |
I am using the addon which, for debugging, has been less than stellar. I have been updating the addon as they come out and retesting. There is so much logging that the supervisor logs and the |
|
I'm encountering the same thing with the HS-WD100+. OZW never sees the final state of the device, just an initial COMMAND_CLASS_SWITCH_MULTILEVEL as it transitions to the final state. Should the device config xml be updated to force a refresh when it sees this command class? |
|
I've updated the config to add That works for basic on/off, but when local dimming, OZW/HA isn't updated with the correct value. When performing local dimming, only CENTRAL_SCENE events for the button press seem to be emitted. What config changes could I use to force a refresh? I tired both a |
What version of the COMMAND_CLASS_SWITCH_MULTILEVEL is being reported? If it's V4, then you would be better off relying on the Target value instead of refreshing. If V3 or earlier then VerifyChanged would be the way to go, but it still fails in some cases. Ideally, OZW should do this w/o any config overrides.
Sounds like you need a firmware update? "v5.15: Updated ZDK to 6.51.08. Added Z-Wave “switch multilevel report” (instant status) to button press (9/30/16)". https://homeseer.com/current-downloads/ |
|
@grizzlyjere I'm hitting what i believe is the same issue with Jasco Dimmers. I couldn't figure out yet how to change the config in my Hassio setup. Is this within the openzwave docker container ? Essentially wanted to try your suggestion of setting: true |
Thanks for the pointer. The HS-WD100+ reports V1, so VerifyChanged seems to work well. The HS-WD200+ is reporting V4, but the TargetValue isn't reported correctly. Not sure if that's a dimmer problem or part of the broader issue OZW is looking into with VerifyChange.
Ah! Never updated the firmware -- that did the trick, thanks! |
|
@andrerod Yes, I'm using the openzwave docker container. I'm running it stand-along instead of the HA add-on. My change can be found in this PR if you want to copy & paste to try: https://github.com/OpenZWave/open-zwave/pull/2272/files |
Strangely enough, in the pre-release version of this a person was reporting that their WD100+ was sending Target values, meaning it is at least V4. I wonder if there are multiple versions of the switch. The ZWave products DB lists two of them, the newer one shows it supports V4, while the older one shows nothing. Pretty annoying if they released two versions of the same switch w/o changing the IDs, happens often though.
That's basically the gist of this issue. If a switch is correctly implementing V4, then using the Target value will avoid having to poll the switch, which is always preferred. Since you're running the standalone docker container it's easier to get logs, did you already check if a Target value is being returned or not when you toggle the switch? |
For the HS-WD200+ I did some testing and I may have misunderstood Target Value and misspoke. I guess TargetValue its only send when there is a local action? And it's only a 100 point scale (vs. 255 in HA)? If so, it appears to work. I'm seeing changes reported in HA and the Target Value being send in MQTT very quickly. Remote changes don't trigger a TargetValue in MQTT. What's not working are status updates when controlling from HA. Changing the brightness or turning on/off from the UI are rarely reported correctly. If I use oz-admin to change the level (on the user values tab) that updates HA correctly instantly. Viewing from MQTT, looks like a dimming duration is briefly turned on and an in-progress, but not final level is reported. Assuming I haven't goofed somewhere. |
What do you mean by local and remote? I would say local is pressing the switch, remote is sending a z-wave command from the controller, or did you mean the opposite?
In zwave valid level values are 0 (off), 1-99 (lowest brightness to 100%) and 255 which means restore the last level. So it makes sense that target would be something 0-99. |
Yeah, local being switch action. I see TargetValue only when there is an action at the switch. |
In that case, the behavior you're observing doesn't seem correct to me. The spec says that if a Get is sent immediately after a Set, the device must return the target value. Either the device is non-compliant, or something is going on with OZW. Would you mind posting the OZW logs from when you remotely activate the switch? I would be interested in taking a look. |
@kpine Sure. Here are some log extracts. Happy to provide more
|
|
Logs look great. Here's my interpretation as a Z-Wave amateur.
OZW does a Multilevel Set (
That looks good, the command to turn off the switch was sent as expected. After the Set is an immediate Get, which is returned via a Report command: The Report payload (
Whoops, that's wrong isn't it? Both the current and target values are the old ones (switch 100% on). How does this happen? It's as if the Get were received before the Set, so the device is returning the state prior to the Set. I would have expected that Current might have been 100% still, but at least Target should have been 0. The Duration of 0 also means that the device is already at the intended value. Because the Report is showing level 99, OZW doesn't notice any change from the current values, so it doesn't tell HA anything, and HA stays as it was.
The same Set and Get commands are repeated: Then the Report: The Report payload (
This is correct, node reports it is off now. OZW agrees and updates HA with the new values, and HA updates the switch state to off.
The Set to turn on the light to 57% brightness: Payload The Report payload (
Oh no, another failure. The Current Level is 0, which sounds reasonable (switch hasn't changed yet), but the Target Value is 100% brightness, even though you set it to 57%. HA shows off, because it the current value never changed and it doesn't look at the Target (as mentioned earlier). Again, how does this happen? Above we see OZW sending the Set command with 57% brightness. OZW processes the report and only the Target value changed, which HA is not properly using yet. If HA did use the Target value here, you would still see the wrong value, the switch would appear at 100% instead of 57%. Also, the Current Level would be out of sync because the value is never updated again. Not sure if that matters or not, if the Target value was correct. @Fishwaldo, any thoughts on what's going on here (did I miss something)? |
|
@kpine your decode is correct. This device is all over the place unfortunately. You could try the VerifiedChange flag, that should work around it (I assume if you manually refresh the ValueID after a while it’s correct?) |
How do I manually refresh ValueID? I added VerifyChange for the 200+, and it doesn't seemed to have helped. I did the same for the 100+ and it "mostly" fixed (will post separately to avoid confusion). On the HS-WD200+, I've added the following to the device specific XML. Cleared the cache, restarted, and confirmed it was picked up by in cache file. This is correct, isn't it? When turning the device from 100% brightness to off, it doesn't get updated. Same with dimming, and turning on to off. I noticed it still says |
|
This seems better on HA 0.114.0. The devices will toggle, go back during dimming then update to the final state at the end. However there are still instances where the HA state and the actual state of the dimmer are different (HA says on, light is off or visa versa). This one issue is really holding me back from HA and I would love to help out on providing a fix, but its' not clear to me where to go next or where to start. |
|
It is still a work in progress. OpenZWave/open-zwave#1321 |
|
I'm a newb with Zwave, but I also have this exact same with HS-WD200+ and have had it since trying to switch to HA completely. I'm very eager to help in any way I can to try and get this truly fixed. I also have a contact with Homeseer, so I'm happy to reach out to them if we're feeling this might be an issue with the device's firmware. Msg me if I can be of help. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Still exists. |
|
Same issue. Anyone try this with zwave-js? |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
This issue still seems to be active. I'm using a WD200+ with the latest Home Assistant and OZWDaemon |
|
As a workaround, I changed the ramps to be 1s for local and remote: Developer tools > services |
The problem
Testing out new ozw integration with my HS-WD200+ switches the state of the switch doesn't initially match (I had the same issue with zwave integration as well)
The on/off switch (HS-WS200+) work fantastic. The result is near instantaneous and works great.
However on the HS-WD200+ if i turn on or off the switch (or change the dimmer) the status toggles and then toggles back before the dimming is complete leaving the switch in the wrong state. Toggling it again fixes the problem
For example if my lights are on toggling the dimmer to off will toggle the HA state to off and the immediately back to on. Mean time the switch/lights will remain off. Switching back to off seems ot fix this.
Looking at MQTT explorer i see there is a Target Value but it doesn't seem to be updated at all (perhaps a problem with ozw?)
Environment
Problem-relevant
configuration.yamlNone.
Traceback/Error logs
None.
Additional information
The text was updated successfully, but these errors were encountered: