Pachube - making reliable connections with Arduino

Arduino and MBED can act as clients to web services like Pachube giving them an online presence but making reliable connections over the internet is easier said than done. This article deals with some of the issues involved in communicating with remote services and how to overcome them, by building a simple Arduino climate logging client that can be accessed via a browser or mobile handset using Pachube.

Pachube provides services for logging, sharing and displaying sensor data of all kinds using an HTTP based API which is easy to implement with Arduino. A free account supports upto 10 sensor feeds updated in near real time and the data is stored for upto 3 months. Interactive graphs provided by the service can be embedded on your mobile giving you access to your data anywhere. You can even use other peoples data feeds as inputs to your own applications.

Here's a screenshot of my feeds

The good thing about Open Source Hardware is there is plenty of sample code available that can help you get a project up and running quickly. The down side is that some of it is not very robust, especially given the problems of communicating over the internet. So my initial attempts using code published online let me connect and send data samples but every few hours I found myself reaching for the reset button because the code was unstable.

I wanted to develop a prototype that could survive all the connectivity problems inherent with http protocol that was extendable for when I needed to add more or different sensors to the project. I also wanted visible indicators of the system state so I could easily debug the sample, send, receive cycle. 

Here is the prototype on the breadboard.

I used an UNO with Ethernet Shield and a couple of DS18S20 temperature sensors on a OneWire bus as there is already a reliable Arduino library available. LED's show the status corresponding to each state of the cycle. The digital thermometers are soldered to RJ cables in parasitic mode so they can be easily placed in different positions. The Ethernet Shield is connected to a router and has it's own IP and MAC address on the network allowing access to the internet. 150R resistors limit the current to the LED's and there is a single 4K7 pull-up on the OneWire bus.

Here is the DesignSpark schematic

The firmware code uses a Finite State Machine (FSM) idiom for the firmware that controls the transition from one state to another through a defined sequence. Each transition is triggered by different events fired in the actions. The FSM was designed and tested using the excellent free software simulator LTSA This allows testing of all possible system states so your code will not become unresponsive. The theory behind the tool is covered in the book Concurrency: State Models and Java Programs by Jeff Magee and Jeff Kramer.

Here is the Finite State Process Chart for the system.

Starting state is IDLE (0), where the system waits for SAMPLE events. These happen every time interval depending on how regularly you want to update Pachube. SAMPLING (2) collects temperature readings and converts them to strings for each sensor on the OneWire bus. CONNECTING (3) tries to establish connections to Pachube. If successful a PUT request sends the data to Pachube before RECEIVING (1) is entered where the response from Pachube is read. Once the buffer is empty the connection is closed, the client is disconnected and it returns to IDLE. If the connection fails at any time FAILING (4) is entered. This flushes the buffer before closing the client. This is very important as there are many reasons why this can occur. Server failure (Pachube is quite reliable), internet latency, router reconnections (this seemed to cause most of the sample code I tried to enter infinite loops) and physical disconnection. The system needs to keep trying to re-connect so that it can resume once connectivity is restored.

There were a couple of other obstacles that I had to overcome with this project. The Ethernet Shield does not reset when using the external power supply on Arduino - this was fixed by bending the reset pin out of the header and connecting one of the I/O channels so a pulse can perform a reset. More recent shields do not suffer from this problem. Also if you have an early UNO board there is a bug in the Atmega8U2 chip firmware that means you have to reflash this.

Now I have a code base and prototyping testbed for all kinds of connectivity projects that is reliable and easy to extend without resorting to hardware watchdogs and it will survive all kinds of network failures. And I can see what the climate is like at home from anywhere in the world!