The invisible kill-joy

Yesterday, around 3 o’clock in the afternoon, I had some time to finish the job with the MS-35 LED strip controller. The LED strips were installed in the hallway, the wires had been made almost invisible, the software side of things was ready, so all that was left to do was putting the MS-35 and EZL-70 in an enclosure and connect it to the LED strips and the LAN switch under the stairs in the hallway. I thought I should be able to finish this before dinner, but in the end it turned out I needed until half past 10 to get it working because an invisible phenomenon spoiled everything..

During the last few days I changed a few things to the setup. The EZL-70 needs 5V DC to operate but I didn’t want to use 2 adapters – a 12V DC adapter for the MS-35 LED controller and LED strips and a 5V adapter for the EZL-70. So I searched for a circuit to convert 12V DC to 5V DC. That shouldn’t be too hard; I’ve done this quite a lot on breadboards with a LM7805, so I took a small piece of perfboard and soldered the circuit shown below:

12V DC to 5V DC


Two additional capacitors and a diode should do just what I needed. I tested it with a small 12V DC adapter and it worked fine – great, now I can ‘steal’ some power from the 12V LED adapter and stop using the additional 5V adapter for the EZL-70.

But somehow, after I installed all the components (MS-35, 12 to 5V converter and the EZL-70) in the enclosure and secured them with some drops of hot glue, it didn’t work anymore.

After I put the power cord of the 12V LED adapter into a socket, I saw the LEDs on the RJ-45 Ethernet connector blinking a bit strange; not the way they usually blink. And my 5-port LAN switch on my desk started making strange sounds as well… something’s not right here. And not a single ping succeeded either… did the EZL-70 die, maybe the heat from the hot glue destroyed something? Loose contacts in 12V to 5V converter circuit? Auch, the LM7805 is hot! What on earth is going on here?? It worked before, so why not now? Why is the LM7805 getting hot (and sometimes not)?

So I started disconnecting everything I soldered together inside the enclosure again… what a mess. First I took the EZL-70 out and tested it with a 5V adapter; no problems. I checked the 12V to 5V circuit stand-alone and this also worked as before. The MS-35 was working as expected too..

Just before I was at the point of pulling my hairs out because I couldn’t think of anything else to check and re-check, I realized that I used a different 12V DC adapter while testing it all here in the ‘lab’. This test-adapter was an old adapter I picked randomly out of a big box full of old adapters I have – the label said 12V DC 1.8A, so that should be OK. However, the new and not-working setup was powered by the original Quintezz power adapter that came with the LED strip… would that be the cause? I couldn’t believe it, but decided to give it a try – I was out of debugging resources anyway… and YES, after swapping the Quintezz power adapter for the one I used earlier, everything worked again!

Right… what is going on here? 12V DC != 12V DC I guess…but why??

I probably need a scope to look at the 12V output signal of the Quintezz adapter and compare that to the output of the ‘better’ adapter to see what’s going on. I suspect that the Quintezz power adapter output is only good enough for powering LED strips and nothing else..

Because the original LED power adapter is not good enough and will probably never be used again, I opened it up (an old habit). As you can see it’s mostly heatsink inside.. I see diodes, a transformer, some capacitors (one of them is very huge), an NTC, fuse, a CS5N60F what seems to be a voltage regulator and a 2CZ10100… on the other side of the PCB are a bunch of SMD resistors and capacitors, that’s it… and I can’t make cheese of this 😉

12V power adapter

The big question here is:  what can be done to prevent me from making this mistake again in the future, how can I easily distinguish the good from the bad ? Do I really need a scope for that, or … ?

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!

Insteon for the EU market

Last week I got an email from a Dutch Home Automation shop about a new product they’re selling. It’s the Insteon Hub, which enables you to control X10 with iPad, iPhone and Android devices.

Actually, in a broader perspective, what’s more exciting about this email is the fact that Insteon apparently made it to the other side of the big pond with their products.

But I was a bit puzzled about the email too – Insteon, that’s the company that makes the dual-mesh Home Automation products, right? Now that makes it even more interesting!

I’ve been asked by to help as a beta tester for Insteon since the past 4 months or so, and I know from my own experience that Insteon is not just about X10, it’s capable of much more. Just think of it: dual-mesh, mesh technology both on your powerline and RF. Most users of powerline-only Domotica hardware will have experienced that sometimes the communication can fail – a washing machine, TV or smart phone chargers can create too much noise on the powerline for the signal to arrive where it has to; and that’s where mesh and RF can kick in to make sure that the command does arrive at the module you wanted to control.

The Insteon dual-mesh technology has been around for quite some time and I would really like to use it in my home – dual-mesh sounds much better. It’s even better than PLCBUS (a powerline technology I use a lot over here; it never became really popular, yet outperforms X10 in many ways).

And that is what Insteon is about in my opinion – new and better technology, more reliable by combining powerline and RF.

To be continued…

Showing off

Not that what I’m talking about in this post is something special or unique, but it’s just that the things I completed last week are a big step in the right direction – big enough to post about and show off a bit in a small demonstration 😉

It’s all a logical follow-up on the smart meter we have in our house since September 3rd of this year. I decided to transform this smart meter into a MQTT client so that my Domotica system wouldn’t have to parse the P1 datagrams every 10 seconds and filter what had changed since the previous datagram. Instead I used a SimpleCortex to parse the datagrams and made it publish new values to a MQTT broker (Mosquitto) and I added a MQTT client to my Domotica system to subscribe to the various smart meter topics. The last step in the smart meter project was creating a web page to display the information from the smart meter in real-time.

