Staircase project, part 2: Raspberry Pi and i2c

After rediscovering the Dimmer Plug  a few days ago, the time had come to see if I could use the Dimmer Plug directly from a Raspberry Pi.

Before I could connect the Dimmer Plug to the Raspberry Pi, I had to enable i2c on the Raspberry Pi; because out of the box, i2c is disabled (because there’s not much to learn about i2c? ;-))

Here’s a short list of what had to be done:

  • Remove i2c from blacklist

The file /etc/modprobe.d/raspi-blacklist.conf had to be modified so that it looked like this:

#blacklist spi-bcm2708
#blacklist i2c-bcm2708

The ‘#’ turns the 2 lines into comment lines, so that those 2 modules are no longer blacklisted/disabled; I also enabled spi which is not really necessary for this.

  • 2 lines had to be added to /etc/modules:


  • Installing i2c-tools:
sudo apt-get install i2c-tools
  • Sufficient access rights for user pi:
sudo adduser pi i2c && reboot

After the reboot, I had 2 new devices:

pi@rpi3 ~ $ ls -rtl /dev/i2c*
crw-rw---T 1 root i2c 89, 0 Sep 12 21:43 /dev/i2c-0
crw-rw---T 1 root i2c 89, 1 Sep 12 21:43 /dev/i2c-1

And after I connected the Dimmer Plug, a scan of the i2c bus resulted in the following:

pi@rpi3 ~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
pi@rpi3 ~ $

Well that wasn’t too hard… The Dimmer Plug with address 0x40 is being detected, so we’re ready to go… The next thing that had to be done was getting i2c working from Node.JS. Fortunately there’s a Node module for i2c, so that part is already covered. A driver for the PCA9635 IC wasn’t hard either – all I had to do was sending the same bytes to the PCA9635 as the JeeLib driver did.

The things I want to do with the LED strips involves sending certain ‘patterns’ to the LED driver at specific intervals. Will the Raspberry be able to do this in a reliable way? I don’t know yet, cause right now the Raspberry which I’m using to test this LED driver, has (almost) nothing else to do than run a single Node app that uses this LED driver. But what if more drivers are running, all consuming CPU cycles, or what if the OS feels it’s time to do something else for a change, just when the LED strips need to be adjusted in brightness? We’ll see.. maybe not now, but too much delay or other irregularities should be visible right away, so I decided to just wait and see how this turns out in practice.

