I’m sending a SetColor message with res_required flag to a Lifx Color bulb (FW Version 2.1, Product 1.1.6). The resulting State message (107) has the previous lamp state instead of the newly set values. Is anybody else seeing that? Behavior is the same with or without additional ack_required flag.
Here is the response I got when I asked one of the firmware engineers:
Yes, if the
res_requiredflag is set, the bulb will respond with the current state, not the future state, because there’s no guarantee the end-state will ever be reached. This could happen if another message changes the color before the current change completes. You should use sequence numbers in the frame header to confirm that your message was received (set
sequence, then set
ack_requiredflag is useful for SET requests, to know that your request was received.
res_requiredflag is useful for SET requests, to also return the current state (which can reduce traffic on the wire, since you don’t need to GET, then SET)
Thanks for the response, David!
It still doesn’t quite make sense to me though: the only parameters that get set in different messages are Power and Color and they are fairly independent.
Or are you saying it’s about collisions with multiple controllers updating different properties within the Color message, i.e. one changes Hue and the other changes Saturation? In that scenario both controllers would need to compare their state with the state they got back and then send a correction message to undo the changes they didn’t intend to make? Not sure that’s a very common scenario.
On the other hand, if the message returned the new state, especially as a broadcast, I could see that as very useful: all controllers could pick up the state change instantly (unless a UDP packet gets lost, of course, so they’d still need to do periodic polling to keep their state current).
I do see how I can build a reasonable user experience with ack’s and periodic polling, but the “stale state” message doesn’t really fit into my picture…
Thanks again for looking into this!
I think what they mean is that if they return the state that you sent to them you might assume that the bulb had reached that state. However in reality several other clients (including ones you cant see in the cloud) may be also changing the state of the bulb and it might never reach that state. For example if another client makes a second change while still within the duration of the first change.
We have tried to avoid broadcasts as much as possible because we found they are particularly unreliable on our customers wireless networks. It also doesn’t scale once you have large numbers of bulbs on the same network.
Is there much use in returning the state that you sent to the bulb back, except in the case of a broadcast? The client knows what state it sent, and provided it has received an acknowledgment it can assume that it has been applied, or was at least attempted.
It seems like that wouldn’t be particularly reliable. If the request makes it through, but the response is dropped, then the original state is gone, and there’s no way to retry and find out what it was. It seems like it would be more reliable to issue a GET, retry until you get a response, and then issue the SET.
I’ll take this feedback to the firmware team, its unlikely that they’ll change the way these existing messages work, but they may add new ones in the future that work differently.