Easter Hack - An Arduino Solar Thermal Controller - in 3 days!

With the longer sunshine hours and warm temperatures, it's time to take my solar water heating out of winter hibernation and improve its control system. After some experience of making an Arduino Mega 2560 based central heating controller, it seemed a good idea to extend some of the ideas to include control of the solar panel. Central heating is generally in use from October through to April, and solar water heating for the remaining months. It seemed sensible to ultimately incorporate solar heating control into the central heating system and get the most from the control and monitoring system.

As part of my aim to use low-cost web connected sensors to measure the contribution of renewable energy systems to the UK domestic energy mix, using a solar thermal panel as a potential first candidate seemed a good idea.

My task for the Easter weekend was to come up with an Arduino based solar controller and use it to collect solar and temperature data and pass this up to the internet using my Nanode low cost Network Node and a web-data service such as Pachube.

It had to measure the inlet and outlet temperatures of the solar panel, the flow rate and control the speed of the pump motor. It also monitors the quantity of solar heat into the water by measuring the flowrate of the circulated water.

Here's my array of 20 evacuated solar water heating tubes. They are mounted on my south west facing shed roof. There is a small 1W solar panel mounted to the upper right of the frame, which can power the Arduino circuitry and also give a good indication of the strength of the incident sun.

This photo was taken about 6pm - just when the sun was leaving the panel.

It is in sunlight from 10am to 6pm, and produces useful thermal output from about 10:30am. Not bad for late April.

The output of the solar thermal array is linked back to my hot water cylinder with about 25m of insulated microbore tubing, and the water is pumped with a 12V dc pump.




Here's my DIY Arduino built on stripboard. It's a bare minimum configuration, just ATmega328, 16MHz crystal and reset circuit with a FTDI cable connection to the laptop programme it and log the solar and temperature data. A 5V linear voltage regulator allows the board to be powered from a wide range of supplies, eventually a small PV panel will be used to power the system during daylight hours.

The dc pump motor speed control is a PWM signal to an IRF640 Mosfet. It is on the bottom right of the case mounted to a heatsink.

The board is mounted inside a Danfoss central heating "wiring centre" case. It's a convenient case with screw terminal connectors.

This photo shows the dc pump (Totton Pumps) and the water flow sensor (UCC from Farnell/RS).

The pump motor is 12Vdc max 4 amps and I use an IRF640 power mosfet with PWM drive to control the speed of the dc pump motor. The Mosfet has to be mounted on a heatsink as it definitely runs on the warm side.

The flow sensor provides a square wave output of frequency proportional to the flowrate. I use an interrupt driven routine averaged over 4 seconds to determine the water flow rate.

Temperature sensors are 10K thermistors. I use a pipe-clip type available from Rapid Electronics (26-7470). These are fitted to the inlet to the panel and the water outlet. I calculate the temperature difference between outlet and inlet, and also the flow rate of the water through the panel.

Multiplying the temperature difference by the flowrate gives a figure which is proportional to the instantaneous power output of the solar thermal panel.

A Wireless Home Energy Monitor to Accompany Nanode

One of the first projects after the Nanode has to be a wireless shield in order to allow Nanode to talk to wireless sensor networks.

In the last couple of years there have been an increasing range of cheap wireless modules available to the hobbyist.

As well as 2.4GHz Xbee and Bluetooth offerings, sub-1GHz is better for in-building propagation. Additionally, if you only want to pass a few bytes between sensing nodes, Xbee and Bluetooth are expensive overkill. Passing a few bytes between nodes is exactly what we want to do with the Nanode, and so a low cost wireless solution working at below 1GHz was sought.

Hope RF produce some nice cheap transceivers that work below 1GHz - and programmable to any of the ISM bands 315MHz, 433MHz, 868MHz and 915MHz. They are available in the UK from Maplin, at just £5.99 for a transceiver.

I had previously experimented with short range wireless, using low cost on-off keyed (OOK) modules. I'd even adapted the SNAP protocol from HiTech Horizons to work across the wireless link, but it was all coded up in PIC assembly code and it was difficult to maintain.

The arrival of the cheap Hope RF modules, and the "Arduino like" JeeNode, meant that progress with with simple wireless networks has been very much accelerated.

JeeNodes are the brainchild idea of Jean-Claude Wippler, a very talented multi-discipline engineer from the Netherlands. J-C had the idea of grafting a RFM12 wireless module on to a BareBones Arduino to make a simple wireless node. The second innovation was to arrange the I/O lines of the AVR into 4 identical ports. Each port consisted of a digital line, an analogue line, power, ground and an interrupt. With this standard interface, any add-on device could be plugged into any port. J-C has also written a comprehensive library to support this port structure.

Glyn Hudson at openenergymonitor.org shared a new design with me for a wireless energy monitor, which he had designed to be compatible with the JeeNode, and with this inspiration I decided to modify it to make it compatible with the Nanode.

Glyn had taken the JeeNode idea of 4 separate ports and an RFM12B wireless transceiver and added the extra hadware needed to do electricity monitoring, temperature measurement and pulse counting - for example from a gas meter.

I decided that the JeeNodes port layout was a good innovation, but if it also had Arduino shield connectors, it could turn a conventional Arduino into a Jeenodes compatible device - as well as all the home energy monitoring interfaces.

So what has been conceived is a bit of a hybrid.

It's a JeeNode wireless shield for an Arduino.
It's a standalone wireless home energy montor.
Its a wireless shield for Nanode
It's a home energy monitoring shield for an Arduino.

Some basic design features:
1. Hope RF RFM12B sub 1GHz transceiver
2. Compatible with Jeenodes firmware
3. Jeenodes "Ports" supported
4. programming via FTDI cable or Vusb port
5. One Wire sensor support - up to 8 DS1802 temperature sensors etc.
6. Connects to one current transformer (CT) and one voltage reference input
7. One interrupt driven pulse counter - for gas meter pulses
8. Supports Nanode local serial bus.
9. Driver for 2 relays or 2 serial slave boards - for central heating/solar hot water control
10 Can be used a basic shield or standalone unit.

With these basic features in mind, I set about laying out a wireless home energy monitoring shield which could also work as a stand-alone wireless node.

Nanode 101

Introduction

Nanode is a low cost sensor node intended for web connectivity applications.

Officially, Nanode stands for Network Applications Node - unofficially it could be described as a Networked Arduino Node.

Nanode shares a lot in common with Arduino, and can be programmed using the Arduino IDE.

Nanode has been cost engineered to under £20 in order to make it attractive to the hobbyist.

Connectivity

Nanode has two separate network connections, firstly an Ethernet connection to access the Internet, and secondly a wired serial bus, which allows several Nanodes to be connected together in a Master/Slave heirarchy using low cost telephone cable.

I/O Capability

Nanode is based on the Arduino and offers a subset of the Arduino I/O.

Up to six uncommitted analogue input channels and up to six digital I/O lines are available.

Analogue inputs can be reconfigured as digital I/O if needed. The remaining Arduino I/O is used internally by the Nanode for running the Ethernet controller, handling the serial bus and USB communications and so cannot be guaranteed to be available for user applications.

Arduino Shields

Nanode accepts Arduino shields, as per the Nokia 3310 display shield shown above. A range of shields in anticipated to cover the essentials of a wide range of applications.

Pachube

Nanode works with Pachube to enable it to communicate with other web applications.

Nanode for Renewable Energy Crowd-Sourcing

