Oops, That Didn’t Work

As an experiment, we’ve written a play. It might be viable to perform in an actual theatre, provided there’s a large screen with a projector that a few between-scene montage things can be played on. Failing that, we’ll just have to run with a short film version.

(a Tragedy in Three Acts, based on a true story)

by Tim Serong and Morgan Leigh


Cast of Characters

TIM, cranky software developer
MORGAN, lover of robots and tech promised by golden age science fiction
SUPPORT, various LIFX support people, QA people and possibly Android developers*

* (These are several different people in real life, but it should be easier to perform as one character)



(A desk with a computer on it, web browser open at the LIFX kickstarter project page. MORGAN is watching the project video)

MORGAN (calls out): Check this out, these lights look really cool. They work with Android. Shall we back this?

TIM (enters from left): Oh, nice. Hey, I know at least one of the engineers behind this thing, yeah, let’s do it.

(Montage showing backing the project, time lapse of project getting to $1,314,542 of $100,000 goal, delivery truck eventually arrives with two LIFX Original bulbs)


(Early 2014, in kitchen, two LIFX Original bulbs being unboxed on bench, two lamps nearby, TIM and MORGAN present with Android phones. TIM and MORGAN each plug a bulb into a fitting, start fiddling around with the LIFX Android app to get the bulbs connected to internal WiFi network. Eventually this succeeds, but then bulbs repeatedly turn themselves off after a few seconds.)

MORGAN: What the fuck?

TIM: No idea. Presumably this should just work, right?

MORGAN: I’ll contact support.

(Flash to MORGAN’s email)

MORGAN: These bulbs are completely unusable.

SUPPORT: This is an issue to do with the Android application. We’ve brought on a full-time developer to rebuild the app from the ground up and hope to have this available soon, but in the meantime do you have an iOS device you can use instead?

MORGAN: No, I don’t. I funded this project because you said there’d be an Android app from the get go. Why didn’t you hire a full time Android developer from the start? I’m not just being difficult here, it’s a serious question. Were you all like, “Hey we can write iOS apps so how hard can it be to write an Android one? We can do that in ten minutes at the end.” Rather than making obvious statements, and asking if I have an iOS device I can use, like you can’t imagine anyone wouldn’t have one, how about some kind of commitment for a delivery date to make the product do what it was advertised it would do at the start? “soon” doesn’t really cut it. I expected better from you guys than the kind of bland, empty crap replies that don’t actually say anything that soulless corporations send.

(TIM and MORGAN re-box LIFX bulbs and put them in a cupboard. Two weeks pass)

MORGAN (to SUPPORT): Thanks for ignoring my reply.

(Two more weeks pass)

SUPPORT:  I’m truly sorry for the delay. An update will be out soon. We appreciate your patience and can’t wait for you to be enjoying the LIFX bulbs the way you want to.


(In Kitchen again, as at start of SCENE 2, but now Android app update has been released. TIM and MORGAN re-unbox bulbs, each plug one into a fitting, and start fiddling around with the new, actually functional Android app.)

TIM: Cool!

MORGAN: Yeah! Let’s use one in the dining room lamp and one in the lounge.

TIM: Sounds good.

(Montage showing lights turning on and off at various times, changing colour, dimming at night, brightening when someone reads a book in the chair under one, and general scenes of well lit life.)



(Early 2016, at desk with computer, MORGAN sees special deal on new LIFX Color 1000 bulbs, decides to buy two, one in particular to replace the conventional bulb in TIM’s mysteriously broken “always on when plugged in” desk lamp. Android app has been updated again, possibly several times over the past two years. TIM is away so MORGAN unboxes new LIFX Color 1000 bulbs when they arrive and attempts to use Android app to connect them to internal WiFi network.)

MORGAN (tapping at LIFX Android app): OK, add bulb, wait, what do you mean “Oops, that didn’t work”?

(Flash to Android phone screen showing “Oops, that didn’t work: Let’s try that again. If this keeps happening, try switching your light off and then on and waiting a minute before continuing.”)

(MORGAN turns bulbs on and off several times, retries app to no avail.)

MORGAN: What the fuck?

(MORGAN re-boxes new LIFX bulbs and puts them in a cupboard)


(Entrance to house, TIM returning home)