The PCA9635 driver code is quite small and simple, actually:

 * PCA9635 LED driver I2C library for Node.JS
 * Based on the JeeLib Dimmer Plug driver
 * (

i2c = require('i2c');

var modes = {
        MODE1:0, MODE2:1,
        PWM0:2, PWM1:3, PWM2:4, PWM3:5, PWM4:6, PWM5:7, PWM6:8, PWM7:9,
        PWM8:10, PWM9:11, PWM10:12, PWM11:13, PWM12:14, PWM13:15, PWM14:16, PWM15:17,
        GRPPWM:18, GRPFREQ:19,
        LEDOUT0:20, LEDOUT1:21, LEDOUT2:22, LEDOUT3:23,
        SUBADR1:24, SUBADR2:25, SUBADR3:26, ALLCALLADR:27};

function DimmerPlug(device, address) {
  this.device = device || '/dev/i2c-1';
  this.address = address || 0x40;

DimmerPlug.prototype.initialize = function() {
  this.i2cdev = new i2c(this.address, {device : this.device});
  this.setReg(modes.MODE1, 0x00); // normal
  this.setReg(modes.MODE2, 0x14); // inverted, totem-pole
  this.setReg(modes.GRPPWM, 0xff); // set group dim to max brightness
  this.setMulti(modes.LEDOUT0, [0xff, 0xff, 0xff, 0xff]); // all LEDs group-dimmable

DimmerPlug.prototype.setReg = function (reg, value) {
  this.i2cdev.writeBytes(reg, [value]);

DimmerPlug.prototype.setMulti =  function(reg, values){
  this.i2cdev.writeBytes(reg | 0xe0, values);

module.exports = DimmerPlug;
module.exports.modes = modes;

Now the Node app… I decided to follow the dimmer_demo sketch, cause if I’d get the same results with the RPi as with the JeeNode I knew everthing was OK. And now the code for the Node app becomes  a bit awkward… it’s a demo, constantly changing the brightness of all the LEDs, but there are no real events, so there’s nothing to trigger on.

This app does its job totally isolated from the rest of the world.. and things get even ‘uglier’, cause the JeeLib demo contains a few delay() statements – which (for the obvious reasons) is not available in Node – yes, there’s setTimeout(), but that doesn’t pause execution! This was the first time I had to think about how to do something in Node.. I needed something to control the program flow; normally (in my case) a driver gets its events from either MQTT messages or incoming data from the hardware, but both are not the case here (yet). I decided to use the async module for that and create a series of functions that should be executed after each other. This is how the Node version of the dimmer demo looks like:

var dimmerplug = require('./dimmerplug');
var async = require('async');

var level = 0x1fff;
var dimmer = new dimmerplug();

    function(callback) {
      dimmer.setMulti(dimmerplug.modes.PWM0, [255, 255, 255, 255,
                                        255, 255, 255, 255,
                                        255, 255, 255, 255,
                                        255, 255, 255, 255]);
      // set up for group blinking
      dimmer.setReg(dimmerplug.modes.MODE2, 0x34);
      // blink rate: 0 = very fast, 255 = 10s
      dimmer.setReg(dimmerplug.modes.GRPFREQ, 50);
      // blink duty cycle: 0 = full on, 255 = full off
      dimmer.setReg(dimmerplug.modes.GRPPWM, 100);
      // let the chip do its thing for a while
      setTimeout(function(){callback(null, '1');},10000);
    function(callback) {
      // set up for group dimming
      dimmer.setReg(dimmerplug.modes.MODE2, 0x14);
      // gradually decrease brightness to minimum
      for (i = 100; i < 255; ++i) {
          dimmer.setReg(dimmerplug.modes.GRPPWM, i);
      setTimeout(function(){callback(null, '2');},2000);
    function(callback) {
        brightness = ++level;
        if (level & 0x100){
            brightness = ~ brightness;
        r = level & 0x0200 ? brightness : 0;
        g = level & 0x0400 ? brightness : 0;
        b = level & 0x0800 ? brightness : 0;
        w = level & 0x1000 ? brightness : 0;
        // set all 16 registers in one sweep
        dimmer.setMulti(dimmerplug.modes.PWM0, [w, b, g, r,
                                      w, b, g, r,
                                      w, b, g, r,
                                      w, b, g, r]);

  function(err, response) {

A bit weird, but it works. The Node demo worked just as well like the JeeNode version, so another part of this staircase project is done – the power MOSFETs have already been ordered, so as soon as they arrive I can connect real LED strips the the Dimmer Plug – can’t wait to see the results!

Dimmer Plug connected to Raspberry Pi

Oh, and in the meantime, it might be good to start working on the real renovation job as well.. 😉

Staircase project, part 1: the Dimmer Plug

Renovation is always a good opportunity to think about some nice automation projects, cause renovating almost always means (partly) breaking down some things and then rebuilding it in a somewhat different way. That’s the right time to do some extra – drilling holes, pulling wires, cable ducts and so forth.

So when we decided to renovate our staircase, I immediately had a great plan: mounting LED strips under the steps to light the stairs. Automatically of course, and with some cool gadgets thrown in as well 😉

I also got the idea to use 2 light barriers at both ends of the stairs to detect that someone is walking up or down the stairs and control all the 12 LED strips independently; so if someone goes upstairs, the LED strips increase in brightness with an interval: starting with the lowest LED strip, going up. And if some goes downstairs, the strips go on from top to bottom. Sounds nice..

OK, but how do I control 12 LED strips independently? And not just on/off, but also in brightness. I didn’t like the idea of using 4 RGB LED controllers, so I started searching for a >12 channel LED controller. After some days I finally got the inspiration I needed – a JeeLabs Dimmer Plug! The Dimmer Plug uses a PCA9635 IC to drive and dim up to 16 LEDs independently.. that should do it! The Dimmer Plug uses I2C to communicate with the outside world, so that shouldn’t be a problem either.

Yesterday evening I soldered a JeeNode, finished the Dimmer Plug (headers etc.), connected 4 3mm LEDS to the Dimmer Plug, uploaded the dimmer_demo sketch from the JeeLib library to the JeeNode and I saw all 4 LEDs doing their own ‘thing’ independently; so far so good.

JeeNode + Dimmer Plug

But why should I use a JeeNode to control the Dimmer Plug? I mean, I have a couple of Raspberry Pi‘s running here, I could just as well use a Raspberry Pi (RPi) for the I2C communication, right? That saves me the hassle of talking from a RPi to the JeeNode, which in turn talks to the Dimmer Plug… so I decided to leave the JeeNode out and connect the Dimmer Plug directly to the Raspberry Pi.

Connecting the Dimmer Plug to the Raspberry Pi will be done in the next couple of days…  part 2 of the ‘staircase project‘ !

Wifi LED controller finished

Yesterday I finished the new Wifi LED controller. One day later as expected, because while cutting the last wire to the correct length, I accidentily also cut 2 other wires that were already soldered.. 🙁 Well, if those things happen and it’s already getting late, it’s better to just stop and clean up the mess the next day – so I did.

Putting it all together

While testing all the components together on a breadboard, I decided to use a different 3.3V voltage regulator, cause the original choice led to a very hot regulator which is something I don’t like, so I chose the following components:

  • Conrad MS-35 LED controller, EUR 20,89;
  • TTL to Wifi converter, EUR 21;
  • Hammond enclosure, EUR 6,83;
  • IPEX/SMA antenna adapter, EUR 4,99;
  • 2×5, 2mm pitch female connector, EUR 0,90;
  • Standard Wifi antenna, from an old Wifi access point;
  • 3.3V voltage regulator, EUR 12,64;
  • 12V DC power adapter, found in the garage.

I started with drilling a hole of  Ø 6.5 mm for the antenna adapter and an opening for the LED wires with a fretsaw. The wires for the 12V that would go to the 3.3V regulator were soldered to the connectors for the LED wires at the bottom of the MS35 PCB, like so:


I took a piece of perfboard, cut it to the right size so that it would fit inside the enclosure and screwed the Wifi module to the perfboard with the help of spacers and 2 tiny screws. The voltage regulator was soldered onto the perfboard as well and now all I needed to do is connect all these components with some wires and a resistor.

Wifi module pinsThe pins of the Wifi module that will be used are 3.3V, GND, UART_TXD, UART_RXD and nReload, so a 5×2 2 mm pitch connector will suffice.

The connections are pretty straightforward; the voltage regulator connects to the 12V DC from the MS35 connector and the Wifi module is connected to both the voltage regulator and the MS35.
Voltage regulator

To the right you see the pinout for the R-78B3.3-1.5. This is the first time I’m using this type of voltage regulator and I’m very happy with it actually. There is no temperature increase noticable, it’s small enough to replace a TO-220 sized regulator, it can take a voltage from 4.75-18V and can deliver as much as 1500 mA.

I think I’ll be using this regulator more from now on, even though the price is a lot higher; now I don’t have to wonder how long the cheaper LD33V will stand the heat… it’s worth the higher price.

So, to conclude all the wires needed:

  1. +12V DC to VR (Voltage regulator) Pin 1;
  2. GND to VR pin 2;
  3. Wifi GND to VR pin 2;
  4. Wifi 3.3V to VR pin 3;
  5. Wifi UART_TXD to MS-35 RX;
  6. Wifi UART_RXD to MS-35 TX;
  7. Wifi nReload to VR pin 3.

The nReload pin can be used to reset the Wifi module to factory default settings, which is something I don’t think I’ll ever use. To prevent this from happening, this pin can be kept high with a resistor of 4.7kΩ..10kΩ – at least, that’s how I’ve interpreted the manual.

This concludes all that’s needed to build your own Wifi LED controller. Some standard components, a few wires and you’re done! No wait, the software… For that all you need to do is read a previous post which provides some additional information on the do’s and don’ts regarding communication with the MS-35 and here’s how I do it:

Making contact

When connecting to the LED controller (i.e. opening a TCP/IP connection to it) you’ll have to send the following byte sequence:

oxfd ox00 ox00 ox00 ox00 ox00 ox00 oxcf ox2c

Think of it as a ‘Hi there’ message, to which the MS-35 should respond with:

0x61 0x5f 0x43 0x5f 0x52 0x47 0x42 0x5f 0x31

Yep, part of it is human readable 😉 From now on, the MS-35 accepts commands to set the R-, G- and B-levels.

Setting the RGB levels

Setting the levels is quite easy, the format is as follows:

0x01 0x00 RR GG BB 0x00 0x00 xx xx

where RR is the byte value for the R channel, GG the byte value for the G channel and BB for the B channel. “xx xx” is the CRC16 of all previous 7 bytes.

Here some images of the end result (click to get the original size):

DSC_7939_3 DSC_7938_3 DSC_7937_3 DSC_7936_3

Have fun!

Testing the Wifi LED controller

Today I started building the Wifi LED controller I wrote about 2 days ago. Not all parts have arrived yet, but all the essential ones are already here, so I could start testing. Let’s see if the I can change the brightness of 3 small pieces of warm white LED strips on a piece of cardboard over Wifi.

I mounted the Wifi module and the stripped MS-35 to a breadboard, connected the two with some wires, added a 3.3V voltage regulator for the Wifi module and waited for the Wifi module to come online.

Wifi UART settingsI already tested the Wifi module ‘standalone’ about a week ago and changed all the settings so that the module would operate like I wanted it to with the built-in Webinterface of the Wifi module; the UART on the Wifi module can work in Transparent or Agreement Transmission mode, the module can act as an Access Point (AP mode) or work in so-called STA mode (like a wireless network card), etcetera. I had already configured all those things, so after power-up the Wifi module was online in a matter of seconds:

Reply from Destination host unreachable.
Reply from Destination host unreachable.
Reply from Destination host unreachable.
Reply from bytes=32 time=2744ms TTL=255
Reply from bytes=32 time=1ms TTL=255
Reply from bytes=32 time=1ms TTL=255
Reply from bytes=32 time=4ms TTL=255
Reply from bytes=32 time=1ms TTL=255

Cool, that’s working again; now let’s see if the UART of the Wifi module is able to communicate with the MS-35. So I added 2 additional wires: one from Wifi-UART_TXD to MS35-RX and another one from Wifi-UART_RXD to MS35-TX. I added a 2nd MS35 LED controller to the database of my Domotica system, started a dev-instance of my system and sent 3 random values for R(ed), G(reen) and B(lue) to the newly added MS-35.

Everything worked as expected – the default program that starts when the MS-35 is powered ended and the brightness of all 3 LED strips changed according to the values I sent. Yep, it’s working 😉

It’s my intention to use a single 12V DC adapter for this LED controller, so just like before I wanted to use a linear voltage regulator to power the Wifi module (3.3V). That means that the 3.3V regulator would have to dissipate (12-3.3) * 0.300 = 2.61W; that’s a lot I guess and I was right – the LD33V regulator I used for testing became too hot to touch, even briefly.

For the sake of ‘learning on the job’ I put a L7805CV I had laying around between the 12V and the LD33V; now the power dissipation was spread over 2 regulators – both still became warm, but not as hot as in the previous single-regulator setup. Another approach I tried was using the 7805 (with heatsink) on the MS-35 PCB but that also led to hot regulators – maybe within specs, but I just don’t like those high temperatures.

So I searched for an alternative, remembered Kyle Gordons comment and decided to give this regulator a try – no need for heatsinks it says! So now I’ll have to wait 2-3 days for this regulator to arrive – which gives me some time to spend time on my solar panel project….never a dull moment!

Building a cheap Wifi LED controller

This is a logical follow-up on a previous post about the Conrad MS-35 RGB LED controller. I’m using this controller for 3 warm white LED strips for a few weeks now and it’s working perfectly – everybody is very happy with how it worked out. So it didn’t take long before I got the question if it was possible to install even more LED strips – in the living-room this time. That should be doable, however, the ideal location for the LED controller is in a corner of the living-room where it’s hard to get Ethernet.. ok, lets try something different. I’ve already got 3 Chromoflex controllers connected to Zigbee modules in the kitchen and garage, I’ve got an MS-35 connected to Ethernet in the hallway – lets try Wifi this time! Don’t wanna do mass-production, every piece of hardware is unique over here!

So I’ve started buying the parts I need, which are:

  • Conrad MS-35 LED controller, EUR 20,89;
  • TTL to Wifi converter, EUR 21;
  • Hammond enclosure, EUR 6,83;
  • IPEX/SMA antenna adapter, EUR 4,99;
  • 2×5, 2mm pitch female connector, EUR 0,90;
  • Standard Wifi antenna, from an old Wifi access point;
  • 3.3V voltage regulator, EUR 1,10;
  • 12V power adapter, found in the garage.


Total cost: EUR 55,71 (and some spare time). And this could have been even less than 50 Euro, if Conrad hadn’t suddenly raised the price of the MS-35 with almost 40%! Despite that, a Wifi RGB LED controller for less than 55 Euro…try to beat that if you can! 😉

I decided not to use the antenna that comes with the TTL to Wifi converter, cause it’s a bit hard  to mount; I would probably have to drill a large hole in the enclosure and use a lot of glue to make the construction robust enough, so I decided to buy an additional IPEX/SMA adapter for that. This will give the end result a more “pro” look. The 2mm pitch connector isn’t essential either, but this connector will fit on the headers of the TTL to Wifi converter (I think) so that I don’t have to solder any wires directly onto the converter PCB headers – I don’t like doing that, a connector just looks and feels better.

And the enclosure I chose has nice ‘ribs’ on the inside so I can put a piece of perfboard between those ribs and solder the voltage regulator on the perfboard and mount the Wifi module to it.

Ok, I think I’ve got all things covered; I ordered the parts I didn’t have yet and they will be here real soon. Let’s see how this LED controller turns out!

Conrad MS-35 LED controller revisited

This post is a follow-up on a previous post where I had a look at a very cheap RGB LED controller. I have 10 meters of white LED strip just waiting to be used, so after finding out what to send to this LED controller, I searched for a way to connect it to my system. This time I took the easy road. The plans are to use 3 LED strips in the hallway: one above the door, one where the coat rack is and one above the door to the living room. And 3 is also the number of LED strips you can control with one MS-35. So the best location for this controller was easy – in the hallway, under the stairs, where we have a small space of 0,75 m² with heating pipes and a lot of domotica hardware -stuff like a RFXCOM receiver, Opentherm Gateway, Plugwise stick, ELV MAX Cube already found a place there.

I’ve also got an Ethernet switch nearby, so I didn’t have to think very long – this first MS-35 will be Ethernet-enabled by connecting the 5V TTL of the MS-35 to a EZL-70 I bought some time ago but which didn’t have a purpose yet. So I tried to get the MS-35 working with the EZL-70. I started on a breadboard.

From left to right: blue patch cable, EZL-70, MS-35, 3 white LED strips.

EZL-70 and MS-35Finding out what the 4 pins for the programmer cable were for was not that hard – the manual for the programmer cable contains an image that shows what is RX, TX, GND and 5V. So the 4 wires between EZL and MS-35 were connected within a minute.

So how to connect the EZL-70 to the MS-35?

EZL-70 settings

These are the settings for the EZL-70 TTL to Ethernet converter. Not much to talk about, actually..

JP13 on the EZL-70 was set to TTL mode. JP17 on the EZL-70 is the TTL port, so I soldered a bunch of headers there; the EZL-70 manual shows which pin is what, so no surprises there either. For the record: you’ll need pins 1..4; pin 1=+5V, pin 2(RXD) and pin 3(TXD) go to the MS-35 and pin 4 to GND.

With the MS-35 in front of you like in the picture above, the wiring is as follows:

  • top left goes to EZL-70.TXD;
  • top right goes to EZL-70.RXD;
  • bottom left goes to +5V;
  • bottom right goes to GND.

Now the software side, the ‘protocol’; this took a bit longer.

At startup, the “RGB Controller MS-35” software that’s on the Mini-CD sends a lot of bytes to the MS-35; about 10 times 0xfd, some zeroes (0x00) and a checksum. The way the first couple of 0xfd’s were sent, the Rx buffer being purged by the software and another sequence of bytes being sent including a valid CRC, made me think the first single-byte transmissions of 0xfd were not necessary and I was right. Then why are those first 0xfd’s being sent? Keine Ahnung… it works without those too.

After I sent ‘0xfd 0x00 0x00 0x00 0x00 0x00 0x00’ (and the CRC-16 of those bytes) to the MS-35, it responded with an ‘a’, immediately followed by (as in: in the same TCP/IP frame)  ‘_C_RGB_1’. The ‘a’ is also used as an ACK as I discovered earlier, so the second part must be some sort of identification for what you’re talking to – an RGB controller 😉

After that, setting the color and brightness (or, with white strips, the brightness of those 3) is very easy. Just send 0x01 0x00, the 3 values for R, G and B and 0x00 0x00. So for red in full brightness this would be: 0x01 0x00 0xff 0x00 0x00 0x00 0x00 (and the CRC-16 of course). That’s it!

One nasty habit of the MS-35 is that when you send it something it doesn’t understand, the whole thing just stops working – you won’t get an ACK (‘a’) but an ‘e’ (0x65) instead and it’s game over – nothing seemed to help to get communication going again, everything gets an ‘e’ reply and nothing happens with the LED strips; the only thing that helped to get on speaking terms with the MS-35 again, was power-cycling it. Very annoying when you’re trying to find out how to communicate with it…. Maybe those first 0xfd’s do something ‘special’? A software reset perhaps? I don’t know and I didn’t bother to find out; just make sure your own software is OK and you’ll never get an ‘e’, right?

I wrote a small test that changes the brightness of the 3 white LED strips I’ve got attached to this LED controller and it has been running fine for an hour or so:

while true do

Nice… now it’s time to find a nice enclosure and put 3 white LED strips in the hallway…

Oh, there’s one last ‘gotcha’ to the MS-35. On the PCB there are 2 ‘things’ that have a heatsink; those heatsinks are very close to the 3 IRFZ44N MOSFETs – for one of them, close enough to make contact.  In that case, the LED strips will light up very dim, even when you don’t want them to (0x00…). Just gently bend the rightmost heatsink away from the MOSFETs and the problem will be gone. Have fun with this 15 euro LED controller – I know I will 🙂

Merry Christmas!

A very cheap RGB LED controller

LED strips are nice, I like them a lot. Especially the (warm) white ones. We use them in the kitchen and behind the TV; in both cases as a replacement for light bulbs and/or fluorescent tubes. Looks very nice.

So when I could get my hands on some cheap white LED-strip, I didn’t hesitate and bought 10 meters. Those LED strips (which haven’t even arrived yet) come with a 12V adapter and a small ‘box’ with IR receiver and a small credit-card sized IR remote. That’s OK for RGB LED strips in the child bedrooms, but not when those LED strips are going to be used in the living room, entrance or anywhere else. So I needed a simple LED controller; not too expensive, and that has just the stuff I need – the controller and a way to send commands to control the strips individually. And last week I found the Conrad MS-35 RGB LED controller: cheap and no unneeded accessories. If you want you can even add buttons to the controller or an IR receiver (both connected to the controller by means of the headers on the PCB) but I don’t need all that – just this small controller for 15 euro, that’s all I need. Cheap and the user reviews weren’t bad either, so why not try it.

I added the P522J USB programming cable to the shopping basket and today those goodies arrived.

Time for some good-old serial port sniffing… The USB programming cable uses the Silicon Labs CP210x USB to UART Bridge driver (which is on the mini driver CD that comes with the cable). Now let’s see what happens when I try to program a so-called user sequence with the software that came with the controller:

User sequence programming

First only the red channel goes on, next only green and after that blue. And I added some variations to the time values, so it’s easier to find them back in the communication between the software and the controller. The software has a ‘Send program’ button for that so after I started a Serial port sniffer, I clicked that button and had a look at what was sent to the controller:

> 02 03 00 00 00 00 00 f3 23
< 61
> 03 00 ff 00 00 04 01 14 e4
< 61
> 03 01 00 ff 00 05 02 54 80
< 61
> 03 02 00 00 ff 06 03 73 41
< 61
> 0a 01 08 00 00 00 00 10 4a
< 61

OK; 61 must be the ACK.  The 02 on line 1 must be some ‘start programming’ id, the 03 is the number of colour transitions. Line 3 contains the first transition, line 5 the 2nd transition and line 7 the 3rd transition. And it’s obvious that the transition line contains a sequence id (pos 2), the R value (ff), G value (00), B value (00), cross-fade time (04) and the hold-time (01). And the last 2 bytes are the CRC16. Byte value 0a on line 9 must be some end programming id, followed by the User sequence id (01) ?? Don’t know what the 08 on line 9 is for…

Edit color dialog

Although this is nice, all I really need is a very simple command to set the R,G and B values – nothing more.

Lets see what more the MS-35 software has to offer.

There’s an Edit button in the User-sequence programming dialog; let’s see what happens there.. hey that’s a WYSIWYS (what you set is what you see) dialog with 3 sliders and some buttons to quickly select some colors. I changed 1 of the sliders and immediately the LED strip responded..

Let’s fire up the sniffer once more! With every change of either the R-, G- or B- value I saw the sniffer capturing a packet, so that should contain what I was looking for:

> 01 00 f6 6d 92 00 00 94 65
< 61
> 01 00 f6 6e 92 00 00 d0 65
< 61

Here, the G value was changed from 109 (decimal) to 110.


Done, I know what I need to know! 🙂

Today the color is…

Orange!! 😉


Well, it could just as well have been any other color of the 256*256*256 colors these RGB LEDs can produce, but since today is Koninginnedag, Orange was the most appropriate color I could think of for today.

The last 2 days I started with putting these RGB LEDs in the ground, under the gazebo.

Removing the stones to get the 20 meters of cable under the terrace, grit around the poles and putting everything back in place took me 2 days and I’m still not completely done yet; I think I need another afternoon for the ‘finishing touch’.



Just for fun I made a small beginning with controlling these LEDs from my system by using scenarios or lighting sequences; here’s what the “random” color scenario looks like:


I’m also going to use a remote for these RGB LEDs; I still have an old 433 MHz remote with 8 buttons that can be re-used to select the different scenarios. This remote will be attached to one of the poles of the gazebo so we won’t need to go inside to change the lighting.

With the Arduino acting as web-interface to the hardware, my domotica system and this remote I think we can really enjoy these RGB LEDs during those many upcoming long, hot summer nights!

Broken cables and Ethernet Shield trouble

It’s time for some work outside.. Last summer the play set  in our garden with slide and swings was hardly used, so I guess the kids won’t miss it. The swimming pool has to be filled with water again, the pump has to be put back in its place, the terrace needs some adjustments and of course, the gazebo RGB LED project needs attention cause the crate with the 6 RGB LEDs, DMX decoder & Arduino has been standing in the office since the end of last summer, so it’s time to finally complete this and get those 6 RGB LEDs where they belong – in the garden. I started with the last job 😉

The first thing I did was completing the indoor part of it all, e.g. putting the adapter, DMX decoder, Arduino with 2 shields (DMX & Ethernet) in a enclosure. This whole setup has already been tested with something I developed last summer. It had a Colorwheel control with which it was very easy to pick a color and control the RBG LEDs. But this is not enough; I still needed to integrate those RGB LEDs into my Domotica system. By doing that, my system is now in full control over the RGB LEDs and they can be controlled based on events, from the GUI (touchscreen) in the living room etcetera. This integration involved creating a Device Class for the RGB LEDs and a suitable interface to ‘talk’ to the hardware.

But not all things went as smooth as I had hoped. First, a power adapter cable was broken, which made the whole setup stop working every few minutes or so. It cost me half the afternoon to find out it was just a piece of cable that was bugging me…

I also applied the ‘Ethernet-shield-powered-from-the-adapter-plug’ fix I wrote about before, but it didn’t help enough. Sure, 4 out of 5 times it worked, but not always. And that’s not good enough, so I searched for another solution and I found one here, and this one worked always – well, successfully powering up 30 times in a row convinced me that this works well enough. So now there’s a wire going from the RESET pin to pin 4 (the Ethernet shield is underneath the DMX shield).

Ethernet Shield fix

The code that comes with it is simple but very effective:

void init_ethernet()
 pinMode(DO_RESET_ETH_SHIELD, OUTPUT);      // sets the digital pin as output
 digitalWrite(DO_RESET_ETH_SHIELD, LOW);
 delay(1000);  //for ethernet chip to reset
 delay(1000);  //for ethernet chip to reset
 pinMode(DO_RESET_ETH_SHIELD, INPUT);      // sets the digital pin input
 delay(1000);  //for ethernet chip to reset
 delay(1000);  //for ethernet chip to reset
 delay(1000);  //for ethernet chip to reset

Calling the init_ethernet() function from the setup() is all that’s needed to get a fully functional Ethernet Shield. Finally this RGB LED project is finished; well, I still have to dig 6 holes and get the RGB cable under the terrace – after that, summer can begin!


Bedroom lighting almost finished

A small update with some results on the bedroom floor lighting project.

Bedroom floor lighting

The small red dot in the center of the image above is where the hardware is (the boxed Arduino) with the PIR to the left. It’s hard to make a picture in almost complete darkness – keeping the picture sharp but also getting a result with colors that match with what my own eyes see is not that easy.. But the picture above resembles what I see when I get out of bed during the night well enough – and it’s exactly what I wanted! The LED strips (1.5 meters on both sides of the bed) light up the floor well enough to spot any obstacles, but it doesn’t light up the whole room. And the 15 seconds turn out to be the right amount of time to light up the floor; and the LDR  takes care of unnecessary lighting during daytime; so in one word, the only conclusion can be: perfect! 

One small glitch though, which points out the difference between a clean testing environment and usage in real life: some days ago, when I had to change the alarm clock, I switched on the bedside lamp so I could see the buttons on the alarm clock. This triggered the LED strips to go on!

This means that the switching of the 230V lamp resulted in a ‘spike’ on the PIR sensor input on the Arduino… hmm. I think I’ll have to redo some wiring and use shielded cables instead of the unshielded & untwisted ones I’m using right now. My bad…

Perhaps another solution would be to watch the incoming PIR signal on the Arduino more closely and detect whether it’s a short ‘spike’ or not and decide not to turn on the LEDs on a short ‘high’; but that just doesn’t feel right – cables first!