How much renewable energy is being produced at any time in the UK? How does a PV array in Surrey compare with a similar sized one in Scotland? Is it currently sunny in Belfast? What is the current windspeed and direction in Welshpool?


These, and other questions could be answered using Nanode based sensors, fitted to renewable energy installations distributed around the country. The low cost of the Nanode makes renewable monitoring very affordable. Even on a £400 solar water heating system, the monitoring and control system, if based around Nanode would be just 10% of the outlay.


At the Pachube Hackathon we connected 3 Nanodes together using Pachube, so that we could monitor the output of a small solar panel plus the outside temperature. This was a small scale version of a real world app for the Nanode.

We believe that this will be a very important application for Nanode, acting as a domestic renewable energy monitor. It could, for example log all of the utility consumptions - water, gas and electricity, plus any renewables you may have installed, such as photovoltaics, solar hot water or wind power.

With a large population of Nanodes monitoring domestic energy consumption or renewable production, using statistical crowd-sourcing analysis of the data, important information regarding the state of the countries energy consumption and renewable production could be made available to the public domain. Nanode users could participate in a competetive game, trying to lower overall utility consumption, whilst maximising their renewable generation

A snap-shot of photovoltaic production in the UK, on a sunny afternoon, could be available to all, in virtual real-time. The low cost of the Nanode will stimulate these types of application. Additionally, on the back of the utility and renewables monitoring, the Nanodes could provide smart central heating or solar water heating control, triggered from an iPhone app, for example. Indirectly, Nanodes would provide weather data - which could be gleaned from the solar output figures. A Nanode could be interfaced to a low cost weather station kit, to give windspeed, wind direction, outside temperature, humidity etc.

In our small scale Hack, one Nanode acted as the sensing device (a slave) producing solar volts, milliamps and temperature readings every few seconds. It was connected via 15m of telephone extension cable to another Nanode which had the ethernet connection to get that data up to the net using Pachube as the host. A third net connected Nanode, subscribing to the Pachube feed was then used to work a servo actuator and a RGB lamp as visualisation devices.

Pachube Hackathon - Nanode's first Outing

I've just got back from the 24 hour London Pachube Internet of Things Hackathon. We converged on Peter Street, in London's Soho district, for #pachubehack- a global event to coincide with International Internet of Things Day (April 9th 2011). Sister events were happening in Eindhoven, Linz, Zurich, Seoul, New York City and Lancaster. (Next year will be bigger better and everywhere).

The event was held in a large airy basement/boilerroom of a Victorian school. Now converted to a media studio. A small courtyard gave a handy area to get some fresh air or chat with friends over a beer.

Here's "Waving Kitty" - a £5 Lucky Cat, bought in Chinatown on Friday afternoon just before the Pachube Hackathon. Waving Kitty now has a Twitter account and responds to Tweets and Pachube Feeds in just the way a robot-hacked Lucky Cat would. Great hack - by Paulo Ricca and Frieder Ganz.

A small patch of sun outside a Soho basement - just enough to try out our Solar Nanode Hack. A Nanode device monitors solar power from a small PV panel. Imagine if every PV array in the country had low cost monitoring like this? £20 is not a lot to pay to know what is going on. Close up of "Breadboard Friendly" Nanode measuring solar volts and milliamps. Supercapacitor, white LED array form the load. Three thermistors give outside temperature readings.. 11th Hour activity in "Nanode Corner". Matt, Luke and Oleg sort out the app whilst Sam, with back to camera in corner tries to sort out Ken's code!

I gave my Nanode presentation at 3pm and informally throughout the session - including at 1am to NYC. I then hit the "Z-plane" for a few hours.

We hacked 3 Nanodes to complete a sensor chain - from PV and temperature sensors, back to a Master Nanode, and then up to Pachube. A subscribing Nanode completed the presentation with an RGB LED orb and a servo-pointer-thingy (servo with coffee stirrer attached) to allow the data feed to be visualised.

Trystan Lea of Openenergymonitor.org had a Nanode connected to an electricity monitor and also a temperature sensor on his hot water tank

Michael Doherty - overall winner in London, catches up with some Zeds after hacking all night!

At 1pm we had presentations from all the hack teams. Outright winner was Michael Doherty who hacked alll night and then slept until lunch time, but received a GPRS modem from Arkessa- well done Michael.

Prizes also to the team that did a RFID bookshelf, and "Rogue Commuter" with some great ideas on how to give everyday objects a personality - so that it can help your daily battle against the dark forces of Southern Railways (or any other thieving rail operator you choose to vent your spume against).

This was a great event, with lots of great talent and ideas, some of which I still struggle to understand.

Well done to all the Pachubehackers who took part around the globe. We can only look forward to the next event in 6 months time.

Pachube Internet of Things Hackathon - Final Preparation

With less than 20 hours before the Pachube IoT Hackathon begins, I am starting to get stuff ready to take.

I've been asked to do a presentation about the Nanode, for 3 minutes, and also run a 1 hour "surgery".

I've emailed the presentation to the groups in Lancaster, NYC, Eindhoven and Zurich - with Seoul and Linz still to do.

I'm bringing 4 of the prototype Nanodes, plus the original breadboarded unit. In addition an Arduino plus ethernet shield which will emulate the Nanode.

There are already six Nanodes out in the wide world, given to friends and colleagues who are beta testing them, or have contributed to the project.

We already have on Nanode which is monitoring electricity usage in a house in North Wales and putting this up to this Pachube Feed

The plan is to distribute 4 Nanodes to the teams at the London Hackathon, sit back, relax and let them dream up some really good apps.

I'm bringing a few RGB lamps which we can use as ambient orb displays, plus a servo-pointer-thingy which makes a good large scale analogue meter. I also home to have some big LED 5x7 matrix displays which we can hack in some shape or form.

Nanode has consumed most of my free time of the last 3 weeks - so it will be good to let others take the lead.

Nano Tweets - It's an Enigma

Minimalist communications between microcontrollers both solves and creates some specific problems.

For example, how do you decode a message and know what context it was written in, what meaning it conveys and having got the decoded arguments, what do you do with them?

Some protocols put the arguments in specific places in the packet, for example, start of packet header, source address, destination address, number of bytes, payload and checksum etc would be placed in the packet in a given sequence. The microcontroller just needs to find the start of the packet header and work its way through the various fields.

An example of this is the simple format is the free and open SNAP (scalable network application protocol) devised some years ago by Swedish home automation company High Tech Horizons.

Another example is to use a mark-up language, such as XML, to convey the context of the various data fields. The CurrentCost CC128 Energy Monitor uses this approach, but the packets tend to be fairly verbose, which is fine if you have a PC, lots of RAM as a packet buffer and high level language with which to parse the packet. This is not often the case with a $3 microcontroller.

How could you convey context to a small packet of data, without having a massive overhead of extra data? In effect strike a balance between SNAP which is context free and relies solely on the order of the data fields in the packet and XML whre everything is spelt out for you with lots of additional text strings.

The answer lay nicely in the cipher machines and code breaking techniques of WW2.

In the 1940's the Enigma machine was used to encryt and decrypt messages so that they could be sent between German Command and various outposts. The Enigma machine had been sold throughout the 1930's as a secure messaging machine for businesses.

The key to the Enigma machine were three (and later four) alphabetical code wheels. The user was instructed what particular codewheels to fit, and in what order. The code wheels were then turned so that a particular letter was visible to the operator.

