Last saturday an article in the newspaper caught my attention. The story was about 3 students that made their own development board: the Simplecortex, built around the LPC1769 from NXP, a ARM Cortex-M3 based microcontroller running @ 120 MHz with 512KB flash, 64KB RAM, MicroSD slot, 8 x 12bit ADC, 10bit DAC, SPI, 6 xPWM, 3 x I2C, 4 x UART, USB-host and Ethernet on board (did I miss something?)

Impressive… this could be the ideal board for projects where the Arduino-like boards can’t manage and a Raspberry Pi is overkill (I can do without Linux on board for those things I want to do).


Here’s a comparison with 2 Arduino boards:

Simplecortex compared to Arduinos

Furthermore, the Simplecortex is Arduino pin compatible.

As development environment the free CoIDE from CooCox is used. This IDE supports debugging and lots of other features not found in the Arduino IDE but which are very welcome 😉

And last but not least, you’re not left in the dark after buying the Simplecortex – the website of the company that developed the board contains information on how to get started, there are libraries and examples you can download and there’s a forum. Sounds good to me, good enough to buy & try one!

The # subscriber

In a recent comment on my new ideas to make my Domotica system more flexible, the term broker was mentioned. ZeroMQ doesn’t have one, Mosquitto, for instance, does. But do I really need a broker? I don’t think so; I think I can very well live without one. In fact, what’s the point of a broker when there will be a part of the automation system that will need to do a # subscription.

This subscribe-to-all entity is in fact the heart of the system, the brains, the glue to it all; the part of the system that does the real automation part.

Automation is actually based on events/scenarios; if all conditions for a specific event are met, the event fires and a series of actions are performed/executed. Some examples:

  1. There’s an incoming phone call which results in lowering the AV receiver volume level in the livingroom. Once the phone call has ended, the AV receiver goes back to its previous volume level. (these are actually 2 events)
  2. The garage door is being opened and a light bulb is switched on. When the door closes again, the light bulb is switched off again. (ditto)

These are 2 very simple examples that everyone can understand.
But the phone line can’t publish anything by itself, nor can the AV receiver subscribe to anything all by itself. For that, a driver, interface or plugin (pick your favorite) would be needed – a piece of software that can monitor one or more phone lines, control one or more AV receivers or switch one or more light bulbs on/off.

First thing I want to accomplish is removing all the interfaces to the hardware (the drivers) from the core application, cause those are the most error-prone; reconstructing incomplete/fragmented frames, faulty data (RF!), bad connections, misbehaving hardware and stuff like that is what’s causing the most problems. So for the sake of stability it would be best to start there. Each hardware interface (driver) will eventually become a stand-alone process, taking care of communicating with the sensors and actors belonging to that specific driver. The PLCBUS will handle all of my PLCBUS modules, the IRTRANS driver enables me to communicate with all the IR controlled devices in range of the IRTRANS transmitter, and so forth. Hardware specific code is nicely tucked away inside the driver, just like it should; for example, the mandatory 400 ms. delay between 2 consecutive (RF) Roller shutter commands is taken care of inside the driver; nothing else knows this delay is needed. This construction makes that it is the driver that does the publishing, not the device. 

Inside the System process every physical piece of hardware (temperature sensor, motion sensor, light actor, TV, AV receiver) is represented by an instance of a specific object class. To make these devices really come alive, they will need to receive the information from their physical counterparts; so all drivers will need to publish to the System process. Or better: the System process needs to subscribe to all the drivers; right?

OK, back to events (or scenarios) again.

Now it’s time for an Event that’s a bit more complicated; ‘house power save mode’. I’ve made a first attempt with this some weeks ago. Goal is to determine whether energy consuming devices can be turned off (or in standby) since there’s no one around anyway: PC’s, laptop, lights, garage door openers, AV equipment, you name it. I’m not going to bore you with the issues that arise once you start with this, but believe me when I say that it can be really hard to determine whether everybody’s out the door or there’s still somebody laying on the couch watching TV – you need every possible input you can get.

Likewise, the devices that will be turned off to save power are handled by various drivers – PLCBUS or X10 for lighting, TCP/IP for networked devices, Infrared or any other hardware specific driver. Should the TV device subscribe to dozens of publishers so it can decide for itself when it’s time to go into power save mode? Just like the laptop(s), lights etc.? BTW, the TV also needs to locally store status information about all the sensors it uses to be able to make the ‘I can turn myself off now’-decision just like the the laptop has to do (for itself); and the light bulbs, and so on..

The effect of the last example is in fact the same as the 2 I gave at the start of this post (something happens automatically), but the numbers are bigger and suddenly direct pub/sub between devices doesn’t sound that appealing anymore – in my opinion, event handling is a typical task that performs best when a single event handler instance takes care of all the events, no matter the complexity. Devices don’t interact directly – a ‘higher power’ is needed for that- at least for how my domotica system works right now.

And this makes me believe I don’t need a broker – I will need some kind of self-made broker anyway, with events acting as some sort of advanced routing rules…

Nemef Radaris Evolution Plugin for Homeseer

Finally the Plugin for my Nemef Radaris Evolution is almost ready to be tested ‘in the wild’. The time for testing the Plugin only by myself has almost ended – it’s time for others to try and find the bugs that I couldn’t.

Nemef Radaris Evolution

One last thing that still has to be tested is multi-controller and multi-RF Module support. It should all be in the Plugin because it was developed from the start with multi-support in mind, but this could never be tested with the single RF module and controller I have.

For that, Nemef was so kind to lend me both an RF Module and an additional controller to do this! Now I can test my own RF module with 2 controllers and also test a configuration of 2 RF modules with 1 controller each; that should suffice.

The total number of supported RF Modules will be set to 4, so that it will be possible  to control a maximum of 16 Controllers with the Plugin – I think that will be enough for most users 😉


The type of lock inside the furniture is a ELMEC600 (dutch), while my own lock has a ELMPS module. Both lock modules have some small differences regarding the protocol (status bits), so now I can also test how the differences between those 2 types work out.

Less than 2 weeks left before holidays start for me so I’ve got to hurry – can’t keep this extra hardware here forever!