Now that I have got a nice, low cost, web-enabled Arduino (WEA) it’s time for it to get on line and develop a whole new social life.
Messages passed between Arduinos are “Tweet like” in their nature – and so I have coined the name micro-twit (micro tweet having been already taken) or u-twit to describe them.
Building on the Twitter model, an Arduino can follow a feed and can also have others following its feed. In the master slave relationship, where only the master is web enabled, then the slaves automatically become followers of the master (disciples?) and also followers of anything the master happens to be following – as the messages are transparently fed to the local network via the serial port.
In order to define a basic system, we must specify the exact nature and length of the messages. The command interpreter running on the Arduino has to decode the instruction and also have a knowledge of the context of the message. Unfortunately the Arduino would struggle to run a full XML decoder, so a lightweight version is needed to interpret the context of the data contained in the message.
The nature of the commands also has to be specified. Some will be hardware specific, such as setting port pins or PWM values or reading ADC values. Others will be more compound and depend on the application the Arduino is running, for example boiler control or electricity consumption monitoring.
Part of the command, the leading letter, is used to define the action routine associated with it. For human convenience and by way of mnemonic, this is given a letter to specify it. Another field of the command is used to define the destination of the command, in other words the sub address of the microcontroller which will ultimately execute the command. Addressing is also partly handled by the number of the feed to which you subscribe. A device which subscribes to feed 8729 for example is effectively on a given network, whilst a device which subscribes to feed 8730 is on another network. 8729 might handle all messages to do with room temperature control, boiler control and solar water heating, whilst 8730 is concerned with gas and electricity monitoring and logging events such as front door opening or doorbell ringing.
As the message persists on the Pachube feed until the next update, there will need to be some mechanism to inform the subscriber that it is a new message, and not lead to the situation where the subscriber continues to repeat the same action following each time it checks for updates. The message should therefore have a “message number” appended to it so that the subscriber can tell whether it is a new message or just the old one still there.
In order to put this lot together, I need to use my command interpreter to enter the message into the sending Arduino. This creates a comma separated text string which can then be loaded into the message buffer of the Pachube client. This will allow different commands to be entered by the laptop and send them up to the Pachube feed. This is now running and produces commands of a standard format: a leading letter followed by 5 comma separated arguments. If the arguments are left off, they default to zero. For example both b1 and b,1 will produce the output b,1,0,0,0,0
With the command interpreter running on one ethernet enabled arduino, I can type a command at the keyboard, have it echoed to the screen in standard format and then PUT up to my Pachube feed as a CSV string.
The second Arduino is running the GET code, such that it feeds the received text string into the command interpreter and also echoes it out to the serial port for viewing on the terminal or passing on to the local network.
With this all working, a command typed to one Arduino appears in the serial debug window of the second Arduino some seconds later. The reason for this latency is that there is an access limit on the Pachube API, and trying to accesss at anything less than 10 second intervals will cause an error and a warning message from Pachube!
A Pachube feed for this has been created here: