Getting it Together

The various development threads of the web enabled smart sensors are now coming together into a convergent design. In previous posts I have discussed ethernet controller hardware, serial command interpreters and messaging methods all under the banner of smarter energy control. Now is the time to bring it all together into a tangible system.

The plan is to build a network of simple devices for home automation, monitoring and control – applicable to home heating, renewable energy and domestic energy monitoring.
The hardware is based on the ever-popular Arduino which consists of an ATmega328 with a clock circuit and programming interface on a credit card sized pcb. In order to keep system costs down, I have taken the essence of the Arduino, and come up with a very much stripped down version which can be built on a prototyping breadboard or small piece of stripboard. None of this is original work, there are several similar examples on the web, from which I drew some inspiration.

Applying the Boards.

These stripped down boards will be deployed around the house and used in a number of applications. One device will be used to monitor my electricity readings, based on the design by openenergymonitor.org. Some of its spare sensor channels will be used to monitor temperature and humidity in the rooms at the front of my house and monitor the doorbell and front door openings. This choice of functionality is purely because the electricity meter is at the front of the house and close to the front door – a matter of cabling convenience. A digital output will be used to control a power resistor which is used to activate the thermostatic radiator valve – for selective control of the radiator in the front room. Warming the wax bulb causes the wax to expand and close the valve. A standard TRV can be turned off in about 10 minutes with a 1W power resistor fitted t the valve.

Another device will monitor my gas consumption using an opto-reflective pulse counter fitted to the register of the gas meter. Again for geographical convenience, spare sensing channels will monitor the living room temperature, at floor and ceiling levels and operate a circulation fan. Further channels will monitor the flow and return temperatures of my woodburning stove back boiler, and operate the circulation pump and hot water valve for optimal warm up and selective water heating.
A further device will gather temperature readings from the gas boiler and co-ordinate its operation in conjunction with the woodburning stove.
Outside in the shed where my solar water heating panel is fitted to the roof, a fourth device will control the circulation pump and monitor the small solar pV battery charging array also located on the shed roof.

So, rapidly there is the need for a network of about 4 distributed control boards and the means to co-ordinate their operation.

Serial Communications

The controller boards will all make use of a standard asynchronous serial bus working at 9600baud. The ATmega328 as used on the board has a single UART and this is used in the Arduino for programming via a serial bootloader and for communicating with the host PC. A small modification t o the serial bus will allow it to work in a multi-drop mode with several slave boards communicating, one at a time with the master board. Because of bus wiring limitations, direct slave to slave communication will not be possible, but instead routed through the master unit. A tristate buffer on the Tx line of each slave will allow individual boards to access the bus, and connect to the Rx line of the master unit. The serial bus can be implemented in 4 core telephone cable, with spare wires supplying 9V power and ground to each slave. Each slave will have an on-board 5V regulator for local regulated power. 0.5mm telephone cable will carry about 1A of power. Slaves can have battery back-up provided by NiMH or lithium cells.

Master Unit

The master unit is fitted with an Ethernet interface and connects to the broadband router. In its simplest mode it could operate entirely as a transparent serial gateway, and all data received at its Ethernet port is echoed out of its serial port. Conversely any data received on its serial bus (from the slaves) is echoed up to the Ethernet port. This would allow the slaves to be remotely interrogated from a terminal emulator web application running on a remote PC.

The slaves will be addressed using a simple 8-bit sub-addressing scheme. The master unit will have a sub-address of 255, and slaves in the range of 1 to 254. Sub-address 0 will be reserved as a multi broadcast option to act upon all slaves together – for example for a system reset.

Command Interpreter.

This is a bit of code which allows the distributed control boards to be controlled by serial commands either from a laptop PC or another source of serial data. It was devised to be as flexible as possible and be extendible if needed at a later date. The commands take the format of several alpha or numerical parameters separated by commas and terminated by the newline character. This is a format which is easy to type at a terminal emulation program – such as Hyperterminal or Termite, and can easily be stored as a CSV file or datastream. Indeed a control board could be made to follow a script of interpreted serial commands.

To illustrate the use of the serial commands, consider the familiar application of driving an RGB LED from the 3 PWM channels of an Arduino. The PWM requires an 8 bit number, and the 3 PWM channels individually drive the red, green and blue LEDs within the multicolour array allowing any colour from a 24 bit colour space to be selected.

The command interpreter evolved from being able to interpret simple commands such as R100 – meaning set the red PWM channel to a value of 100, to being able to interpret longer strings with more arguments such a B,5,100,200,50 – which would set the Brightness on slave board 5 of the RGB channels respectively to 100,200 and 50.

Once the basic framework of the command interpreter is in place, additional commands and their associated action routines are easily added.

Tying it all together with Pachube.

Once there is a mechanism for controlling the hardware with simple comma separated commands it is a relatively simple step to implement web based control. The idea is to use the CSV feed format supported by Pachube to act as a repository of serial commands, such that they can be issued to any web connected sensor network that has subscription rights to that particular Pachube feed.

The principle of command will follow a publisher-subscriber relartionship using the Pachube feed to act as a message broking intermediary. Using the RGB multicolour LED example above, if the command B,5,100,200,50 is PUT up onto a Pachube feed, then any device which has the necessary API-Key authoriasation, can perform a GET operation on that feed, and receive the B,5,100,200,50 command string. This would be buffered by the ethernet enabled master device and re-transmitted through its serial port, where it would be received by slave number 5 and acted upon.

Note that there is currently no error checking or correction on the local serial bus, and it is assumed that command packets are received without error or corruption. If the network distances are short (about 20m) and there is only one device transmitting at any one time, then the error rate should be fairly low. If better error detection and correction is needed, the serial packets could be further encoded using a protocol such as SNAP by High Tech Horizons.