Once this was done correctly, all characters in and out of the Enigma machine would be correctly encrypted/decrypted.

Remembering this gave me a flash of inspiration. How do you come up with very short messages, which are character efficient but allow a wide variety of different tasks to be actioned?

The answer is to use a method analogous to fitting different code wheels. And these "codewheels" convey the context. You would only need to send the "codewheel" byte once, and from that point everyone who's listening, knows what you are on about.

For example sending Context 55, would tell all your subscribers that they should look up from ROM that Context 55 is for a 6 channel temperature sensor, and so that all subsequent messages contain temperature data in centigrade to one decimal place.

For simplicity, lets assume that single alpha characters A,B,C initiate certain action routines. In order that the Nanode performs the correct action for the application, it first has to be instructed which code wheel or rather book of actions it should be using.

By instructing a subscribing Nanode to use a different set of action routines, would be a very quick way of changing its application or context.

There would be a default set of routines to which all respond in the same manner, and a series of command primitives or directives based on punctuation characters like @ and #.

The first character of any nano-tweet message would either be an alpha character to signify an action routine, or a punctuation character to define a primitive command or the context of the remainder of the message.

Nano-Tweets?

Last August I blogged about an idea I had for an equivalent of Twitter, but for short messaging between resource limited microcontrollers.

With a little bit of thought, this could become a very simple means for smart sensor nodes or simple devices to communicate via the Internet of Things.

I had already experimented with simple CSV serial command strings to control an instrument I was developing, which used an Arduino. Typing commands in the serial window, sent data to the serial port of the Arduino, which was then decoded and used to invoke certain action routines to control various functions. This worked well, used a human readable (memorable) set of alphabetical and numeric commands, and used very little firmware overhead to write a simple command interpreter. Easy enough for even my C-skills to cope.

The command interpreter was as rudimentary as a series of switch/case statements that if you receive character "a" do this action, "b" do another action and so on.

So I had character "a" controlling signal amplitude, "b" for setting the brightness of the LEDs, "s" for setting the position (angle) of a R/C servo, and so on.

s,90 would move the servo to its 90 degree position - it really was that simple!

About the same time, I was getting interested in remote sensors and home automation. It dawned on me that my messages were identical to a Pachube CSV feed, and that Pachube could easily be used without modification to get data from one microcontroller to another.

The whole thing would be set up as a Publisher/Subscriber messaging model.

The message would consist of a few characters of data or arguments, separated by commas, which would be broadcast from one device to many subscribers using a Pachube CSV feed as a data exchange mechanism. All of the hard work was done by the Pachube API.

With the advent of low cost hardware, in the form of the Nanode, the need for this message format is now growing, and it is hoped that some ideas can be discussed and tried at the Pachube Internet of Things Hackathon at the end of this week.

For one thing, the messages need to be short, just a few bytes of data to convey the minimum of information necessary to convey sensor readings or command data. In the case of wanting to directly control a remote device, the remote device needs to be alerted that the message is intended for it.

In a similar fashion to Twitter, use of the @ character could be used to indicate that a message is aimed at a particular node. Conveying context in the message could be done purely by the order of the arguments, or by preceding a particular argument with a special character.

Again, borrowing from Twitter, the hash symbol # could be used to precede an argument, to convey that the argument is a particular subject. An example of this might be two Nanodes controlling some sort of central heating system. Let's assume that the relay to control the boiler is controlled by digital output 8. Using #8 could be used from the sending Nanode to signify that it is refering to an object on "number 8" and the next byte could be used to define what state it should be in. This would be a good way to convey 8 bit PWM commands to particular pins of a given Nanode.

The sort of operation we wish to perform on a microcontroller involve the setting and reading of port lines, reading and writing to memory or registers, outputing PWM, making ADC measurements and timing pulses. Additionally we may have a list of high level action routines pre-programmed into the Nanode, which we just want to invoke, on receipt of a certain command. Nano-tweets could be devised to be non-machine specific - a bit like the register based Firmata protocol. A simple command interpreter, written for a given microcontroller, would be all that was needed to handle nano-tweeting. Moving to a different micro would be simple.

For debugging purposes, it may be beneficial if these Nano-Tweets are semi-human readable - so the use of memorable characters or punctuation marks will be useful in achieving clarity of meaning.

Nano-tweets consisting of comma separated arguments can be transmitted down various kinds of network, wired, wireless or ethernet. A nano-tweet originated by a web connected Nanode, published up to Pachube could be echoed by a remote Nanode down it's local serial bus and used to control slave Nanodes connected to that bus.

Over the next few weeks, I need to define the nano-tweet protocol, and write a generic nano-tweet command interpreter, which can be applie dto many different applications.

Pachube - Social Networking for Nanodes?

For a few days I have had the Nanode prototypes running code and transferring data via Pachube.

Nanode uses the Pachube API with simple CSV data, so that any message or command packet which can be coded into a few bytes of CSV can be broadcast from the publishing Nanode to many subscribing Nanodes. This is effectively Tweeting for low cost, resource limited microcontrollers.

A Nanode, fitted with sensors can send a message out through Pachube, and expect its subscribers (followers?) to receive and act upon it within 5 to 10 seconds.

In the same way that Twitter is not for the verbose - Nanode communications need to be short and to the point. About 5 bytes and a checksum is optimum. Those bytes can contain sending address, destination address and command bytes. Could a micro-tweet be social networking for microcontrollers, and central to the Internet of Things?

More Applications on the Nanode - RGB LED lamp

Today I have been sorting out some application code for the Pachube Hackathon, and have got a simple RGB LED lamp to be controlled from one Nanode instructed from another Nanode via Pachube. I see the passing of data from one Nanode to another via Pachube as a fundamental application, and today's tests proved what it can do, and some of its limitations.

As you may know, Pachube can handle comma separated variables (CSV) as one of its low level data exchange formats in its API. Simple, resource limited microcontrollers can readily produce CSV data using print statements and manipulate the data within them using string functions and string ennumeration such as the atoi (ASCII to Integer) function.


First some background. Last summer, I had the task of designing a test harness interface for a light-box I was building at work. Conveniently I was controlling the ultra-bright white LEDs in the light box with an Arduino Nano, so it was a useful exercise to come up with a simple serial protocol and command interpreter, written for the Arduino which could be used on other projects.


I wanted a semi-human readable format, so commands would start with an alphabetic character to make them easy to remember, followed by a short series of numerical parameters. For example, to control the brightness of the lamps you would use B (for brightness) followed by the value desired: B,100 would set the brightness to 100, from a maximum of 255. It was then and easy extension to modify thes commands to include more parameters - for example a RGB LED lamp might have the command L,55,130,75 - L for LEDs, and 55,130 and 75 being the valuse for the R,G and B PWM channels.


Having stumbled on this simple serial command method, it occurred to me that it could be passed down any serial communication channel, but more excitingly, Pachube could pass this command data by way of one of its feeds from one web connected node to another, and thus the project which was to become the Nanode was born.


As stated above, I use a very simple serial protocol, and have two terminal windows open, one for the Publisher (Putter) and the other for the Subscriber (Getter). Typing r128 in the Putter window, sends a command up to Pachube, and shortly afterwards the command appears in the Getter window and the red led changes to mid brightness.


A concatenated commamd of l, 255,0,255 is interpreted as l for lamp, and 255,0,255 turns red and blue full on and green off - resulting in a nice glowing mauve.


In terms of overall command latency, i.e. the time taken from entering the command to the Nanode at the far end acting upon it the mean time is about 5 or 6 seconds. Once the Publishing Nanode has set the post to Pachube, the lamp controlling Nanode responds in about 3 seconds. It's not lightening quick, but some control tasks, such as central heating or remote appliance switching don't need to be lightning fast. Fast enough to control relays and actuators.


The sample code for the Pachube Putter and Getter is available from my Thingiverse site.

Preparing for Posting

Having rushed the first pair of Nanodes through on Wednesday and proved that they work together, I have been putting some further documentation on the London Hackspace Wiki page.

I'm a very infrequent visitor to the Hackspace, now living and working some distance from central London, and so I have offered the Hackspace "first bite" at the Nanode, as an open source design which will benefit their members, allow them to develop new applications given a boost of very low cost hardware. There will be a special "Hackspace" branded board, bearing the distinctive Hackspace logo and a construction and use workshop session planned to coincide with the arrival of the first batch of Nanode boards bearing the Hackspace Logo.

The new "Hackspace" Nanode features one or two corrections and updates over the first prototypes.

It has an easy to connect 4 way screw terminal block on the left to connect 12V power, ground and the wired local network. Boards can be connected together easily with 4 way telephone cable on a bus that supplies both communications and power for the applications.

The reset switch is now either a vertical or horizontal type and located at the edge of the board for easy accessability when a shield is fitted. Likewise for the LED, now on the board edge.

The biggest upgrade is to include provision for Virtual USB or Vusb. This is a USB transceiver which runs in firmware on the ATmega328, and means that the Nanode can be programmed and communicate with a PC without having the need of the FTDI cable. I have implemented it the same as the Metaboard, thus making it compatible with their programming software drivers which can be installed as part of the Arduino programming environment (IDE).

The first of the Hackspace Boards will be available in early May - if all goes to plan.

Meanwhile, on the first 10 samples, I have been busy preparing kits of parts for some Beta testers of the Nanode. Hopefully these boards will be shipped this weekend. These first boards will go to friends and associates who have assisted with the project, and best placed to do something special with the newborn Nanodes.

Two will go to my friends at Openenergymonitor, a further two to Andrew Lindsay who wrote the improved ENC28J60 Ethernet library for the Arduino, two to John Crouchley of Nottinghack who assisted me with the Pachube Getter code, and two for Stephen Blomley and Samuel Carlisle - members of the London Hackspace who wish to take it on as a collaborative project. That just leaves two for me, which I hope to demonstrate at the end of next week at the Pachube Internet of Things 24 hour Hackathon. Just 166 hours off......

I have done some costing of the Nanode, and by choosing Cool Components, Rapid Electronics and Spirit Electronics for the PCBs its possible to build a batch of 10 Nanodes for £18 each (and that includes VAT and shipping). This low cost should appeal to Hackspaces, Colleges and amateur enthusiasts alike.

I have also adopted Thingiverse as a repository for all the build and construction files for the Nanode. As it is a work in progress, there are likely be a number of changes in the next few weeks. Remember to check for regular updates. Already there have been a couple of corrections around the ethernet magjack connector and the power supply connection.

So now its back to kitting, three 10 resistors, check, four 51 ohm resistors, check and so on......

Applications for the Nanode

Having now built up the first pair of Nanode boards it's time to test them out and then start to develop applications.

The first thing on the list is to test the basic ethernet connection, and ensure that the boards can communcate with Pachube, which I am using as a brokerage service to broker messages and data between Nanodes.
As described in a prevous post, one Nanode will publish data up to a Pachube feed, and the other Nanode will subscribe to that feed at regular intervals, and print out the data to the serial port.
Here are the two boards each connected to a network port. The orange and brown wires between the boards is so that they can share the 5V power from the FTDI cable.

The upper board is the Publisher (Putter) and the lower board is the Subscriber (Getter). Every few seconds the Putter sends a new packet of data up to Pachube feed 8729, and at regular intervals the Getter subscribes to this feed to retrieve the data. In this case the data is a simple comma separated list of 6 arguments, which could be six readings from the ADCs on the Putter device, or a numerical command to which the Getter will respond.

Nanode 5 - Just Make It!

Nanode is a very low cost internet connected microcontroller board - compatible with the Arduino programming environment. It allows applications for internet remote monitoring and control to be developed on a familiar low cost platform, such as web servers and clients or for data exchange and control using services such as Pachube.

You can keep updated on the Nanode Project at the official website and also on the Hackerspaces Wiki.

The EagleCAD schematic and board file have been uploaded to my Thingiverse account. Here's how to build a Nanode - takes about 90 minutes.

Follow the Pictorial Guide on the London Hackspace Wiki for full instruction of the Build Sequence.

Nanode - It's a Bit Small Isn't It?

Here's the first of the prototype Nanodes built up, tested and working. The Nanode can be used with a variety of Arduino shields, but you may have to use extended stackable headers like these from Cool Components to give extra clearance between the shield and the Magjack. Using the local serial bus, it is possible to connect Nanodes together using 4 way telephone cable in a Master/Slave Network. It is likely that the Master device will be the one with the internet connection, and the slaves are used for specialist tasks such as pulse counting, electricity monitoring, controlling relays, measuring temperatures etc. In this case, you might wish to create a simple user interface on the Master device, possibly by fitting a display, such as the NuElectronics Nokia 3310 shield as shown below.

Nanode - Just Make It!

Pachube Internet of Things Hackathon

Just 9 days to go until Pachube hosts the first global Internet of Things Hackathon - a 24 hour event commencing in London and with sister events happening in several different countries.


In preparation for the event, to provide suitable web connected microcontroller hardware - I am putting together a small batch of Nanodes - a low cost target board designed for Internet of Things sensor applications and built to be compatible with Arduino technology.

For under £20, the Nanode offers a platform to develop intelligent sensor network node applications, capable of communicating via the Internet and Pachube or locally with other nodes on a low cost wired serial network. It can act as a web server, a web client or communicate with other web connected Nanodes using a publisher/subscriber messaging protocol.

Nanodes can also be connected together using a simple "multidrop" serial bus - made from low cost telephone extension cable. This carries power and data and allows Nanodes to be distributed around the home for tasks such as home heating control, home automation and energy (electricity and gas) monitoring.

Slave Nanodes can be cheaper still, by not fitting the ethernet components, yet still communicate with a master device connected to the internet.


Last summer, a pair of early prototype Nanodes successfully communicated with each other using Pachube as a publisher/subscriber service for short messages. A message left on the Pachube feed by one Nanode, would be picked up by a second Nanode which subscribed to that feed, decoded and used to perform some local action - such as switching a relay or changing colour on a RGB LED lamp.

For the example of the RGB LED, the publisher would send a short message consisting of comma separated arguments to Pachube b,1,255,255,255 This would be interpreted by the subscribing Nanode as a command to set the brightness (b) of the red, green and blue PWM channels of the LED (number 1) to full brightness (255) resulting in a white colour.


The publishing Nanode might have a temperature sensor connected to one of its analogue inputs, and change the arguments of the brightness command according to the temperature. Any Nanode subscribing to this feed, and equipped with the RGB LED would change the colour space accordingly in response to temperature.


This is a trivial example of how two Nanodes can communicate via Pachube. The publisher pushes the message, with no regard to whether it is received or acted upon. It might be possible to use a second Pachube feed as a "back-channel" to allow the publisher to be informed if the message has been received and acted upon.


