search

OpenZWave / open-zwave

a C++ library to control Z-Wave Networks via a USB Z-Wave Controller.
http://www.openzwave.net/
GNU Lesser General Public License v3.0
1.05k stars 916 forks source link

VerifyChanges integrated with level and target in SwitchMultiLevel (and others) #1321

Open Fishwaldo opened 6 years ago

Fishwaldo commented 6 years ago

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

AlCalzone commented 6 years ago

See #1322 :)

thoraxe commented 5 years ago

@Fishwaldo @AlCalzone so is this issue (1321) closed since 1322 is merged?

AlCalzone commented 5 years ago

Seems so, but I can't close it.

Fishwaldo commented 5 years ago

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

thoraxe commented 5 years ago

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: true

This feels kinda like oh it doesn't work right so I'll just poll

Fishwaldo commented 5 years ago

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

aerofeev2k commented 5 years ago

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.

Fishwaldo commented 5 years ago

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: https://github.com/OpenZWave/open-zwave/issues/1321#issuecomment-440968139

kpine commented 4 years ago

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, verify_changes="true" for the Level value (I had to restart ozwd for the flag to take effect though, even though the cache value was correct, is that expected?). The verify works fine when toggling the light on or off, and the entity state in HA is correct. The polling might be a little aggressive though.

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.

Dinth commented 4 years ago

Ive got same problem with Fibaro Dimmer 2s

DanielBaulig commented 4 years ago

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: https://github.com/MichaelStruck/SmartThingsPublic/blob/master/devicetypes/michaelstruck/ge-motion-dimmer-switch-26933.src/ge-motion-dimmer-switch-26933.groovy#L413-L418

Fishwaldo commented 4 years ago

Target Handling is implemented for those newer devices. Old Devices should use the VerifiedChanged flags.

kpine commented 4 years ago

The duration value is not being set correctly with these latest changes. For example, duration 0x255 is actually being sent as 0x4.

kpine commented 4 years ago

For example:

