Testing

Besides the setup process and features, there are a couple of questions that may be important. First is the total number of devices that can be supported, and second is the range of coverage that's provided. Testing either of these can be a bit tricky, but I did make an effort to find the range limit of the Bridge.

To test the range of the Bridge on its own, I placed the Bridge in a corner of my basement and powered off the two other lights (they were unscrewed so physically they’re no longer present on the network). Then I moved the remaining light to the farthest corner of my house, a second story bedroom. The total distance between the Bridge and the light is approximately [50] feet, and there are two floors and four or five walls between the Bridge and the bulb. Even at that range and with all the material potentially interfering with communication, the Bridge was still able to see the bulb, so if that sort of range propagation holds for communication between the lights, coverage should be fine in most layouts. If you had a gigantic estate with lights spaced out hundreds of feet between them, you might run into problems, but that's a corner case at best; typical homes should be fine.

The second question—the number of total devices supported—is something that we couldn't actually test, as we only had the three bulbs in the Starter Pack and with a cost of around $60 per additional bulb I wasn't about to try to overload the network. (Yeah, sorry—I didn't have a spare $3000 lying around waiting to be invested in Hue lights!) Philips states that the Hue Bridge can support up to 50 bulbs, which should be sufficient for a moderate size house.

What isn't clear is whether or not you can increase the total number of devices by adding additional Bridges to the location. Given the use of the ZigBee controller along with the fact that there is no configuration on a per device level to connect it to the network (e.g. you just buy additional bulbs and they apparently broadcast and communicate with any and all Hue devices), we would assume that 50 lights and a single Bridge is about as far as you'll be able to go within a single area. Conceivably, there could also be problems if your immediate neighbor also picked up a Hue—how would the lights know to talk to your Hue network and not his? This is both the blessing and curse of going with an easy to configure technology.

In the process of testing the range I made some other interesting observations on the behavior of the Hue lighting system. First, I powered off the Hue Bridge (to move it to the basement), and while it was powered off I launched the app. The app did not complain about not being able to connect to the Bridge. Then I touched “All Off” in the app, and again the app shows no error; the app is behaving as if the Hue Bridge is up and alive. However if you go into settings the Bridge has disappeared, and the entry says “Find new bridge”.

In theory it’s of course possible for the Internet to have issues that prevent communication with the Bridge, or for your home network to have problems. Rather than behaving as though nothing is wrong (until you go into the settings and find your Bridge is no longer present), it would make more sense to update the app to let users know that there is a problem communicating with the Bridge. This should be a relatively simple update on the app side.

Similar behavior is exhibited when you disconnect the bulbs from power. The bulbs don’t disappear from the app, and if you send a command to a non-present bulb the app behaves as though nothing is wrong. This may not be a huge problem, but potentially someone could turn off a light switch and thus cause a bulb to power off. While showing a communication error message that needs to be dismissed every time that happens (especially if there are many bulbs on the network) could become quite annoying, a small note at the bottom of the app or a greyed out bulb icon in the app indicating that communication with the bulb failed and to check the power would be easy to implement. Once more this is something that could be fixed with an app update and/or a Hue Bridge software update in the future.

Power Consumption

I used Kill-A-Watt to do some basic power measurements in the “Off” vs. in the “On” state as set by the app for a bulb. When the bulb is on and set to maximum brightness, it consumes about 0.08-0.09 Amps (about 5.4 Watts). In the off state (but still drawing some power so that it can communicate with the network), each bulb draws around 0.01 to 0.02 Amps (about 0.4 Watts). As expected, even when the LEDs are off power draw is not zero. The ZigBee network controller and other circuitry need to remain active in order to listen for communications from the Bridge.

While it might be possible to cut power use in the “off” state further by having the bulbs go into a low-power sleep state and only wake up for a short period of time every second or two, that would only work in a non-mesh network (or perhaps if the bulbs could all stay in perfect sync so that they’re awake at the same time). Given the complications associated with such an approach, keeping the design simple appears to be the best solution, and that’s what Philips has done.

In a worst-case scenario, if you have a fully populated network of 50 Connected Bulbs, each will draw approximately 1W more than a regular light in order to run the communication hardware. Over the course of a year, that will add up to 236kWh of power, or approximately $24 (at around $0.10 per kWh), which is negligible in comparison to the $3000+ in lights that you’ll have spent. For the Starter Pack and three bulbs, you’re looking at around $1 per year, not to mention compared to incandescent lights you’re already cutting power use per light by about 55W, so it should come out as a large net savings (though not compared to running non-connected LED lights everywhere). The minimal power use while “off” should not be a big issue for most people, but the cost of being able to remotely control does come with a small cost (beyond the initial expenditure for the hardware).

ncG1vNJzZmivp6x7orrAp5utnZOde6S7zGiqoaenZIN5fJRop6GhnJ69tHnHrpxmmaWpvK6t056bZqCforJuuMign62hnpx6qLHTrGScp5ykv6fBy2ht