Tinkering Tuesday – HUEify – Making the custom binary and the demo app work on the JN5168

Today I will describe my progress on the development of my own Hue connected lights. Because other people developing with the JN5168 are not necessarily german speakers I will continue my project (which I call HUEify) in english. There is some discussion going on at the latest post from PeeVeeOne.

As I had some trouble with the build provided by PeeVeeOne (lights not turning off, dimming and red not working properly) I had to go through the proecss of building my own binary. This was planned anyways because I have some other plans on top. This post is all about my troubles getting the demo app and a custom build project to work. This should be seen as an additional detailed description to the information that can be found at PeeVeeOne’s website and github repository. So far it is all his work that I am just setting to work on my device. The general setup of the developing environment BeyondStudio and the demo application is described in this post by PeeVeeOne.

Building the binaries

First of all I had some trouble building the binaries from both the NXP demo and the github project PeeVeeOne supplied. Both were not joining the Hue bridge and were not giving any debug information, though the binary directly downloaded from PeeVeeOne was doing both without any issues.

The build of the NXP Demo Application (JN-AN-1171) is defaulted to create a binary for the JN5169. To change this I changed the default in the Makefile (Common_Light/Build) to 5168:

But that is not enough as the builder is getting the command additionally (mind the configuration in the dropdown at the top of the window) In the project properties you have to change the Build command:

Now the correct binary will be build.

Sometimes I had the binary not correctly rebuild after changes as it didn’t recognize any changes (nothing new to build). Then it helped not to use the normal „Build“ but the „Build selected“ and choosing the options „Clean selected configurations“ and „Build selected configurations“:

Debugging the Demo Application and making it work

To trace the startup and the connection you can leave the USB serial converter (FT232) wired to the chip after flashing the binary. It will send debug information which you can read at your PC. I use the serial monitor from the Arduino IDE (you have to close the monitor before flashing the binary because it will lock the serial connection and you get an access error).

In the default of the demo application and the PeeVeeOne github rep the debugs are not enabled. To do this, just uncomment the options in the Makefile (you don’t need all of them, actually I use only some from the first block, check the source code for the relevant ones):

It will show something like this:

This is the debug output when starting the device with no search for new devices from the Hue bridge. It goes through all channels serching for something to connect to.

With a search from the bridge started instead of

Disc st 0 c 1 sel 255
Pan 6a075d40c856781e Ch 11 RCap 3 PJoin 0 Sfpl 2 ZBVer 2
No more nwks to try

I got the following output from the demo application:

Disc st 0 c 1 sel 0
Pan 6a075d40c856781e Ch 11 RCap 1 PJoin 1 Sfpl 2 ZBVer 2
Try To join 6a075d40c86781e on Ch 11
Try join status 00
Join failed ad
No more nwks to try

So it seems like 6a075d40c856781e is the ID of my bridge. When not searching for devices it recognizes it but is not trying to join. When searching for devices it is trying but it is not successful.

This was all from my office room which is located at the other end of our appartment. Moving closer to the bridge the original binary from PeeVeeOne successfully joined and I get the following output:

Discover on ch 11
disc status 00
Disc st 0 c 1 sel 0
Pan 6a075d40c856781e Ch 11 RCap 2 PJoin 2 Sfpl 2 ZBVer 2
Try To join 6a075d40c856781e on Ch 11
Try join status 00
Joined as Router

I was searching the error message and found the lines in the code that output it:

