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

      2. Looking at the photo and the datasheet of the 5169 seems that the SPMISO is pin 2 on the chip, which also is PWM4 and the pin 9 on the side of the board, I’ll see if grounding this I could upload the firmware

          1. Looking at the picture at AliExpress I would rather suggest giving the third connection Pin on the side (of the short side) a try. From the french site you can also see a 6-pin connection, using the third Pin for setting program mode:
            1 = TX
            2 = RX
            3 = DO1
            4 = VCC
            5 = RST
            6 = GND
            Whereas DO1 refers to Pin 22 on the datasheet which is also SPIMISO which needs to be connected to GND. Just grab your multimeter and check the connection from the 3rd side pin to Pin 22 (should be the little pad/hole between the three big pad/holes next to the JN5168 according to the pictures).

          2. Ok, a quick post to share a little achievement, I managed to get the chip recognized from the nxp cli programmer.
            I used a FTDI controller connected on the short side
            and PIN1 on the long side to 3.3V
            Launching the programmer it shows:
            Detected JN5169 with MAC address 00:15:8D:00:01:12:3F:26

          3. I tried to erase the eeprom but no success:
            Error erasing EEPROM: Code protection prevents loading extension binary into RAM

            checking config says this:
            JN51xxProgrammer.exe -s COM8 –deviceconfig -V 0
            COM8: Detected JN5169 with MAC address 00:15:8D:00:01:12:3F:26

            So it seems I’m not getting in program mode or I need to do something more

          4. sorry to spam here, but progress continues, I built the firmware image and tried to load it, it says that it could be incompatible with the chip (probably because is compiled for 5168) but at least it loads 🙂
            now I’ll try to recompile for 5169

          5. Last post for tonight
            I think I’ve got the firmware right built and loaded.
            i tried to remove ground to SPMISO and power the board, the programmer won’t see it anymore, but also I cannot see it from hue app.
            To program I’ve powered it on 3.3V is that the working voltage too?

          6. Good work, from what you’ve written this should work. Did you restart it (directly) after you started searching for new lights in the app?

            Maybe I will order a few modules myself, they are pretty cheap compared to the other options.

          7. Hi, did you enable the debugging output before compiling the firmware? Then you could keep your FTDI connected and open up a serial monitor (I use the one from the Arduino IDE) and see what is going on booting the chip.
            Have a look at my post:
            3.3V is the voltage it uses, yes.
            If I am successful I will publish a blog post reprogramming the JN5169 of my Xiaomi Smart Home button soon. Thanks for your updates.

          8. Thanks for the help guys,
            Later I’ll follow Boris advice and try to recompile with debug, but after further readings I think maybe I need to properly place the keys in the code…
            I’ll write later with my findings

          9. Ok, tried to run the debug, it goes on loop repeating something like this:
            APP: PDM Load ZLL_ROUTER returned 1, RecState=0

            Zll recovered state 00
            Set Sec state
            EPCR = 0 : EEAR = 0
            Stack dump:
            (follows long stack dump)

          10. I checked the code a lot of times and don’t know where things go wrong
            I tried also building colorLight from demo code, it compiles, then when you run it says illegal instruction and dumps.
            What could I also check?
            Querying the device I also saw that there is flash protection that prevents reading back the eeprom (CRP_LEVEL1)

            But if I try to change that I get this error back
            Error: one time programmable data has already been set in this device

            maybe it’s not a problem reading back, but I just put this info too.
            Tomorrow I’ll buy the programmer (got a good shipping price) and the NXP JN5168 of Peter, just to see if I flash it correctly
            But I want to make this thing work 😀

          11. No progress so far, don’t really know what more I could check
            The jennicsniffer binary works, my build of zlllights not.
            Boris or Peter, could you try to build the binary for JN5169 for me, just to check if I do something wrong compiling?

          12. Hi Peter, thanks for the binary, but sadly it still doesn’t work, it stack dumps too:

            Stack dump:
            4007e88 : 00000003
            4007e8c : 000a0828
            4007e90 : 0000f424
            4007e94 : 000a1748
            4007e98 : 00000000
            4007e9c : 0400035f
            4007ea0 : 000a0822
            4007ea4 : 00000003
            4007ea8 : 00000000
            4007eac : 04001bde
            4007eb0 : 000a1688
            4007eb4 : 1da6bcdb
            4007eb8 : 000821ad
            4007ebc : 00001000
            4007ec0 : 00000000
            4007ec4 : 040009fc
            4007ec8 : 34694308
            4007ecc : b63f25f7
            4007ed0 : 1e6f4a6b
            4007ed4 : 049b5857
            4007ed8 : 00000000
            4007edc : 000000a9
            4007ee0 : 000000ab
            4007ee4 : 00000000
            4007ee8 : 093b8f44
            4007eec : 0189ff19
            4007ef0 : 019fff56
            4007ef4 : 3476a67b
            4007ef8 : 00000000
            4007efc : 00000000
            4007f00 : 00000000
            4007f04 : 6f049cc3
            4007f08 : 5cf4c384
            4007f0c : e6a1509c
            4007f10 : 0eebbb57
            4007f14 : 973a28d4
            4007f18 : 62278d9d
            4007f1c : 00000000
            4007f20 : 00000000
            4007f24 : 00000000
            4007f28 : 00000000
            4007f2c : b2004240
            4007f30 : 00080500
            4007f34 : 38000004
            4007f38 : 00087d8f
            4007f3c : 000842cd
            4007f40 : 000842a0
            4007f44 : 0008d3db
            4007f48 : 00082b1c
            4007f4c : 0a040203
            4007f50 : 04050607
            4007f54 : 00090a0b
            4007f58 : 0c0d0e0f
            4007f5c : f87d2551
            4007f60 : 00000000
            4007f64 : ffffff5e
            4007f68 : 00000010
            4007f6c : 00047ff4
            4007f70 : 00000be6
            4007f74 : 007c74da
            4007f78 : 974116f2
            4007f7c : 702c3217
            4007f80 : 00000010
            4007f84 : aa4c01ee
            4007f88 : 00000000
            4007f8c : ec1794a1
            4007f90 : 2758399e
            4007f94 : 936cf761
            4007f98 : bdc9bd29
            4007f9c : 00000000
            4007fa0 : 00087df6
            4007fa4 : 7cbfd068
            4007fa8 : 341a0d09
            4007fac : 00000001
            4007fb0 : 04007f4c
            4007fb4 : 00000001
            4007fb8 : 00000024
            4007fbc : 0000021c
            4007fc0 : 040002a0
            4007fc4 : 00000001
            4007fc8 : 000a06e3
            4007fcc : 87f29ad8
            4007fd0 : 00087d8f
            4007fd4 : 000842cd
            4007fd8 : 000842a0
            4007fdc : 0008d3db
            4007fe0 : 00082b1c
            4007fe4 : 00000003
            4007fe8 : 00001ae8
            4007fec : 00000000
            4007ff0 : 00000000
            4007ff4 : 000a04d0
            4007ff8 : 76543210
            4007ffc : fedcba98
            EPCR = 0 : EEAR = 0

            maybe there is some more difference between JN5168 an 5169 programming

          13. Hmm, I don’t know what’s going on here. Just ordered a module myself, hope to get them to work. If so, they are great value for money!

            To be continued…

          14. Yeah they are at a very good price, I only we can get them to work 😀
            If I make some progress I’ll write here

          15. As I am still excitedly waiting for the Multiple RGB endpoints (don’t want to bother you Peter but it would be really really great!) I finally had some time to disassemble the SmartHome buttons from Xiaomi with the JN5169 and at least successfully flashed a new binary to it giving serial debug output. I tried the On/Off Controller but as expected it is not working “out of the box” but it is doing something. Will try with the light binary soon and try to figure out how to use it as a controller.

          16. A short update from my side. I also flashed the JN5169 binary provided by Peter on my Xiaomi SmartHome button but it didn’t join either (no stack dump here). Unfortunately the debug output on that build doesn’t provide much information.
            I build a new one from the demo application with all debugs enabled and the keys in place as I did with the JN5168 but I am getting the same output I had when not correctly putting the keys in place the first time with the JN5168 (see my post

            Try To join 6a075d40c86781e on Ch 11
            Try join status 00
            Join failed ad

            I already researched the error code “ad”:
            ZPS_APL_APS_E_SECURITY_FAIL: An APSDE-DATA.request requesting security has resulted in an error during the corresponding security processing.
            Which definitely hints to a key problem.
            So the general function is there and it even tries to connect to the bridge but get’s a bad response. That can’t be everything here 😉
            I will go the other route and try to make it join as a controller. Didn’t anyone else go into that direction?
            If there is any news on your ends regarding both topics, I am more than happy to hear about!

          17. Hi Boris,
            No big news, I made no big progress, the last big one was flashing the JennicSniffer (which unfortunately seems distributed binary only) and running it without problems.
            Any other code, even jennic sdk light demos give me the stack dump.
            I ordered some more xiaomi sensors, I’ll try to hack one of them when arrives.
            In the meantime, @boris if the chip is the same there must be something wired differently if on the xiaomi one it doesn’t stack dump.
            You used the switch which is indeed a controller, not an end point (just thinking)
            I’ll try to follow your idea and build a controller firmware from the sdk to see if anything changes

  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.

    2. homekit support is device dependent, so the single bulb must support (with a chip), in order to user unsupported bulbs with homekit see my comment below about homebridge

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

      1. Or you can install homebridge on a linux machine (maybe a raspberry) and use the homebridge-hue plugin to use different brand bulbs with siri

  24. Hi,

    Great project first of all. I have some trouble with getting my own-built examples to get recognized by the Hue bridge though:-( (custom firmware from this site works OK on the same HW, but has inverted PWM signals).
    As you can see from the logging below, it does manage to join, but the Hue app says “no new lights found”. I’m using a MeshBee, Hue bridge SW is 01039019.

    Is there any make flag that I need to switch on? I used the github repository, and tried both initial commit and latest status; but I don’t get the same binary as posted on this site.

    Pan 4e589278dddxx834 Ch 20 RCap 3 PJoin 3 Sfpl 2 ZBVer 2
    Try To join 4e589278dddxx834 on Ch 20
    Try join status 00
    Joined as Router
    JP Time 10
    JP Time 9
    JP Time 8
    JP Time 7
    JP Time 6
    JP Time 5
    JP Time 4
    JP Time 3
    JP Time 2
    JP Time 1
    JP Time 0
    R 255 G 227 B 139 L 254 Hue 0 Sat 0


    1. Hi Mischa.
      I had some issues getting it to work, too. See my post

      From what can be seen in the debug it should work indeed.
      Did you remove the light before rejoining with the new firmware?
      If you don’t erase the eeeprom before flashing the new firmware it keeps the connection information. So I would try the following:
      1) check whether the light is still available in the app (I know, obvious but sometimes… 😉 if it is not, perhaps the bridge knows that it has deleted the light, then:
      2) erase the eeeprom of the MeshBee and then flash your custom binary again. If this doesn’t help:
      3) I read the recommendation to reset the whole bridge on connection issues when the light can’t be found or the light is not properly deleted… but I don’t think it will be necessary.
      You could also try to enable more debugging to see whether there is something else going on.
      Hope this helps

      1. Hi Boris,

        thanks for your advice. Just to report back, I finally got it to work after the following steps (not sure if all of those were necessary, but resetting the bridge was…):
        a) moving close to the bridge
        b) erase EEPROM (together with flashing firmware)
        c) let Hue app search for lights
        d) press reset on MeshBee
        e) wait for it to join the network (2 secs or so)
        – light doesn’t show up yet in Hue app, it just prints a message on the debug console that join was successful.
        f) reset Hue bridge, through power cycling by physically removing adapter plug
        g) you will see after some 30 secs some debug messages on the console (Data Ind: Profile :0 Cluster :13 EP:0), of course depending on which msgs are enabled in Makefile
        h) Search for hue lights again
        i) Reset MeshBee again
        j) Light is found

        Thanks for your support!


Leave a Reply

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