What to do with surplus dev boards

I’ve been using Arduino boards for a few years now and it re-kindled my interest in microcontroller systems after having worked in the field quite a few years ago. Since then I’ve also used various Arduino compatible boards, shields and d-i-y boards, I’ve created libraries, published code and generally had a lot of fun with them. I’ve also used the ethernet connected Arduino compatible Nanode, dabbled with 32bit ARM architectures of the mbed products, tried the BeagleBone Black, had a brief affair with the Raspberry Pi and other development boards. With all these dev boards I’ve acquired quite a collection. With new boards coming along almost monthly and a change in my focus to more wireless connected devices, there is always something new to try. A lot of the older boards that I have stopped using still have a lot more life in them and would make ideal tools for a novice to learn about embedded micros if they find the purchase of new kit is outside of their means. Or for a small community group providing educational services based on Arduino and similar hardware. This is no way an attempt to undermine any sales of new boards but a way to provide new life for surplus boards. I’d urge everyone to buy at least one original Arduino board if you can afford it to show your support and enable them to continue the good work they are doing.

In the past year I’ve already given away at least 2 Arduino compatibe boards, the most recent was to a fellow attendee of the Thingmonk conference last year.

I’m sure I’m not the only one that has a large collection of boards that are feeling unloved and gathering dust in a box or drawer. After a few exchanges on Twitter I started to have an idea.

The Idea

After seeing the replies to my initial tweet it was going to be a difficult choice of what to do with the boards, who to send them to and what was a deserving cause. The replies included donating them to:

  • Local Hackspaces or Makerspace list of UK based spaces here
  • Schools for extra-curriculum clubs
  • Arduino workshops
  • Community projects
  • Just sell them on eBay
  • Give them to the first person who puts their hand in the air and says Me…Me…Me…

I’ve no idea if this is already being done anywhere in the UK or even the world. So lets see how much interest there is.

As it’s Arduino Day on 29th March 2014, celebrating 10 years of the Arduino I’d like to propose a global Donate a Dev Board scheme or event. The name probably needs work as I’m no marketing expert. There are numerous events going on around the world so this would be an ideal opportunity to share your used boards. If organisers of these events, or even if the Arduino ‘management’ would give the OK or even promote the donation of used boards to worthy causes this would help encourage less privileged people and especially youngsters to take an interest in this exciting world of Arduino and embedded micro controller boards. Although the idea is not limited to Arduino boards, they are ideal for teaching novices the basics and beyond. The range of mbed boards I would say are aimed more towards the more experienced user and are ideal for someone who has experience of the Arduino platform and wants to expand their knowledge and create bigger and better things with a more powerful platform.

The only rules I’d suggest for the dev boards being donated is that they must be fully functional, come with their original bootloader and sockets must not be damaged. Any shields donated must also include a link to where the new user can obtain the required library if it is not part of the core IDE.

I’m not sure if I’ll be able to attend an event, as much as I’d like to, so in support of this I have a number of boards that I’d like to donate. These are listed below.

Arduino Day 2014

My Boards

I have a number of Arduino, Arduino compatible and non-Arduino boards including:

2014-03-11 20.07.33

  • Arduino Due (not pictured)
  • Arduino Bluetooth
  • Mbed FRDM-KL25Z
  • Mbed NXP LPC800-MAX
  • ENC28J60 based ethernet shields for Arduino (x3)
  • 2.4″ TFT LCD Touchscreen
  • LPCXpresso 1768 board, not mbed abut uses version of eclipse ide
  • FEZ Mini .NET micro framework based

I’m sure I have more if I start digging deeper!

What’s next?

I’ve presented my idea, other ideas and suggestions are welcome. There are still a lot to work out, like who gets what, how to send or deliver it, who would run a scheme locally (hackspaces?), support etc. What’s the best way to continue this? Create a google group?

Comments appreciated.

Remote controlled LED Kitchen lights


Over the Christmas and New year holiday I’ve been doing a little kitchen refurbishment. This included the usual repaint and replacement of cabinet doors and handles. As an extra I decided to add some additional lighting above the cabinets to illuminate the ceiling. This is achieved using a more than 5m of 12V RGB LED strips. This is the variety that produces the same colour for each LED and as a result is a much cheaper option than the individually addressable LED strips I have used previously. There are two parts to this project, the first being the LED driver, the second being the controller that sends new colour to the LED driver.

2014-01-04 20.54.25


