Create Cheap Philips Hue Compatible Devices

The Philips Hue range is a great way to add wirelessly controllable lighting to your home, but the protocol is proprietary which makes it difficult to add our own custom hardware. [Peter] found a way to create his own Hue compatible devices based on cheap JN5168 modules that are able to connect to the Hue bridge. This means you can roll out your own lamps using cheap RGB or White LEDs, a power supply and the JN5168 Zigbee Light Link module.

He started off by trying to clone a Zigbee Light Link device to a MeshBee — Seeed studio’s open source Zigbee Pro module based on the NXP JN5168. Even though the MeshBee used the same device as a Hue lamp, it would not connect to the Hue bridge. But another clone lamp called Innr that he purchased from the local hardware store did connect quite easily. Using NXP’s open source tools, he was able to download the flash and EEPROM contents from the Innr and copy them to the MeshBee which did the trick.

After the EEPROM transfer trick, he figured out how to modify the two keys used for the ZigBee protocol — one for Home Automation and the other for the Light Link. With this final discovery he is able to take the ZigBee Light Link demo project, edit it using Beyond Studio, and then load the binaries on the MeshBee device so it can connect to the Hue bridge.

All of this work culminates in two custom firmware binaries; one for white dimmable lights and another for RGB dimmable ones. It even runs on these cheap JN5168 breakout kits he found for a few bucks. With all of the software taken care of, and having cheap ZigBee Light Link compatible modules on hand, building low cost Hue compatible lights becomes pretty straight forward.

Thanks [wind-rider] for the tip.

21 thoughts on “Create Cheap Philips Hue Compatible Devices

    1. You have to also consider that all their products are color matched, and the bulbs maintain very high CRI over their full temperature range.

      I originally rolled my own Hue strips with cheap RGBW tape but everything would be slightly different and it looked really awkward.

      I now have gen1 and gen2 bulbs as well as gen2 strips and there is absolutely no variation in color (unless you extend outside the gamut in which case you get truncation on the products which cannot reproduce the desired color).

      1. The bulbs are not RGB, they are RGLime. I have seem some tear-downs, they seem to be using their LUXEON Rebel Color Line line of LEDs. It looks like the 660nm, 450nm and broadband 567nm leds in particular, however I don’t have the kind of money to destroy a $60 light bulb to confirm.
        Their tape I have only seen in the store, but it looks to me like their red and blue continue to use that dark blue 450nm and the dark red 660nm. I am not sure what they use for green, but it looks like they also have a white chip adjacent to the RGB chip rather then a lime. This is actuality even more problematic since different manufacturers can be all over the place on their whites depending on what particular phosphors they are using.
        So you won’t be able to color match these cheap RGB strips because they don’t have that broadband lime, and they typically use something closer to 630nm red and 470nm blue. Maybe there are some out there, but good luck finding accurate photmetics on a $10 ebay strip, never mind any sort of binning.
        I have bought the raw Rebel LEDs, and can get pretty close to matching the bulbs, but doing a system where you set color temperature or CIE coordinates like the hue stuff rather then just levels is a bit beyond me. Also, I think they are doing their color matching by some sort of calibration rather then any binning, this seems to be confirmed by the fact that one of my bulbs has lost it’s calibration and no longer quite matches the other one.

        1. You sound like you know what you’re talking about.

          Suppose you had a decent spectrometer and (whatever the thing is called that measures luminous flux as a function of current) and could characterize the spectrum and gamma of arbitrary sources. Given that data, would you be able to software-compensate a pair of arbitrary $10 eBay strips to match each other decently? Or would the wavelength differences likely be too severe?

          I feel like calibration in software is the step we’re all missing, and it’s because we don’t have the measuring equipment to produce the input data. But prisms and gratings are pretty straightforward, and everyone’s got a camera. Hmm.

          1. The ZigBee Colour Control cluster operates in CIE 1931 colour space. All you have to do is give it the X & Y coordinates for the 3 primary colours used (should be available in the datasheet for any half decent LED manufacturer), and the colour control cluster will take care of the rest.

            I think these values are specified in the zcl_options.h file for the NXP bulb app. Simply find out your R, G & B primary coordinates, change them in the header file and recompile. This should at least get you reasonably close colour representation. Any variations in x,y due to temperature effects will have to be taken care of separately though.

          2. I don’t know. I’d imagine it would be quite complicated across an arbitrary number of colors and wavelengths.
            Some theatrical lighting control consoles do this kind of color matching with some models of common stage lights, but I’m not sure how automated of a process it is. Last I heard there was still some amount of tweaking by eye.
            Even so, the difference in spectrum means color rendering would very likely not match when producing whites. With colors, the color space would either be limited to less saturated colors that both systems could reproduce, or you would have to put up with not matching on more saturated colors. Not quite matching the most saturated colors is probably good enough for most of us in home/hobby use, you’d just have to put up with the fact that some lights would produce some colors or color rendering better then others.

    2. I built a small RESTful physical lightswitch to control my Hues, and when I realized it used REST, I just set up a RasPi as a middleman server.

      Now I have co-operative wifi(esp8266 of course) lights and the Hue’s Zigbee lights operating from the same control panel.

    1. Wink has a local control system, so some of their infrastructure (Zigbee, Z-Wave, Kidde and Lutron) devices would keep working.

      The egg box and AC unit are based on Electric Imp and would probably have died, I know Wink use AWS in the cloud.

  1. What’s the source for “cheap” jn5168 modules? Other chipset ZigBee modules go for $3-4. Alternately you can emulate hue bridge on an esp8266 and do your own esp-now mesh.

    1. Yea. That link is just for a breakout board. the modules themselves are about $15-20 additionally, putting ya at a TCO of about $20-$25 just for the core components.

    1. I bought one of their smart home switches today just to try compatibility with hue, do you have some documentation on how to pair them to a hue bridge (last gen, EU so with LightLink)?

  2. This has even more implications, it’s the first crack in the armor that is the Closed ZHA firmware for zigbee.

    This is a lot bigger that one would expect, this means you can make ZHA compatible devices without a ZHA firmware enabled device or license. ZHA enabled zigbee boards typically run $29.00 due to the license costs.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.