it would be great to see something like this - in fact, a generic gateway device alone would be a huge step forward, let alone getting wireless devices to connect to it.

i've also been thinking about something like an arduino + ethernet shield, the idea being that, with pachube API access built in, it could be a general "serial-to-internet" device. so, a current cost could use it, and no longer require a computer switched on all the time to remain tethered to the web, but so could anything else that talks serial - hopefully a big ecosystem.

with the arduino mega now out, it could become a pretty powerful little hub for a whole range of other devices - and as you point out, if a radio transceivers piggy-backs on top, then it could even become a wireless gateway for all those devices.

what's stopped me is a concern about cost: arduino + ethernet ends up being relatively expensive (especially if you take the current cost meter as an example case: the gateway ends up more expensive than the device), so i'm wondering what other basic solutions there might be.

i have worked with ladyada's lantronix which is serial-controlled - it made me wonder whether there was anyway to remove the requirement for the arduino in there.

any thoughts?

i've not used 433Mhz much, but the cost and power requirements you quote make it sound like a very elegant solution. i'd be interested to know how much those little wireless sensors Martin Dix handed out cost - they would seem to do the trick!

IMHO arduino (or another microcontroller) is the best low cost approach at the moment. To make it cheaper we could make a single PCB with the ethernet chip on it. this would also make it easier to package.

I have not succeeded with interfacing from current cost because of CC's serial interface ( @martindix is aware of this - lack of handshake). However, you can always connect directly to the meter with some form of optocoupler. That's what I have done for gas and electricity - works great and gives exact meter reading.

Using an always-on PC feels like overkill to me and takes away from the whole idea of low cost low power.

As to connecting to the net, a good option is to wire it direct to your router/ hub. If this is too much cabling things do get more complicated, cost more and consume more power.

Paul

BTW. I did not write the pachube code on arduino yet - I have it on an intermediate server. However, this will not be difficult when I have some time available.

Hi Usman, Paul, Community

Thanks for your feedback.

The idea of a generic serial to internet gateway is also attractive.

The minimum hardware configuration I can think of is an Arduino driving the Microchip ENC28J60 ethernet controller over an SPI bus. This is essentially the hardware solution provided by the Nuelectronics ethernet shield - where the Arduino has to provide a cut down TCP/IP stack. About £30 the pair.

Another starting point would be to hack a Current Cost and add the Nuelectronics shield - this might be a development that would appeal to Martin Dix at CC. Cost about £13 plus some additional firmware on the CC.

I know that the Nuelectronics shield is relatively unrefined/yet to be further developed from a firmware point of view - plus the limitations of running the TCP/IP stack within the resource constrictions of the standard Arduino mcu.

I am happy to help with the 433MHz part of the system - I have a Tx and an Rx design I did from a couple of years back, interfacing the RF stages to a MSP430, which is a fairly good choice for a low power sensor. I even have some pcbs lying around.

In volume a 433MHz ASK transmitter can go on a board for between $0.60 and 0.75, and a crystal controlled superhet receiver for about $3.00.

To maintain low power, you need an infrequent transmission, a small packet size, and an efficient payload to overhead ratio in the packet. I have used HTH's (High Tech Horizon's) SNAP protocol coded up on a 16F PIC in the past - it's simple and not overburdened by overheads. A low baud rate (<10K and preferably <4800) makes for longer range transmission as there is more energy contained in each bit. Pick a baud rate that you can view directly with a terminal program - it makes debugging so much easier - a lesson I learnt from a product with a 2000 baudrate!

Ken

I re-purposed a livebox for exactly this kind of thing. An always on PC is definitely overkill.
Check out the screen shots of the WEB UI: http://livebox.dbzoo.com/uishots.html
It's part of a home automation project I've been working on in my "spare" time.

some other approaches employed by pachube users, which are wifi-enabled, include:

* http://www.evriskosys.com/
* http://www.gainspan.com/

e.g. http://www.pachube.com/search?query=evrisko and http://www.pachube.com/search?query=gainspan); i'm not sure whether it meets your requirement for "simpler" and "cheaper" (might well do, i'm not clear on the actual implementation used in the feeds)

also, anyone had experience with 6LoWPAN?

Hi All,

It's a few months since I first thought about a generic protocol to allow remote sensors based on low cost micros to connect to a gateway and then on to Pachube.

A few thoughts have now gelled, and I now have a remotely controllable mains socket, activated across a wireless link, from a PIC based microwebserver. It was a quick hack - but I wanted to start with something simple to get the creative juices flowing.

It contains all the essential elements of a control and monitoring path: A web connected low cost gateway, a short range wireless link, a packet based serial protocol to run on the wireless link, and a simple application - turning a mains appliance on and off, and monitoring room temperature.

I've written up some of the detail on my blog http://sustburbia.blogspot.com/2009/11/take-control.html

Part of the problem is that we encounter several different micros in low cost sensors such as AVRs, PICs, MSP430, 8051 etc. I wanted to try and find a serial communications protocol with low overheads, which could be ported onto each of the micros I use.