if (sStackEvent.eType == ZPS_EVENT_NWK_FAILED_TO_JOIN) {
DBG_vPrintf(TRACE_CLASSIC, "Join failed %02x\n", sStackEvent.uEvent.sNwkJoinFailedEvent.u8Status );

Having a closer look at the error message in the output it gave the two letters „ad“ after the „Join failed“. This was actually an error code. In the User Guide of the ZigBee PRO Stack (JN-UG-3101) I was able to find the code (9.2.2 APS Codes):

ZPS_APL_APS_E_SECURITY_FAIL: An APSDE-DATA.request requesting security has resulted in an error during the corresponding security processing.

This made me think of a post at PeeVeeOne’s about Keys. And voila, using the keys in the right places (zpr_light_node.c and app_light_commission_task.c) it successfully joined. Sometimes it’s just careful reading. 

Custom Build from PeeVeeOne

I also applied the debugging to the repository from PeeVeeOne’s github and was moving closer to the bridge so it finally joined my hue bridge. The problems I described in my last post (dimming and the color red not properly working and turning of the light not working) was caused by the inverting of the PWM signal PeeVeeOne was applying. I already had that in mind when turning of the light in the App caused the lights to turn bright. So switching the signal did the trick. In the file DriverBulb_JN516X_RGB.c go to line 57 and modify the value from TRUE to FALSE:

The final outcome can be seen in this youtube video:

Next steps

Until now it was all about the initial setup. But this is where the fun begins. Now I can program the device to my likes and I already have something in mind. I hope to find the time to try it soon. There are some more blog posts about the development, based on PeeVeeOne’s findings, e.g. SevenWatt hacking a SmartPlug from Innr. I am looking forward to see the other projects.

My goal is to use the JN5168 with multiple endpoints configured to act as not only one light to the hue bridge but as several (e.g. to separately control all 4 parts of our nightstands). PeeVeeOne is also working in this direction with controlling 4 dimmable lights with one module. I have some other ideas I first have to check for feasibility and then there will be updates here.

13 thoughts on “Tinkering Tuesday – HUEify – Making the custom binary and the demo app work on the JN5168

  1. Hi Boris,
    So you switched over to English! Easier reading for me at least! (although a make my way through your previous post in german as well).
    Great work. Good and clear explanation!
    I may have said it before, but I worked on improving the join function. I now keep discovering (every 8 seconds) as long as no join has happened. And I found how to enable touchlink. I am still thinking how to publish my code. I actually hope Peeveeone is willing to take a pull request on his repository. I did not ask yet.

    1. Thanks. Until now it is just copying :-)
      To keep discovering is actually a good idea. For the publishing of the code I am quite undecisive yet because I don’t know the legal situation about those keys in the code… but of course it would be great to have everything shared. I am very interested in your solutions as well and very like your blog posts as well.

  2. Hi,

    guess you already figured it out. But since peeveeone hasn’t published his multiple endpoints source yet (afaik):
    App_Light_DimmableLight.c (or the equivalent files for other applications) is the place to set up multiple endpoints.

    Modify eApp_ZLL_RegisterEndpoint to make multiple calls to eZLL_RegisterCommissionEndPoint with LIGHT_DIMMABLELIGHT_COMMISSION_ENDPOINT being the id to be used for the endpoint.

    Reference: , Chapter 7 (ZLL Core Functions), p. 134

    It’ll take some more time to put it all together, but I’ve been working on a carrier board for the JN5168 Eval and a companion board containing 4 FET drivers. Boards are in prototype production right now.

    Future plans include a companion board with PCA9685 (I2C to 16x PWM). This shouldn’t be too hard since the demo code already includes
    #ifdef USE_PCA9634
    #include „SMBus.h“
    #include „PCA9634.h“
    which is quite a similar chip.

    1. Hi Daniel,
      thanks for the hint. I already played with that function call and other places but didn’t get it to be recognized by the Hue bridge yet so I will be waiting for an update from Peter.
      I will be using the Arduino Mega as a PWM extension and also have a companion board to address 4 RGB strips from PWM (see my latest blog post for a pic of the first part put together, I will post the details soon). If you have a better solution I would be really interested in the details. Do you have a blog or some documentation, too?

      1. Hi,

        I don’t blog… but there is a visualization of the driver board:

        Main parts:
        4x STB16NF06LT4 NMOS
        4x LTC1981 (FET drivers)
        as well as some associated R/C/connectors.

        I designed the board to be used with a carrier board for the JN5168 module. The carrier board provives a regulated voltage supply (12V/24V input), Reset switch, Programming switch and breakout of all module pins.

        Still waiting for the boards. Both went into manufacturing on 28Apr2017.

        Using the Arduino as PWM slave is quite a good idea since there is not much to be changed in the original sources except for enabling debug output. Didn’t think of that…

    2. common/app contains the file app.zpscfg.
      This is where a lot of the stack setup (magic) happens (configuration of Clusters and Endpoints). Extending one of the examples with more endpoints starts there. Sadly, the appropriate plugin (ZPS configuration plugin) isn’t much of a help because I didn’t find a way of just copying endpoints to add some more. Actually, there is a „Copy“ option in the context menu. But „Paste“ doesn’t work. Anyone?
      I ended up editing the file manually. Which works great if one is just duplicating endpoints. Building the app led to the endpoints showing up in zps_gen.h:
      /* Endpoints */


      Now, on to code modifications. Which is where the real work starts… Each newly defined endpoint requires setup in eApp_ZLL_RegisterEndpoint. And of course all that, which is associated with it: Context save, Effects,… Not done with that, yet.

  3. Diving into the Application one gets stuck at a certain point regarding the bulb drivers. (At least that was what happened to me because I didn’t have a reference to an actual hardware, forgive me, I’m a hardware guy, somehow.) But there is help available on Google. You might try googling for „nxp DR1192“. „Googling is like thinking, just crazier…“ 😉

  4. Boar endlich eine Lösung, danke! NXP Demo Projekt konnte ich kompilieren und flashen, nur mein JN5168 Module wollte sich nie mit der Hue Bridge verbinden. Den Masterkey hatte ich ja bereits ausgetauscht. Nur auf den Gedanken zu kommen auch mal in der „zpr_light_node.c“ nachzuschauen bin ich nicht gekommen ^^.

    Möchte alle Meine Lichtschalter gegen Doppelwippen-Taster tauschen. Zum Glück gibt es mein Schalterprogramm noch bei Gira (S Color). Einfach den Ausschalter gegen 2 Wippentaster (4-Taster sind es technisch, so wie der Osram Switch) tauschen. 230V zur Lampe brücken und das JN5168 Module mit einer Batterie mit in die Unterputzdose quetschen … mal sehn obs klappt.

    1. Moin. Klingt auf jeden Fall spannend. Ich hoffe du hast Ahnung von dem ganzen Elektrokram. Nicht dass dir das Ding in der Wand verbrutzelt und keine Versicherung zahlt wegen Bastellösung. Da mach ich mir bei meinem Vorhaben schon Sorgen… würde mich über Updates zu deinem Projekt sehr freuen!

      1. Als Schalter ist das kein Problem da, 3V Zelle. Als Lampe schon bisschen gefährlicher da man einen AC-DC Wandler von 230V auf 5V (HLK-PM01) und DC-DC 5V auf 3,3V benötigt. Gibt es zum Glück als eingegossene Fertiglösung. Dann noch ein 230V Relais und eine kleine Vorsicherung. Man sollte schon eine Ausbildung oder Studium abgeschlossen haben. Zum Glück habe ich beides.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *