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.

OOPS, THAT DIDN’T WORK
(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)

ACT 1

SCENE 1

(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)

SCENE 2

(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.

SCENE 3

(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.)

ACT 2

SCENE 1

(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)

SCENE 2

(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.

SCENE 3

(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.

ACT 3

SCENE 1

(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.

SCENE 2

(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 172.16.0.1:56700`? 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.

SCENE 3

(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?

THE END

 

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.