Custom firmware Hue lights

Update (mar 23, 2017)

Now supporting Multi Endpoint Lights (RGB is coming). I put all the relevant info on this page, and I will keep it updated.

Update (dec 3, 2016)

Pushed the sources to GitHub, available here

In my previous posts I described how I was able to connect a Mesh Bee with cloned firmware to a Philips Hue and how the cloned firmware provided me with the key to connecting custom firmware to my Philips Hue. For the past few weeks I have been doing just that, creating custom firmware that connects to a Philips Hue. Using the NXP Light Link demo project as starting point, I managed to created two custom binaries, one for a monochrome dimmable light and one for a dimmable color light. Both binaries use the PWM output of the JN5168 for controlling the levels, which makes them suitable for driving led’s directly or through an external driver.

In this post I describe the hardware, software and process to run the custom binaries (download here) yourself. I will open source the entire project with a future post.


JN5186 module connected to Philips Hue using custom color light firmware, driving an RGB LED


The hardware

Since the Mesh Bee’s do not expose all pins of the JN5168, and I was having some trouble loading firmware (turned out to be a bad UartSBee). I decided to order some JN5168 modules and breakout boards, which also turned out to be a bit cheaper. I ordered the breakouts here , and soldered them according to the guide here. The first board was killed in action after accidentally powering it with 5v instead of 3.3v. To the next board I made two small changes. I changed the header for connecting with the FTDI to be male, this way I can plug the FTDI connector directly to the module without additional wiring. Also, there is a bug in this board, the TX and RX are reversed. Now, this is something I will forget at some point and it will cost me valuable time before I will realise this was indeed the case. So, I modded the board by breaking the TX and RC traces and soldered wires to the correct pins en solve the bug.


JN5168 breakout as received


JN5168 modules as received


Completed board with male FTDI header


Completed board with TX/RX bug corrected

The binaries

UPDATE: I moved all the downloads and connection info to a new page:  ZLL – tl;dr 

I created two binaries, both of them use the JN5168 on board timers to generate PWM signals required to drive the LED’s. The binaries are available in zipped format:


This is zip contains the binary for the monochrome dimmable light. To drive the LED timer_03/PWM3 is used. By default, this timer is activated on DIO13.

PWM : timer_03/PWM3 – DIO13 – PIN 21

Breakout – PIN: 21

Mesh Bee – PIN: D13


This zip contains the color light binary, three timers are used (red, green and blue). At the time I only had a common anode LED available, so I had to invert the PWM signals, which means, this binary only works with a common anode LED, or a driver that requires an inverted signal.

Red : timer_01/PWM1 – DIO11 – PIN 19

Breakout – PIN: 19

Mesh Bee – PIN: D11

Green : timer_02/PWM2 – DIO12 – PIN 20

Breakout – PIN: 20

Mesh Bee – PIN: D12

Blue : timer_03/PWM3 – DIO13 – PIN 21

Breakout – PIN: 21

Mesh Bee – PIN: D13

That’s it, that’s all there is to know about the hardware.

Loading the software

With the hardware in place it is time to load the firmware. For this the JN5168 needs to be in programming mode. To put the JN5168 in programming mode, pin 22, SPIMISO has to be low while booting the device. With the breakout boards this is easy, while holding the program button you reboot the chip by pressing the reset button, after the reset you can release the program button. For the Mesh Bee you can do this by connecting SPIMISO to ground while powering the device.

Download the NXP programmer (here) and the binary you want to load. If you want to create a fresh device, or change the light type, I recommend to erase the eeprom before programming it. This removes the saved device settings such as the network it belongs to. To erase the eeprom execute the command below, where COM3 should represent the port you are using.

JN51xxProgrammer.exe -s COM3 --eraseeeprom=full

After executing the command the eeprom should be erased and you should see a screen similar to the one below.


Eeprom erased successful

With the eeprom clean we can program it with one of the binaries. Again, boot the device in programming mode as described above and execute the command below, where COM3 should represent the port you are using, and binary.bin the binary of your choice.

JN51xxProgrammer.exe -s COM3 -f binary.bin

After executing the eeprom should be programmed and you should see a screen similar to the one below.


Eeprom programmed successful with the RGB binary

Connecting to Hue

At this point the programmed device is a Zigbee Light Link endpoint. To register it with the Philips Hue, you have to start scanning for new lights in the Hue app. After you start the scanning you have to reset the device to be picked up by the Hue. I don’t know yet why this is, but for now this is how it works. A few moments later your device should be recognized and depending on the binary you loaded, You should see a Dimmable – and/or Color light.