MORGAN: Hey, I got new LIFX bulbs but they won’t onboard. Can you see if you can figure out what’s going on?

TIM: Sure.

(TIM and MORGAN re-unbox new LIFX bulbs, plug them in, TIM starts fiddling with new LIFX Android app, flash to Android phone screen showing same “Oops, that didn’t work” message.)

TIM: I’ll contact support.


(TIM’s computer, web browser pointing at LIFX support site)

TIM: I’m trying to connect new LIFX Color 1000 bulbs to my network. I have Android 4.4.4 on a Samsung Galaxy S3 4G, but I get a dialog that says “Oops, that didn’t work”. I’ve tried power cycling, fiddling with WiFi settings (some reddit thread said to turn off “avoid poor connections”, but my version of Android doesn’t have that option), and nothing works. Onboarding also fails with a Samsung Galaxy Note 3 in the same way.

SUPPORT: Please try updating the bulb’s firmware.

TIM: Done. That didn’t help though. What’s next?

TIM: It’s been a week now…

SUPPORT: Do you have access to an iOS device you can try instead? Also, please check your WiFi router, and make sure it too has up-to date firmware.

TIM (wondering why the WiFi router settings are relevant as he can’t even get to the point where he tells the bulb about his local WiFi AP): I don’t know when my friend with an iPhone will next be over. I’ve verified my WiFi AP is configured correctly.

SUPPORT: We’ll do an RMA and send you a LIFX Original bulb to see if that can be set up.

TIM: Don’t bother, I’ve got two LIFX Original bulbs here already. I just factory reset one of them, and tried to onboard it again with the Android app. This LIFX Original bulb which was onboarded successfully with a previous version of the Android app now also fails to onboard with the same “Oops, that didn’t work” message as I get with the new bulbs. This tells me the Android app (version 3.3.3) is broken.

SUPPORT: Can you try the new beta of the Android app (version 3.3.4).

TIM: That doesn’t work either.

SUPPORT: Make sure location services are enabled during onboarding.

TIM: What? OK, fine. But that also didn’t help. My friend came over with an iPhone and we got the bulbs onboard, so this is totally an Android problem of some description.

SUPPORT: We’re getting a Galaxy S3 to test with so we can try to replicate the issue. Meanwhile can you send us some diagnostics from your phone? Also, if you have a Windows 10 device, you can use that for onboarding.

TIM: I do not have access to a Windows 10 system. I have attached the diagnostic info.



(TIM’s desk, some time in the afternoon. Hundreds of browser tabs open, pointed at things like the LIFX Developer Zone, an unsupported LIFX Ruby Gem, some wildly unofficial protocol docs. Various terminals open showing hacks to the Ruby Gem to make it not ignore virgin bulbs, and allow sending an onboarding packet via UDP)

TIM (factory resets LIFX Original bulb, runs hacked up lifx-gem to onboard): Shit, I think it worked.

TIM (calling out): Hey, I managed to hack up the lifx-gem so it could onboard LIFX Original bulbs, by shoving a SetAccessPoint packet at it via UDP broadcast.

MORGAN (entering): Cool. What about the Color 1000 bulbs?

TIM: Nope, doesn’t work for those, and I’ve no idea why. LIFX have apparently deliberately not documented the onboarding part of the protocol, so I’m shooting in the dark here. If I can figure this out though, it’ll mean we’ll actually be able to buy more bulbs in future then onboard them without having to worry about whether or not the Android app will ever be fixed.

MORGAN: Make it so.

TIM: I need to do a network trace while onboarding with an iPhone to see if I can figure out what I’m missing.


(TIM’s desk, a few weeks later. Desktop monitors showing protocol docs and various bits of code. Laptop off to one side running Wireshark to capture WiFi traffic, TIM fiddling with friend’s iPhone.)

TIM: OK, I’ve got a capture of onboarding an Original bulb, and a Color 1000. I screwed up the first time and only got the broadcast and multicast traffic. Turns out I needed to enable monitor mode, but I’ve done that now and hopefully have what I need.

MORGAN: Go you. I’m tired though, so I’m going to go lie down and watch a movie or something. Good luck.

(Montage of network traces, queries for TCP and UDP traffic on port 56700, some recognised UDP packets and some TCP packets the unofficial LIFX Wireshark packet dissector couldn’t cope with)

