Hello John! Gotta New Motor?

Not one but two new arrivals today! Having traded in a 2007 Subaru Forester, our driveway is now gleaming with German and Japanese technology.


Having just started a new job 30 miles away - I'm now doing 300 miles a week, which was about 60 litres of petrol in the Subaru Forester. Realising that was just not fuel efficient enough, to justify keeping it, it had to go.

So in one simple transaction it was swapped for a VW Golf TDi and a Nissan Micra - both of which achieve better than 50 mpg.

Whilst the Forester was a very comfortable car, and very low mileage, it certainly liked the taste of petrol. On the windy lanes of my cross-country route, it was returning at best 25mpg. Petrol is about £5.30 a gallon right now, so it was costing me almost £13 per day in fuel. So for reasons of economics, plus my desire to cut down on fossil fuel consumption, the Subaru had to go.

The Golf is a 105hp TDi with about 49,000 miles on the clock. When driven economically, it should return close to 50mpg. Around town, I have seen the mpg meter show better than 56mpg.

The bitter irony is that I have now started a job in renewables engineering, and I will have to expend an additional 1250 litres of diesel fuel solely on my daily commute. This is about 12,500kWh of fossil fuel energy, which is about the same in energy terms as my 15,000kWh annual gas heating consumption. Biodiesel is a possibility - it's certainly a little kinder on the planet, provide that it is made from waste vegetable oil - and not new oil crops - grown purely for biofuel use.

By way of comparison, a return flight to Hong Kong (in a 747-400) works out at about 850 litres of fuel per passenger, or about 73mpg per passenger!

I did consider (and try) the public transport option, but found it to be unworkable. I live a mile from the station, but my new company is 2 miles from their nearest station, so a folding bike would be a good idea. The journey involves 1 change (at East Croydon) a lengthy wait, and then catching the one train per hour to Crowborough. The journey takes at best 2 hours and costs £20 in fares - which in my book is wholly impractical - since I start work at 7:30am. By car, the journey time is a comfortable 50 minutes, door to door.

So I'm back in car-commuter mode, not great when we are striving for a more sustainable lifestyle - but there is a recession on, and we have to do what we can to make a living and pay the bills.

Update: Drove the Golf to work for the first time today. Once the engine has warmed up after the first 4 miles or so (and that appears to be critical), the mpg meter seldom went much below 53mpg. The route to work involves several hilly sections and winding back roads. It will cruise at 60mph on the level in sixth gear at 51.8mpg, rising to 53.5mpg if you keep the speed to around 50mph - that's good enough for me.

The fuel tank is 55 litres with a 7 litre reserve. The "reserve" lamp came on about 5 miles from work - so being early, I filled the tank up at the local garage, with 50.47litres. I'm rather hoping that I won't have to do that again until the end of next week. If it averages 50mpg, the 55 litre tank should be good for about 600 miles.

The InterWeb of Things

Yesterday evening I attended an event hosted by MinibarLondon. This was my first minibar meetup, but they are held every fourth Friday, and last night's was held at the Corbet Place Bar, which is part of the old Trumans brewery, on Commercial Street. The venue is a short walk from Liverpool Street Station, and not too far from Old Street Tube, which is a common destination for my evenings out in Shoreditch's rapidly evolving Silicon Roundabout district.

Minibar is a meeting place, forum and a platform to launch ideas for the new tech crowd. The evening was attended by about 270 people, and there was even a waiting list of some 40 others wishing to attend. The format consists of half a dozen speakers, who have 5 minutes to put forward a pitch, and a slide presentation of something they are involved with. There is then an open mike session for anyone else wanting to pitch something for 20 seconds. It's a great ideas platform and also a good way to keep up with what's going on in the tech community.

Last night's event organiser was Christian, who I have met previously at an Open Source Hardware conference. The topic of the night was the "Interweb of Things", exploring how devices and sensors can be easily put onto the web, so that they can interact with physical objects.