Prototype testing on breadboard with lots of jumper wires, IFRZ44N MOSFETs to drive the individual LED colours and 1K resistors for a bit of current limiting on the gate of the MOSFETs. The controller is a Ciseco XinoRF Arduino UNO compatible board with built in wireless transceiver module.
The LED strip is a commonly available on eBay, search for 5050 SMD RGB LED Strip. The ones I used are 5m in length with 150 RGB LEDs in total. It came with a small controller which can be used to test the strip is functioning.
2014-01-04 16.30.10
A quick layout done using Fritzing


Once the prototype was working on the breadboard, it was time to make it permanent on an Arduino compatible proto-shield from Ciseco. This sits on top of the Ciseco XinoRF board. As the LED strip required 12V I only wanted to use a single power supply. The XinoRF has a 3.3V regulator and 12V was at the top end of its range, to lower the voltage two IN4001 diodes were used to connect the 12V to the Xino RF VIN pin. This is then regulated by the 3.3V voltage regulator onboard. 2014-01-04 18.15.42
The device used to control the colour of the LED strip is yet another use of my wireless LCD display. This has software that described below. 2014-01-06 21.22.34

Control Commands

The communication between the LED Controller and the LED Driver is done using the Ciseco LLAP protocol. The commands implemented in the LED driver are:

Set new colour




Request current colour




In the above, XX is the ID of the LED Driver, rrggbb is the hex value for the colour with each pair of values being in the hex range 00 to FF and representing the colours red, green and blue in that order.


The software is in two parts, the LED driver and the LED controller.

LED Driver

The LED driver software receives commands wirelessly and sets the colour of the LEDs. The main features are:

  • Send starting message so that main hub knows this device is active
  • Responds to colour change commands by acknowledging them and changing the LED colour
  • Responds to current colour request command so that LED controller can determine what the current colour is
  • Saves the current colour in EEPROM and sets this colour when next powered on

LED Controller

The LED controller displays a set of 3 bars representing the three colours of the RGB LEDs. The colour is selected by moving the mini joystick up and down. The currently selected colour is highlighted. Moving the joystick left and right will increase or decrease the length of the coloured bar. This represents the intensity of the colour to be set on the LED driver. The colour change command is only sent to the LED driver when the joystick is released. The main features of the LED controller are:

  • Uses existing wireless hardware platform
  • Query LED Driver for current colours and set bars appropriately
  • Allow new colours to be selected and send them to the LED Driver

In use

A quick video showing the controller changing the colour of the LED strip.


The code is not yet in a releasable state, there are a couple of things to tidy up such as the layout on the controller screen needs a few tweeks and the code needs clean up before I publish it.


I use a lot of products from Ciseco but I don’t work for them, I’m just a customer who appreciates a good range of products that are developed in the UK. However I have over the years had a few freebies and samples from them. If you do want to get free stuff from their shop then check out this blog post.

2013 – Personally a great year!

Out with the old, in with the new. I’ll be sad to see 2013 go as for me personally it was a great year. I did a bunch of cool stuff, met loads of cool and interesting people and generally I’ve been living the freelancer dream!

Some of the things I have done or achieved this year, that I can remember, in no particular order:

  • Cleared all my loans and credit card debts and kept them clear, except mortgage.
  • Attended my first weekend music festival – Download2013 you were awesome!
  • Flying over the Download main arena on a zip-wire shouting Mother*****rs to the people below.
  • Had a great family holiday touring through France.
  • Dolphin watching in the Bay of Biscay while heading down to Bilboa.
  • A few weekends away in London with wifey and no kids – Quality time!
  • Visited UK MakerFaire in Newcastle.
  • Visited Elephant and Castle Mini MakerFaire.
  • Saw a couple of good cover band gigs.
  • Iron Maiden at the O2 were excellent second time seeing them this year!
  • Saw Avenged Sevenfold and Five Finger Death Punch at the LG Arena, Birmingham.
  • Saw Meatloaf – Like a Bat out of Hell!
  • Had a day of off-road motorcycling for the first time, must do it again.
  • Attended Over The Air 2013 at Bletchley Park, won IoT prize for the hack challenge.
  • Attended Thinkmonk IoT conference.
  • My parents celebrated 50 years of marriage.
  • Celebrated 19 years of marriage to my lovely wife.
  • My eldest turned 18 and still hasn’t bought me a pint yet!
  • My mother-in-law turned 80.
  • Built my first 3D printer – its the future!
  • Started to learn to use OpenSCAD to create 3D models for printing.
  • Made significant progress on my CNC cutter, but still not finished, one for 2014!
  • Celebrated the first anniversary of my company!
  • Attended the first SusHack hackday to kick off the Oxford Flood network – continuing this in 2014.
  • Did a brewery tour at the Wadworth brewery.
  • Drank a lot of beer, some good, lots great.
  • Drank a lot of wine but not much spirit this year.
  • Got a taste for Margaritas!
  • Successfully grew sweetcorn for the first time – those plants are tall.
  • Took over 40 days leave during the year, some to work on other projects. The joy of being a freelancer!
  • Contributed to the excellent Node-RED.
  • Learnt to use EagleCAD to design schematics and PCB layouts.
  • Had a lot of my PCBs professionally manufactured.
  • Bought a Quadcopter, now need to learn to fly it without crashing.
  • Had my first sit in an ambulance while being checked over after coming off bicycle.
  • Built lots of cool things including what could be most annoying IoT device – Bellduino!
  • …and anything else I’ve forgotten!

