res_required not working for all Message types?

I have a working implementation in java of the current LAN Protocol specification. Whilst testing and playing around with res_required flags, I noticed that responses are not always sent back?

In casu, I have the SetPower (decimal 117) message, that does not generate responses at all. (Bulb is on latest firmware). Set

Are there any other message types know not to generate response? e.g. it does only generate a response when explicitly written in the specification?

On a separate note, what is the difference between SetPower at the Device level and the Light level? Is the former all about energy management? Or do they achieve the same thing?


Excellent! I know there are a few people interested in Java implementations of our protocol.

I just did some testing and found that both Device::SetPower and Light::SetPower both return their respective StatePower messages when the res_required flag is set, on all the devices with the latest firmware. The StatePower message that is returned includes the previous power state before the SetPower action was processed. Are you using a non 2.X firmware version?

Currently all the Get and Set messages documented return responses, along with the EchoRequest message. For backwards compatibility some messages may return responses even if the res_required flag is not set.

Device::SetPower and Light::SetPower will do the exact same thing on a LIFX Lightbulb. The difference is that Device::SetPower is intended to work on devices other than lightbulbs if we make them in the future. Also Device::SetPower does not support a duration like Light::SetPower does.

I will verify again, and check exact version they are running. In any case, all bulbs were triggered to upgrade to the latest firmware using the iOS app.

Now that we are on the subject, and as I have read elsewhere, the returned message is always the previous state? e.g. that hold true for all Message types? if so, the only way to detect the real latest state is to do a Set (without res_required), and then a Get? in doing so, is there a delay to respect between the two, e.g. time the bulb need to perform the Set action?


Yes, the state that gets returned from Set messages is that state of the bulb before the action gets processed (ie the state that is destroyed). What I suggest is that if you don’t care about that state then instead of asking for a response, ask for an acknowledgment. If you receive an acknowledgment you can assume that the change applied and update any internal state tracking.

I myself to let the bulb be the source of truth and do a Get every single time I want to know the state. this is because there are many other things that could be talking to the bulb (our apps, third party apps, the cloud, third party cloud apps and so on) and altering the state. If you tell the bulb to fade itself off over 10 seconds and it doesn’t complete it is likely because the user interrupted it via some other channel. If you keep a cache inside your application or try to track the state there it is nearly impossible to decide when to invalidate it and when not.