First up, was Adrian McEwen, with his Arduino based bubble blowing machine Bubblino. It was programmed to respond to the twitter feed, and anytime "minibarlondon" appeared it sent forth a stream of bubbles. Adrian's device was created from a hacked child's toy, and is very popular wherever it appears.

Next up was Georgina Voss from Tinker London. Tinker are local to Shoreditch and are heavily involved with all things Arduino, and most recently the new ethernet Bridge product for the CurrentCost energy monitor.

Other presentations from Paul Downey of Osmosoft (a fast moving Open Software company buried in the monster we know as BT) gave a presentation on OSHUG open source hardware user group, who have regular meet-us in London.

River Simple told us about the development of an open source hydrogen powered car - which in my book is pushing the open source model to the extremes of the envelope.

Another presentation from Make Magazine - who are also into the Arduino scene.

Next time I will try to remember the speakers, but I had had a few beers and the fast pace of presenters, and my unique ability to instantly forget names put me at something of a disadvantage.

By 9:30 the inside bar was very hot, so most people elected to sit outside at the extensive patio bar area. Patio Bar is a bit of an exaggeration - its more like some decking and pub tables out the back of the rather scruffy old brewery yard.

Thanks to Kjen who came along at the last moment and took the place of my "plus one", Katee Hui who pitched a really interesting 20 seconds on disrupting the energy market, Chris, Nick - who has an interest in some of my energy logging stuff and the guys from Osmosoft / OSHUG whom I have bumped into at other similar events.

Sensory Deprivation

The UK is heading for an energy crisis in which we become over reliant on imported natural gas for our home heating and power generation. Of the 27 EU countries, the UK has the largest gas consumption of close to 100 billion cubic metres (bcm) per year. By 2015 as a result of changes in the UK electricity generating mix is going to further increase the percentage share of gas used for generating, as coal and nuclear stations reach end of life. Our gas consumption is set to rise to 120 bcm. Unless the UK can maintain a secure supply of natural gas, from friendly nations, we are heading for an almighty energy crisis.

Currently about 35% of UK gas consumption is for domestic heating. Much of our housing stock offers such poor energy efficiency that we are literally throwing away billions in our gas bills every year. The new coalition government have been advised of this and are targeting the domestic sector to reduce their energy consumption by way of better energy efficiency in the home - such as improved insulation and more efficient boilers.

In the next 40 year time frame there will be co-ordinated effort to improve the energy efficiency of our housing stock. 60% of our homes were built before 1960 and have very poor efficiency. National programmes to roll out internal and external insulation will bring our homes up to a better standard. This will help maintain gas consumption at 2010 levels, and keep our national CO2 footprint to a minimum.

Part of the problem is that older UK homes leak heat like a seive. Solid brick walls and uninsulated lofts mean that we are using at least 3 times the energy than we need to. Clearly something has to be done to curb these energy losses.

First it is important to quantify the energy consumption and losses in the older property. As part of my personal effort, I have been monitoring gas usage in my home for nearly 10 years, and noting year on year improvements.

Part of the problem is to understand the energy usage and where the heat losses occur. For this I have been working on a temperature and energy monitoring system.

In the last couple of days, I have put together a simple Arduino temperature sensing application which sends readings up to Pachube for logging and graphing.

A mental block, last weekend prevented me from converting the readings from the thermistor temperature sensors to a true centigrade reading, but in the cool light of Friday morning, I revisited the code and got the thermistor linearisation code working.

The results can be seen at my Pachube feed - I'm looking at a couple of room temperatures, the temperature at two points of my hot water tank and the outside temperature.

The standard Arduino has 6 analogue sensing channels (the Nano has an additional two ADC channels). By using Dallas 1-wire temperature sensors connected to digital pins, a much larger network of temperature sensors is possible.

At the moment, I'm monitoring my hot water tank temperature - solely becase it shows a wide range of temperature swing, which is good for testing. It would also be beneficial to monitor the inlet and exit temperatures of my solar water heating panel and in the heating season, the boiler and woodstove temperatures. Each room of the house could be individually monitored including the loft, to give a complete picture of the thermal behaviour of the house

More Messaging

Below are some jottings and thoughts I wrote down on 13th July. Just about 5 weeks later (starting new job etc) - most of these ideas are coming to fruition. The idea of communicating between ethernet enabled microcontrollers using Pachube as a message broker is currently being pursued.

Getting small microcontroller systems to talk to the web is an area of increasing interest. With many homeowners now possessing "always-on" broadband routers, the task of getting home automation, sensing and security systems online has never been easier or cheaper.

In this interesting talk/slide show, "The House That Twitters", Andy Stanford-Clark, describes how he has arranged devices around his house to publish data using MQTT to a Really Small Message Broker (RSMB) and then make that data to other subscribing devices. As Andy invented and subsequently developed MQTT, it is fitting that he choses to use his own house as an example of what can be done. He also explained that once he had established the basic system, then new devices and applications could be added relatively easily without having to start from scratch each time.

My aspirations are somewhat different, and perhaps much cruder. My aim is to get stand-alone Arduinos to exchange data with each other using Pachube as the message broker.

With a little help from others, I now have analogue readings from my Arduino appearing as a Pachube feed. The next task is to retrieve the data from that feed using another Arduino and make use of it, for example display it on a local LCD, or have the second Arduino parse through the data, and make control decisions based on the numeric values of the data. Here Pachube would be acting solely as a message broker - receiving data from the first Arduino which is the publisher, and making it available to any other Arduino which wishes to subscribe to it. It is this Publisher/Subscriber relationship (PubSub) which is key to any message brokerage system.

For this to work, the subscribing Arduino(s) must have a means of accessing the raw csv data on Pachube, using the GET method. I'm still reading up on this and am yet to find an example which explains it in simple terms. I'm hoping to reach the point where the whole PubSub functionality is handled in underlying code, and all the Arduino user needs to do is read from or write to a suitably sized buffer.

Messaging between Arduinos, or other small micros, should be made as simple as texting your mates.

All you need is a feed number on Pachube to send the data to, and the subscribing Arduinos regularly look for updates. The subscribers might just display the data on an LCD for example, or use the various fields for specific control purposes. One field might be a bit pattern that you want to send to an output port and control a bunch of relays, another field might be the unique address of a specific Arduino that you want to send a command to. If the message length was kept to 128 bytes then this should be small enough to allow easy manipulation on the Arduino, be compatible with Twitter, and provide sufficient scope for several fields to reflect analogue values, bit maps for port setting and various other control structures.

Hardware Thoughts.

Hardware needs to be cheap and cheerful with much of the elegance of the application provided in the firmware.

What is needed in terms of hardware to give a microcontroller access to web connectivity? What are the opportunities for a low cost, open source hardware solution?

First what is needed is a network interface controller - a NIC chip. Microchip offer the low cost ENC28J60 which is available for about £2. With a RJ45 jack, with integrated magnetics - a mag-jack, a 25MHz crystal and a few other components you can put together a simple 10Mbit ethernet controller.

Alternatively, if you are working with the popular Arduino microcontroller, then you can buy a ready built and tested ethernet shield which uses the ENC28J60, for as little as £12.50. This little board comes with example sketches, and others have developed and improved upon these to make connection to Twitter and Pachube relatively straight forward.

Now one of the problems of ethernet and web access is the hosting of the TCP/IP stack, which tends to put a large burden on the resource limited microcontroller, in terms of RAM and program code size. This leaves little available for the application - which may be a problem. Indeed the ethernet shield with the ENC28J60 is limited in application when compared to the Wiznet W5100 based "Official" Ethernet Shield- but that costs twice the price!

However with the availability of the 32K ATmega328 microcontroller, now fitted to most new Arduinos, the problem is somewhat reduced.

