VerifyChanges integrated with level and target in SwitchMultiLevel (and others) #1321
Comments
|
See #1322 :) |
|
@Fishwaldo @AlCalzone so is this issue (1321) closed since 1322 is merged? |
|
Seems so, but I can't close it. |
|
Keeping it open as I want to integrate the target Value with the Refresh mechanisms. So the CC is updated but we can leverage a bit better internally |
|
Ah gotcha. I was having an issue with Home Assistant calling OZW and a dimmer switch. Basically the dimmer switch has a very slow ramp down from its max level (99) to its min level (0). OZW would stop refreshing the value before the dimmer hit 0 on the off cycle. This would result in Home Assistant thinking the dimmer was still on (val=34) when it was actually off. There's an extra refresh setting in HA that has "fixed" this issue. But I feel like it's a workaround for what the OP of this issue is talking about -- HA/OZW doesn't look to see if we hit the "expected" value and thus we never go back to check if it ever got there. The workaround: zwave:
usb_path: /dev/zwave0
network_key: !env_var ZWAVEKEY
config_path: /usr/local/lib/python3.6/site-packages/python_openzwave/ozw_config/
device_config:
light.master_bedroom_light:
refresh_value: trueThis feels kinda like oh it doesn't work right so I'll just poll |
|
I have no idea if HA implements it, or if the setting you refer to is the same thing, but as long as you call SetChangeVerified on the ValueID in question, OZW should continue to poll the device till such a time that two consecutive replies are the same. http://www.openzwave.com/dev/classOpenZWave_1_1Manager.html#ac26cc3c1b37cf068ac9eee23ef343c30 |
This is unfortunately not quite right. If Value::VerifyRefreshedValue() detects that the first SwitchMultiLevel report after a change contains the same value as the original, it will not proceed with verification. And that's sad because e.g. when I try setting new level in Domoticz/OpenZWave for HS-WD200+, I see a Set command immediately followed up by Get and SwitchMultiLevel report containing the value just before the change. So even if I force verify_change="true" for the Level in the XML, the verification doesn't happen, and the updated value is not reported. |
See my comment above: |
Fishwaldo
changed the title
|
I have a GE 14294 dimmer which implements Switch Multilevel V2. It suffers from this known issue in Home Assistant, where the Get after the Set reads the wrong level because of the slow ramp. I'm now testing the new zwave_mqtt HA component, and this same issue was logged there. I thought I'd give this switch a go in 1.6. I noticed besides the API there is an xml compatibility flag to enable the VerifyChanged flag. I added this to the GE xml and refreshed the node and the change was picked up in the ozwcache file, However, when I turn on the light with a different Dim Duration value, the level value is never refreshed. The command works (light slowly turns on), it's just OZW never attempts more than one Get despite the VerifyChanged flag being enabled. The result is the light appears off in HA (first Get returned level of 0) or even OZW Admin, but it is actually on. This sounds like the same thing @aerofeev2k has mentioned. This GE switch does not support the Target Value since it is only V2. |
|
Ive got same problem with Fibaro Dimmer 2s |
|
I'm using GE 26933 with HA and believe to be running into the same issue. The Get after Set causes HA to be updated with a wrong value during the ramp. I haven't tried verify_changes="true" yet. Note that the DTH for this dimmer for SmartThings seems to be solving this problem by simply deferring the Get until after 3.5 seconds have passed: |
|
Target Handling is implemented for those newer devices. Old Devices should use the VerifiedChanged flags. |
|
The duration value is not being set correctly with these latest changes. For example, duration 0x255 is actually being sent as 0x4. |
|
For example: Toggling a switch on results in a 4 second transition |
|
Here's a full log of toggling the switch on and off. With the 4 second transition it takes 7 seconds to complete. OZW seems to be stuck too many times repeatedly reading the level when it has reached 99 (off to on). I also noticed that toggling the light switch kills OZW-Admin. This is using a local build of the allinone image with the latest master here. |
This is a device with VerifiedChanges right? |
Yes. |
|
Not sure if you're done yet, so apologies if you're still fixing things, but here's what I see with the latest. I wiped my cache first before doing this as there were some errors after updating. I'll have to see if I can reproduce that. Turn on switch, without changing duration, setting level to 15 in ozw-admin: It appears the dim duration value gets defaulted to 15300, which is what was used after setting the switch on. The command sent 0xff as the duration, so that's correct, but the logs are misleading. Turn off switch in ozw-admin by setting level to 0: Same thing, duration is fine but the logs are wrong. Turning on the switch from Home Assistant: Well, obviously this is a breaking change for applications. They need to set the value in total number of seconds instead of encoding it. I think that's a better API anyways, that app can just pass through the time w/o having to encode it. Some other questions: 255 seconds -> 4.25 minutes -> round down to 4 minutes, that seems OK. Is the value 0x84 correct? The spec says 1 to 127 minutes is 0x80 to 0xFE, so wouldn't 4 minutes be 0x83? The code says that the maximum value is 15240 seconds (254) minutes, but that appears to be at odds with the 127 minutes (7620 seconds) / 0xFE from the spec. It looks like you are assigning 0xFE to 254 minutes instead of 127 minutes? open-zwave/cpp/src/command_classes/CommandClass.cpp Lines 581 to 589 in f81bc04 Any times over 127 minutes are going to overflow and be truncated. Take for example 128 minutes, 7680 seconds. So 128 minutes will end up being instant on. In fact that's what happens, OZW tries to round it to -128 minutes, and sets a duration of 0x00. Last thing, since the value is now a signed integer, what about using -1 for the factory default (0xff) value, instead of some arbitrary large number? |
|
Here's a log showing some weird behavior for the verify changes (as discussed in Discord). Using latest ozwdaemon. First I set the Dim Duration to 10 seconds. The switch was off. Then I set the Level to 50. ozw did a single Get, which immediately returns a current level of 0 and it never tries again. Then I went to the switch and turned it off manually. This switch sends a node info update (UPDATE_STATE_NODE_INFO_RECEIVED) when the switch is toggled, apparently. That causes ozw to issue many Gets until the level reaches a stable value of 0. However, the Gets are sent approximately every 50 ms, which seems a bit aggressive (a total of 28 Gets in 3 seconds) and it was stuck on |
|
Ok - I've added some code to backoff the initial validation check when verified change is enabled, and we will only check every 250ms. Might have to play with those numbers a bit to see what works well. I've fixed the Duration Encoding and Logging as well. Lets see how this goes. |
|
Could you make this interval configurable? 250 ms works fine when I'm only moving one blind. But when I move bunch of them at the same time, refreshes every 250 ms on every single blind seem to bog down my network and I'm often getting timeouts resulting from this. |
|
Hi, OZW is sending 2 messages when I change the switch status in UI: set switch status and then it (probably) verifies the status with get switch status. I'm sending the log, where you can see this strange behavior - I've deleted unneeded messages. This happens when I turn on the switch from UI. As you can see it sends Set(true). The light turns on, but the UI shows it's off. The system receives Get result at 21:20:03.054 -> changes the value from false to false. The value node in the device definition XML file: Same result if I set If I set attribute As you can see the command Set was sent at 21:20:02.965, and the command Get was executed at 21:20:03.007, so the difference are only 42 milliseconds. Isn't is possible that this is not enough time for the device to change the state? As someone already mentioned this device is able to report the changes, so it's not necessary to query the status after change. It seems like the verify_changes="false" is ignored by OZW. Thank you! |
|
Hi, I've fixed the device definition XMLs for two Aeotec switches ZW132 and ZW140, if anyone interested. This definition disables the automatic sending of SwitchBinaryCmd_Get command immediately after setting the value of the switch. You can enable updates from switch to OZW by setting the parameters 80-82. Just replace the XML file in config directory, and refresh node info. |
Hey @oxgl, would you be able to guide me in the way of doing the same thing for the Homeseer HS-WD100 dimmers ? How do we set the parameters 80-82 ? Where do I find the xml I would need to change and, indeed, how do I replace it? |
Hi @cben0ist! I'm not an expert, but I can try. So first of all, try to locate the ozwcache_xxxx.xml file. Find the device you want to modify. You can see the node ID in OZWAdmin. Try to find the XML tag Node id="xx", and then find the switch based on description. In my case the device ID was 23, and a switch description was inside the command class 37: Command class 37 is COMMAND_CLASS_SWITCH_BINARY - I believe it's the type of given value (in our case a binary switch), but maybe I'm wrong. Anyway, we will tell the OZW library to add one compatibility attribute Of course you have to replace the id with your command class. There is already a compatibility section in file homeseer/hs-wd100plus.xml for command class 38. If it's the same command class, delete this section. The parameters 80-82 in my case are the settings in device; description To set which notification would be sent to the associated devices (Group 1) when the state of Nano Dimmers load is changed. Probably it will be a different param In your case with similar description. |
We are at Version 3, Version 4 adds a Target Value Option in the report. It would be nice to update to this and incorporate into the Value::VerifyRefreshedValue Code
The text was updated successfully, but these errors were encountered: