CC command multilevel switch with 0xFF

[aleconakad]

Hi,

I have a channel in my sketch defined as ZUNO_SWITCH_MULTILEVEL(). I 've implemented both setter and getter for it. All is fine. When I try to send from a controlling device (per direct association) the value of 0xFF, in the setter I see the value 0x63 (Full On) being logged and interpreted.
what could be the root cause of this? Can this be modified in some hidden configuration parameter?

with the same controlling device I can control an AEOTEC Dimmer and it works as expected. I notice that the dimmer starts on to the latest value set.
Thanks in advance

[PoltoS]

Sure you are on 2.15? The value 0xFF should be passed as is to your setter. It is your responsbility to convert it to something in the range 1-63

[aleconakad]

Hi,

I am on 2.1.7. I have just confirmed this behaviour with Indigo domo Sw on Mac. From there I can send RAW commands to the Z-uno. I see that 0xFF is automatically interpreted to 0x63.
shall I switch to an older version, 2.1.6 maybe?

[PoltoS]

I ask R&D

[aleconakad]

Btw, I just tested with CC BASIC with 0xFF and it works fine. It restores to the last active value. It seems that the issue only happens with CC MULTILEVEL SWITCH

[PoltoS]

Indeed.... Please check this line in ZWSupport.ucxt
https://github.com/Z-Wave-Me/Z-Uno-Core ... .ucxt#L434

You can remove the check for 0xFF and then 0xFF will be passed as it is to the Setter. The file in the library folder.

The reason for this is because 0xFF was deprecated:

Switch Multilevel specification

Снимок экрана 2021-05-24 в 13.34.53.png (91.48 KiB) Viewed 6302 times

[aleconakad]

Thanks. I will give it a try.

[aleconakad]

BTW,

the 0xFF value has been deprecated only for the Multilevel Switch Report Command, but not for the Multilevel Switch Set Command. This means a device must be able to respond to 0xFF values in Set commands, but should not report a 0xFF value when reporting back to Controller or other associated nodes.

[PoltoS]

Well noted. We will check it again