At the Hackathon it is hoped that we have 5 pairs of Nanodes distributed around the country at various sister events - Nottingham Hackspace, OpenEnergyMonitor.org, North Wales, London Hackspace, Thatcham and at Pachube's own event.

Anyone with an Arduino and NuElectronics Ethernet Shield, could participate with nearly the same firmware. Following that, the intention is to make a batch of 100 boards and offer them at discount to interested parties. Bare boards will be offered at £5, and complete kits for under £20.

Pubbers & Subbers, Putters & Getters, Movers & Shakers - and Purple Hearts!

Sometimes the best made plans fall apart - due to circumstances beyond one's control. As a result of missing the postman at 8:13 this morning, my component order has gone back to the Royal Mail depot - and not retrievable until 7am on Monday morning - doh. Time to get a louder doorbell!

That rather put a kybosh on any new hardware developments this weekend. Instead, I thought I'd dust down some of the hardware I developed for the prototype ethernet node back in August last year and get re-aquainted with firmware which allows it to communicate via Pachube.

The first Arduino/Ethernet node was built on breadboard from 3 ICs (Atmega328, ENC28J60 and 74HC125) and about 35 other components. With a little care, the design will fit on a single standard, 63 strip breadboard, and cost about £12 in components to make. The Nanode is just a compact PCB version of the original prototype, designed with through hole components to make it easy to build at home.

Firstly, I thought I'd look back over the simple Publisher/Subscriber code I wrote for the prototype Nanodes about 8 months ago and have a go at getting the breadboard ethernet hardware running again - see above.

The strategy is based on the simple model that one ethernet connected device publishes a string of data to a Pachube feed, and that multiple nodes can subscribe to that feed and make use of the data.

The simplest Pachube feed is a comma separated array of values (CSV), so the publishing device - the "Putter" has to put out a CSV string of arguments, and the subscribing device, the "Getter" has to be able to subscribe to the given Pachube feed and get the CSV data into a form where it can do something with it.

I have dusted down the "Etherduino" breadboarded ethernet connected Arduino ( see August 2010 posts for details) - and this is acting as my "Getter". A standard Arduino and ethernet shield is acting as the "Putter".

The first test is to ensure that a simple message of say 6 comma separated arguments can be passed seemlessly from putter to getter. So far, so good - my getter is printing out the serial CSV string to my monitoring serial port every few seconds. Now to come up with an interesting demonstration application which involves some moving and shaking.

Back at Homecamp in April 2009, I showed a very simple use of a radio control servo with a coffee-stirrer glued to the servo arm, which was used as a large scale analogue meter. The Arduino can drive the arm to any angle from 0-180 degrees, and use the coffee-stirrer pointer to point to any chosen value on an A4 sized graphic. The great thing about servos is that they buzz when they move, and this attracts one's attention to the fact that something is changing.

Another easy hack is the use of low cost LED lamps to make colour changing "ambient orbs" to visualise a physical parameter - such as temperature or electricty consumption. A recent sale at Homebase and I bought 4 lamps for £10, including Heart, Orb, Cube and Star. From chilly blue to toasty red orange, and optimum green when the room temeperature is at its best.

A combination of the servo and RGB LED "ambient orbs" might be a good set of visual demos for the forthcoming Pachube Hackathon.

Nanode - A Net Applications Node

Nanode - a £20 Network Applications Node for remote sensing projects.

Having worked with Arduinos for a couple of years, I was keen to extend the functionality and scope of the basic Arduino to include the ability to be networked with other Arduinos or devices via the internet or a local serial network - as the communication to the Arduino is fundamentally serial.
The opportunity came with the low cost NuElectronics Ethernet Shield, which provided an ENC28J60 ethernet controller and a Magjack for about £12, however by the time you had added an Arduino (and 20% VAT), the cost was approaching £40. The simplicity of the hardware was such that I reckonned that there must be a much cheaper way of getting internet connectivity - and thus the Nanode was conceived.

Combining an Arduino microcontroller and ethernet controller onto a single small board for developing networked sensor applications at minimal cost seemed an attractive proposition reducing the cost of net connectivity for microcontrollers by a factor of 2 - to an affordable £20!
The Nanode takes the standard ATmega328 microcontroller - as used in all the standard Arduinos, and combines it on a single board with an ENC28J60 ethernet controller and Magjack.

This was not the first time this had been done, Tuxgraphics produced the first one about 5 years ago as detailed in this article, and there was a very capable design on Instructables a couple of years ago. Indeed, almost all of the firmware for the ENC28J60/ATmega combination is derived from the original Tuxgraphics code.

So Nanode is not new, it owes its heritage to at least two previous designs, but it does introduce some new features which I hope will bring it more into the Arduino playground. Unlike previous designs it presents its I/O in a form which is compatible with Arduino shields, but also enhances the I/O capability with additional connectors - making the I/O more accessible when a shield is fitted and allows the device to be plugged directly into a breadboard and still access all of the power and I/O.

So after the initial idea was hatched, I had to make a prototype. I'd had a bit of prior experience breadboarding ethernet, so last August I combined the Microchip ENC28J60 ethernet controller and the ATmega328 and 74HC125 tristate buffer on a breadboard to prove the design. The combination of the 3 ICs and the Magjack on its breadboard friendly breakout board (from Cool Components) was a neat fit on the standard size breadboard. Cool Components source most of the key components, allowing the design to be built on a breadboard for about £12. A later post will describe the breadboard construction in detail - for those brave enough to follow this route.

So the Nanode, provides ethernet connectivity to what is essentially a standard Arduino and allows access to most of the original I/O lines for the control and sensor applications. To summarise you have 6 analogue inputs, 8 digital I/O lines and a serial port remaining after driving the ethernet controller. With this you can sense analogue variables such as temperature, pressure or energy consumption such as electricity or gas, and have the ability to control relays, displays or actuators using the digital I/O. The Nanode takes the serial interconnection one stage further and using some of the spare 74HC125 buffers implements a "multidrop" serial network - allowing Nanodes to be connected together on a local serial network, which provides communications and power.

Having built the first one up on breadboard, as a minimalist proof of concept, I got it working to the point where I could send messages or control packets to another network connected Arduino and NuElectronics Ethernet shield, using Pachube to transfer data between the nodes. Then I got distracted by other things and the "Etherduino" - the early construct name for the Nanode, got put to one side for 6 months.
It was on hearing that Pachube are hosting an Internet of Things Hackathon in London on April 8th/9th which encouraged me to revisit the design with the aim of having it ready for the Hackathon. The breadboard ethernet Arduino is now Nanode - a Network Applications Node. (Or Networked Arduino Node - for those in the Arduino camp).

Timing of the Hackathon was perfect, allowing me 2 weeks to finish my design and get some boards made. I also had wanted for some months, a general purpose DIY Arduino compatible board, which could be made more cheaply than commercial units. With the features of more friendlier I/O connections and had the means to be networked to other nodes on a serial bus, the Nanode seemed the ideal entry point into Net Connectivity for under £20.

Above: First Prototype Nanode Runs Pachube Client Code. Blue LED shows Ethernet data activty.

This new board was the opportunity to address some of the points on my wish list. There were several design points which I wanted to take into consideration and resolve:

