[LAN Protocol] Messages not always being received

Developing with LIFX
#1

Hi all,

I’m having a few issues with a program I’m writing using C# (LifxNet wrapper) and a couple of LIFX Originals. Basically I’m sending the same command to both lights but it seems to be a hit and miss situation where sometimes one light will instantly receive the command but the other won’t at all and other times they both receive the command.

A good example of this is using the (light) SetPower command. In my code I send the SetPower On command to both my bulbs at the same time and sometimes they will both turn on but, more often then not, only one will turn on and the other will just stay off like it never received the command.

Now one workaround for this issue I have found is to put my code in a while loop using the GetPower command to poll the bulbs and continuously send the SetPower command until the light eventually gets it (usually the 2nd or 3rd attempt in most cases). However this isn’t very practical because, not only is it inefficient, but it looks pretty bad having one light turn on and the second light turn on 3 seconds later.

For what it’s worth this problem doesn’t happen when using the Lifx iPhone app or other applications which utilise the LAN protocol, so I haven’t ruled out it’s a problem in my own code, but at the same time it doesn’t feel like that is the cause here.

So with that all said, I guess my question would be, is there a reason why these bulbs are not receiving these messages? Or is this a common issue found using the LifxNet wrapper maybe?

Any advice would be much appreciated.

#2

Wireless networks will try to retransmit your packets in order to deliver them, even if using UDP. However ultimately some packets will get lost.

Instead of polling to see if the bulb has received your message you should be using the request with acknowledgement workflow for any messages the don’t have a response, and request with response for messages that do. This way you can tell if the bulb received the message based on if you saw an ack or reply. If you don’t receive a message in time you can retransmit the message you think didn’t arrive.

This is what we do in our phone apps, and the LIFX Cloud to ensure messages are delivered fast.

#3

New to the community, so I apologize if this is not a proper location for this post.

I haven’t dug in deep to figure out exactly what’s going on yet, but wanted to just chime in to say I observe exactly the same behavior, in case there are yet more people out there observing the same.

Android LIFX app on a Samsung Galaxy Note 5. One of two (random, which) Color 1000 bulbs will execute an action, the other behaves as though it’s not receiving any commands.

This is also limited to LAN (assuming LAN commands are sent whenever client is on the local network), because if I turn off my phone’s WiFi and switch to 4G LTE (and therefore LIFX Cloud), all bulbs respond.

During any particular time period, the acting bulb remains the acting bulb and unacting bulb remains the unacting bulb i.e. they won’t switch places within a 1-2 minute time period.

For example, I tap my group (containing the two Color 1000 bulbs) to turn the group on/off. One bulb does so, the other doesn’t. If I expand the group to show the individual bulbs, and tap the specific bulb that’s failing to act, the UI toggles that bulb’s icon (to reflect the state it should end up at per the command), then a few seconds later (after seeing the bulb not act), the UI then seems to perform its regular polling and updates the icon to reflect the bulb’s current state (having taken no action in response to the previous command).

Bulb on.
Tap bulb to turn off.
Icon turns off.
Bulb remains on.
Icon turns on.

If power cycling the bulb, the unresponsive bulb will respond for ~20 seconds, and then is likely to become unresponsive again.

Seems to be limited to LAN commands and to Color 1000 bulbs (as opposed to the Original A21 bulbs). When writing LIFX Support about the Android app constantly asking to perform firmware updates, I also noticed this in the diagnostics that were attached:

LAN IP: ‘NO_IP_AVAILABLE’ (Gateway: false)
Reachability: true
LAN Reachability: false
Cloud Reachability: true

Host Firmware: 1.10 (0)
Host Firmware Name: Unknown
Wifi Firmware: 101.62 (0)
Wifi Firmware Name: Unknown
Wifi Signal Strength: null
Wifi Signal Strength (RSSI): null
Hardware: LIFX Color 1000, vendor: 1, product: 22

Not sure how a device could be cloud reachable while having no IP, no gateway, and no LAN communication… this data also seems to be inaccurate, as my router clearly reports the bulb being connected, having an IP, and a strong signal. In any case, the log comports with my observations of being limited to LAN commands. This also makes me think the issue lies within the Color 1000 firmware, which is probably where my constant firmware upgrade requests are arising from as well. Perhaps I’ll try a factory reset on both Color 1000, reupgrade, and see if the issue(s) persist.

#4

the NO_IP_AVAILABLE message in the diagnostics means that the phone is not aware of the bulbs LAN IP. Most likely because it is not responding to packets. Though as you said it does seem to be responding to packets from the cloud, which is very interesting.

I’d be really interested in getting the firmware team to review your support case. Can you give me the case number?

#5

Hi Daniel,

[Ticket # 173788] I wrote support about the LIFX Android app asking me to perform firmware upgrades multiple times per day for the last several weeks at least (can’t be more specific than that, sorry).

I’ve not reset the bulbs yet to see if it (or my LAN communication issues) goes away, but I have tried clearing the app cache as well as reinstalling it.

Let me know if you or the team would like me to perform specific test steps, send in logging data or environment information, etc. I’ll gladly assist.

#6

I believe that that bug is being fixed in the next Android update. It happens sometimes when a firmware update doesn’t fully complete. In those cases it can be fixed by downloading one of the desktop firmware updaters which can resume a broken update and complete it.