This all went very well; well enough to upgrade my Touchscreen application that’s running in the living room on a Asus Eee Top, from UDP broadcast to MQTT as well (to receive updated values from my Domotica system).

And I knew I had all the tools available to start working on another type of user interface – web based this time. So I bought a new Andoid tablet (we needed one for upstairs anyway), saw JQuery Mobile, liked it and just started developing and testing some basic web pages, all with the wish of being able to use this new UI on our smart phones as well.

And last week I completed the technical side of things – I (we) can now also control all our roller shutters and lights from our tablets, PCs, smart phones – anything that has a browser.

And to show how it all works together, I made a small video showing (off) a light bulb being controlled in/from 3 different ways – a PC browser, a smart phone and the touchscreen application. Wow!

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! 🙂

Websockets and mobile network operators

Something I found out very recently, is the fact that Websockets don’t always work as expected. And neither the client side nor the server side can do anything about it- in my case, it’s the telco that messes up things. Either intentionally or not, I don’t know. And to be honest, I don’t really care – it doesn’t work, that’s the only thing that matters.

There are several sources that warn about proxy servers in combination with Websockets. According to one of those sources, the chance that Websockets will work when the traffic has to pass a proxy server is about 60%.

The day after I had my first Websocket-enabled web page running, I tested it from my PC at my work location. But unfortunately, it didn’t work.. my first thought was that it must be the transparent proxy server we use over there – I installed that one myself, so I know the state it is in 😉 But hey, never mind, I still got my smart phone, an Android with Firefox Mobile which supports Websockets, right?

Wrong. It didn’t work either. First thought was that I must have been dreaming. But that same day, back at home, the page worked again. Strange, cause I don’t use the company network with my smart phone.

So what’s the difference? The distance? Well, in fact it is.. 😉  The distance from my home Wifi to be precise! That’s why I couldn’t get websockets working 50 km away from home – I needed Wifi to get things running..

Time for some serious WSI (Websocket Scene Investigation).

While at home, my websocket page worked fine. But after I disabled Wifi on the smart phone, it stopped working. But after turning Wifi back on, it all worked perfect again, as before. What is this; what’s the big difference? It’s not like I’m addressing local IP addresses while I’m at home, so firewalls and all other things that can block or otherwise mess up things can be ruled out…I got the feeling that there was some unknown entity in between that was bugging me and I just had to find out what it was.

The first thing I did was setting the log level of my Apache reverse proxy server to debug. Maybe it was my own proxy server that was misbehaving? Wifi-mode told me it couldn’t be that, but it’s always good to check and double-check the things under your own control before blaming something or someone else, so I did. I performed 2 tests with my smart phone – 1 with Wifi enabled and the other one with Wifi disabled and watched the Apache logs.

The good, with Wifi enabled: - - [28/Nov/2012:20:44:05 +0100] "GET /mosquitto/ HTTP/1.1" 101 20 "-" "Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0"

Perfect. Response 101.

Now the bad (Apache error log, with Wifi disabled):

[debug] proxy_util.c(1415): [client] proxy: ws: found worker ws://localhost:80/ for ws://localhost:80//
[debug] mod_proxy.c(849): Running scheme ws handler (attempt 0)
[debug] mod_proxy_http.c(1812): proxy: HTTP: declining URL ws://localhost:80//
[debug] mod_proxy_ajp.c(524): proxy: AJP: declining URL ws://localhost:80//
[debug] mod_proxy_ftp.c(807): proxy: FTP: declining URL ws://localhost:80// - not ftp:
[debug] mod_proxy_connect.c(100): proxy: CONNECT: declining URL ws://localhost:80//
[warn] proxy: No protocol handler was valid for the URL /mosquitto/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule

And the access log says:

62.111.137.xx - - [28/Nov/2012:20:41:15 +0100] "GET /mosquitto/ HTTP/1.1" 500 615 "-" "Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0"
62.111.137.xx - - [28/Nov/2012:20:41:21 +0100] "GET /mosquitto/ HTTP/1.1" 500 615 "-" "Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0"
62.111.137.xx - - [28/Nov/2012:20:41:24 +0100] "GET /mosquitto/ HTTP/1.1" 500 615 "-" "Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0"

Aha, response 500, which means Internal server error, the error code you get when there’s something going wrong. But what and why? I still didn’t get it. Same phone, same browser, same web page, .. the only differences were connection and time of day.

Digging a bit deeper was all I could think of to find the cause. tcpdump, a network traffic analysis tool I haven’t used for quite some time, was the first thing that popped up in my mind, so after re-reading the man pages I set up tcpdump to capture the port 80 traffic to and from my Apache server – one capture from my smart phone with Wifi enabled and the other one without Wifi. Here are the results:

Wifi enabled:


And with Wifi disabled, the headers are:


You see? Why did the Upgrade: websocket header suddenly disappear? Cause that’s what triggers the server to respond in a way that enables working with websockets!

The only conclusion I could make is that it must be my telco Vodafone to be the one to mess up the headers that are sent by my smart phone.

And I did another test, just to be sure I’m not telling any rubbish here;  Lightstreamer has a ‘special‘ URL with which you can see how your browser connects to their streaming demos; either by websockets, streaming HTML or any other mechanism that allows real time streaming of data. And that webpage confirmed my conclusion: Vodafone blocks  websockets, intentionally or not.

Now, this is really stupid – my wife also has a smart phone, but with a very low monthly tariff and websockets are working OK for her. And me, with my monthly Vodafone costs of three times as much, can’t use websockets.. ?

So pay attention to which mobile network operator you choose!

A tip for a Websocket friendly telco, anyone?