PLCBUS as serious test case for all

Some time ago I wrote about a spare PLCBUS Interface that had been unused for quite a while; I wanted to get rid of the USB cable and see if I could do something useful with it.

Today my first thought was: why send the raw PLCBUS frames to the interface over Ethernet¬†(what I planned to do)? Why not add some more ‘intelligence‘ , closer to the hardware; why not completely remove the PLCBUS driver from my Domotica system and put it somewhere else??

I mean, MQTT has been working great right from the start and it’s here to stay, so lets see if I can ‘remove’ the PLCBUS protocol from my monolithic Domotica system and make a MQTT capable PLCBUS driver, just like I did for the Opentherm Gateway – hide the ‘ugly’ details!

There are quite a lot of PLCBUS modules in our house, so a problem with the PLCBUS driver should surface almost instantly – I can use this spare PLCBUS interface as a perfect test case and roll back to the old situation any time in case of serious problems.


The first thing I did was examining the internals of the PLCBUS interface once again. USB is out of the question, RS232 will need more hardware (5V for the MAX232), so TTL looked like the right choice. I saw that the MAX232 on the PLCBUS interface PCB was connected to the rest of the hardware by 2 4N35 Optocouplers – 1 for incoming and 1 for outgoing signals. Why not solder 2 wires to these Optocouplers and directly connect this to a UART? Good question…

So I tried. I soldered a wire to each of the two Optocouplers and used a spare Arduino Duemilanove to see if the output was what I expected.

PLCBUS connected to Arduino

And some lines of code (most of them for getting each frame on a new line) for the Arduino to show what’s being received in the Serial Monitor window:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3);

void setup()
  Serial.println("PLCBUS I/O test");
  // set the data rate for the SoftwareSerial port

long time=0;
int nl=0;
void loop() // run over and over
  if (mySerial.available()){
    int c =;
    Serial.print(" ");
  if (millis() > time+100){

Yep… all is well. I used a PLCBUS Mini controller to send some frames with a House code which is not in use and saw the following output being displayed in the Arduino IDE Serial Monitor window:

2 6 A5 21 22 64 0 C 3
2 6 A5 21 23 0 0 C 3
2 6 A5 11 23 0 0 C 3
2 6 A5 11 22 64 0 C 3
2 6 A5 11 23 0 0 C 3
2 6 A5 11 22 64 0 C 3
2 6 A5 A8 22 64 0 C 3
2 6 A5 A8 22 64 0 C 3

For those not that familiar with PLCBUS frames: those are all 100% valid frames ūüėČ So that is working just fine. Next test will be sending PLCBUS frames to the interface to control some appliance modules.


Next issue: where does the driver go? For this I have (had) several ideas and options. The most important thing for me is that I want all my drivers to work independent of each other – if one of them breaks down for whatever reason, the rest of ’em should not be influenced by that. Now that I have an unused interface which I can talk to @ TTL level, the options are endless – JeeNode, .NetMF boards, Arduino (Mega), Simplecortex, TTL to Ethernet adapter, anything goes, but I decided to go for the Simplecortex. Lots of processing power, Ethernet and I/O. Maybe even suitable for hosting multiple drivers (the less important ones, that is).

This PLCBUS interface will be a good excercise to translate the relatively small amount of Delphi code (about 200 lines) to C and make an application for the Simplecortex with lwIP TCP/IP Stack, DHCP, DNS and MQTT and see how this works out. DHCP to make life easier, DNS to make the application more adaptive network-wise and MQTT as transport layer on top of TCP/IP.

And if this excercise turns out the way I hope, this could be the real start of what I started thinking about in June last year; cutting my Domotica system into relatively¬†independent¬†parts – especially the essential ones like PLCBUS, Zigbee, AV equipment, IRTrans, OpenTherm and all other drivers which are heavily used and make life more comfortable…

Lets do it!

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!

Going solar

It looks like it’s going to happen this year – we’re going solar!¬†It has been on my wish-list since 2008, so it’s time to do something about it.¬†The decision to finally cover our roof with solar panels was the easy part – and now I’m overwhelmed with all kinds of questions!

Solar panels

Of course, I want the best there is in terms of quality, the amount of electricity they produce, power degradation caused by aging, guarantee (and all that within our budget of course..).

What brands should I look for, which ones should I avoid? The panel dimensions seem to differ a bit as well (lengths from 160 to 180 cm); which dimensions are optimal for our situation (orientation, available space)? How much room do I actually have to place solar panels? Should I buy mono- or poly-crystalline panels, or should I not even worry about that?


Again, which brands have a good reputation, have well documented monitoring capabilities. ¬†And what’s this Optitrack Global Peak, do I need it? Or maybe all recent inverters have it built-in already?

These are all questions related to the hardware; but there are some other issues to resolve as well and not all are that easy to deal with.

Should I go all the way now or save some space (and money) for next year? And should I buy an inverter with more capacity than I really need, so that I can easily add more solar panels next year? Will this have a considerable impact on efficiency this year? What’s the best place to install the inverter? As close as possible to the solar panels sounds like the best thing to do, but that’s not so practical in our case.

Another thing to tackle is that we don’t have a crawlspace under our house, which makes it harder to easily hide cables; how difficult will it be to get cables from the inverter to where the connection to the utility grid will be made? I don’t really like cable ducts on the outer walls of our house; however, I like them even less inside!¬†How much do our roofs suffer from shading caused by surrounding objects? What will this do to the solar panel output?

Oh my… all those questions, decisions to make, things to dive into… so I decided to first take one ‘easy’ decision: I will install our solar system myself (with a little help here and there). Mounting the panels on the roof, the cables from the panels to the inverter and to the mains distribution panel. That should all be not too complex for me, I guess.

I’ve been sketching, surfing, measuring, reading, searching, discussing during the last 3 weeks and I think I know a bit more now. For instance, in our case it looks like it’s better to give the solar panels a SW (South West) instead of a 100% South orientation, since the number of panels that can be placed on the roof in SW orientation is much higher; and those extra panels can easily (over-)compensate the efficiency loss caused by the SW orientation.

Another thing is that it looks like a good idea (efficiency-wise) to give the solar panels an angle of 30¬į inclination, but this will result in a very large distance between multiple arrays of panels, sometimes as much as 2.40 m! By using an angle of 20¬į¬†this distance can be reduced¬†drastically, which might give enough room for an additional array..

Portrait or Landscape, another thing I’ve been thinking about. With partly shaded panels the preferred orientation is landscape, cause (assuming that it’s the lower part of the panel being shaded) in portrait orientation the bypass-diodes can/will shutdown a complete panel instead of just a part of it.

Talking about shadow; how much shadow will the solar panels face? I really don’t know! I don’t spend that much time on our roofs… I do know where the sun rises and sets approximately, but never really paid attention to if, where and when we suffer from shadow – especially on the roofs.

To get some more grip on this I made a Google SketchUp Model and created 6 animations, for January 1st, March 1st, May, July, September and November. Just to give me some more insight on the amount of shadow. And now I know that (what a surprise) November till January are really shady months up there! Watch the 6 animations yourself here:


Well, it seems I’m still in a stage where trying to find an answer to a question brings up more questions than answers…