1. Must be easy to build by anyone who can solder - so 2 layer PCB design (EagleCAD) using conventional and readily available through hole components. Board is 72.4mm 58.4mm (2.85" x 2.3") - marginally bigger than Arduino, to account for additional I/O connectors.

2. Low Cost - hence the use of the Microchip ENC28J60 ethernet controller.

3. Compatible with standard Arduino shields - matching connector pitch - warts and all!

4. More flexible I/O arrangement. I have fitted additional connectors on 0.1" pitch which allow compatibility with breadboards and stripboard. All of the standard I/O pins and power from the ATmega328 are available along one edge of the pcb, which simplifies plugging this board into breadboard or 0.1" stripboard. They also allow the I/O headers to be accessed even with a shield fitted. An extra connector in the top left corner brings up the analogue inputs and 5V power - so all of the ATmega I/O and power can be accessed from a single edge of the board with a SIL header pins - handy for one sided connection of everything to a breadboard.

5. Spare tristate buffers in the 74HCT125 allows several Nanodes to be interconnected on a serial bus, controlled by a master unit which is connected to the internet. This feature was developed last August and found that we could get 9600baud serial data down 300m of cable. Simple 4 way telephone cable can be used to string these nodes together.

6. With the ENC28J60 and Magjack omitted, the device becomes a simple serial node - at £5 lower cost.

7. Extra I/O connector allows direct plug-in of R/C servo or Moderndevices LCD display on 3 wire bus.

8. Serial accessed via FTDI cable or similar USB to Serial adaptor.

9. Tall headers will be used to increase the clearance between the shield and the Magjack connector - which is 3mm taller than the USB socket usually found on the Arduino.

10. Programmed through the Arduino IDE (or AVTdude) with access to the standard AVRISP 6 pin header.



BOM (Most specialist items from Cool Components in South London)

• ATMega328P-PU - DIP version Cool Components £2.81


• Microchip ENC28J60-I/SP - DIP version Cool Components £1.99


• 74AHC125D tristate quad buffer


• 3mm LED


• 1N4004 Diode


• 7805 Regulator


• 78L33 Regulator


• 16 MHz HC49-4H Crystal


• 25 MHz HC49-4H Crystal


• 51R 0.25W 1% resistor x 4


• 270R 0.25W 5% resistor x 5


• 2K 0.25W 1% resistor x 1


• 330R 0.25W 1% resistor x 1


• 10K 0.25W 5% resistor x 3


• Ferrite inductor


• 18pF ceramic cap x 4


• 100nF ceramic cap x 4


• 10uF 16V electrolytic cap x 3


• 28 pin 0.3" DIL socket x 2


• RJ45 MagJack £1.99 CoolComponents recommended


• 36 pin 0.1" SIL header x2


• Small Tact switch Cool Components £0.28


• ATmega Nanode PCB - that's me!
  

I have sent off to have batch of 10 boards made up in time for the Hackathon. If anyone would like the EagleCAD files, or purchase a pcb - please drop me a comment.

The Big Dig - Water Main Replacement

Today, just 3 days before Christmas, and with snow on the ground, Sutton Water Company are busy replacing the water main to my property plus that of my 3 neighbours.

The houses were built in 1905, and at that time it was standard practice to share a water connection between houses - especially if they were pairs of semi-detached properties. So it came to pass that four properties were all connected to the one section of lead pipe - and after 105 years in the ground, that lead pipe was leaking like a seive.

Back in July, during leakage testing, an excessive flow was detected on our shared main, and since the old lead main is no longer accessible as it passes under driveways, patios and modern extensions, the only effective measure is to replace the shared main with a separate modern plastic main and meter for each property.

The crew from the water company turned up at 8am on Tuesday and started to dig a couple of trenches, one near the pavement and one close to where the main would enter the property. Using a pneumatic mole, a duct was bored through the soft clay soil to connect the two trenches - a distance of some 15 metres. However because of very cold conditions yesterday, the Mole froze up in the bore, and had to be retrieved by digging a third hole, just 2m short of the pavement excavation. With one bore in place the blue water pipe was threaded through and the Mole set up again to put a second bore through for my neighbour's pipe.

Today the gang have got extra help from another 3 crews, judging by the 4 large vans in the street. The main runs down the road on the opposite side of the street, and so 4 separate access pits will have to be dug on each side of the street, and individual plastic connections tee'd into the original main. A lot of digging in temperatures that are barely above freezing.


Thursday morning, and Day 3 of the Big Dig. Two gangs from Clancy Docwra accompanied by another private contractor who's turned up with another compressor. About 11:15am, the water company arrived to assist with the pipe connections. It should not go unmentioned that replacing the water mains to 4 adjacent properties is no small undertaking, and made particularly gruelling in such bitterly cold weather. Whilst to the homeowner, the pipe from the pavement to their kitchen might at first appear a major task, this is actually only one small part of the job, and the connections to the water main on the opposite side of the street each with two access trenches is by far the bulk of the work.

Inside the house, in the kitchen extension, the dishwasher was removed to gain access, and a 32mm hole drilled downwards and outwards through the kitchen wall, such that the drill emerged in the small connection pit outside the kitchen window. This is a busy area in the kitchen with heating pipes, hot and cold water pipes and cables all laid in a ductspace that runs around the external wall of the kitchen. It's now a case of connecting up to the incoming main to ensure that the kitchen, bathroom and toilet, and the rising main to the tank in the loft are all connected to the new supply. The plumbing in this house dates back in various phases back to 1905, and much of it is no longer accessible, having been laid under the concrete floor of the kitchen and the 1950's bathroom extension. Once everything is working properly from the new main and no leaks detected, the old lead and copper connection can be isolated and left in the ground as a bit of ancient history.

I must say I am very impressed with the teams that have worked outside in miserable conditions, and temperatures barely above freezing. Sutton and East Surrey Water who did the work within the boundary of the properties and Clancy Docwra who undertook the excavations and connections to the main in the street. Whilst £900 is quite a large sum to find just before Christmas for replacing a main, when you look at the effort involved with up to 6 people on site for 3 days, it is clear that it is justified when you see the effort and comittment involved.

Smarter Heating - Ideas for Low Cost Zoning and Weather Compensation

In the last post I began do describe some of the desirable features of an upgraded heating controller. Here's a recap:

1. Smart Relay unit retrofits in place of existing time controller - no changes to mains wiring
2. Uses a hand held combined display and programmer/thermostat connected via wireless link

The hand held display/thermostat allow the thermostat to be located in whichever room you spend most of your time in. In most homes this would be the living room for the evenings, but if you work from home, you may choose to have the thermostat in your work room or home-office during the day. Portability means flexability. If you are wanting to reduce fuel bills by partial heating of a property, best that you focus the heat and the temperature control into the room that you are most likely to be occupying, and let the thermostatic radiator valves prevent excessive temperature in other rooms.

Regardless of where you choose to site your thermostat it will communicate via a wireless link to the relay unit which controls the central heating and hot water circuits. As a display unit it will offer you real time display of your energy usage (similar to an electricity monitor) and also an efficiency indicator and an indication of mean outside temperature.

Low Cost Zone Heating.

Back around 2005, I discovered that you could use a small amount of heat applied to the wax cartridge of a thermostatic radiator valve, which would cause the wax to expand and shut off the valve. I experimented first with power resistors and then power transistors and found that approximately 1W of dissipated power would completely close a thermostatic valve in 15 to 20 minutes. It would therefore be possible to have a controllable resistance fitted to each radiator's thermostatic valve and shut down individual radiators when they were not needed. It would only take about 10W of electrical power to shut off 8 radiators and this could be done as a low voltage (24V) signal distributed along cable, such as telephone extension leads. When the boiler is not running, the valve control resistors would not have to be energised, allowing further economy.

