It’s been about 2 years since I started this project. Back then I was almost done with remodeling and I wanted to add lights to my ceiling. With the construction of the new, lowered, plasterboard ceiling I already put the wiring in place, so I could easily add the lights later. Since the lowered ceiling only has about 8 cm clearance to the old (concrete) ceiling, the lights needed to be slim, and produce little heat. This meant halogen (gu10) was not an option. After a few bad experiences with cheap, chinese Ebay lights, I found a great deal and bought some 7.5 Watt Philips Smartspots.
Out of convenience I picked up a Klik Aan Klik Uit system, as it was available at the local hardware store. I used a remote to control the leds in groups of three, as Philips supplied them with a driver per set. After about a week this setup started to annoy me, I wanted to be able to dim each light individual and in groups. It didn’t take me long to realise, I wanted to connect them to my Hue system. At this time I started to gather information about how this could be done. After a short while I came across the Innr lights and the rest is history.
The dimmable lights from the previous post where a great success, but it was not enough. Today, there are 15 lights in my ceiling and adding a JN5168 for each one of them would work, but would also break the bank. Also, the cost wouldn’t be far from these commercial ballasts (in fact, if I’d know about them before I started, I would not have started this project at all). For this project to be a success and make it usable for the community I needed the results needed to be more efficient. Luckily I knew (actually it was hoping until a few weeks ago) the project could be way more efficient, while reading up on the Zigbee and Light Link specification, I came across the following paragraph:
“A node may have several applications running on it – for example, a node in an environment monitoring network may be measuring temperature and humidity, each of which is an application. Access to application instances is provided through endpoints, which act as communication ports for the applications. In order to direct a message to the appropriate application instance on a node, the relevant endpoint must be specified. Endpoints are numbered from 1 to 240. Therefore, to communicate with a remote application instance in a ZigBee network, you need to supply the address of the remote node together with the required endpoint number on the node. Endpoint 255 is the broadcast endpoint number – the same data can be sent to all application instances on a node by sending the message to this endpoint number.”
These lines made me realise that if I could get a JN5168 running a single light, connected to my Hue, it would be a matter of time before I could control all my lights with a few controllers. And that time has come. Last week I completed the firmware capable of controlling up to 5 lights and I controlled 3 (for testing) of my ceiling lights through the Hue system. This video shows the 5 light endpoint in action:
Of course my ceiling lights cannot be controlled by the JN5168 directly, for this I was gonna need some other hardware. After some googling I found some great info with the reefing community. This community has some great DIY LED projects, just use google and you will find a ton. I’ve spent hours looking through these projects, mainly because of the beauty of some of the tanks. A little distracted I eventually did find what I was looking for.
Mean Well LDD-H 700
The Mean Well LDD-H driver is a complete driver, just add power and a PWM signal and you are ready to go! Exactly what I need. To use the drivers I needed some sort of board to put them on. As it turns out, the reefing communities DIY projects opened a whole market for commercial and open source products.
Coralux LDD driver board
For the driver board, I picked one from Coralux, as I found some positive reviews (and had some bad Chinese Ebay experiences). The shipment contained everything I needed, including chip sockets for easy removal of the drivers and a 3d printed part to remove the unused pins from the socket. Great!
Everything was easy to solder and I had the board ready in no time. With all the parts in place and the firmware for three endpoints loaded, I connected the PWM and ground to the driver board and temporarily mounted it to the wall.
Temp setup. All parts in place, the black and red wires are connected to the Philips Led’s
Time to put it all to the test. I did some testing with a single light, and that was working fine. The following video was actually the first time I tried to connect multiple lights at the same time.
Wow, this felt like magic. At this time I ran to the living room and played with the lights for a few hours! After that, I made a video with the actual lights. For this one I deleted the lights from the Hue, so they could be rediscovered (hang in there, it takes a while 🙂 ).
This feels like coming home after a long journey.
I’ve created a page dedicated to the new firmware (including downloads) and I will keep it updated. You can find it here.
Now, on to a new project.. I’m thinking reefing 🙂
Hi Peter,
great you made it work. I am also currently fiddeling with the multiple endpoints for RGB lights. Do you update your Github repository for the sources? I’d really appreciate that.
I also want to go beyond the 5 PWMs and my current approach is to simply use the standard debugging on the serial output to connect to an arduino mega which provides 15 PWM outputs to drive 4 (max 5) RGB strips.
I will provide the sketch as soon as I am done.
Boris
I will make the sources available once I get the external PWM and RGB working. I’ve ordered the parts, and have some time this week, so hopefully this shouldn’t take to long.
Are you using a an actual protocol (I2C, SPI), or plain old string parsing?
Currently I am using string parsing from the UART debugging as I didn’t connect the other pins in the first place.
But SPI shouldn’t be hard to do either as far as the documentation goes. This is what you would have to use for the PWM driver board, right?!
Unfortunately I don’t have too much time currently so I don’t make quite the progress as you are. As I am still struggling with the registering of multiple endpoints it would be great to see your solution for the dimmable lights. But if you plan on providing a version for RGB I might just wait for that ;-p
Hi Peter,
just wanted to give you an update on the PWM extension via Arduino Mega. It is definitely working via the UART interface, see http://www.boriswerner.eu/tinkering-tuesday-hueify-jn5168-to-arduino-mega-pwm-extension/
Now the missing piece for my lights is the multiple endpoints. Did you make any progress regarding the RGB version or do you plan on publishing the code for the dimmable lights soon? I would be so thankful to see your solution as I got a bit stuck.
Hi Boris, great post! The RGB’s are comming, I am having an issue which limits me to 4 RGB’s, and of course, I want more 😉 If I find some time this week I will publish the results so far.
Hi Peter,
great project you have there. I am really interested in using your method to control customs lights. I just ordered 2 mesh bees.
Just one thing I’m not sure about.
An Endpoint is an PWM channel right?
So it’s one JN5186 with X Endpoints
Is it possible to build a few JN5186 modules to control separated lamps or is there something like an ID hardcoded in your binary file for the JN5186 that makes this impossible?
Thanks for your help and best regards Philipp
Hi, you are right. An Endpoint is a light your Hue will discover, in the case of monochrome lights each one uses 1 PWM channel. I don’t know if all the PWM outputs are available on the Mesh Bee.
Hi Peter,
I just wanted to say thanks for doing all the hard work for me. I guessed someone out there must have found a way to ‘retro fit’ existing lights into the Hue network.
I’m just about o read through your project again and then proceed to order the bits I need. I’m a bit of an RC nerd, so I don’t think I’ll have too much trouble.
I too have only just come across the Innr bulbs here in the UK and figured if they could do it, I must be able to do it too and your project answered my question, so thanks again.
If I come up with any suggestions I’ll be sure to repay the favour.
Regards, Michael
PS I have just thought of the following. One must be able to use the switched output voltage to run other electronic devices, such as servos etc – I guess anything that runs on a 12v circuit.
If that is the case, then surely it must be possible to get the Hue system to run say a small water pump to water house plants for example, as a type of ‘Mood’ programme – if you get what I mean.
That idea literally just popped into my head, which I am definitely going to investigate. Cheers, Michael
Hi,
ZigBee Light Link might be a bit oversized for controlling non-lighting devices. ZigBee Home Automation could be a better choice for that.
Daniel
Hi Peter,
thank you for sharing your interesting project with everyone and keep up the good work! 🙂
I just started experimenting with a JN5168-000-M01 module and got some good results on a single Endpoint so far.
I want to create a Home Automation Device that acts as Multiple Sensors and I have problems reading attributes from clusters that are not on Endpoint 1.
I saw that you want to publish your source code once you’ve figured out the external PWM. As I don’t need this function I wanted to ask if there’s a chance to get a look at your code or parts of it in the actual state… I can’t find examples of multi Endpoint devices and maybe I could learn a bit from your code 🙂
Greetings from Germany
Martin
I have been pretty busy lately, and there are still some minor issues with the multi RGB version. I will try and find some time in the coming weeks to upload the project to GitHub.
Hello
Tried to rebuild your Git ZLL_DimmableLight example…
Just throws an error with:
c:/NXP/bstudio_nxp/workspace/ZLL_Multi_Endpoint_Dimmable_Light/Light_DimmableLight/Source/zps_gen.c:799:5: error: ‘zps_msgMcpsDcfm’ undeclared here (not in a function)
make: *** [/c/NXP/bstudio_nxp/workspace/ZLL_Multi_Endpoint_Dimmable_Light/Light_DimmableLight/Build/zps_gen.o] Error 1
Any ideas?
cheers
richard
Hi, Are you still able to download all necessary files from nxp page? I logged myself in but when click on particular links getting zip with 0 bytes size
Hi,
Thank you for your work so far. I experimented with these devices as well. For my projects I created a small PCB with 5 PWM outputs. For this, I was able to change your source code and control a white/warm white led strip. It registers as a color temperature light. Very nice.
After that I started with implementing multiple endpoint. I was able to get two endpoints working. But I have issues with controlling them as a group (with the hue app). Then only one turns of in stead of two. I must be doing something wrong. But I am a bit stuck at the moment.
Is it possible if you could share your source code that has more than one endpoint? I don’t mind it is a work in progress version. Just so I can compare it with my own code.
Thanks in advance.
Hi Stefan,
Did you create you own PCB? I would be interested in something like that, care to opensource the design?
As for your issue, I think you need to increase the queue size for incoming messages. Today I pushed the RGB multi endpoint sources to Github, take a look at the App_ZLL_Light_JN516x.oscfgdiag file.
Hi,
The PCB is really simple actually. It is PCB with 5 mosfets with some protection (fuses and TVS diodes). Also a 12 to 3.3V LDO for the module and a header for an FTDI cable. It fits in a small enclosure which can be passed through a hole in the ceiling for spots: http://www.hammondmfg.com/pdf/1551KFL.pdf
I want to make a new PCB with some fixes. If you have some ideas for the redesign, please share them. Maybe I can send you a PCB for testing when I have a new version.
The queue size might be a good idea, I will check tthat tonight. Thanks.
Hi,
I’d be interested in that PCB too… in case you publish the design, please don’t forget to post about it in this thread…
Thanks
How were you able to compile the git sources?
Did you use a specific version of the SDKs as the last one throw the above error…
No, I had to change the oscfgdiag file. There is something missing in there. You can check the demo project from NXP, I have no idea why Peter his version would build. Trying his newest RGB build gives the same error for me.
Hi, I was contacted by someone who had the same issue with the builds from Peter. He downloaded a new version of the demo project (1.16) and SDK which he was able to compile but the sources from Peter gave the above error message as well.
I compared to my version (1.13) and sent him my version of the project and SDK (Build 1470) and he was able to successfully compile. So I guess NXP updated the SDK and something changed.
Peter: can you confirm that you are not working with the newest version and also post the build number you are working with?
I could also provide a download link if you contact me (see my page, Impressum). I am not sure whether a public link would be appreciated by NXP (or are you even able to get the older version there?)
And last but definitely not least: Thanks Peter for publishing your code! I was busy with some other project but will soon continue with mine and hopefully be able to get things working 🙂
I uploaded my file to wetransfer, you could try thist one: https://we.tl/wrp9zXtBvi
Please let me know if this works for you.
Just curious, did you try to implement the ambiance (adjustable color temp with two different white leds) lights?
No plans at the moment.