I have a rule that turns on all the lights in the house. It is rarely used (more of a safety feature) but I use it to test ZWave performance.
I just noticed today the logs show the device being set to 255% of brightness. That seems an odd level..... The rule commanding the setting is set for 95%.
255 seems suspiciously like hex FF so I wonder if there is a bug related to hex2dec or vice vesa?
Not sure this is harming anything other than an erroneous log entry. Is this a device reporting, driver logic, or system bug?
Since you are using a custom driver, it would be best to start with the author -- my guess is that it's parsing some report value of 0xFF (as you suspect), almost certainly something related to SwitchMutlilevel, that it should either ignore or treat differently. But the author would be in the best position to know that as well as what logging may be helpful to dig in more if not already apparent.
I'd also make sure you're using the latest version of their code. Your hub model and whether you have Z-Wave JS (or legacy) enabled may also be helpful.
That being said, this looks like a @jtp10181 driver from the name, and I'm sure he'll know.
Ah.. If it's ZWave-JS .. I think I know the problem.. Can you confirm @CuriousB
2 Likes
Ok.. I'll get that fixed..
1 Like
Thanks, cause yeah, this is not my problem. The device would never be responding with that value, it is not a valid response. The driver just accepts whatever the device responds with (unless using brightness correction) and pushes the event.
My driver will SEND the 0xFF value to the device for an "on" command, which tells the device to turn on to its default/last level. In this case though @CuriousB said they are being explicitly set to 95, so the 0xFF would not be used. So I have no idea where ZWJS would be hallucinating this 0xFF from.
1 Like
Confirmed fixed in 2.5.0.129
1 Like