TIM (to self): Wait… 0x0316. That’s not a LIFX packet length, that’s way too long. What else is here… "VIC1.0 Cremorne1.0 LIFX1.0 lifx.co"… Hang on, is that an SSL certificate? Shit. Can it really be this easy? What about `openssl s_client -connect`? Damn, that’s it, got a connection. OK, and if I synthesize an onboarding packet, then cat that into openssl s_client? It works! On a Color 1000 bulb! The only thing you need to do is connect to that port via SSL and shove the right chunk of bits over that connection!

MORGAN (entering bleary eyed at 04:00): What are you doing?

TIM: LIFX onboarding. I fucking did it. Someone said the onboarding process is quite complex, but it’s just one packet over an SSL connection and you’re done.


(TIM’s computer, web browser pointing at LIFX support site on one screen, two months after the original request was opened. Other screen shows TIM’s tiny LIFX onboarding Python script on GitHub)

TIM (to SUPPORT): It’s been another two weeks with no further response. Were you able to reproduce the Android onboarding problem?



I hope the above was entertaining. No doubt it has some shortcomings; it is, after all, my first attempt as a playwright. I should note that the interactions with LIFX support as presented in the play are heavily abridged – various points went round in circles more than once, and I’m slightly confused as to whether or not they have a Galaxy S3 to test with, or are still trying to obtain one. The LIFX support team has always been courteous though, even when Morgan and myself have been obviously frustrated due to the various problems we’ve had.

Here’s the thing: we really like the LIFX bulbs. They’re a great product. They only pull a few watts, and being able to turn them on and off and change the colour and brightness at a touch of our phones is excellent. I even set up a cron job to turn the dining room light on at 16:30 each afternoon and turn it off in the wee hours. It’s really cool.

We really want to be able to buy more LIFX bulbs to replace our other conventional bulbs, but we need to know that we can actually onboard them and thus use them. In case you haven’t guessed, we don’t exactly have faith in the Android app. I’m baffled that LIFX hasn’t released the documentation for the onboarding protocol, when they’ve released everything else. I’ve seen comments like “There are no plans to document the onboarding protocol”, “We don’t currently have an ETA for the release of the onboarding documentation” and “This was something we consciously dropped from the documentation for time reasons. The onboarding process is actually quite complex.”

I suppose there must be more to it than I’ve found looking in from the outside – there’s a handful of messages I didn’t bother to send to the bulb in my little onboarding script, which I know the iPhone app does (“disable factory test mode”, “set bulb label”, “set bulb waveform”). And I have zero interest in using the LIFX Cloud APIs, so maybe there’s more complexity there that I’m not aware of, but seriously, if you’re documenting a protocol, you’re documenting it for software developers. It doesn’t matter if it’s complex, that’s what software developers do. Most probably wouldn’t even care if the protocol documentation was a bad photograph of a state transition diagram on a napkin stained with barbecue sauce. The important thing is that we have some way of using the hardware we bought, with our own code.

I realise that the newer bulbs are compatible with Alljoyn, but that means figuring out how to build another giant framework to work with these bulbs, and in any case doesn’t help for the LIFX Original bulbs. Myself, I’d be far happier with just having protocol docs, or even some shitty sample code which says “don’t try this at home it might void your warranty”. Judging from comments on the developer forum I’m not alone in this.

In my more cynical moments (like, right after reading Bruce Sterling’s The Epic Struggle of the Internet of Things), I wonder if maybe someone at LIFX (probably not one of the engineering staff), declared that the onboarding protocol must not be published, and that all requests for this should be fobbed off. This then forces all LIFX users to create a LIFX Cloud account with the official LIFX app in order to be able to onboard the bulbs. Think about it: that’s a fantastic way of guaranteeing a high quality database of email addresses of people who already have your bulbs that you can direct market to. When I suggested that login to the LIFX Cloud be made optional in the Android app (given that it’s possible to control the bulbs directly over the local WiFi network, and that’s all I want to do), I was told I should instead use a bogus email address, which is frankly absurd.

In my less cynical moments though, I figure the LIFX Cloud tie-in is probably simply the path of least resistance that creates (hopefully) the best experience for most users, and that in not wanting to use a cloud service we don’t ourselves control, Morgan and I don’t fit that mould.

