In developing applications with the Philips Hue lights, it's become painfully apparent that the "bridge" (the white circular control device that comes in Hue starter kits) is pretty inadequate. Philips has not been very developer-friendly to those of us with more advanced needs than a disco smartphone app.
The woefully inadequate bridge has rate limiting... it does stuff that you may not want it to, in ways that you may not desire... not to mention that you're pretty much stuck with their paltry API and its limited functionality, etc. Basically, it's like being stuck with an old un-rootable Android phone, when you could otherwise breathe new life into it (and have advanced capabilities) by flashing a custom ROM to it (Apple fans: substitute jail-breaking for this analogy).
So, I got to wondering: why couldn't the lights can be controlled without going through the Philips-supplied, Philips-controlled bridge? The bridge is just an IP-to-Zigbee gateway... in other words, it connects two separate networks: your IP network and the lights' wireless Zigbee network.
If there were some other third-party device that would do this -- one which would give you more direct control of the lights, then you could seemingly go completely around Philips' restrictive control, right? If my server could have more "direct" access to the Zigbee network, I think I could do some pretty slick things... right?
Enter, the Digi ConnectPort X2e.
I found this product via a co-worker's suggestion (he's had recent experience with Zigbee devices), and it's basically just a programmable IP-to-Zigbee gateway (probably just an embedded Linux SoC). Hmmmm.... now I just need to figure out how to develop it's Python-compatible programs on a Linux machine (they seem to only offer an IDE running under Windows or Mac).
So it begins, my venture deeper into advanced Philips Hue light development; and, moreover, further opening the door to the M2M world. More hopefully to come...
Showing posts with label Internet of things. Show all posts
Showing posts with label Internet of things. Show all posts
Monday, September 9, 2013
Friday, August 30, 2013
Philips Hue: So Close, yet...
Having developed my company's signal light product (one of our first "internet of things" devices), I had the fortune to play with the Philips Hue lighting system... from as high level as the official mobile app, down to the API, and even as deep as the Zigbee protocol underlying it all.
I actually dived into the project thinking that it would be a lot fun (after all, what's not cool about stuff like sending curl commands to a friggin' light bulb?). But instead, my enthusiasm was eventually dampened by problems like the following:
I found it simply astounding that a massive global company can release and promote such a polished-looking product (they certainly focused intently on packaging), while the underlying code and logic is so incomplete and buggy. The API and associated logic all seemingly borrows from existing off-the-shelf technologies (JSON, UPnP, Linux -I'm nearly certain, etc.); but, frankly, looks like it hasn't had quite the development effort it probably should have been given... it just really seems like it would have been pretty easy to release a more robust API.
I can understand releasing a version 1.0 API for bleeding-edge technology; but these bulbs have been out for over a year now. With their popularity and enthusiast userbase, we should be up to 2.0 at least, by now. At least, if things were open sourced, we'd be making some better progress, I bet. But, Hell, it took twisting Philips' arm by the community to get the API "opened" (read: documented).
Meanwhile, a major crowd-sourced project has completely opened their API and source code, and has a light with superior qualities, all around. Why you no fear obvious competition, Philips?
I actually dived into the project thinking that it would be a lot fun (after all, what's not cool about stuff like sending curl commands to a friggin' light bulb?). But instead, my enthusiasm was eventually dampened by problems like the following:
- An incomplete API
- Just try to delete a light bulb without doing a factory reset
- Pointsymbols, anyone?
- Strange colors
- Non-RGB LEDs with impure colors (but, admittedly, good whites)
- Unable to light just one color of LED at a time
- Haphazard firmware updates
- Updates that break or reset important things (like which bulb is which)
- Minimal changelog documentation, if any
- Different updates for bridge vs. bulbs... can't update bulbs manually nor rely on automatic updates
- An arbitrary bulb addressing scheme that can change on a whim (like w/updates) ~ Philips, please give us access to the bulbs' unique identifier! If nothing else, then this at least! That way, at least when you push a light bulb firmware update to us (without permission or acknowledgement, by the way), it won't matter that bulb #2 is now addressed as #5 or something.
I found it simply astounding that a massive global company can release and promote such a polished-looking product (they certainly focused intently on packaging), while the underlying code and logic is so incomplete and buggy. The API and associated logic all seemingly borrows from existing off-the-shelf technologies (JSON, UPnP, Linux -I'm nearly certain, etc.); but, frankly, looks like it hasn't had quite the development effort it probably should have been given... it just really seems like it would have been pretty easy to release a more robust API.
I can understand releasing a version 1.0 API for bleeding-edge technology; but these bulbs have been out for over a year now. With their popularity and enthusiast userbase, we should be up to 2.0 at least, by now. At least, if things were open sourced, we'd be making some better progress, I bet. But, Hell, it took twisting Philips' arm by the community to get the API "opened" (read: documented).
Meanwhile, a major crowd-sourced project has completely opened their API and source code, and has a light with superior qualities, all around. Why you no fear obvious competition, Philips?
Subscribe to:
Posts (Atom)