Other options include a combination of ATmega328 and ENC28J60 on one simple pcb which have recently appeared - such as this one from Tuxgraphics who also provide a handy tutorial on their cut down TCP/IP stack specifically for AT mega microcontrollers. Tuxgraphics have been developing AVR/ENC28J60 applications for several years, and are a useful source of information - should you wish to follow this particular hardware combination.

Message in a Bottle

The Smart Heating Controller took a step further today with the addition of an ethernet shield from NuElectronics. I bought this back in 2008 but it took some aspiration and some updated code from Andrew Lindsay in order to get it to work.

The Arduino measures the temperature from six analogue thermistor channels and then PUTs them up to Pachube in a CSV format - but you can also browse them locally or remotely at the IP address of your router.

The readings are updated to the net about every 10 seconds, whilst the LCD is refreshed every second. The LCD shows the time, the 6 temperature readings and whether the circulation pump is on or off.

The rather scruffy breadboard below the Arduino terminates the cables to the thermistors - which are about 10m away. It also holds the potentiometer for setting the set-point temperature and the 433MHz wireless module for turning the boiler on and off.

I'm still trying to get the device to work reliably with Pachube. It showed signs of promise this afternoon, briefly PUTting data up to a Pachube feed, but when I integrated my LCD code, I have clearly introduced a bug to the overall program. After some serious back-tracking its now working correctly on Pachube Feed 8729

Personally, I've found the whole web client business a bit of a ball-ache, possibly because I'm a C newbie plus the fact that I'm unfamiliar with the methods involved. There has to be an easier method to get small low cost microcontroller systems to send messages to one another.

I've been thinking about how microcontrollers could communicate with one another efficiently, with low resource overhead, across a variety of communications links - ethernet/internet, wired and wireless networks.

I recently came across the MQTT messaging system developed by Andy Stanford-Clark and his team at IBM Labs, Hursley. Andy has demonstrated MQTT in his automated home and has a number of interesting applications - as described in this video.

Nick O'Leary, also at IBM, has developed a MQTT Client for the Arduino

To make use of MQTT you need to run a message broker application such as Really Small Message Broker RSMB - and in this document, Mark E. Taylor describes the end to end implementation of a network connected temperture sensor, using an Arduino with the RSMB running on a Linux machine.

RSMB is a proprietary IBM product, but there is at least one open source alternative - such as mosquitto by Roger Light.

Hopefully it will achieve momentum amongst the hacking community as an efficient way of messaging between low cost micros and other applications including Twitter etc.

The Heat is On!

Here's a challenge. Teach yourself C in 21 days!

The book on the left runs to 700 pages. I borrowed it 10 years ago from a mate, and now just getting around to studying it!

Learning C from a text book is somewhat dull, but with hands-on and near instant results using the Arduino - it makes the whole process a lot easier and more interesting - especially if you have an application waiting.

So whilst my code is a little clunky, and having never been taught good programming practice (we were taught FORTRAN 77 for a year at Uni in 1983, whilst the year above us learned ALGOL 68!!), I am still learning quite a few of the basics, and trying to make the journey and transition from being confined byPIC assembly language.

This morning I learnt the structure of arrays and how to index into them with a pointer. Whilst I have been using this construct for years in PIC code to send messages - today was my first time in C. I can now send all sorts of serial messages to devices using a modified bit-banging serial routine.

As an update to my Arduino base central heating control system outlined in the previous post I have now got the wireless boiler commands working and combined the sketch with the temperature controller sketch I wrote at the end of June to read 6 thermistor channels and display the temperatures on an LCD display.

My boiler is now turning on and off under Arduino control. Like I said earlier - just enough knowledge of C to be dangerous.

The plan now is to integrate this application with Andrew Lindsay's modified ethernet code for the NuElectronics ENC28J60 ethernet shield. The intention is to get the readings of the six sensors up to Pachube. The NuElectronics shield has not proven so popular as other ethernet shields, as it relies on the ATmega to host a cut down TCP/IP stack. This can be troublesome on the mega168, but with Andy's code improvements it should run better on the mega328 which has double the codespace and double the RAM.

