Working_Prototype

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

***********************************************
LIGHT NODE RESET
***********************************************
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:

***********************************************
LIGHT NODE RESET
***********************************************
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 );
vTryNwkJoin();
}

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.