For this to work well, the controller would have to pre-anticipate when it was due to turn the boiler on, and open the valves some minutes in advance. It would make sense to use a long boiler on time and off-time, so that the latency of opening the valves is insignificant compared to the boiler on times. A longer boiler on-time could be achieved by turning down the boiler water temperature, so that it heats more slowly. This would also have the benefit that the return water would be close to 50C so that the boiler works in condensing mode most of the time. Additionally by increasing the hysteresis from say 0.2 to 0.4C would double the boiler on time. In an ideal world, the boiler would run continuously at what ever kW output was needed to maintain the set temp, however this may be difficult to achieve with a 24kW boiler in a property that really only needs a 12kW unit.

The boiler output temperature will be a function of circulation pump speed. By dropping the circulation pump to the lowest speed, the boiler will lower its output accordingly. This can however be counter-productive, as some tests proved. A combination of low pump speed and low water temperature means that the radiator barely gives out enough heat to satisfy the room temperature demand of the thermostat, so the boiler runs for very extended periods at low power. Ironically this can lead to the use of more gas, than if it were allowed to run for say 30 minutes and then coast, until the lower hysteresis level of the thermostat.

Building on the above idea, another control strategy might be to have a fixed on period of say 30 minutes, allowing the temperature to rise, if necessary, above the upper hysteresis point and then turn the boiler off until the room temperature fallss below the lower hysteresis point. A small amount of temperature overshoot will not be noticed, and this strategy will lead to a decent length of on time and a longer off time.

Weather Compensation

This is usually performed with readings from an external temperature sensor, which allows the output of the boiler to be controlled in response to outside temperatures. For example, in cold weather, it might be desirable to bring the boiler on for longer if certain temperature conditions are required by a certain time. Similarly, in a property with high thermal mass, the boiler could be turned off earlier, for example in the late evening, if it is known that the night is milder and heat loss will be reduced.

With the Christmas break plus daily cold weather, I hope to code up some of these ideas on my Arduino mega based heating controller, and try them out.

Smarter Heating - Some Results

Previously I stated that for an older property, there was the heat required to warm the house up, plus the heat to maintain a given set point temperature. Over this weekend which has been bitterly cold I have had the opportunity to do some datalogging and put some figures on to this.

First, here's the warmup from nominal 17C to nominal 19C on Sunday morning. This took 4 hours and used 50kWh of gas. In each of the following plots the x-axis is the time in minutes.

At the same time the outside temperature was rising from about -4 to about -1C - but more importantly to the controller, was the difference between inside and outside temperature - the Delta temp. As you can see the delta temp was between 20 and 21.5 C for all of the warm up period.

By 10am the room had come up to temperature and the controller enters the second phase - main room temperature at a comfortable 19C +/_ 0.2C.













The next set of 3 plots shows the detail from 10am Sunday to 10am Monday. This was the coldest night so far with temperatures down to -9.3C! Note how the delta reaches a maximum of 29. In real terms this means that the heating has to work about 50% harder, than if delta is about 20 - and thus use a lot more gas.






Below is the plot of the room temperature, once the system had stabilised, holding the room at 19C +/- 0.2C. Each little sawtooth is the effect of the boiler coming on at 18.8C and heating the room up to 19.2C - this maintaining an average temperature of 19C.

The Icy Blast

Unusually cold weather this winter arriving earlier than expected has once again focussed the mind (well mine anyway) on the subject of efficient home heating.

The nights of 17th and 18th December were without doubt the coldest nights so far this winter with suburban Surrey temperatures dropping to -6C.

As I write this we are experiencing a second wave of Arctic winds bringing temperatures down well below zero, large flakes of snow settling on an already frozen ground. More chaos due on the roads and airports, just 3 weeks after the first blast of winter that caused widescale disruption to transport and infrastructure.

In Britain we have the awkward situation that we do not get severe winters each year, so little is done in advance to prepare us for wintery weather. Much of our older housing stock was built with very poor insulation, and the time has come to upgrade the older houses with measures such as draught-proofing, adequate loft insulation, double glazing, more efficient condensing gas boilers and ultimately whole house external insulation.

External Insulation

Now whilst it may be possible to reduce heating gas consumption by 25%, in an older property with no cavity with a suitable thickness of external insulation, the cost of this upgrade will run to appproaching £10,000. With a current gas consumption of just £500 per year, a saving of £125 per year and with an 80 year payback time make the expense of external insulation seem barely worthwhile. However, the price of gas has trebled in the last decade, and if it continues to follow this trend, or just double with each decade, it brings the payback to a more realistic 35 years. It is questionable whether one would benefit from that level of expenditure, and there may be cheaper and more cost effective means to achieve the same effect.

A Cheaper Option

Over the last few weeks of wintery weather, my day to day gas consumption has been around 110kWh, costing around £3.50 per day. Now suppose that across the heating season, you could achieve a 10% reduction in gas usage through a smarter control system, well that would save about £50 on the annual bill, or possibly up to £100 for some larger users. It could paypack within 2 years.

The average central heating controller is a very simple timeswitch, used in conjunction with an often poorly sited thermostat. It is a technology which has hardly changed for 30 years, and is certainly not best suited to today's lifestyle. With modern microcontrollers and better temperature sensing it should be possible to gain overall better control of the heating system and a higher degree of comfort for lower gas consumption. This was the motivation behind the Navitrino Heating Controller.

The S-Plan wiring schematic for central heating uses two motorised valves connected in series with the room stat and tank stat respectively. When the valves have reached their closed position the circulation pump and boiler are energised.

Many houses have this simple heating plan. The time controller often uses an industry standard backplate, making upgrading the controller relatively simple.

Modelling the System

Firstly it is important to gain a knowledge of the existing heating characteristics of the house. These will depend on type of construction, outside temperature, prevailing wind, and whether intercommunicating doors are left open or closed. For example, one night last week, the boiler stayed on for an unnecessary two and a half hours, solely because the door between the living room and the hall had been left ajar. As my boiler is generally running on average for one hour in every three, that extra 2.5 hours represented a significant extra gas usage. However, for a given outside temperature, a certain amount of heat will be required to maintain the principal rooms at the comfort temperature.

Older houses, without cavity walls need more heat than better insulated ones. You have 2 layers of brick to warm up before the house feels warm, and considerably more heatloss through the solid walls. Older houses were often fitted with open chimneys and sash windows and these too lead to extra draughts and heat losses. For any given house, there will be a certain amount of heat needed to bring it up to temperature, and then another rate of heating to maintain constant temperature determined by the difference between external and internal temperatures. This difference between internal and external temperature may vary widely in cold weather, and it is not unusual for an older house to use twice as much heating fuel on a very cold day compared to a milder day just to maintain a constant room temperature.

The effects of weather can be fairly predictable, for example a cold day in 2010, may follow a very similar temperature pattern to a cold day in 2009, and a knowledge of past temperature profiles could be used to optimise the response of the heating controller to any particular day's weather. The temperature profile of a day could be characterised by just the maximum and minimum temperatures, the average temperature, or a series of readings taken at regular intervals throughout the day and night. The daytime temperature is also reasonably predictable, in that it will generally rise after sunrise and fall after dusk, and the rate of change of temperature lies between certain credible limits in terms of degrees change per hour. Knowing the rate and direction of outside temperature changes would allow a controller to predict where it needs to be in order to maintain comfortable conditions indoors, without burning gas unnecessarily.