16 thoughts on “Oops, That Didn’t Work

  1. That all must have taken a big chunk of time – living the experience then writing the play. The characters sound true to life!

  2. Thanks for the python script, seems to be an issue with the more recent Android app and the Color 1000 model as I had the same problem. For the record, cloud works perfectly once the bulb is ‘claimed’ by the Android app after sending the wifi onboarding packet using your script.

  3. Hi Tim, great play. Terribly painful story. I hear you.

    I totally agree about the Android onboarding issues. Things should not be this hard. The recent combination of the LIFX Android app + current Android OS releases + some particular Android devices has been a battle for us – we’re constantly doing all we can to fix this. I appreciate your efforts to share your story (and solution) in the meantime. Nice work on onboard.py – I do advise people “don’t try this at home it might void your warranty”, but totally see how this could be useful to those that know what they’re doing.

    We’re recruiting engineers, let me know if you’re interested in joining us to help officially: http://www.lifx.com/pages/careers

    The vast majority of our customers do enjoy the extra connectivity+features that logging on to the cloud gives, such as Scenes and Schedules shared across multiple devices, HTTP API, control even when your mobile device has dropped off Wi-Fi but still has cellular coverage, integration with Amazon Echo, Nest, SmartThings etc. so that’s the use-case we’ve optimised for by defaulting to cloud connection. But we can’t suit everyone (not immediately, anyway!) so I’m sorry the cloud model doesn’t suit you and Morgan. I’ve taken note and chalked it up as another request for a LAN-only option, we’re driven by customer feedback and where we can we act on it.

    I’d be happy to talk more about the more complex reasons (relating to security, partnerships and the IP-protection needed to keep a young, growing, disruptive, independent hardware company viable for our customers/stakeholders in the long run) that we have not officially published our onboarding protocol yet. I have contacted you on LinkedIn if you’re interested.

    Thanks for taking the time (rather entertainingly too!) to make the world a better place.

    John Cameron
    Vice President, LIFX

    • Thanks for your reply John.

      I had a warm glow for your company when I backed your kickstarter. I don’t have it any more. Customers with that warm glow are worth more than anything any lawyer will tell you to do.

      Don’t get me wrong, I love the bulbs. I love them so much I want them to work.

      I understand that sometimes one is bound by deals that have been done. But sometimes it is better to not make those deals.

      Yes, there are a lot of devices running a lot of Androids. But you knew this when you started, so allocating more resources to Android development from the start than to iOS would have ameliorated that. I’m guessing that isn’t what happened…

      Security by obfuscation is no security. Someone will hack it. The more eyes you get on it at every stage the more secure it will actually end up being. Also people are more likely to hack things that don’t work in an effort to fix them.

      IP protection is not required for viability in the long run. There is now a plethora of research that shows that the more open you are the more viable you will be, and also what a waste of time ideas like intellectual property are. Trust me, I have a PhD in open. No really. You can find it at http://eprints.utas.edu.au/22422/.

      You don’t need to try to hamper other’s efforts in order to succeed. You need to engage with your customers and create loyalty through having the best product and the best service. This is not done by sending them idiotically cheerful form replies filled with buzzwords as a response to their enquiries. Nothing loses loyalty faster. Well, maybe selling them things that don’t work…

      One way to engage customers is to open your software so other people can write software for your hardware. Don’t be concerned with controlling the way people access your device. They are going to ignore you anyway.

      A classic case of this is the way Linden Lab tried to control which client people used to access Second Life. Residents hated the version 2 client when it came out and persisted in using third party viewers, especially ones that offered features LL didn’t want, like backing up items. The result was that users ignored LL and embraced the third party clients. LL responded by cracking down and as a result lost land to OpenSim at a rapid rate. The lesson is your users are not your enemy. Once you start thinking adversarially about them you are doomed.

      Open your software and people will write awesome software that will make your bulbs do things you didn’t even dream of. And that will sell bulbs.

      • Thanks Morgan. I’ve shared some further thoughts with Tim on LinkedIn.

        I totally accept your points on OSS, in that spirit we’ve managed to navigate the legal requirements to publish our LAN and HTTP protocols openly – that’s a milestone for me. Hopefully we can continue to publish more material along these lines, while protecting our brand and customer security / experience. Completely open-sourcing our apps has not yet been high on our radar though – thanks for adding a voice to this idea, much appreciated.

        Its so sad you’ve lost that warm glow. We’ve had to lose some people along the way as the “IOT” landscape evolved and we’ve become more mainstream, interdependent on our partners and our customer base has grown. Every lost glow is devastating to us – we’re a very dedicated team doing our very best. In hindsight more engineers on Android could have been a great idea, but investing there requires investors, and investors don’t always agree on the direction to drive things (eg. OSS vs closed). I can’t change the past but will do all we can to earn back your glow Morgan – thanks!

  4. Just wanted to leave a message here to say: THANK YOU. The Android’s app on-boarding has been getting worse and worse with the time. I used your Python script, rebooted the bulb and it was done.

    Thanks again!

  5. It is midnight on October 14th, 2016 and the reason I’m on this site is to further understand why I’m looking at 5 bulbs which can not be onboarded.

    It would be easy to ask me if my router is plugged in, have I paid my Internet access bill this month…..but here is the rub, I’ve purchased close to 130 Lifx bulbs (all gen 2). Using the exact identical hardware environment I have had zero issues with say 110 or so bulbs. But there are 20 or so bulbs that have left me crying in the corner from the fetal position.

    I have a bent personality in that I enjoy working through tech issues that have gone bust. I’m good with the whole alpha/beta risk and reward approach.

    But would I recommend these bulbs to anyone requiring a “plug & play” product, absolutely not.

    I can’t imagine how many bulbs have been returned to BestBuy because the consumer tried for 7 full minutes to get the “light bulb” to turn on, but ended up returning the purchase out of frustration.


  6. thanks so much for putting up the onboarding script!

    i only bought the lifx because it looked like i could control it over my local network without getting any sort of cloud account — and was unpleasantly disappointed when i discovered that it doesn’t work out of the box and the activation isn’t part of the published protocol!

    i tried activating via the app (after grugingly giving it my gps location and a set of temporary wifi credentials — wtf, can someone with a copy of lifx’s customer database just drive around and use thousands of people’s wifi networks?!) but it still wouldn’t activate — maybe because my bulb was firewalled off from the internet?

    anyway, with your script, i got it activated and am now running them using the open-source lampshade app.

  7. Hi
    will it work on newly bought A19 bulb without any router?

    Here is what Lifx told me…
    just bought A19 bulb, but..
    I dont have wifi, my phone is my wifi (hotspot). So when i connect to the bulb it wants the credentials of my wifi network. All i need is the wakup feature.
    Question: if i setup temporarily a wifi network with a router and configure as per the instructions, can i then disable/get rid of the wifi and still use the function? Will it keep all the settings and wakeup times inside it’s chip or it relies on the cloud and can’t function without it. I really dont need/want wifi.

    (LIFX Support)
    It relies on the cloud for schedules. Unfortunately this will not work locally.

    • I’ve not tried the A19 bulbs myself, but AIUI all LIFX bulbs have to be connected to a wifi network if you want to control them. If you temporarily set up a wifi network, then later killed that network, you’d then have no way to talk to the bulbs (the network is gone then, right?)

      As to the question of whether wakeup times are maintained by the bulb or require cloud (and thus wifi) access, my guess is the latter.

      • I wan’t to control it with the ad-hoc / peer / decentralized wifi from my phone, without any router

  8. 2 years later and the Android support is still garbage. The bulb is actively not taking DHCP assignments from my mikrotik router. So it’s connected to my wifi numerous times, but it won’t get an IP on the network. If I could just force an IP upon it, I could probably get it to work.

    If the apps would let you pass in manual network settings, that would be a huge help. Instead, LIFX sent me two newer bulbs that we’re still very difficult to connect to the network but I finally got it.

    I’m thoroughly impressed with the info you figured out about the onboarding to the WiFi itself.

  9. Thanks in 2020 🙂 My pretty old android device refused to register using their app (it couldn’t detect the internet for login/registration despite being able to control a virtual bulb running on my desktop). Using your hack got it assigned to my local wifi network where I can play with it. Always nice when someone has done the hard work before you 🙂

  10. Also thanks from the future! Still very relevant and helpful in 2020! Appreciate the write up as well… 😉

Leave a Reply

Your email address will not be published. Required fields are marked *