Why does OZW need to send GET after every SwitchMultiLevel report

[matejdro]

trafficstars

After changing position of my Z-wave blinds, OZW log is filled with entries like this:

[info]: Info - Node: 66 Received SwitchMultiLevel report: level=39 
[debug]: Detail - Node: 66 Value Updated: old value=39, new value=39, type=byte 
[debug]: Detail - Node: 66    Target Value is Set to 37 
[debug]: Detail - Node: 66 Value Updated: old value=39, new value=37, type=byte 
[debug]: Detail - Node: 66 Changes to this value are not verified 
[debug]: Detail - Node: 66 Value Updated: old value=0, new value=0, type=int 
[debug]: Detail - Node: 66 Changes to this value are not verified 
[debug]: Detail - Node: 66   Expected reply and command class was received 
[debug]: Detail - Node: 66   Message transaction complete 
[debug]: Detail - Node: 66 Removing current message 
[debug]: Detail - Node: 66 Notification: ValueChanged CC: COMMAND_CLASS_SWITCH_MULTILEVEL Instance: 1 Index: 9 
[debug]: Detail - Node: 66 Notification: ValueRefreshed CC: COMMAND_CLASS_SWITCH_MULTILEVEL Instance: 1 Index: 5 
[info]: Info - Node: 66 Sending Get to Refresh Value after Target Check 
[debug]: Detail - Node: 66 Queuing (Send) SwitchMultilevelCmd_Get (Node=66): 0x01, 0x09, 0x00, 0x13, 0x42, 0x02, 0x26, 0x02, 0x25, 0xcf, 0x6b 

If I understand this properly, even after receiving updated value from the device, OZW will still poll for a new value. Blinds already send their updated value pretty frequently, so this doubles the already frequent chatter on the network.

With one device, this is not that big of a problem. But when I change position of several blinds at once, excessive chatter on the network often causes timeouts.

Why is this necessary? Would you be willing to accept PR to disable this on per-device basis (similarly to the NoRefreshAfterSet flag)?

[kpine]

I would not assume this behavior is intentional. The target check and refresh logic was recently added as part of #1321, which is still in progress. If you downgrade to a prior release you will not see this, for example, build-150 of the ozwdaemon container.

[matejdro]

Thanks for the answer. I've tried build-150 and you are correct, there is no get spam. However, interestingly enough, device also does not seem to send SwitchMultiLevel report on its own anymore. I assume OZW stack sends some flag whether to send reports or not?

[kpine]

From your initial report I was assuming you were activating the device locally (from a physical switch). Can you clarify if you were doing that, or using z-wave commands? There was only a snippet of logs, with no Set shown, so I was assuming that the report was unsolicited.

When you activate a switch locally, I think (?) the usual behavior is to send a single final report. I'm not familiar with blind controls (which use the same command class as dimmers), but if you say the "device also does not seem to send SwitchMultiLevel report on its own anymore", then I would guess it was never sending reports and it was OZW requesting them. You can sometimes enable or disable reports in config parameters, or change group associations to add or remove notifications, but I doubt you've done that.

If you do a Set from Z-Wave, in build-150 it will follow with a single Get. In later builds (e.g. build-170), it will refresh the value until it reaches the target, as your log snippet was doing.

Maybe you want to provide a full logs to clarify? With build-150, you need to manually refresh the value after a set to get the final value. If you want OZW to refresh the value automatically, you'll need to go back to the latest version. And yes, it is very aggressive and not always reliable. I've noted that in https://github.com/OpenZWave/open-zwave/issues/1321#issuecomment-663132492. Even with the polling backed off to 250 ms it seems to be too much.

[matejdro]

I am doing it from z-wave commands.

Here is full log of me changing the position: https://github.com/OpenZWave/qt-openzwave/files/5288386/ozw.log

I thought reports were unsolicited at first (lots of Aeotec devices send reports on their own), but based on what I've seen on build-150 it seems that they are requested by OZW. So sorry about that.

[oxgl]

Hi, in my case this is a huge problem. The Aeotec switches are totally out of sync - details here.

[oxgl]

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 .

[abmantis]

I've added the following to zw116.xml (aeotec), bumped revision, and refreshed the node. Despite the revision getting updated in the ozw_cache, the Compatibility section is still empty. Do I need to do anything else?

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

I also see this on the log during the node refresh:

2021-01-06 23:53:32.008 Info, Node085,   Opening config param file /etc/openzwave/aeotec/zw116.xml     
2021-01-06 23:53:32.014 Info, Node085, (37 - COMMAND_CLASS_SWITCH_BINARY) - Compatibility Flags:       
2021-01-06 23:53:32.014 Info, Node085, (37 - COMMAND_CLASS_SWITCH_BINARY) - State Flags:               
2021-01-06 23:53:32.014 Info, Node085, (112 - COMMAND_CLASS_CONFIGURATION) - Compatibility Flags:      
2021-01-06 23:53:32.015 Info, Node085, (112 - COMMAND_CLASS_CONFIGURATION) - State Flags:              
2021-01-06 23:53:32.016 Info, Node085, (133 - COMMAND_CLASS_ASSOCIATION) - Compatibility Flags:        
2021-01-06 23:53:32.016 Info, Node085, (133 - COMMAND_CLASS_ASSOCIATION) - State Flags:        

[matejdro]

Try turning off OZW, editing the file while it's off and then turning it on

[abmantis]

@matejdro I can't edit the zw116.xml file while it is of, because I'm using HASSIO plugins, so I cannot map a volume for /etc/openzwave/. Editing the zwcache file does not work also, because it gets rewritten when I start Z2M. Still, refreshing the node (without rebooting Z2M) was picking the new file revision, so it should be picking the file changes, right?

[matejdro]

Sorry, I have no idea. I'm not using HASSIO, but I've noticed that editing files while OZW is active usually results in changes being reverted.

[abmantis]

But when I edit zw116.xml with Z2M running and refresh the node, it does update the revision on the cache for that node. It is just ignoring the NoRefreshAfterSet for some reason.