Smarter Heating Control?

Central heating control systems historically tend to be incredibly simple, responding to a single, often badly located thermostat, and a time of day timer, which is often out of kilter with the hours we actually need the heating to be effective.

Using low cost, open source hardware, can we improve on the levels of control and make significant savings to the amount of energy we use heating our homes?

About 6 months ago in January, when we were up to our knees in snow, I started thinking about how our simple central heating systems could be modified to make them more efficient and to use less gas.

We have all strived to reduce our electricity consumption - by turning off unnecessary equipment, but with gas heating, we could be wasting hundreds of kWh and not even realising it.

Before I dive into more sophisticated electronic controls - I will point out that improved insulation and draughtproofing will always offer the most cost effective reduction in domestic heating fuel usage.

The extent to which we heat our houses is entirely subjective depending on our personal level of comfort and the house occupancy, which is a function of lifestyle. For example, a modern well insulated home occupied by a professional couple might need to run the heating for two hours in the early morning and a few hours in the evening, whilst for someone working from home, or at home with a young family might need constant background heating.

The first thing to do is to measure the existing usage, in terms of time of day, internal temperatures needed for comfort and absolute gas consumption, and relate these to the average outside temperatures.

In order to make use of low cost open source hardware, I have chosen the Arduino to form the basis of my home heating monitoring system. As well as low cost, it is easy to interface to, relatively easy to program and benefits from the vast experience of a very large user base. With the use of a series of expansion shields, such as the ethernet shield and the Real Time Clock/sensor/SDcard shield, it becomes a useful cost effective tool for on line, real time datalogging. It can function as a standalone system - without the need of a PC or laptop in attendance.

So what parts of this project are already in place? The following list are those that have already been achieved by various enthusiasts (plus myself), or arisen from suggestions from others in the HomeCamp Community.

1. Measuring the temperature across several rooms.

The standard Arduino has 6 analogue input channels. These can be readily used to read low cost thermistor temperature sensors. A few lines of code running on the Arduino, linearises and scales the output of the thermistor to give a temperature reading in degrees centigrade. You can also use pipeclip thermistors to monitor the temperature of points on your hot water cylinder so you can decide whether it it hot enough to bath or shower.

2. Tracking the outside temperature - weather compensation.

By measuring the outside temperature - particularly in the very early hours of the morning, it is possible to predict how much heat is likely to be needed to bring the house up to a comfortable temperature when the occupants awaken. Older, less well insulated houses lose more heat to the environment. Knowing this rate of heat loss - which is proportional to the temperature difference between inside and outside allows you to better predict how much gas heating you will need. As comfort is very much a lifestyle choice, if you have alternative heating, such as a multifuel stove, you may choose to use this in preference to gas - at weekends for example, to offset the gas consumption.

3. Historical records of daily average outside temperatures.

A historical archive of daily average temperatures is available online for many towns across the UK. This record could be coded into the Arduino as a look up table, so that it could make a prediction to how much heating is likely to be needed on a particular day. Based on the early morning temperature, the historical average, and whether it is a weekend, your heating control system might choose a different strategy than if it were a milder weekday - for instance.

4. Measuring gas consumption on an Arduino and outputing it in CurrentCost XML format to display on Dale Lane's GUI (and others).

An earlier post to this blog showed how it was possible to read the gas consumption from a gas meter by using a non-contact optical sensing method. The pulse count data, relating to gas consumption can be converted into an XML message format similar to that output by the Current Cost electricity monitor, and passed out via a serial connection to be logged and graphed on a PC. As an example of a third party application for graphing and logging - I chose Dale Lane's GUI.

As an aside, Current Cost have sold 1.126 million energy monitors, and are introducing new products to give access to internet connectivity. The "10 channel" display capability of the Current Cost Envi could be used to monitor additional household data - such as solar water heating, pV or anything else.