[20200709 8:13:17.807 PDT] [ozw.library] [info]: Info - Node: 3 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 255
[20200709 8:13:17.807 PDT] [ozw.library] [info]: Info - Node: 3 SwitchMultilevel::Set - Setting to level 255
[20200709 8:13:17.807 PDT] [ozw.library] [info]: Info - Node: 3   Duration: 255 seconds
[20200709 8:13:17.807 PDT] [ozw.library] [debug]: Detail - Node: 3 Queuing (Send) SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0xff, 0x04, 0x25, 0x3a, 0x23
[20200709 8:13:17.807 PDT] [ozw.library] [debug]: Detail - Node: 3 Queuing (Send) SwitchMultilevelCmd_Get (Node=3): 0x01, 0x09, 0x00, 0x13, 0x03, 0x02, 0x26, 0x02, 0x25, 0x3b, 0xde
[20200709 8:13:17.807 PDT] [ozw.library] [info]: Info - Node: 3 Sending (Send) message (Callback ID=0x3a, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0xff, 0x04, 0x25, 0x3a, 0x23

Toggling a switch on results in a 4 second transition 0x26, 0x01, 0xff, 0x04.

kpine commented 4 years ago

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.

ozwdaemon.log

Fishwaldo commented 4 years ago

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.

ozwdaemon.log

This is a device with VerifiedChanges right?

kpine commented 4 years ago

This is a device with VerifiedChanges right?

Yes.

kpine commented 4 years ago

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:

[20200709 16:49:03.200 PDT] [ozw.library] [info]: Info - Node: 3 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 15
[20200709 16:49:03.200 PDT] [ozw.library] [info]: Info - Node: 3 SwitchMultilevel::Set - Setting to level 15
[20200709 16:49:03.200 PDT] [ozw.library] [info]: Info - Node: 3   Duration: 15300 seconds
[20200709 16:49:03.200 PDT] [ozw.library] [info]: Info - Node: 3   Rouding to 127 Minutes (over 127 seconds)
[20200709 16:49:03.200 PDT] [ozw.library] [debug]: Detail - Node: 3 Queuing (Send) SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0x0f, 0xff, 0x25, 0x3a, 0x28

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:

[20200709 16:50:19.950 PDT] [ozw.library] [info]: Info - Node: 3 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 0
[20200709 16:50:19.950 PDT] [ozw.library] [info]: Info - Node: 3 SwitchMultilevel::Set - Setting to level 0
[20200709 16:50:19.950 PDT] [ozw.library] [info]: Info - Node: 3   Duration: 15300 seconds
[20200709 16:50:19.950 PDT] [ozw.library] [info]: Info - Node: 3   Rouding to 127 Minutes (over 127 seconds)
[20200709 16:50:19.950 PDT] [ozw.library] [debug]: Detail - Node: 3 Queuing (Send) SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0x00, 0xff, 0x25, 0x3d, 0x20

Same thing, duration is fine but the logs are wrong.

Turning on the switch from Home Assistant:

[20200709 16:50:59.247 PDT] [ozw.library] [info]: Info - Node: 3 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Dimming Duration - 5 - 1 - 255
[20200709 16:50:59.250 PDT] [ozw.library] [debug]: Detail - Node: 3 Initial read of value
[20200709 16:50:59.250 PDT] [ozw.library] [debug]: Detail - Node: 3 Notification: ValueChanged CC: COMMAND_CLASS_SWITCH_MULTILEVEL Instance: 1 Index: 5
<snip>
[20200709 16:50:59.251 PDT] [ozw.library] [info]: Info - Node: 3 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 15
[20200709 16:50:59.251 PDT] [ozw.library] [info]: Info - Node: 3 SwitchMultilevel::Set - Setting to level 15
[20200709 16:50:59.251 PDT] [ozw.library] [info]: Info - Node: 3   Duration: 255 seconds
[20200709 16:50:59.251 PDT] [ozw.library] [info]: Info - Node: 3   Rouding to 4 Minutes (over 127 seconds)
[20200709 16:50:59.251 PDT] [ozw.library] [debug]: Detail - Node: 3 Queuing (Send) SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0x0f, 0x84, 0x25, 0x43, 0x2a

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?

https://github.com/OpenZWave/open-zwave/blob/f81bc04b672d52b7bd5f8e8b604058c170c9911b/cpp/src/command_classes/CommandClass.cpp#L581-L589

Any times over 127 minutes are going to overflow and be truncated. Take for example 128 minutes, 7680 seconds.

(gdb) set $seconds = 128 * 60
(gdb) p $seconds
$1 = 7680
(gdb) p /x (unsigned char)0x80 + (($seconds/60) & 0xFF)
$2 = 0x100
(gdb) p /x (unsigned char)((unsigned char)0x80 + (($seconds/60) & 0xFF))
$3 = 0x0

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.

[20200710 0:30:34.672 PDT] [ozw.library] [info]: Info - Node: 3 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Dimming Duration - 5 - 1 - 7680
[20200710 0:30:34.672 PDT] [ozw.library] [debug]: Detail - Node: 3 Value Updated: old value=999999, new value=7680, type=int
[20200710 0:30:34.672 PDT] [ozw.library] [debug]: Detail - Node: 3 Changes to this value are not verified
[20200710 0:30:34.672 PDT] [ozw.library] [debug]: Detail - Node: 3 Notification: ValueChanged CC: COMMAND_CLASS_SWITCH_MULTILEVEL Instance: 1 Index: 5
<snip>
[20200710 0:31:24.664 PDT] [ozw.library] [info]: Info - Node: 3 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 99                                                                                                                                                [20200710 0:31:24.665 PDT] [ozw.library] [info]: Info - Node: 3 SwitchMultilevel::Set - Setting to level 99
[20200710 0:31:24.665 PDT] [ozw.library] [info]: Info - Node: 3   Duration: 7680 seconds
[20200710 0:31:24.665 PDT] [ozw.library] [info]: Info - Node: 3   Rouding to -128 Minutes (over 127 seconds)
[20200710 0:31:24.665 PDT] [ozw.library] [debug]: Detail - Node: 3 Queuing (Send) SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0x63, 0x00, 0x25, 0xb6, 0x37

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?

kpine commented 4 years ago

Here's a log showing some weird behavior for the verify changes (as discussed in Discord). Using latest ozwdaemon.

ozwd.log

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 old value=0, new value=0 for 7 Gets in a row, which is probably more than necessary.

Fishwaldo commented 4 years ago

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.

matejdro commented 3 years ago

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.

oxgl commented 3 years ago

Hi, this is a serious problem in my case. I have 2 types of Aeotec dual switches: ZW132 and ZW140, and their status is totally out of sync when I'm changing the value from OZW (or from Home Assistant). I'm not sure how to check which version is used by Home Assistant, but I'm using the OZW add-on version 0.7.1, and I think It contains the OZW build 1c7b620.

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. 

[20201213 21:20:02.960 CET] [ozw.library] [debug]: Detail - Node: 23 Queuing (Send) MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Set (Node=23): 0x01, 0x0e, 0x00, 0x13, 0x17, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x01, 0xff, 0x25, 0x75, 0x14 
[20201213 21:20:02.962 CET] [ozw.library] [debug]: Detail - Node: 23 Queuing (Send) MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Get (Node=23): 0x01, 0x0d, 0x00, 0x13, 0x17, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x02, 0x25, 0x76, 0xe9 
[20201213 21:20:02.964 CET] [ozw.mqtt.commands] [info]: Processed Message for  "setvalue" :  "{\"ValueIDKey\": 390676512, \"Value\": true}" 
[20201213 21:20:02.965 CET] [ozw.library] [info]: Info - Node: 23 Sending (Send) message (Callback ID=0x75, Expected Reply=0x13) - MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Set (Node=23): 0x01, 0x0e, 0x00, 0x13, 0x17, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x01, 0xff, 0x25, 0x75, 0x14 
[20201213 21:20:02.967 CET] [ozw.library] [info]: Info - Node: 23 Encrypted Flag is 0 
[20201213 21:20:02.975 CET] [ozw.library] [debug]: Detail - Node: 23   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8 
[20201213 21:20:02.977 CET] [ozw.library] [debug]: Detail - Node: 23   ZW_SEND_DATA delivered to Z-Wave stack 
[20201213 21:20:02.990 CET] [ozw.library] [debug]: Detail - Node: 23   Received: 0x01, 0x07, 0x00, 0x13, 0x75, 0x00, 0x00, 0x02, 0x9c 
[20201213 21:20:02.992 CET] [ozw.library] [debug]: Detail - Node: 23   ZW_SEND_DATA Request with callback ID 0x75 received (expected 0x75) 
[20201213 21:20:02.995 CET] [ozw.library] [info]: Info - Node: 23 Request RTT 25 Average Request RTT 26 
[20201213 21:20:02.997 CET] [ozw.library] [debug]: Detail - Node: 23   Expected callbackId was received 
[20201213 21:20:03.000 CET] [ozw.library] [debug]: Detail - Node: 23   Expected reply was received 
[20201213 21:20:03.002 CET] [ozw.library] [debug]: Detail - Node: 23   Message transaction complete 
[20201213 21:20:03.004 CET] [ozw.library] [debug]: Detail - Node: 23 Removing current message 
[20201213 21:20:03.007 CET] [ozw.library] [info]: Info - Node: 23 Sending (Send) message (Callback ID=0x76, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Get (Node=23): 0x01, 0x0d, 0x00, 0x13, 0x17, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x02, 0x25, 0x76, 0xe9 
[20201213 21:20:03.009 CET] [ozw.library] [info]: Info - Node: 23 Encrypted Flag is 0 
[20201213 21:20:03.017 CET] [ozw.library] [debug]: Detail - Node: 23   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8 
[20201213 21:20:03.020 CET] [ozw.library] [debug]: Detail - Node: 23   ZW_SEND_DATA delivered to Z-Wave stack 
[20201213 21:20:03.033 CET] [ozw.library] [debug]: Detail - Node: 23   Received: 0x01, 0x07, 0x00, 0x13, 0x76, 0x00, 0x00, 0x02, 0x9f 
[20201213 21:20:03.035 CET] [ozw.library] [debug]: Detail - Node: 23   ZW_SEND_DATA Request with callback ID 0x76 received (expected 0x76) 
[20201213 21:20:03.038 CET] [ozw.library] [info]: Info - Node: 23 Request RTT 25 Average Request RTT 25 
[20201213 21:20:03.040 CET] [ozw.library] [debug]: Detail - Node: 23   Expected callbackId was received 
[20201213 21:20:03.045 CET] [ozw.library] [debug]: Detail - Node: 23   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x17, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x03, 0x00, 0xad 
[20201213 21:20:03.047 CET] [ozw.library] [info]: Info - Node: 23 Response RTT 35 Average Response RTT 36 
[20201213 21:20:03.049 CET] [ozw.library] [info]: Info - Node: 23 Received a MultiChannelEncap from node 23, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_BINARY 
[20201213 21:20:03.051 CET] [ozw.library] [info]: Info - Node: 23 Received SwitchBinary report from node 23: level=Off 
[20201213 21:20:03.054 CET] [ozw.library] [debug]: Detail - Node: 23 Value Updated: old value=false, new value=false, type=bool 
[20201213 21:20:03.056 CET] [ozw.library] [debug]: Detail - Node: 23 Changes to this value are not verified 
[20201213 21:20:03.058 CET] [ozw.library] [debug]: Detail - Node: 23   Expected reply and command class was received 
[20201213 21:20:03.060 CET] [ozw.library] [debug]: Detail - Node: 23   Message transaction complete 
[20201213 21:20:03.062 CET] [ozw.library] [debug]: Detail - Node: 23 Removing current message 
[20201213 21:20:03.064 CET] [ozw.library] [debug]: Detail - Node: 23 Notification: ValueRefreshed CC: COMMAND_CLASS_SWITCH_BINARY Instance: 2 Index: 0

The value node in the device definition XML file:

<Instance index="2" endpoint="1" />
<Value type="bool" genre="user" instance="2" index="0" label="Switch" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="False">
  <Help>Turn On/Off Device</Help>
</Value>

Same result if I set verify_changes="true".

If I set attribute write_only="true", then only SwitchBinaryCmd_Set is executed, but SwitchBinaryCmd_Get isn't.

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!

oxgl commented 3 years ago

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.

AeotecZW_rev 6.zip

cben0ist commented 3 years ago

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.

AeotecZW_rev 6.zip

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? I am using the ozw addon 0.7.1 in home assistant. Thanks

oxgl commented 3 years ago

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? I am using the ozw addon 0.7.1 in home assistant. Thanks

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:

<Node id="23" name="" .......                                        <- DEVICE
    .....
    <CommandClass id="37" name="COMMAND_CLASS_SWITCH_BINARY">    <- COMMAND CLASS ID
        .....
        <Value type="bool" genre="user" instance="1" index="0" label="Switch" units="" read_only="false" write_only="false">
            <Help>Turn On/Off Device</Help>
        </Value>
        <Value type="bool" genre="user" instance="2" index="0" label="Switch" units="" read_only="false" write_only="false">
            <Help>Turn On/Off Device</Help>
        </Value>
        <Value type="bool" genre="user" instance="3" index="0" label="Switch" units="" read_only="false" write_only="false">
            <Help>Turn On/Off Device</Help>
        </Value>
    </CommandClass>

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 NoRefreshAfterSet to all values with given command class. Now open the device configuration file. Probably this is the file homeseer/hs-wd100plus.xml, and add this tag before section "":

  <!-- Compatibility Parameters -->
  <CommandClass id="37">
    <Compatibility>
        <NoRefreshAfterSet index="0">true</NoRefreshAfterSet>
    </Compatibility>      
  </CommandClass>

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. Now refresh the node in OZWAdmin (right click on the node).

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.