I have recently been experimenting with some XRFs from Ciseco Plc. The firmware (v0.36) on these XRFs is beta but I understand it is about to be released.
I have tested this on a Nanode and also on a Ciseco Xino for Atmel, it should work with a standard Arduino but I have not tested it.

The new features of the firmware are:
1) reduced delays when continuously sending or receiving data
2) Support for remote reset

These when taken together allow Arduinos to be remote programmed.

So to set this up we need an XRF connected to the Arduino (I’ll call this the remote XRF) and an XRF connected to your PC (the host XRF).

Wiring, the remote XRF needs GND, PWR, Rx, Tx and pin 17 hooked up – see the fritzing diagram below,
the host XRF needs to be connected serially to the host PC – e.g. by using a FTDI cable; GND, PWR Rx, Tx and pin 16 need connecting.

Remote XRF setup:
You need to give the remote XRF an ID (command ATMY) e.g. to give the ID “NN” to the node enter the AT command “ATMY NN”.
You also need to set up the baud rate to match that expected by the bootloader. This is 115200 for a UNO bootloader and 57600 for a standard ATMega386 bootloader.
For the Uno
ATBD 1C200
and for the standard Arduino
ATBD E100

Host XRF setup:
You need to tell the host XRF the ID of the remote XRF to program.
To set a remote ID of NN
ATRI NN
you also need to enable the remote reset (1 to enable and 0 to disable)
ATRP 1
Finally you need to set the baud rate as for the remote XRF.
ATBD 1C200 or ATBD E100

Now you are all set up – run the Arduino IDE, select the board type and the port for the host XRF and program.

Note: This method of programming is intolerant of any radio noise or other XRF radio traffic on the same frequency/panID. I understand future firmware updates may improve this, but at the moment you may need to try and upload more than once – the Arduino IDE will tell you if it succeeded.

Images:

Host XRF to PC.

Remote XRF to Arduino. Note Pin 17 of the XRF should be connected to the DTR line if the Arduino has a FTDI connector, also if used the capacitor value is 100nF.

I built this onto a small XRF module board that Ciseco produce. Miles assures me that these will be available soon. The boards contain a 3v3 regulator as well as sufficient prototyping space for the connections needed.

Photo of the remote setup, Nanode, XRF and XRF module board

Photo of the host setup – SparkFun FTDI board, AdaFruit XBee board and XRF

Videos:

Disclosure: Miles (Ciseco) lives near to me, we met at the Nottingham Hackspace. In return for beta testing Miles supplies me with some of his kit.

The question of how to do GET requests with the ENC28J60 arose recently so here is an example.
This is using the etherShield from Nuelectronics and @andrewdlindsay‘s etherShield library.

The code assumes some familiarity with the ethershield examples.

#include <etherShield.h>

static uint8_t mymac[6] = {0x54,0x55,0x58,0x10,0x00,0x28};
static uint8_t myip[4] = {192,168,1,25};
// Default gateway. The ip address of your DSL router. It can be set to the same as
// websrvip the case where there is no default GW to access the
// web server (=web server is on the same lan as this host)
static uint8_t gwip[4] = {192,168,1,1};

//============================================================================================================
// Pachube declarations
//============================================================================================================
#define PORT 80                   // HTTP

// the etherShield library does not really support sending additional info in a get request
// here we fudge it in the host field to add the API key
// Http header is
// Host: <HOSTNAME>
// X-PachubeApiKey: xxxxxxxx
// User-Agent: Arduino/1.0
// Accept: text/html
#define HOSTNAME "www.pachube.com\r\nX-PachubeApiKey: xxxxxxxxxxxxxxxxxxxxxxxxxxx"          // my API key
static uint8_t websrvip[4] = {173,203,98,29};  // www.pachube.com
#define HTTPPATH "/api/9999.csv"      // The feed

EtherShield es=EtherShield();

#define BUFFER_SIZE 500
static uint8_t buf[BUFFER_SIZE+1];