5. Determining the heat-up, cool down curves for the particular property.

For a given average outside temperature, heat loss from a property will be at a certain rate. By determining this rate, it is possible to calculate the amount of heat needed to warm a property up from cold to the comfort temperature, and this can be converted to the required boiler on-time.

6. Wireless control of the boiler using a hacked wireless thermostat protocol.

Some years ago I deciphered the wireless protocol used by my Drayton Digistat wireless thermostat, and implemented this protocol on a low cost PIC microcontroller and wireless transmitter. By simulating the "boiler-on" and "boiler-off" codes, it is possible to override the existing wireless thermostat and control the heating directly with your own control system.

I now have a very simple sketch for the Arduino which implements this wireless boiler on/off control.

This leads to possibilities of remotely controlling the heating either from a web browser, telephone link (using DTMF tones) or something as simple as a TV remote control.

7. Individual control of radiators with wireless remote rad-valves etc.

Wireless motorised gearheads are available from Conrad Electronics (search for Radiator thermostats) for popular makes of thermostatic radiator valves (TRVs). These allow complete rooms to be individually temperature controlled, by monitoring the room temperature and setting the local TRV accordingly. It's possible to fool a TRV into shutting off its radiator by gently warming the wax "bulb". It takes a power resistor and about 1W of power to keep a TRV shut. This could be an alternative to a wireless system.

8. Uploading data to web with ethernet shield and datalog/display with Pachube.

Several low cost ethernet shields and gateways are now available which allow data to be sent up to the net for remote hosting, using free services such as Pachube. By using an external microcontroller that hosts the TCP/IP stack and has an integrated ethernet controller, the burden of this is taken from the Arduino. Data can then be communicated to/from the web as simple serial text.

9. Remote control/ access to heating system via web browser / iPhone app etc.

Once you have an ethernet connection to your central heating controller, remote access and monitoring is possible via web browser or custom app running on iPhone or Android etc. Not my immediate field of expertise - but many HomeCampers are working on similar apps.

10. Back-end datalogging, graphing and analysis (Ubuntu, Joggler, Processing etc).

A serial or wireless connection from the central heating controller to a laptop, PC or other graphical platform allows historical consumption to be logged and displayed. The O2 Joggler is a particularly economically priced platform capable of running Linux/Ubuntu. Again, whilst not my area, there are many hacking various platforms and re-purposing them for home automation applications.

Remote Possibilities

The infra-red remote control unit arrived from NuElectronics with the RTC and SD datalogging sensor shield. The photo shows the combined stack of three boards, Arduino, RTC and ethernet shield. The IR sensor for the remote control is plugged into one of the inputs on the sensor board.

This assembly now provides the building blocks needed for a stand-alone, real time sensing system, with local datalogging and ethernet/Web accessability for between £40 and £50 of off the shelf hardware.

In my opinion, this now puts remote sensing well within the capability of the enthusiast or hobbyist, and with free, on line data hosting and graphing services such as Pachube, brings an interesting new dimension to home monitoring and control projects.

So what is needed now is a convenient way of stitching this lot together with opensource code modules, to allow quite sophisticated applications to be rapidly developed. In discussions with Trystan Lea of openenergymonitor, this could be done using the Arduino code libraries.

However, I believe that there is ultimately an opportunity for a PC application, which allows you to quickly chose the functionality you need, and the PC then compiles the relevant code libraries into the final sketch.

For example, the "Configurator" application would allow you to select what hardware you have assembled - from a list of popular vendors, in a mix-and-match manner. Then you select the functionality from a similar list - eg. RTC, datalogger, ethernet client, and define the sensors you have connected. This is then compiled with other operating parameters - eg. MAC address, logging frequency etc to produce a sketch tailored to your particular application.

Whilst most of the above is beyond my programming skills, it would certainly hasten the development of complex applications and make the system more accessible to new users.