Changes to level are ignored when a light is off

[dhylands]

The Zigbee spec actually states that changes to the level SHALL be ignored when the light is in an off state.

The adapter can cache the level and, if it changed, send the updated level the next time that the light is turned on.

Steps to reproduce:

• turn the light on
• make it really dim
• turn the light off
• make the light bright
• turn the light on and you should observe the light turning on in the dim state

[twobraids]

this is also true with color. changing a color of a Philips Hue light (no Hue Hub) is ignored by the bulb, but not by the Gateway UI.

Steps to reproduce:

• turn philips hue bulb on
• change color to yellow
• turn philips hue bulb off
• change color to red
• UI now shows red and off
• turn philips hue bulb on
• the bulb lights up yellow, but the UI shows that it is red

[benfrancis]

I'm going to call this a bug although I realise in the case of Zigbee it's just following the spec. I agree that having an adapter cache property changes is a good approach, so that the UI doesn't represent state which can't be set.

[twobraids]

This bug is affecting my work with the Web Things API. It appears that the order of operations when interacting with the Things Gateway is not guaranteed. Here's a log from my code that is using the Web Things API:

2018-10-07 09:22:07,517 rules.py:265 INFO Philips HUE 05 setting on to True
2018-10-07 09:22:07,521 rules.py:265 INFO Philips HUE 05 setting color to #FF0000

The Things Gateway UI shows that the bulb should be lit with the color red "#FF0000".
However, in the real world, the bulb lit with the color that it had before it was turned off last time "#0000FF" rather than "#FF000".

The Things Gateway log reveals why:

2018-10-07 16:22:07.751 zigbee: setProperty property: color for: zb-0017880103415d70-onOffColorLight profileId: 0104 endpoint: 11 clusterId: 0300 zcl: hsv: [0, 100, 100] value: #ff0000
2018-10-07 16:22:07.754 zigbee: setProperty property: on for: zb-0017880103415d70-onOffColorLight profileId: 0104 endpoint: 11 clusterId: 0006 zcl: on value: true

The commands got reversed in order. The command to turn red was given to the bulb first, but since the bulb wasn't on, the command was ignored. When the bulb received the "on" command, it lit the color it had been before it had been turned off last time.

There are several places where the order could have been disrupted. My own code is asynchronous in behavior, so even though the logging shows the requests happen in the right order, the order of the details of the network requests may not have been preserved. Perhaps the network congestion delayed the first request which gave the second request the chance to jump ahead. Since the Things Gateway is inherently asynchronous, the ordering could have been reversed within the scheduling of responding to the two requests.

I think I've seen this behavior once with the built in GUI rules system, however, I've not been able to reproduce it. see next comment

Regardless of where the order of operations were reversed, implementing a caching mechanism to allow changes to the state of things not actually turned on would resolve the issue.

[twobraids]

@hobinjk, you might find this interesting:

Within a few minutes of my previous post, I witnessed the same out of order behavior using the GUI Rules System. A Philips HUE bulb was supposed to turn on and then change to red. Instead, according to the log, it set the color red and then turned the bulb on. It lit up blue, though, the GUI showed as red.

2018-10-07 17:50:32.362 PropertyProxy: setProperty property: color for: zb-001788010311383e to value: #ff0000
2018-10-07 17:50:32.376 PropertyProxy: setProperty property: on for: zb-001788010311383e to value: true

[dhylands]

I have a branch in the works which will cause property changes to be cached when the device is off and applied once the device turns on.