The lights are detected.

Thats it, you can now control your custom lights with your Hue! I added some pictures of my setup below. I use the Mesh Bee to drive a cheap LED strip, I simply broke the PWM trace and inserted the signal from the Mesh Bee.

That’s it for now! Please leave a comment.



Mesh Bee running dimmable light, powered off.


Mesh Bee running dimmable light, powered about 30%.


Mesh Bee running dimmable light, full power.


JN5168 running color light, orange


JN5168 running color light, red(ish)


JN5168 running color light, blue


JN5168 running color light, green


Author: Peter


  1. Pingback: Breakout breakthrough |

  2. Pingback: Connecting Mesh Bee to Philips Hue |

  3. Pingback: Cloning a Zigbee Light Link Device to a MeshBee |

  4. Hi Peter,
    thank you very much for your article. It looks very interesting. As the JN5168 breakout board is not available here in Germany, I designed a custom board for the JN5168-001-M00 including an onboard RGB LED for testing and MOSFETs to drive LED stripes etc. I hope that it arrives before christmas and will be working 🙂 I guess you finished testing more or less and as my board will also be more like a prototype, you might not be interested, but if you like, I could give you the PCB files and you could order the board yourself for <20$ for 10 pcs at the chinese manufacturers.
    I am looking forward to read your post about the software. It would be great if you would publish the code 🙂
    Have a nice day, David

    1. Nice to hear about your project, I’m very interested in your results. At the moment I have all the boards I need, but I will keep your offer in mind.
      I hope to find some time next month to publish the entire project to GitHub. Maybe you can add your PCB designs to it? Would be great to offer a complete solution 🙂 Right now I am waiting for some components so I can finally start the project that started all this. More on that in a future post!

      1. Sure, I could do that. But at first I’d like to test it 😉
        The boards and components should arrive next week. Looking forward to see if it works.
        Thank you for uploading the code btw. !

      2. I just tested the board after assembling. Unfortunately the Reset and SPIMISO pins show some strange behavior.
        I am also using a JN5168-001-M00Z board with a program and reset button that pulls pin 22 / 3 to GND (added a 10k pull up to VDD 3.3V). While pressing the buttons, I realized, that the luminosity of the power LED that I added decreased. As I measured the current, I saw that while the button is pressed, the current consumption changed from ~10mA to ~500mA.
        Actually I have no idea why that happens. The datasheet says, that there is an internal 500k pull-up resistor, but there must be something wrong :/

        1. Ah, too bad it doesn’t work. I can’t really be of any help in the electronics area, which is exactly why I order my parts as complete as possible 🙂

          Hope you figure it out though!

  5. Thanks for the guide, I’m just done finishing soldering the first chip to its breakout. I’m stuck without tools though. NXP requires that you go through a download request. I already did that the day before yesterday, how long did it take you to get the flash programmer and SDK in the end?

    1. When I started this project, no registration was required. I did create an account a few months back, but I don’t think it took very long before it was approved. The programmer is available without registration here, there is also a GUI programmer available from the Mesh Bee wiki, here.

      1. Thanks, the device is operational 🙂

        It’s odd however that I still don’t have a reply. The ‘download request’ is actually an ‘Export Compliance Project Inquiry’. After going through live chat support they were able to guide me to a download link that worked.

  6. Hi Peter,
    Thank you for your work! After reading this article I ordered 2 Mesh Bees and an UartSBee v5. I used the Jennic flash programmer (GUI programmer mentioned in a post above) to write your binaries to the Mesh Bees. This works perfectly!
    I finished the NXP registration without any problems and downloaded the required tools. There was no download request necessary.
    The Jennic programmer with UartSBee puts the Mesh Bee automatically in program mode – no need to manually wire the SPIMISO pin.
    There is even a red LED (RSSI) connected to the red output on the UartSBee, so you can easily do a first test. Because the LED is connected to GND it works inverted (on=off, off=on).
    Next step is to write my own binary (try to combine RGB + W) and order some power LEDs and electronics.

    1. Good to hear this project is helpful! Creating an RGBW controller should not be to hard, there is one in the the NXP ZLL-demo which you can use as template.

  7. Hi,
    this is brillant! Do you know of a way to use them not as lights but rather as switch and/or dimmer? So use them as input into the Hue network not as output? Many Thanks!

    1. Thanks. The base NXP project does supply a demo controller solution for this, so I suppose it could be done without to much effort. At the moment I have no intention to do this, but you are welcome to try, I will help where I can!


  8. Hay Peter,

    This is some great work, Thanks!
    Using the binaries you provided everything worked fine with my OSRAM Lightify gateway, so i thought let’s cancel that invert to get the RGB to work…
    long story short, it couldnt get it to work: I can get the program to build, can get the new binary flashed on the JN5168 but the new light doesnt get discovered.

    Any idea what might cause this?

    1. Have you tried the default builds, those should be working (if not, I will look into this). It could be your light is still registered with your hub. Try to delete the light from the Hub, and erase the eeprom before flashing it with a new build. Sometimes, after a lot of testing, you have to reset the Hub completely and start fresh.


      1. I think I’m doing something wrong with the beyondstudio for nxp.

        Your default builds work great, switching between the binaries causes no issues with adding/deleting/recognizing the “lamp” (yes, I erase the eeprom every time i program the chip)
        But using my own binaries the gateway doens’t see any “lamp”, resetting it sadly didn’t help.

        I’m gonna reinstall everything first, make sure everything works 🙂

        1. Did you try to build the default builds yourself? The binaries should come out the same as the ones you can download, so if they work, the problem is with your modification. Otherwise, it’s your environment or the repository.

          1. Progress!

            so i managed to build a working binary through the demo project 🙂 but it’s merely the dimmable light and not a rgbw which i aim to create. :/

            though when using your repository, the builds i create wont work (changing nothing at all). i have no option to debug yet, so it’s still guesswork.

            comparing the binaries to the ones here in the post in texteditor does show a lot of differences.
            so i’ve come further, and have tried to reinstall beyondstudio multiple times but still haven’t found the problem with my environment; though i do think that is the main problem.

  9. Hi,
    after my zigbee try failed, I started to search for an other way to control custom lights (and switches) with my smartphone.
    For me as an Apple user, I found a nice way to achieve that. The solution: A ESP8266 chip in conjunction with “Homebridge”. As I am also running a Synology NAS Server, it was easy for me to get the “Homebridge” server application working, but you could also do that with a Raspberry Pi. There are a lot of plugins to use officially non HomeKit-compatible devices with the Homekit environment of Apple.
    At first try I used this description ( and it worked well, programming the ESP8266 in the Arduino IDE.
    I think the combination of the cheap ESP8266 chips with the Homebridge application with numerous plugins is the way I will try to realize my ideas.
    Have a nice day,

    1. Hi David,

      Sorry to hear your custom boards are not working. I was kind of hoping for them to work 😀
      Your new project sounds like a very different approach, good luck!


  10. Thank you for the post! I am trying to find the production flash programming utility you speak of but can’t seem to access it via the link. Do you know where I can locate it?

      1. I don’t know if NXP recently changed it but it seems like the production programmer requires a sales contact for approval. In terms of the other application, I have been able to upload firmware to the device but I am sadly unable to get it to be recognized by the Hue.

        1. Hi Sean,

          I’ve had no problem registering, no sales rep. required. Make sure you fully erase the flash before loading the binary and reset the device right after the scanning for new lights starts. A full reset of the Hue will sometimes do the trick!

          It is impossible for me to debug your exact situation..

  11. Great work!

    Could you show a bit more of the inner workings of the innr bulb you showed in your earlier thread? You showed how to connect a UART device, but I’m interested in what connections their boards have, and how they are powered? I assume there is an output to the LEDs, and I assume there is a separate transformer board in the bulb?

    Since they are sold here it might be a quick way to get started, instead of going through the ordering process of the JN5168 modules and breakout boards.

    I would like to try connecting the innr board to a relay to switch on/off my non-dimmable 230V LED bulbs.

    Would the firmware for that be difficult to make?

    1. The innr bulbs are pretty much straight from the reference design by NXP (including the transformer). You can find the link on this page (Reference design : JN-RD-6048). This would get you started, I do remember having a hard time getting the Innr board in programming mode, as you have to short pin 22 with ground. Also, I think only the PWM for driving the light would be exposed to the power board, so no full control over all the pins.
      If you have some programming experience it shouldn’t be to hard, you could use the NXP Light Link demo project as starting point.

      If I find some time I will try to add some more pictures.

  12. Hi Peter,
    great work. Thank you very much for that. I am about to order some MeshBees (I am not quite confident in SMD soldering and the breakout boards are not available in germany as David already stated) to control my nightstand lights but I have a question in advance:
    As you copied the firmware from a bulb, is there a way to have more than one MeshBee in parallel or will they have the same identification and thus appear as the same light for the hue bridge?
    I will soon have some posts on my blog, they will be in german though but will definetely have some references to your work!
    I also found a german company which offers something to build custom ZLL compatible devices:
    Perhaps that could be of interest for someone reading this post.
    Best regards,

    1. The firmware for download is not a clone of the Innr bulbs, it is a custom built firmware based on the NXP demo projects. Identification is based on the MAC address of the device, so you can have as many as you like! I’ve seen those ballasts, looks great. Actually I would not have started this project if they would have been available at the time.
      Let me know when you finish your post, I would like read it and see your project!

  13. Pingback: Create Cheap Philips Hue Compatible Devices – #OpIcarus

  14. Hi Peter,
    Discovered this a month back and got myself a few JN5168-001-M00 modulesand soldered some wires to it. My first attempts to join where cumbersome, but now I can reproducibly get them joined. I installed the IDE, SDK and examples, and your example. Modified it and implemented my own P9813 RGB ledstrip driver, and I got the WS2812 driver to work. Nice result.

    I could also quickly make available those two binaries, if there is a demand. Source code would require some cleanup first.

      1. No, I actually did not find such a demo. Is it part of JN-AN-1171?

        For WS2812 I used the Driverbulb_WS2812 from JN-AN-1166, and I had to modifiy the assembly code to get the timing right. The roiginal driver may have been made fro a 8MHz MCU. Now it works on a 16MHz MCU.
        For the P9813, I wrote a new DriverBulb which implements the two-wire protocol.

    1. Hi Seven,
      I would love to be able to see your work even in a rough version. I am grateful to Peter and others such as yourself who keep expanding on what we can do with these JN5168 modules.

      I think this project is a breakthrough in allowing the HUE system to control new devices. I am awaiting the delivery of my own modules and can’t wait to start experimenting with what can be done.

      On another website someone mentioned that Xiaomi’s home automation products use the same JN5168 chip. I wonder if they could be reprogrammed since they are cheaper then buying the JN5168 modules directly.

    1. Wow, you really made an effort! I’ve had a look at your site, looks like you are way deeper into the matter than I am.

      The JN-AN-1171 does provide a demo for RGBW and some other lights and switches, my project is just a stripped down version. The endpoint index is set to 10 because I am experimenting with multiple endpoints on one JN5168 device. The index tells the router where the light is located in the device table. I think I am at 80% with this project, but I haven’t had much time lately. You can follow the progres here

      1. Hi Peter,
        Could you mail me directly? I think we could both benefit from exchanging information directly. You should be able to see my email address from these word press comments.

  15. Hi.
    The JN5168 finally arrived and I have successfully flashed your firmware on it getting discovered by the bridge. As it shows some odd behaviour (I think I have to invert the PWM back) I build a new binary from your rep and also directly from the demo project. Unfortunately it shows the same behavior as for Gillian and Sean. I can successfully build and flash but it didn’t get discovered.
    I can also see debugging information via UART on the serial monitor right on startup of the device with your firmware but nothing from the ones I build. I’ll keep on testing.
    At least it’s great to see those LEDs reacting on Hue 😀
    You can see my progress in my latest blog post:
    Best regards,

    1. Hi Boris,

      Joining can be a big pain. I have spend the last days quite some times trying to improve the join process. I made some progress. One important observation: The chance to join increases greatly with a freshly power-cycled bridge. So try pulling the plug from the bridge. Let it starve from power for 5-10 seconds. Reconnect.
      Then power-off your JN5168.
      In the app start searching for lights and after about one second turn on the JN5168.

      Real soon, I will publish some more findings on my website.


      1. Hi SevenW,
        looking forward to your post.
        But I think my problem may be somewhat earlier as I don’t get any startup output on the serial monitot from the custom builds while from Peters binary I get them immediately.
        Also Peters binary joins immediately. Nothing changed at the bridge or the device other than the firmware flash.
        On the weekend I will continue testing.

        1. In the case your first build that did not log to uart is build from peeveeone’s github directly, then don’t expect logging. It is all disabled. Enable it on the Makefile, starting with removing the comment form line 141 in the makefile.

  16. Pingback: Innr SmartPlug for Philips Hue - part 1 - SevenWatt

  17. Pingback: Innr SmartPlug for Philips Hue - part 2 - SevenWatt

  18. I took this project as starting point and used it to modify the firmware of the Innr SmartPlug, to enable it to serve in my Philips Hue network. This enables using lights that can’t easily be replaced by Hue bulbs. When you are interested take a look here:

    More information, including an application for a string of WS2812 LEDs will follow (soon).

  19. I stumbled upon your project while trying to find a cheap way of integrating my RGB strips to my hue system. But I’m also interested in the things you did and I don’t quite understand everything (but I’m also not familiar with the ZigBee ecosystem). Could you maybe help me to understand this.

    They way I understand it is that your firmware runs as a standalone firmware on a JN5168. I couldn’t find any blobs in your repository so I assume your implementation is the only software on the JN5168 there are not parts from the original Innr firmware running on it, right?

    It seems like access to the official Light Link protocol is restricted and I wasn’t able to find anything related to it. You started with the firmware of a Innr lamp but you don’t actually use this firmware on the JN5168, correct? So what information did you get from the Innr firmware that is used in your own firmware? I know that there are two keys involed but these were leaked anyway if I understand this correctly. And even if these keys were part of the Innr firmware you would still had to reverse engeneer their firmware which you didn’t mention in your blog posts so I guess you didn’t have to do that. But then I don’t really understand what was the point of flashing the Innr firmware on another chip (apart from testing if it stills works I guess).

    So did you actually implement the whole LightLink stack yourself? I tried to find some information about it and it seems like the protocol is quite complicated I wonder if I’m missing something because it really seems like a huge task for a single person without access to proper documentation.

    I skipped over a few comments in other posts. Maybe you have already answered this question. I couldn’t find it though.

    1. You are right in your assumptions. I did not implement the complete Zigbee/Light Link stack myself and I am not using the binary I got from the Innr light. And yes, the keys where already available. The cloning of the Innr lights introduced me to the JN5168, Zigbee, Light Link and all the (free) resources available from NXP. The binaries available on this page are all builds from the NXP Light Link demo project. The multi endpoint lights are also based on this project, although they required a lot more work than just adding the keys. The upcoming RGB versions are even more involved.

      So yes, all parts where available, I just put them together and now I am building on that. I guess, looking back, all answers are easy!

  20. Hey Peter,

    First off, thank you so much for posting all of this online. I had been looking to do something like this, but had a struggle getting ZLL software.
    I am enjoying everything so far, but am a little peeved by the 1kHz buzz that the module seems to make due to the PWM and would like to boost that up to at least 20kHz. and am unable to register on NXP’s website, any suggestions on how to get that to work?

  21. Thanks, again for the software,
    I am currently struggling with getting my JN5168 to join my network,
    I am using the build the binary that is provided for the white lights and watching the UART

    Discover on ch 20
    disc status 00
    Disc st 0 c 1 sel 0
    Pan eb82affe6894f13c Ch 20 RCap 1 PJoin 1 Sfpl 2 ZBVer 2
    Try To join eb82affe6894f13c on Ch 20
    Try join status c2
    No more nwks to try

    I keep getting this try to join status C2, does anyone know what that means?

    1. I am assuming this is not all the info from the UART, channel 20 is the last one scanned while trying to connect. It says here all channels have been scanned, and none are accepting connection requests. Please use one of the new binaries (found on this page) and make sure you follow the instructions exactly.

    1. Don’t know if this board exposes the pins required to program it. Also, it’s a JN5196 I haven’t used those, I think they are the same except with more memory. You can set the target device to JN5169 in the build parameters, should work!

      1. the board has twelve pins (in the link there is a photo with the names of those pins) and other six that seems to be a serial connection. there is really no great doc, and I’m not a big expert what I saw is that hue led strip has six pins (that should be RGBW and I suppose 5V and GND) so it should beh connected, the only unknown thing is how to connect to pc to reprogram it, this week I’ll make a few tries

  22. Hey Peter,

    Thanks for your awesome post!

    Do you know if the NXP controlled bulbs can also to be controlled via Homekit? I have one 3rd party bulb that does work with the HUE HUB, but it can not be controlled via Homekit (My HUE is homekit approved). Apparently Philips doesn’t “hand-off” the non-hue bulbs to Homekit.

    1. Home Kit is not supported, it requires an Apple certification. Home Kit is not part of the Zigbee protocol, it is a closed proprietary Apple protocol. Philips certified the Hue system with Apple, and implemented the protocol next to Zigbee, this is why only Hue devices work with home Kit.

  23. Thanks!

    Any idea if you could change the ID in such away, Hue sees the NXP as a ‘true’ Hue bulb (and not a 3rd party bulb)?

Leave a Reply

Your email address will not be published. Required fields are marked *