Many thanks to all the great people I’ve met along the way on my journey that was called 2013, you know who you are!

I’ll be raising a glass of something, beer, wine, cocktail or spirit to say “Here’s to 2014!”

Bellduino – The Internet connected handbell

I’ve recently been looking at alternative notification after seeing things like Bubblino created by Adrian McEwen, co-author of Designing the Internet of Things and the Cheerlights project from ioBridge labs. I had a gift ‘Ring for Beer’ bell that has been hanging around my desk for a couple of years now and decided to use this as the notification device. The first job was to decide how to ring it, the obvious solution would be a servo motor connected to an Arduino Ethernet or equivalent. The prototype uses a basic ATMega328 board and a shield containing a Wiznet Wiz820io module as this is what I had available to me at the time.

I have also successfully used an old Nanode board (Arduino compatible ATmega328 with ENC28J60 Ethernet controller) to drive Bellduino. This was achieved using the Arduino_UIP library with a few minor modifications to the original sketch. So far this seems to be working quite well as a lower cost solution.

The following describes how I built Bellduino, but first, lets see it inaction:

Building the Frame

OpenBeam parts used for the frame:

  • 4 x 150mm extrusion
  • 2 x 90mm extrusion
  • 1 x 45mm extrusion
  • 4 x Corner joining plates
  • 5 x T joining plates
  • 4 x Feet
  • 1 x NEMA17 Stepper motor mount and 608 Bearing mount
  • 1 x Servo motor mount
  • 1 x Big bag of M3 nuts and screws
2013-12-28 11.27.48
The frame is made up as a rectangle with the bottom and top as shown below. Remember to insert enough M3 nuts into the extrusion for the various inner brackets and mounts if the ends of the extrusion are blocked by other pieces. The parts that need extra nuts adding are:

  • Bottom – 3 nuts for T-piece, same side as corner pieces
  • Top – 3 nuts in front slot for servo mounting plate, 3 on rear for T-Piece
  • Right – 3 nuts in rear slot for T-piece to mount Arduino
  • Left – 3 nuts in front slot for NEMA17 mounting plate
  • Right and Left – 2 nuts in outer slot for frame feet
2013-12-28 11.42.46
The support feet are attached using T-joining pieces. The plastic OpenBeam feet are fitted underneath to provide protection to the surface that Bellduino stands on. 2013-12-28 18.45.57
The Arduino or equivalent electronics are mounted using two T-joining pieces taking care to ensure the screws are not shorting any tracks, if in doubt, use fibre washers between the screw head and board. 2013-12-28 18.47.45

Bell Clamp

Using my 3D printer I printed out a clamp and actuator arm that I designed using OpenSCAD. This clamps to the bell, providing a hole at the back that was threaded after printing to take a M8 bolt. The clamp also provides an arm that can then be attached via a rod to the servo motor in order to ring the bell. 2013-12-28 18.33.30
The pivot for the bell is made up from a M8 bolt, 2 nuts and an old 608 skateboard bearing robbed from one of my kids skateboards (Must remember to put it back and source a replacement bearing!). This just sits in the bearing mount and as there isn’t a lot of weight on it a single bearing does the job adequately. 2013-12-28 18.35.28
Close up of the bell pivot. 2013-12-28 18.36.01
The actuating rod connecting the bell to the servo motor is made up from a 140mm strip of 8mm wide aluminium with a hole drilled in each end. Washers and double nuts locked together provide a smooth motion when the servo operates. 2013-12-28 19.16.10
I found that the bell wouldn’t ring properly due to the spring supporting the hammer being too strong. To fix this, a lump of blu-tak (or similar) was added to provide additional weight to the hammer. This solved the problem and it now rings on command. 2013-12-28 18.34.24
The finished Bellduino 2013-12-28 18.31.05


