I have a GU10 bulb running 2.1 and sometimes it just stops responding to anything on the network. Both lightsd and the LIFX apps (Android/iOS/cloud) are affected, as anyone else seen that?
I don’t remember having this issue with the firmware 2.0.
I haven’t been able to identify anything that could cause it.
Yes, I see that a lot. I don’t have a GU10, but my White 800 running firmware version 1.5 goes “out to lunch” frequently (can’t be seen by cloud, Android app, or my own program) and has to be reset by turning the light off and on at the switch. I also saw this a lot with my Original running firmware 2.0. I don’t think I’ve seen it as often with my Original running firmware 2.1, but I may have seen it some, too. I don’t remember for sure.
This used to be really problematic up to about last week or something, did you guys changed anything on your cloud api or android/ios apps related to the GU10 bulbs?
This actually still happening :(. No idea why, nothing changed in my setup, @daniel_hall how can you guys help? Does that help if I tell you that the MAC address of the bulb is d0:73:d5:03:54:00? You should be able to find my LIFX cloud account pretty easily.
When it stops responding does it still show in the Wifi stations list?
The best place for this would probably be to email email@example.com and Taber and myself will take a look.
I’m not aware of anything we could have changed on the devices side of the cloud.
I had both cases:
- the case where the bulb becomes unresponsive on the LAN/Cloud API but I can still (ICMP) ping it;
- the case where I can’t even ping the bulb.
I’m gonna watch that, and circle back.
Alright, so it actually happened shorty after this reply but I had to attend to something else.
More interestingly it happened for all my “cloud enabled” bulbs at once. (Half of my bulbs are running outdated versions of the firmwares).
I pulled the IP addresses of the bulbs out of the ARP cache of my router, it’s pretty easy to see which IP maps to which bulb using their MAC addresses.
- bulb d0:73:d5:12:68:97 (Color 1000): ping ok;
- bulb d0:73:d5:10:14:bb (White 800): ping ok;
- bulb d0:73:d5:03:54:00 (Color 650): i can see it’s out of the Wi-Fi in my logs and ping timeouts.
They are all unavailable in the LIFX apps (and lightsd). I had to reboot them.
edit: and it just happened again, this time the Color 650 is up but the Color 1000 and White 800 are down; all three bulbs are reachable with ping. The pre-cloud bulbs are working fine.
I’m still seeing the same issues even with my recent firmware updates. The White 800 and the Color 1000 in particular. You can ping them but nothing else.
I just wanted to say, we are actively looking into this issue. It appears to be quite complex though, so it may take some time before I have any useful information about it.
It’s cool to get it acknowledged already, let me know if there is any way I can help!
I’m not really using the LIFX app, so I can’t see when firmware updates are available, do you guys have a changelog I can watch somewhere?
I am having a similar problem with a generation 1 color bulb with the latest firmware ( 2.1 ). It is seen by the router, I can ping it just fine, and it even responds to commands very quickly when directly addressed. It just doesn’t respond to discovery requests consistently. I suspect that the LIFX iphone app (3.1.1) is hindered by this since it appears and disappears as an “available” bulb. I would say about 90% of the time it’s not available. Even during these “unavailable” times I can turn off/on this same bulb using direct addressing and commands sent from a simple perl script.
@rhubley that sounds like a slightly different issue from the total loss of control of the bulbs I’m experiencing.
By the way, @daniel_hall this is still a very painful issue, what have you guys learned on your side?
Are you able to pull some information? I imagined giving you the mac addresses of my bulbs would help with that.
@rhubley If its not responding to broadcast messages but still responding to all unicast messages then it is a different issue. Broadcasts act differently on a wireless network to unicast messages, so they are often a little bit unreliable. I wrote a post about broadcasts and 802.11 networks recently. Feel free to follow up there if you have any questions.
@lopter Email me at firstname.lastname@example.org (or email@example.com and tell Taber that you’ve been talking to me already) and it’ll create a ZenDesk ticket. I’ll work with you directly to see if we can get more details. I looked up the MAC address you added earlier and it seems your particular Color 650 might be faulty.