Fortunately, about 10 years ago, the Swedish company High Tech Horizons (HTH) developed such a protocol called SNAP.

http://www.hth.com/snap/

SNAP stands for Scaleable Node Addressable Protocol. I first came across it in 2002 when I bought a pair of powerline modem kits from HTH. SNAP has already been implemented on PICs and AVRs - so a C coded version to run on an Arduino should not be too difficult.

So suppose we have an Arduino with ethernet shield acting as the gateway to Pachube. The Arduino is fitted with a low cost (433MHz AM for example) wireless transceiver. Running the SNAP core on the Arduino allows it to receive packets of data from the remote sensors - for example temperature readings, and also send out commands to the sensors - such as close a relay, to shut a valve etc.

Now I realise that lots of other protocols exist, X10 for example has got a very large user base. But SNAP is simpe enough for me to understand from scratch, and able to debug using Hyperterminal and an FTDI serial lead.

SNAP is independent of the communications media. It is equally applicable to wired serial, such as RS232 or RS485, powerline carrier or even just sending SNAP packets to a socket server and having a server based application decode them.

SNAP allows you to package up a few bytes from registers on your microcontroller, and send them over a serial (wireless) connection where they can be decoded or retransmitted by a second device. Each node has its own address, so you can individually send data to certain nodes, or broadcast to all nodes.

The overhead to implement this protocol - plus all the serial bit-banging comms routines is considerably under 1K of program space. On the PIC the SNAP core fits into about 850 words of program memory. SNAP needs just 32 bytes of RAM to hold the various header bytes, address bytes and checksums, and it my PIC implementation I use a further 16 bytes to buffer the received packet and 16bytes to buffer the data ready for transmit.

In the proposed application, the sensor will run an interrupt driven real time clock, and wake every second to take a set of readings from its ADCs. These might include temperatures, ambient light etc. These ADC readings are packaged up into the transmit buffer, and once they have been packed, the complete 16 byte buffer is transmitted as a payload added to the SNAP header and checksum. The sensor can then turn off its transmitter, turn on it's receiver and wait for a reply message from the gateway. If there is no reply, the sensor can employ a retransmit strategy and listen again. Assuming that the gateway replies this time, the sensor stores the incoming message into its receive buffer, where the main loop application decodes it and acts accordingly. This might just be to take individual bytes from the payload and poke them straight to the microcontroller's I/O pins - a very simple way of turning relays on and off. Alternatively the received data could be used as new scaling factors for the ADCs or any number of other purposes.

Another application might be to use SNAP as the transport protocol for an over-air bootloader, allowing sensors to be reconfigured remotely from any browser.

A SNAP node can be very cheap, in some cases just a microcontroller and the wireless transceiver. Some nodes will be transmit only - requiring a 433MHz SAW transmitter which costs about $1 to implement.Some nodes will be receive only - such as my remote controlled mains socket. This uses a very skanky super-regenerative receiver based around a single RF transistor and an op-amp - again for some applications the performance of this receiver is adequate - and need cost no more that $1 to produce. Add this funtionality to a $2 microcontroller and you have a complete wireless smart sensor transceiving node for under $5. To reinforce this low cost philosophy - I will offer the term "CheaperNet".

So SNAP is quick and cheap to implement. It's scaleable so that you can use it for bigger things - but the key point is that it is small enough to be manageable within small standalone sensors.

The internet controlled mains socket will probably be making an appearance at the Homecamp Christmas bash on December 17th - as a neat way of remotely turning the Christmas lights on.

Ken

All,

Since my first foray into Pachube connectivity about a year ago, I have sought and come across another candidate for a low cost serial to ethernet gateway.

The PIC18F67J60 is a PIC 18F core combined with an ethernet controller (equivalent to ENC28J60) on the same silicon die. To turn this into a serial gateway, you need a 25MHz crystal, an integrated magnetics RJ45 (such as a Stewart MagJack) and very little else. If you don't want to build this yourself - Olimex make a reasonably priced PIC Micro Web - which is an exercise in minimalism. In volume these gateways could be produced for under $10.

To get things up and running, you need the Microchip TCP/IP stack - which is free available and licence free. It has a serial interface which allows you to talk to the PIC using Hyperterminal and an FTDI serial cable. The Microchip stack removes the overhead otherwise imposed on the micro (eg an Arduino is fairly burdened by the Nuelectronics ethernet shield). I think Nuelectronics would do well to ditch the ENC28J60 from their shield, and substitute a PIC18F67J60 in its place - making a smart shield for almost no extra cost.

So putting this into practice, I use a PIC18F67J60 as a serial to ethernet gateway to get my household power readings up to the net.

Thanks to some intensive code development from a work colleague, I now have real time, live electricity power readings being served to Pachube. The once per second data is also served and graphed on this site - so you can see my household consumption roll out in real time - as it happens.

http://protodev.onzo.com/?stream=3

Ken