The software runs on an Arduino Ethernet or equivalent and is basically an Arduino sketch that subscribes to a specific MQTT topic on my local server listening for any requests. It uses the Arduino MQTT client library created by Nick O’Leary, one of the co-creators of Node-RED.

As Bellduino subscribes to a MQTT topic, its just a matter of publishing to this topic in order to get it to ring. The easiest way to do this is to use Node-RED to produce the required MQTT publish request based on whatever input you want to use. The example I have at present is a twitter node that responds to the word ringmybell. A rate limiting delay node is included so that the bell is not continuously ringing.


  • Publish bell clamp design files
  • Publish sketch for Bellduino – still a work in progress
  • Example Node-RED flows

Using Node-RED with Twilio

For a while now I’ve been using the most excellent Node-RED to provide a way of integrating my various sensors and devices around the house. One thing that was lacking is a general mobile control or status update facility. This could be achieved using browsers on smartphones or custom made Android or iOS apps. These have the problem that they take up resources, are platform specific and may not always work if there is no data signal available. Using SMS to receive notification and perform simple control and status request operations would therefore seem to be the ideal solution. There are a number of providers that provide an API to send SMS but this is all they do. Having a service that enabled both sending and receiving SMS plus the ability, if needed to use voice calls would be ideal. Such a service is provided by Twilio. You can sign up for free and try a limited version of the service. Once you upgrade and start paying for the service you can choose your own number instead of the number allocated originally. You can also have multiple numbers, there is no Twilio banner at the start of your SMS and no Twilio announcement at the start of each call.


Twilio already provide extensive documentation and a number of libraries to use their service. They conveniently provide a helper library for Node.js so this was a perfect starting point for the Twilio node. The node I created is a basic output only node as this is what uses the helper library. The input side can be implmented using existing Node-RED nodes.

The Twilio node is currently not yet pary of the Node-RED package, but this is in progress.

The Node-RED Twilio output node

The Twilio output node is configured with a twiliokey.js file located in the directory (or folder) above node-red. This includes your Account-SID, Auth-Token and the telephone number that you will be sending SMS from.

2013-11-08 10.41.20

To send a SMS to a number, the topic parameter of the msg object must be set to the number, e.g. +4416358000xx and the payload parameter is the actual message that is to be sent.

In a simple test, you would use an inject node to create the msg topic and payload, this would feed directly into the Twilio node to send the SMS. How this is used would be up to your own imagination and requirements.

Receiving SMS

To receive and process SMS from Twilio is a little more involved, however there isnt a node for this and it can be easily implemented using the available Node-RED nodes. Input is handled using a http input node. This URL must be available to the Twilio servers so you may have to set up a dynamic dns service such as to point to your IP address. Fortunately my BT HomeHub supports this service. in addition to this, you’ll also need to setup port forwarding to your internal Node-RED server. This URL mus then be configured in the Twilio Messaging Request URL field. The purpose of this URL is that it returns a TwiML XML file to tell Twilio what to send as a response.

The basic function to create the response message could be:

var messageObj = { "Message": "You sent: " + msg.req.query.Body } ;
msg.payload = messageObj;
return msg;

The JSON msg object must be converted to XML format using the json2xml node and specify a root element of Response. The final node is the http response node that then sends the reply to Twilio. Once Twilio receive the XML they will read the message and send the reply to the originator of the SMS. This could be as simple as a status update or an acknowledgement that the command had been processed.

The received message can be processed to look for key words and commands to perform actions such as returning the status of a switch or sensor or just acknowledging that a light was switched on as requested.

Example usage:
2013-11-08 17.16.56

The usage described here only relates to sending and receiving SMS, however it is possible with little more effort to use voice calls instead. I’ve done a simple test where the number is called and a voice reads a custom message. Other examples include having your computer call you up and tell you that a window has been opened on your property. The possibilities for communication with mobile devices in this way is only limited by your imagination.

Over The Air Hackday challenge

I recently attended the Over The Air mobile development conference at the historic Bletchley Park, Home of the Codebreakers. This was a superb event including talks and hackday challenges covering a variety of categories. The challenge lasted just over 24 hours and in this time teams and individuals had to come up with something that was fun, useful, clever or just plain stupid! I had decided to enter the Internet of Things category and here is a description of what I came up with during that time. The photos included here were taken at the time of the event and subsequently used in my 90 second presentation for the audience favourite.

The venue: Bletchley Park
2013-09-27 13.51.49

The hack idea

