Success : Building PeeveeOne code for JN5169 in NXP Demo code.

[gerardwr]

Had a problem with flashing the JN5169 binary from https://peeveeone.com/?page_id=252#comment-415.

• The Hue App did not find the Light using the regular “search light” in the Philips Hue App, but it was found OK when I used Touchlink in the iOS App “Hue Light”.
• The Light is visible in the Philips Hue App, but is reported “unreachable” after appr. 1 minute. Resetting the light and the Hue bridge did not resolve this, so the light can not be used :-(

So I tried, and succeeded building the Light_Colorlight from this Git integrated in the latest NXP code.

Did it like this:

• copy the content ( from "Macro Definitions" to the end of file) of https://github.com/peeveeone/ZLL_Lights/blob/master/Common_Light/Source/DriverBulb/DriverBulb_JN516X_RGB.c
• paste the copied lines to the NXP Demo code file ..Common_Light/Source/DriverBulb/DriverBulb_DR1175.c, replacing the code AFTER the defines of teh "Macro Definitions". Resulting file in the attachment below.
• Change the Makefile for the Light_ColorLight example of the NXP demo code, and build the (default) binary for DR1175

I flashed the binary to a general JN5169 board. The light was instantly found using the Hue App, and seems to work fine. Changing the RGB color in the App changes the PWM values of D11/D12/D13 pins of the JN5169 module.

Thx to @peeveeone for sharing the excellent information!

DriverBulb_DR1175.c.txt

[tugstugi]

@gerardwr I am assuming you are using some JN5169 switches/sensors? I have also managed to program Xiaomi sensors as a light bulb which is pretty useless. Have you tried to flash your JN5169 devices as Hue switch/dimmer etc.?

[gerardwr]

@tugstugi My current "development platform" is an Innr RC110 Remote Control unit based on a JN5169 module.

So far I only made builds of the standard NXP Lights code and the PeeVeeOnee Lights.

Did not build the standard NXP controller firmware. I understand that they would NOT connect to the Hue bridge anyway, and that only "real" Philips Hue controllers are recognised by the Hue bridge.

Tried to flash a Xiaomi Door Sensor as bulb too, but unfortunately I ruined the PCB testpoints while soldering connections to it. Would be great if sensors like this could be flashed with Hue-compatible firmware.

I assume you have seen this reverse-engineering of Xiaomi stuff (it's in French, so you may need Google Translate: https://faire-ca-soi-meme.fr/tag/xiaomi/

[SevenW]

@gerardwr congrats. I think you are the first to get the JN5169 custom programmed to work with Hue. So the key was in using code from the latest NXP demo code. The actual code differences are small. Two removed includes. Two new includes and a new define (ADC_FULL_SCALE). I would not expect those changes to make a difference in connecting to the Hue bridge. But obviously it does!

Did you also build the whole thing in the "latest" NXP demo code"?

[gerardwr]

@SevenW Thanks for the “flowers”, you are to “blame” for me having to cope with the JN5169.

Inspired by your blogarticles on using the JN5168 module in the Innr Smartplug I ordered an Innr Remote Control. Surely, it had an JN5169 module inside :-(

Had lots of Arduino experience , but the JN’s are quite a challenge to code for. The PeeVeeOne code and the comments on his blog really helped a lot.

When I notIced that the NXP examples worked OK on the JN5169 i tried to build the PeeVeeOne code, but that resulted in many errors due to the older SDK he used. So, instead, I chose the route to only use his Driverbulb code and use it in the NXP example.

I also tried to build the code from the git of someone42. That was based on the PeeVeeOne code, but changed for the latest NXP SDK and the JN5168. Building for the JN5169 resulting in strange effects when linkng to the Hue bridge. When my JN5168 module arrived, I could build his code without any trouble, and linking to the Hue bridge was instantly. https://github.com/someone42/ZLL_Lights

So it seems that the JN5169 is not an easy upgrade to the JN5168. For now I continue with the code from someone42 and JN5168 and store the JN5169 for “later”.

Not sure if this answers your question about building “the whole thing ............”.

Did you continue working with the JN5168 or did you move on?

[SevenW]

@gerardwr I bought some of those JN5169 Xiaomi things. At that moment nobody was able to join there own code with the bridge so I decided to give priority to other activities such as mastering hand layup of carbon fiber epoxy laminates for my sailing dinghy. As it is fall now, I regained interest in these kind of activities. I will pick it up again one of those winter months.

Would you care to directly mail me? domain sevenwatt.com and a user that will normally works is info.

[tugstugi]

@SevenW I think @gerardwr was working with Innr devices. I was able to use Xiaomi ones. For Xiaomi, you have to execute this code snippets before pairing with Hue:

ZPS_vNwkSaveSecMat(ZPS_pvAplZdoGetNwkHandle());
vRemoveAllGroupsAndScenes();
vResetDataStructures();
vAHI_SwReset();

[gerardwr]

@tugstugi Interesting.

My Innr Remote and the Xiaomi’s are both based on a JN5169, so your code snippet could be usefull for every JN5169. The code of someone42 built for the JN5169 links with the Hue bridge with some difficulty, and when it’s built for JN5168 it links without any trouble. Possible your code snippet could tackle the problems.

Could you explain in what module you use the snippet, and what the code does. I’m rather new to the programming of the JN516x.

[tugstugi]

@gerardwr I am doing this way:

if (sStackEvent.eType == ZPS_EVENT_NWK_FAILED_TO_JOIN) {
  DBG_vPrintf(TRACE_CLASSIC, "NWK_FAILED_TO_JOIN %02x - vTryNwkJoin\n", sStackEvent.uEvent.sNwkJoinFailedEvent.u8Status  );
  ZPS_vNwkSaveSecMat(ZPS_pvAplZdoGetNwkHandle());
  vRemoveAllGroupsAndScenes();
  vResetDataStructures();
  vAHI_SwReset();
  //vTryNwkJoin();
}

It is programmatically doing a factory reset. After that pairing should be no problem.

[gerardwr]

@tugstugi

From the NXP doc :

vAHI_SwReset(); This function generates an internal reset which completely re-starts the system through the full reset sequence.This reset has the same effect as pulling the external RESETN line low and is likely to result in the loss of the contents of on-chip RAM.

So the JN516x is reset when pairing fails, instead of trying to pair once and then stop pairing. Nice!

Thanks, will try that to see if it solves the pairing hickups I see when building the someone42 code for JN5169. Note that the JN5168 with the same code pairs immediately.

[gerardwr]

@tugstugi I replace the original code in zpr_light_node.c by your snippet (see pic below).

In the Trace I see that the JN5169 continuously resets every second or so while pairing, but no sign in the Trace that pairing is started. With the original code the JN pairs with the Hue bridge but within 1 minute turn "unreachable". So my change to the code is no success :-(

I think I selected the right spot for your snippet, correct?

[tugstugi]

@gerardwr the place should be correct. I had another change around the line 241:

            u8Status = ZPS_eAplZdoJoinNetwork( &psNwkDescTbl[u8NwkIdx] );
            DBG_vPrintf(TRACE_CLASSIC, "Try join status %02x\n", u8Status);
            if (u8Status == 0) {
                u8NwkIdx++;
                return;
            }
            else if (u8Status == 0xc2) {
              DBG_vPrintf(TRUE, "failed factory reset\n");
              vResetDataStructures();
              vAHI_SwReset();
            }

The "ELSE" block is new added code. Could you also add this code and try again?

[gerardwr]

@tugstugi Thx for the hint, but adding the "ELSE" block did not change the behaviour. The Trace output below is repeated appr. every second.

It discovers on ch11. The Hue bridge is on ch20 so it does not pair, and the JN resets. Then this repeats, so ch20 is never scanned, right?

APP: PDM Load ZLL_ROUTER returned 0, RecState=0

Zll recovered state 00
Set Sec state

 eCLD_ScenesCreateScenes: eCLD_ScenesCountScenes() u8SceneCount = 1
 eCLD_ScenesCreateScenes: eCLD_ScenesCountScenes() u8SceneCount = 1Capabilities 000f

Set a Pan 0xcafe

FN start
PDM: Capacity 36
PDM: Occupancy 27

Discover on ch 11
disc status 00
OS started
***********************************************
LIGHT NODE RESET                               
***********************************************
NWK_FAILED_TO_JOIN ea - vTryNwkJoin
Removing all groups from endpoint 3
Removing all groups from endpoint 6
Set Sec state
Removing all groups from endpoint 3
Removing all groups from endpoint 6

APP_vInitialiseNode*
APP: PDM Load ZLL_ROUTER returned 0, RecState=0

[juria90]

@gerardwr I purchased JN516x-EK004 and programmed the binary mentioned here, but no success finding it from Hue. Is there anything else I need to check?

For JN5168, will JN516x-EK001 work without any issue?

[Wessiez]

@gerardwr I have tried your post, but the Hue app did not recognize the JN5169. Do I need to insert a Key somewhere?

[SevenW]

@Wessiez This work is now pretty old and by now all my home made devices have failed for unknown reasons and I moved over to inexpensive third party led controllers as RexTech zigbee 3.0

What I hear is that Hue upgrade software to only accept pairing with zigbee 3.0 devices and the software used here might be 2.0 or no longer compatible in another way.

If this is true then it will take considerable effort to move over to a 3.0 software stack.

[Wessiez]

I'm getting there. I ordered the JN5189 wich is the latest licht bulb chip from NXP.

But I got a JN5169 and would like to connect with Hue. NXP has the JN-AN-1218-Zigbee-3-0-Light-Bulb software. There should be a Preconfigured Link Key what overrules all the other keys. But I cannot make connection with the Hue.

Thats why I'm looking and asking, but most of all: learning