void browserresult_callback(uint8_t statuscode,uint16_t datapos){
 Serial.print("Received data, status:"); Serial.println(statuscode,DEC);
 if (datapos != 0)
 {
  Serial.println((char*)&buf[datapos]);
  // now search for the csv data - it follows the first blank line
  // I'm sure that there is an easier way to search for a blank line - but I threw this together quickly
  // and it works for me.
  uint16_t pos = datapos;
  while (buf[pos])    // loop until end of buffer (or we break out having found what we wanted)
  {
   while (buf[pos]) if (buf[pos++] == '\n') break;   // find the first line feed
   if (buf[pos] == 0) break; // run out of buffer
   if (buf[pos++] == '\r') break; // if it is followed by a carriage return then it is a blank line (\r\n\r\n)
  }
  if (buf[pos])  // we didn't run out of buffer
  {
   pos++;  //skip over the '\n' remaining
   Serial.print("CSV line is:");
   Serial.println((char*)&buf[pos]);
  }
 }
}

void setup(){
 Serial.begin(9600);
 Serial.println("Ethershield Get example");

 /*initialize enc28j60*/
 es.ES_enc28j60Init(mymac);

 //init the ethernet/ip layer:
 es.ES_init_ip_arp_udp_tcp(mymac, myip, PORT);

 // init the web client:
 es.ES_client_set_gwip(gwip);  // e.g internal IP of dsl router

 es.ES_client_set_wwwip(websrvip);  // target web server

}

void loop()
{
 static uint32_t timetosend;
 uint16_t dat_p;
 while(1){
  // handle ping and wait for a tcp packet - calling this routine powers the sending and receiving of data
  dat_p=es.ES_packetloop_icmp_tcp(buf,es.ES_enc28j60PacketReceive(BUFFER_SIZE, buf));
  if (dat_p == 0)
  {
   if (millis() - timetosend > 10000)  // every 10 seconds
   {
    timetosend = millis();
    Serial.println("Sending request");
    // note the use of PSTR - this puts the string into code space and is compulsory in this call
    // second parameter is a variable string to append to HTTPPATH, this string is NOT a PSTR
    es.ES_client_browse_url(PSTR(HTTPPATH), NULL, PSTR(HOSTNAME), &browserresult_callback);
   }
  }
 }
}

*********
Notice – the protocol to be used has pretty much completely changed. I am adopting the aProtocol described on the OpenKontrol web site

aProtocol is essentially a hub polling devices, it does allow for devices to announce events but in the main it is polling.
The aProtocol is still work in development, I have joined the team to help make it into a robust home monitoring and automation protocol.
*********

Now that I have decided on the hardware (JeeNode V4 for nodes and Arduino for data logger) I have started to look at the data format and protocols between the nodes/sensors and the data logger. It is clear that there are three basic types of data to be dealt with

a) Current reading (sensor to data logger ). This includes events (e.g. PIR trigger or Battery Low).

b) Totals & counts (sensor to data logger). Note: totals/counts are never cleared down (unless the node is reset), the receiver of the data needs to keep track of the last total and subtract it. This makes it easy to get total for last 15 minutes, total for day etc.

c) Requests and instructions (data logger to sensor)

Low level protocol will ensure message integrity (CRC check or similar). If the sending message requests it then the receiver will ack the message (most messages will not use this – see message descriptions).

Some means to assess transmission quality (number of missing packets) is needed. The low level transmission protocol will send an incrementing sequence number (byte) with every message. Each node will also track the last sequence number received from the data logger. The data logger will keep a table; for every node the last sequence number sent and received will be stored.

The basic mode of operation is that nodes will send out data at predetermined time intervals (say every x seconds – but may differ for some sensor types), if a message goes astray or is corrupted then this is not important and we will get the value next time. Whilst this is not completely accurate (for example for energy readings) in that some values may be lost it is good enough for monitoring purposes. We require to know if some messages have arrived successfully so these will request an ack, (and re-transmission if no ack is received) in these cases the receiver should be able to accept the same message more than once without issues as the ack may be lost.

All sensor to data logger messages will be broadcast (destination node 0) – this facilitates having more than one listener – although only the data logger will ack (if ack is requested).

All messages will be in the following format : 12 bytes, human readable ascii to facilitate debugging (32 bit values will be sent as hex). Numeric information will be zero padded to the left (e.g. 123 will be sent as 00000123).
Message Format

Message Types

Some sensor IDs are reserved for special use. These are: (lowercase letters)

Sensor Types