A controller could be given a model of a typical winter's day, expressed in likely temperatures, chosen from a short list of typical types. There might only be only a dozen different day models required, to match the temperature profiles of every day between September and April. If these day models are characterised by average temperature, and sorted in order of descending and rising again temperatures, then if you have just experienced a day which matches model type 8, for example, the next day is most likely to be another 8, or a colder 7, or a warmer 9. The controller should be able to anticipate from night time temperatures, taken in the early hours of the morning, say 4am, what the following day is likely to be, and then take the necessary action to ensure that the interior of the house is kept comfortable. If say by 8am, the outside temperature has sufficiently warmed, then the controller may decide that it should be following a warmer profile.

Interfacing to existing systems.

In order to achieve general acceptability, a new heating controller should be easily retro-fitted to an existing system, without the needs for an electrician, plumber or heating engineer - it should be self-installable "Plug & Play" and utilise existing wiring, pumps and valves.

Fortunately, most standard timer based central heating controllers use a common wiring backplate, which allows one controller to be swapped out with a new one or indeed one from a different manufacturer.

This backplate usually has 6 connections, including live and neutral supply connections, and separate outputs for selecting central heating on and hot water on. If heating is demanded because we are in a heating on period, a relay switches live to the heating switched live, and depending on whether the thermostat is closed (demand) this live then energises the heating motorised valve. When this valve has fully opened, a microswitch is activated which then energises the circulation pump and the boiler. Similarly, if hot water is demanded, subject to the position of the tank-stat, the hot water motorised valve is closed and the boiler and pump energised.

So the existing controller could be replaced quite simply with a microcontroller and a couple of mains SPDT relays. Often the central heating programmer is fitted in the most awkward of positions, such as the airing cupboard, where the pump and valves and cylinder are located. This is generally inconvenient and a better solution would be to have a combined programmer and thermostat, which is battery powered and portable and which can be placed within the room where the greatest degree of comfort is needed – such as the living room.

Using wireless technology, this control unit could readily communicate with the boiler control unit to schedule the heating and hot water as required, whilst additionally acting as a display device for showing heating trends, gas usage and offering functions such as hot water and heating boost. This central display would communicate with room temperature and outside temperature sensors, and possibly wireless controlled thermostatic radiator valves, to make a fully integrated zone heating control system.

Some of the work done by Jean-Claude Wippler of JeeLabs on his JeeNode might be of direct relevance such as the JeeLabs RoomNode which was designed with the aim of measuring temperature, humidity, light levels and occupancy via PIR using a simple wireless sensor. Such a sensor network using low cost wireless technology which could be extended at a later date to include other compatible sensors and actuators.

Homecamp3, Heating and Disruptive Technologies

Monday 13th December was Homecamp3, held at the Centre for Creative Collaboration, in Acton Road, near to King's Cross station.

For a Monday afternoon/evening event it was fairly well attended with about 40 to 50 present. Many of these were Homecamp regulars, plus a few new faces.

The evening consisted of several interesting presentations on energy, cleantech and interconnectivity, with plenty of beer, wine and pizza which gave the event an informal, social atmosphere.

After James Governor's excellent opening address, first up was Gavin Stark founder of AMEE who described how AMEE were now codifying nearly a million different variables around the world.

Andy Piper, of IBM, Hursley, spoke about MQTT as a means of achieving interconnectivity between physical computing devices, and quoted some examples developed by Andy Stanford Clark, who unfortunately could not attend.

Usman Haque and Ben Pirt of Pachube presented an update on the new features included in the recently released new Pachube API.

Georgina Voss of Tinker London described the first phase Homesense Project - making Arduino technology available to real families and households with the intention of incubating new projects in home energy efficiency and lifestyle change.

Unfortunately, the 8pm deadline for closure of the venue came around all too quickly, and so we quickly re-charged on pizza and retired to the local Queen's Head pub. Regrettably there was not enough time to hear all of the presentations and get around to talking to all the attendees, hopefully Homecamp4 will be a full day event, and less pressurised for time.

Thanks must go to Mike Beardmore @mikethebee and his wife, who organised the venue and were perfect hosts. Additionally to James Governor's firms Redmonk/Greenmonk who sponsored the pizza and drinks.

All in all it was an excellent evening, and just what was needed during these dark days in the run up to Christmas. Hopefully it will have sustained the momentum of the Homecamp movement and given attendees something to think about over the Christmas break.

One of the people I did get to chat to was Simon Daniels, CEO of Moixa Technology

Simon described his low voltage dc household power distribution system. The concept is based on the premise that more and more of our household energy consumption is low voltage dc needed for an ever increasing variety of low wattage electronic devices which fundamentally run on dc, such as consumer electronics and LED lighting. Low voltage dc can efficiently be distributed on a household scale using existing wiring, with surprisingly low cable losses. This eliminates the needs for lossy ac to dc adaptors, and produces a power system which is efficient and compatible with home scale renewable energy devices.

Simon describes how a small window sill mounted pV solar panel, could be installed to many properties, such as flats, where access to the roof is not available, and at a price of £1K to 3k making it more affordable than a full rooftop solar installation. The dc from the solar panel would recharge a lithium battery system and provide sufficient power for the dc distribution system. A small solar panel of perhaps 200W could provide sufficient power to offset between 5% and 15% of the domestic bill.

For this technology to gain momentum, the large manufacturers of electronic goods and appliances need to collaborate on standards for dc supply, cabling and standby switching. A generic dc cable, for example based on a USB cable but with an additional pair of high current contacts to supply the variable voltage dc power. A process similar to USB enumeration would allow the device or appliance to be recognised by a central power controller, and supplied with the correct voltage. The standby modes of many devices, such as microwave ovens, are particularly inefficient, as they need to use 50Hz transformers to provide small amounts of dc power to run the timer or clock functions. By adopting a hybrid system of a dc cable for standby mode and control and a conventional ac connection for high wattage loads, would minimise the standby load to a few tens of mW plus offer the possibility of dynamic demand control. A washing machine with a timed standby mode could be automatically scheduled to run during a time of low grid usage, or the washing heating cycle paused and restarted, on the event of a sudden large demand on the grid.

Moixa will be running field trials in the Spring.

The Moixa technology is an example of a range of disruptive technologies which will ultimately change the way in which we use and pay for energy. Industry analysts have coined the term "Electricity 2.0" to describe the outcome of these changes. When combined with other systems such as smart metering, demand based tarrifing and dynamic demand control of appliances, the package could add up to significant energy savings within the household. Every kWh of electricity saved in the home is 2kWh off the nation's gas bill and more importantly less CO2 and waste heat into the atmosphere.

By introducing an energy storage element into the grid, possibly in the form of wide scale roll-out of Moixa's dc battery system, will allow consumption to be time-shifted out of peak time, and greatly assist in load balancing. Improved load balancing will permit the wider use of intermittent generation technologies such as solar and windpower, plus reducing the wasteful start-stop cycling of conventional generation plant.

With the recent and persistent cold weather, the annual subject of home heating and fuel efficiency has once again come to mind. In the next post I will describe some recent musings.

Stay Warm.