By the evening of the first day I still didn’t have nay idea as to what I was going to do, other than using Node-Red as a way of interconnecting a number of devices. I had taken a large box of Arduino, mbed boards, cables, components, sensors, pcbs, tools and devices. I was looking to do something with wireless sensors that I had taken with me but what, I wasn’t sure. I eventually came up with the idea to use the TFT LCD display I had built previously. This would become a display for the temperature and also the number of tweets detected with the hashtag #ota13. As an added feature I added some very bright addressable RGB pixel strips as everybody likes flashing lights!

Implementing the hack

The Hardware

The temperature sensor node is a pcb and Ciseco SRF module running the LLAP thermistor firmware. For demo purposes it was set to send the temperature reading every 60s. Full details of the sensor node are in a previous post.

2013-09-28 13.31.45

The display is based on a Ciseco RFu-328 which is basically a tiny Arduino with a SRF radio module in a surface mount form factor. The display is a cheap 128×160 SPI display. Its all put together on a PCB that I’d previously designed and had manufactured by Ragworm. A recent post describes the display. As an additional feature I decided to add a pair of Adafruit NeoPixel strips to provide an indication of the number of tweets seen. The connections for these had already been designed into the PCB, but up until this point, no sockets had been soldered on. The sketch used is available for download.

2013-09-28 13.31.36

To be able to receive temperature readings from the sensor and to send updates to the display I used a USB SRF Stick plugged into my laptop.

2013-09-28 13.32.02

The Software

The obvious choice for integrating the various bits of hardware and other systems is the new Node-Red, Node.JS application. The screen capture of the nodes may look like there are a lot of nodes in there but this includes many debug and inject nodes used for debugging and testing the application. I’d pre-installed Node-Red onto my Windows7 laptop and installed all the required libraries, making sure it actually ran too. So during the hack day, it was only a matter of dragging the appropriate nodes into place, linking them up and writing the functions to do all the clever bits.


The two main input nodes receive the LLAP input from the temperature sensor and search for new tweets with the hashtag #ota13. The input from the temperature sensor is formatted into a single message then directed to three (there is a fourth shown but this was not used in the hack) nodes that reformatted the data to a Xively datastream, sent it via the api to my mobile phone and the third was to re-broadcast the temperature reading to the wireless display module. The second input node reads a twitter stream and filters on the hashtag #ota13. A count is incremented and the new value is sent to the wireless display. The code for the main nodes is shown at the end of this post.

The twitter input node was configured with my usual twitter name and I’d put ota13 into both the tags and topic boxes. I’m not sure this made much different as it didn’t seem to catch every tweet with the hashtag.

2013-09-28 13.33.11

The Xively output was setup to send the request to a newly created feed and datastream using the MQTT API. This is easy to setup using a MQTT output node, entering the hostname and using a topic of api_key/v2/feeds/feed_number/datastreams/0.csv. Where api_key is the API key for the feed with write permissions and feed_number is the number of the feed.


Node-Red functions

These can be pasted into the function nodes to perform the given action. For some reason the code tags are not preserving the format.

Parse LLAP – input from temperature sensor

// name: Parse LLAP message
// outputs: 1
// anything stored in context is kept available for next time we get called
context.buff = context.buff || "";
context.count = context.count || 0;

// wait for an a and reset the buffer and counter
if (msg.payload == "a") { context.count = 0; context.buff = ""; } // this does mean the a must NOT appear elsewhere in the message

// add payload to the buffer and increase the count
context.buff = context.buff + msg.payload;
context.count += 1;
// when we reach 11 then output the whole message, assumes length is the a plus 11 - may need to tweak...
if (context.count == 12) {
msg.topic = context.buff.slice(1,3); // return the first two chars as the topic
msg.payload = context.buff.slice(3); // return rest of the buffer as the payload
return msg;
return null;

Format Xively – Output to Xively for logging

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA") {
// Create message
var value = msg.payload.substr( 4, 5);
// Strip any - chars
value = value.replace(/-/g,"");
var msgPayload = value;
var newMsg = { payload: msgPayload };

return newMsg;
return null;

Format Temperature for Pushbullet

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA" || msgType == "LVAL" || msgType == "BATT" ) {
// Create message
var value = msg.payload.substr( 4, 5);
// Strip any - chars
value = value.replace(/-/g,"");
var msgPayload = "Temperature is " + value + "C";
var newMsg = { payload: msgPayload };

if(msgType == "TMPA" && msg.topic == "T4" ) = value;
else if( msgType == "TMPA" && msg.topic == "T2" ) = value;

return newMsg;
return null;

Format LLAP to send to wireless display

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA" ) {
// Create message
var msgPayload = "aNPTMPR" + msg.payload.substr( 4, 5) + "-----";
var newMsg = { payload: msgPayload.slice( 0, 12 ) };

return newMsg;
return null;

Extract Hashtag to count tweets and send count to wireless display

var entities = msg.tweet.entities;
var hashtags = entities.hashtags;
var newMsg;
try {
var numTags = hashtags.length;
if( numTags > 0 ) {
var tagName = hashtags[0].text.toUpperCase();
else if( tagName == "OTA13" || tagname == "OTA2013" || tagName == "TESTOTA13" ) {;
var count =["tweetCount"] || 1;

var llap = "aNPTWOA" + count + "-----";
// Extract first 12 chars
newMsg = { payload: llap.slice(0,12) };
count += 1;["tweetCount"] = count;
return newMsg;

return null;

} else {
newMsg = { payload: "No tags" };
return null;
} catch(e) {
newMsg = { payload: e };
return null;

That’s it, the hack was entered into the Internet of Things category and won first prize, winning a Fez Spider starter kit worth about £200.
Look out for some .NET Gadgeteer posts!

My slides from the Over the Air presentation are available at SlideShare.

Using Node-Red with OpenRemote for basic home automation

I’ve recently been using a new tool that describes itself as “A visual tool for wiring the Internet of Things“. More details are available at their website The idea is that ‘things’ can be brought together in a visual manner without any programming, although a little coding in JavaScript is needed in places. I’ve also been looking at OpenRemote to provide a tablet based front-end for home automation and monitoring. For this project I selected the D-I-Y approach using the open source version available from MQTT is also being used as a message passing mechanism. The broker I use is the most excellent Mosquitto. This post described a basic setup for using Node-Red and OpenRemote to produce a simple tablet based control and monitor application. Full details of Node-Red, OpenRemote and Mosquitto are available on their websites and should be referred to for installation and configuration of these packages.

The components

I have a number of components that need to be linked together, these are on the hardware side:

  • 2 Channel wireless relay board, based on Ciseco SRF module
  • Linux server to run the stuff on
  • Ciseco XRF with FTDI interface connected to Linux server
  • Nexus 7 tablet

And on the software side:

  • Node-Red
  • OpenRemote controller and Android app
  • Mosquitto MQTT broker


Wireless communications is being done by the Ciseco SRF modules using the LLAP protocol described in detail here.

The relay boar id controlled by sending the command aRLRELAYAON- to turn on relay A on board with an ID of RL. The relay board will respond to indicate the state of the relay.

Within the server, the messaging broker will have topics that the various parts of the Node-Red application can subscribe and publish to. For example, to send new LLAP message, I would publish to a topic llap/send. Received messages from sensor nodes would publish to their own topics, for example llap/T4/TMPA or llap/T4/BATT which would be for the sensor node T4 where the temperature and battery voltage are published to.

One final part of the communications is to provide a basic HTTP interface to control the relays and provide feedback to the OpenRemote application.

Building the Node-Red application

Interfaces to wireless devices

The first part is to receive LLAP messages from the module plugged into the Linux server, this uses the Serial input node then builds up the complete 12 character message. The LLAP message is then split up by the second function before it is finally published to a MQTT topic. A number of debug nodes are included for debugging purposes and can be turned on and off at runtime to display messages being passed between the nodes. A number of values are also stored in the Node-Red global context variables for retrieval later.


Code for the LLAP Parse function:

// name: Parse LLAP message
// outputs: 1
// anything stored in context is kept available for next time we get called
context.buff = context.buff || "";
context.count = context.count || 0;

// wait for an a and reset the buffer and counter
if (msg.payload == "a") { context.count = 0; context.buff = ""; } // this does mean the a must NOT appear elsewhere in the message

// add payload to the buffer and increase the count
context.buff = context.buff + msg.payload;
context.count += 1;
// when we reach 11 then output the whole message, assumes length is the a plus 11 - may need to tweak...
if (context.count == 12) {
msg.topic = context.buff.slice(1,3); // return the first two chars as the topic
msg.payload = context.buff.slice(3); // return rest of the buffer as the payload
return msg;
return null;

Code for LLAP to MQTT function:

// Topic is part set, now see if TMPA, LVAL or BATT msg

var msgType = msg.payload.substr(0,4);
if( msgType == "TMPA" || msgType == "LVAL" || msgType == "BATT" ) {
var newTopic = "llap/" + msg.topic + "/" + msgType;
var value = msg.payload.substr( 4, 5);
// Strip any - chars
value = value.replace(/-/g,"");
var newMsg = { topic: newTopic, payload: value };

if(msgType == "TMPA" && msg.topic == "T4" ) = value;
else if( msgType == "TMPA" && msg.topic == "T2" ) = value;

return newMsg;
return null;

The second part is to subscribe to the topic llap/send and pass the message out through the Serial out node and onto the wireless devices that would be listening for it.


The code for the LLAP format function:

var newMsg = { payload: "a" + msg.payload };
return newMsg;

I have additional nodes that take received LLAP messages, parse them and store the values in the global context for later retrieval.

Interface to Openremote

Next I provided a way to read the previously stored values in the Node-Red global context, this takes a URL of the form http://ip_address:1880/sensor?name=varname where varname is the name of one of the variables. The value is returned without any other formatting or markup. The values I’ve setup this way include temperature measurements, electricity usage and relay states.


The code for the Get Reading function:

var name =;
var reading =[name];
var newMsg = { payload: reading };

// Send http response
msg.res.send(200, reading );

return newMsg

In order to control the relay board I’ve setup another node to receive http requests of the form http://ip_address:1880/relaycontrol?relay=a&action=on. This will post a message to the MQTT Topic llap/send that will in turn be picked up by the nodes previously described and turn on the relay. Other options are to select either relay a or b and to turn them on, off or tog (toggle).


Code for the Relay To MQTT function:

var deviceId = "RL";
var cmd = "RELAY";
var id = msg.req.query.relay.toUpperCase();
var origAction = msg.req.query.action;
var action = msg.req.query.action.toUpperCase();
if(action == "ON") action="ON-";
var llap = deviceId + cmd + id + action;
var newMsg = { payload: llap };

// Send http response
msg.res.send(200, origAction );

return newMsg;

Building the OpenRemote Application

The OpenRemote Android or iPad application connects to the local controller to retrieve the details needed to draw the panels on the screen that perform the control actions defined using the OpenRemote designer. To start with, OpenRemote needs a number of components defining. These are the building blocks that provide the functionality for a particular device. In the example presented here, I have associted them with a device called Node-Red which is my linux server with Node-Red running on it. The components are:

  • Commands – Perform communication with a device using a variety of different protocols and methods and polling intervals
  • Sensors – Define asensor that uses a command to read a value, range of values or custom data
  • Switches – Select the commands to turn the device on, off and determine its state
  • Slider – Select a command to send a range of values depending on slider position

In the example below, I’m setting the http command to access the relay control node that was previously defined using Node-Red.If this was a slider command then parameters could be passed in the URL using parameter notation ${param}.


Once the commands, sensors and switches have been defined, you can start on the panel layout by adding labels, buttons and images to create your panel. Multiple panels can be created and accessed via a series of tabs or sliding from left to right. An background image can be used to create different effects and styles.


When using switches, you need to select both an ON image and an OFF image to show the switch or button state. The community version of the designer doesn’t come with any images so you need to provide your own. I used a couple of images found on the net but for my final design I’m looking to employ a graphic designer to work on new images and the user interface. But for now its not pretty but is functional. The switches are defined as shown in the image below, they need the name, sensor selected from the drop down of available sensors and the images to use for the on/off states.


Adding labels that have a sensor associated with them will draw the received value where the label is positioned. You need to remember to set a polling interval in the command setup otherwise your readings wont be updated.

This is only a small selection of what OpenRemote can do. I’ve not even explored the many protocols and devices it can control or the macros and rules that can help automate tasks. I’ll leave this for another time.

Testing the application

When the panels have been designed and you are happy with it then you need to sync the design with your controller. This can be done in an online or offline mode. Online is the most convenient method as you just need to select the controller url of the form http://server_ip:8080/controller then enter your OpenRemote designer username and password and click the Sync with Online Designer button.

The Android app is available in Google Play, however this is an old version, following the links on download page will get you the latest version. If you use your tablet and have the option to install software from non-marketplace sites then you should be able to download and install directly.
If all is well then you should see your panel appear on the tablet. The buttons should be selectable as shown in the demo video below.
If the switches fail to operate correctly then it could be down to the sensor part not working correctly as it appears the state of the switch needs to be correct for it to change the image and command used.

Quick Demo video

Listen for the Exterminate as its triggered by the relay board when the second round button is pressed.

Have fun if you decide to try this yourself.

Programming Ciseco SRF LLAP Firmware

I’ve been using a number of Ciseco SRF Radio modules recently, including designing my own PCBs to produce temperature sensors and button sensors. The firmware used is for the XRF range of devices, but as they use the same chip, the firmware will mostly work. There are one or two exceptions, plus the fact the XRF firmware is not supported by Ciseco when programmed onto the SRF modules. Firmware is available from Github repository.

The SRF is hooked up to my SRF programming jig. This is basically a number of spring loaded pins that provide power and the serial rx/tx signals for the SRF module.
2013-09-10 20.32.49

A FTDI cable was used to connect to my programming jig. The Ciseco XCM software is available from, the Ciseco support site. The SRF are shipped with serial pass through firmware loaded, running at 9600 baud. Using the Download config option you can verify that the SRF is responding to commands.
2013-09-10 20.44.23

Once you are happy that the XCM software is communicating with the SRF, you can re-program the firmware. Select the Upload Firmware tab, select the image to use then press the 3 buttons in turn to Program, Verify and Commit the new firmware. Once the firmware has been committed, the SRF will restart. When the SRF starts, it will send a a–STARTED– message 5 times.

2013-09-10 20.47.24

Using the Download config option again should confirm the firmware has been uploaded.

Once the firmware has been uploaded, the SRF can be soldered onto your board.

TODO: On board re-programming.

Using Node-Red with Ciseco LLAP devices

I’ve been using the Ciseco wireless modules for a while now and after seeing Node-Red I wanted to use the Ciseco modules as both an input and output to the nodes. This post describes how to setup the Serial In and Serial Out nodes to use either the USB SRF Stick or the XRF and a FTDI breakout module.

The Serial In node node should be dragged to the workspace and by double clicking on it, you will get the edit dialog.


This one has already been configured, but selecting the Add new serial port… option and clicking the Pencil icon will allow you to define a new port


In this example I have used /dev/ttyUSB0, alternatives could be /dev/ACM0. Select the correct speed and clear the newline character. The node should be named something suitable, such as LLAP In. Do the same with the Serial Out node, this time there should already be a serial port defined. Select this and give the node a name, for example LLAP Out.


Once you have the serial nodes defined, you can start to build up the received LLAP messages. This i sdone with a function as each time the Serial In node receives a character it passes it on. The function identifies the start character, builds up the message and then passes it to the next nodes.

The output of the LLAP Parse function will store the LLAP node ID in the msg.topic property and the rest of the message in property msg.payload. For example, if the received string is aT4TMPA19.56 then msg.topic will contain T4 and msg.payload will contain TMPA19.56. The function looks like this:


Code, for cut and paste:

// name: Parse LLAP message
// outputs: 1
// anything stored in context is kept available for next time we get called
context.buff = context.buff || "";
context.count = context.count || 0;

// wait for an a and reset the buffer and counter
if (msg.payload == "a") { context.count = 0; context.buff = ""; } // this does mean the a must NOT appear elsewhere in the message

// add payload to the buffer and increase the count
context.buff = context.buff + msg.payload;
context.count += 1;
// when we reach 11 then output the whole message, assumes length is the a plus 11 - may need to tweak...
if (context.count == 12) {
msg.topic = context.buff.slice(1,3); // return the first two chars as the topic
msg.payload = context.buff.slice(3); // return rest of the buffer as the payload
return msg;
return null;

All the nodes can now be put together to send received messages to other services, or use other inputs to generate LLAP messages to send out.



Thanks to @Dave CJ for helping out with the LLAP parsing function while I get my head round Node.Js.

Simple Wireless Display using Ciseco RFu-328

The Idea

For a while I’ve been tinkering with the Ciseco RFu-328 Arduino compatible wireless module but hadn’t done much with one. I’d obtained a pair of 1.8″ SPI TFT displays via an eBay seller in China that I had previously used with Arduino and mbed modules. The displays are driven using the Adafruit ST7735 library. I built a quick prototype and was able to test the basic LCD software. I then decided to go for a proper PCB design based on my recent experience designing PCBs using EagleCAD.

The remote sensors I was using are all base don the Ciseco SRF radio modules using the LLAP protocol described at

The PCB was manufactured in the UK by


The features I wanted to include were:

  • Compact design
  • Battery powered
  • Over the air programming – No cables!
  • Mini Joystick for control – Eagle footprint available in Sparkfun library
  • Additional PWM or NeoPixel outputs for indicators
  • Software should display nodes and the values they send
  • Include timer to remove nodes that dont respond after a certain time
  • Display receive battery voltages, if nodes support it

Build and use pictures

2013-09-03 12.05.11

2013-09-03 17.28.58

A quick trial fit of the display and spacers Starting to populate the board
2013-09-03 17.11.12

2013-09-03 17.05.41
More components and headers added Working display

EagleCAD files

Files are available from SolderPad.


This is the early stages of this project, future plans include:

  • Use joystick to navigate menus for setup and control
  • Be able to send LLAP commands for control of relay boards
  • Use as a range tester for mapping signal strength around a building

More to follow….