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:

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

Thursday, August 22, 2013

Firing CSS3 Transition on Page Load Event (in WordPress)

CSS3 has some pretty cool stuff ~ among these are transitions and animations. So, when I was tasked with making the tagline on my company's website "pop" or stand out somehow, CSS3 is the first thing that came to mind.

It was fairly easy, but the one trick I needed to figure out was how to make it all happen when the page is finished loading -- of course, WordPress didn't really make this easy on me... it has a nasty habit of not rendering or interpreting the code that I tell it to. Naturally.

Anyway, here is the tagline...
(forgive the poor quality of the GIF I used to record the browser window)




Here is the HTML event hook, which I added this to my header.php file...
(don't you just love that WordPress syntax BS?)
<script language="JavaScript" type="text/javascript">
// <![CDATA[
window.onload = function(){
  document.getElementById("body").setAttribute("class","loaded"); }
// ]]>
</script>

And add an ID attribute to the body tag, with a value of "body" for the hook above...
(ignore the elipses, I have other stuff in that tag that you don't need to care about)
<body id="body" ...>

Here is the CSS...
(the tagline container is classed "header-right" ~ the only thing you need to care about is the "#body.loaded" selector)
.header-right div {
  color: #ffffff;
  font-size: 1.8em;
  font-weight: normal;
  text-align: right;
  line-height: 1;
  margin-right: 15px;
  font-style: italic;
  text-shadow: 0 0 0 #dd5500;
  /*the following configures our transition effect - 500/200ms are
    delays to give the page time to render before doing transitions*/
  transition: color 2500ms ease-out 500ms, text-shadow 2000ms ease-in 200ms;
}
#body.loaded .header-right div {
  color: #178582;
  text-shadow: 0 0 180px #ff9944;
}

How does it work? Well, basically, you give the body node (which is what onLoad works with) an ID that we can later use to grab it and work with. Then, a JavaScript listens for the onLoad event; and when it fires, that same JavaScript will apply an attribute (class="loaded") to the body tag. Then, CSS will naturally go in and apply the transition effect (since the selector for "loaded" now exists in the document).