Drayton Digistat heating controller

[Laura Cowen]

Hi,

I went searching for my Drayton Digistat heating controller (RF3
wireless system) to see if I could substitute the on and off commands
to the boiler with a PC. I came across a post from Ken Boak mentioning
that he has the protocol: http://www.navitron.org.uk/forum/index.php?topic=1912.0;wap2

Is the "protocol and code to generate "boiler on" and "boiler off"
commands" online somewhere? Or does someone have a copy of it, please?

I did find Ken on Twitter but @andysc suggested I try here
instead. :-)

I have yet to make it to a homecamp - each of the previous two somehow
ended up clashing with weddings - but my fingers are crossed for the
next....(I surely don't have many more unmarried friends...)

Thanks,

Laura

[mikethebee]

Welcome Laura,

Ken should catch your post from here, he also has an excellent blog at
http://sustburbia.blogspot.com/ if you haven't come across it already,
though it doesn't have the Drayton codes posted unfortunately.

Cheers, Mike

[Ken Boak]

Hi Laura,

I managed to de-cipher the packets sent by the Digistat into 9 hex pairs, and get a low cost micro and 433MHz ASK transmitter module to emulate these.

I used a PIC to generate the serial packets - mainly because I had a PIC based transmitter available and I was able to easily match the data rate.  The same thing could be done using an Arduino or similar microcontroller with a serial output routine to a pin that can produce data at 2000 baud (non-standard baudrate).

The detail of the packets is as follows:

; Outputs a wireless packet (2000 baud) to control a Drayton Digistat wireles thermostat receiver
; Boiler Off packet   AA AC 59 99 59 55 59 56 AA
; Boiler On  packet   AA AC 59 99 59 55 95 65 AA

; read MSB first from left to right

I can send you the original PIC assembly code, but it might be a good opportunity 
to re-code this application into C for an Arduino - which can handle 2000 baud. 
If you translate the  above packets into decimal and then use the Serial.write funtion 

to send them as binary data. Something like this - untried and untested ;-)

void setup() {

	Serial.begin(2000);	// opens serial port, sets data rate to 2000 bps
}

void loop() {

Serial.write(170);           // Output the common part of the packet 6 bytes

Serial.write(172);
Serial.write(89);
Serial.write(153);
Serial.write(89);
Serial.write(85);

if(boilerstate==HIGH) {

Serial.write(149);          // Turn the boiler on
Serial.write(101);
Serial.write(170);


}

else {

Serial.write(89);          // Turn the boiler off
Serial.write(86);
Serial.write(170);

}


}


regards,



Ken 

[Ken Boak]

Laura,

Having re-read your email  - I see that you want to use a PC. I would suggest that you use a low cost Arduino (£16.50) to generate the packets at the correct baud rate - solely because I'm not sure you can easily get a PC port to run at anything other than the "standard" baudrates.

It's fairly easy to get the Arduino to monitor the temperatures from 5 or 6 rooms, and the outside temperature, and make a decision on whether to fire the boiler.

I'm currently hacking something similar and would be happy to share ideas.


Ken

[Laura Cowen]

Hi,

Thanks for the replies. I do have an Arduino (though I'm very much a
beginner at it all - mostly flashing LEDs so far) and actually would
prefer to try with that anyway. What I'd like to see is if I could use
an O2 Joggler (running Ubuntu) as a touchscreen front-end instead of
the Drayton controller display, as well as having more granular
temperature monitoring and decision-making with the Arduino and
sensors.

I haven't thought about it hugely beyond that yet and am probably
missing a lot of things as I've not done a lot of hardware hacking
yet. I would be interested, though, in what you're doing with your
boiler - partly because we seem to have the same boiler/controller
combo as you do, which is handy. :)

Thanks again (and to Mike for the welcome!),

Laura

[Ken Boak]

Hi Laura, and Homecampers,

I read from your blog that you had already used the Arduino to flash some Xmas lights, to show the electricity consumption at your, and your mum's houses.

From simple LED flashing in response to a MQTT message, it's not much of a step to get the Arduino to read analogue temperature sensors and make the data available locally to a laptop, or get it up to the web using an internet shield and a service such as Pachube.  (I hear the new Current Cost internet gateway is based on the same micro as the Arduino).

Central heating control systems historically tend to be incredibly simple, responding only to a single, often badly located thermostat, and a time of day timer, which is often out of kilter with the hours we actually need the heating to be on. 

As a result, we tend to burn a lot more gas than we need to - and it's not so easy to see this energy wastage, in the same way that it's easy to spot lights being left on.  We may be conserving a few kWh of electricity whilst unwittingly wasting hundreds of kWh of gas.

It ought to be fairly straightforward to gain better control of our heating systems - remembering that every property is different, and has varying heat requirements. What is needed is a system that tracks outside tempertature, has a "knowledge" of the typical house heating and cooling profiles and so can effectively tune its response to meet optimum fuel usage. 

Most of the pieces of this jigsaw are already available from Homecamp/Arduino enthusiasts:

1.  Measuring the temperature across several rooms.
2. Tracking the outside temperature - weather compensation
3.  Historical records of daily average outside temperatures
4.  Measuring gas consumption on an Arduino and outputing it in CurrentCost XML format to display on Dale Lane's GUI (and others).
5. Determining the heat-up, cool down curves for the particular property
6.  Wireless control of the boiler using a hacked wireless thermostat protocol
7. Individual control of radiators with wireless remote rad-valves etc.
8.  Uploading data to web with ethernet shield and datalog/display with Pachube
9.  Remote control/ access to heating system via web browser / iPhone app etc
10.  Back-end datalogging, graphing and analysis (Ubuntu, Joggler, Processing etc).

I would be keen to start a discussion on how we can assemble these various pieces into an integrated open source project. 

I can offer hardware skills but I need the assistance of others when it comes to stitching firmware and software apps together to geta fully integrated system.


Ken

[yellowpark]

I have a feeling that Peter from Tinker worked on the production of
the Drayton thermostat. I have one of these at home also, and I had a
conversation with him about it a few months ago. If it's not the
Drayton, it is very similar! I can't find Peter's twitter name at the
moment, but it is probably worth having a chat with him.

[Ken Boak]

Hi Chris, & Homecampers

I met Peter at the HC Party.  He has certainly worked on some interesting projects.

I was fortunate that when I upgraded my heating system, that the Drayton thermostat was used - and it has such a simple protocol - just 9 bytes for on and 9 bytes for off of which the first 6 bytes are common.  Later units might use something a little more sophisticated.  I used a wireless "sniffer" and a scope to see what was actually being sent across the air, and what the bit time was.

I've updated my blog to reflect some ideas about open source smarter heating controls:

http://sustburbia.blogspot.com/2010/07/open-source-heating-control.html

I'm going to try replicating the boiler-on and off commands with an Arduino and see if I can get it to work.  Mid-summer is not the normal time to start working on heating ideas.

Good to hear your news about the Current Cost bridge.  Is it 100% compatible with the original Arduino ethernet shield?

http://hotzone.org.uk/chris-dalby-on-the-currentcost-bridge/



Ken

[Ken Boak]

Hi Homecampers and Drayton Digistat devotees,

I have now written some Arduino code to generate boiler-on and boiler-off packets.

The function I used is a modification of David A Mellis's Software serial which is supplied with the Arduino in the file SoftwareSerial.cpp

The serial.write function (suggested yesterday)  was unsuitable because it uses start and stop bits. These have to be removed.

It was necessary to customise the bit-banging serial routines, firstly to remove the start and stop bits, and secondly to write the data to the Tx pin starting with the most significant bit MSB (usual serial is LSB first).

I have tested the code and it turns my Digistat on and off - however you have to train the Digistat receiver first. 

This suggests that the codes are not universal, but unique to each Digistat transmitter.  I only found this out because I have two transmitters here, and my code refused to work for one - so I retrained the receiver to accept  codes from the other thermostat - and all was well.

What is now needed is an RF sniffer, which listens out for Digistat codes and displays them, so that anyone wishing to follow this work can decipher their own Digistat. 

Whilst this adds an extra level of complexity it should be do-able using a low cost 433MHz receiver from a wireless doorbell or one of the Telecontrolli modules that Farnell sell.

Here's the code for anyone to cut and paste

/*

; Outputs a wireless packet (2000 baud) to control a Drayton Digistat wireles thermostat receiver
; Boiler Off packet   AA AC 59 99 59 55 59 56 AA
; Boiler On  packet   AA AC 59 99 59 55 95 65 AA

; read MSB first from left to right

Uses function RF_tx  to put 8 bit serial on digital output pin 2 (no start or stop bits)


*/

int boilerstate = 0;
int ledPin = 13; // LED connected to digital pin 13
int inPin = 7;   // pushbutton connected to digital pin 7
int val = 0;     // variable to store the read value

int _transmitPin =2;  // define the serial output pin

int _bitPeriod = 1000000 / 2000;   // define the serial baudrate in microseconds



void setup()
{
  pinMode(ledPin, OUTPUT);      // sets the digital pin 13 as output
  pinMode(inPin, INPUT);      // sets the digital pin 7 as input
  pinMode(_transmitPin, OUTPUT);

 
  Serial.begin(2000);    // opens serial port, sets data rate to 2000 bps
 
 
}



void loop() {
 
 

  val = digitalRead(inPin);     // read the input pin
  digitalWrite(ledPin, val);    // sets the LED to the button's value
  boilerstate = digitalRead(inPin);              // boiler on or off according to digital input
 

RF_tx(170);           // Output the common part of the packet 6 bytes
RF_tx(172);
RF_tx(89);
RF_tx(153);
RF_tx(89);
RF_tx(85);

if(boilerstate==HIGH) {

RF_tx(149);          // Turn the boiler on
RF_tx(101);
RF_tx(170);


}

else {

RF_tx(89);          // Turn the boiler off
RF_tx(86);
RF_tx(170);

}

delay(5000);              // wait 5s before resending


}



  void RF_tx(uint8_t b)                 // this function writes the serial MSB first

 
{
   
  int bitDelay = _bitPeriod - clockCyclesToMicroseconds(50); // a digitalWrite is about 50 cycles
  byte mask;

//  digitalWrite(_transmitPin, LOW);   // send a start bit
//  delayMicroseconds(bitDelay);

  for (mask = B10000000; mask; mask >>= 1) {                 // start with bit 7 and right shift the mask until mask = 1
    if (b & mask){ // choose bit
      digitalWrite(_transmitPin,HIGH); // send 1
    }
    else{
      digitalWrite(_transmitPin,LOW); // send 0
    }
    delayMicroseconds(bitDelay);
  }

//  digitalWrite(_transmitPin, HIGH);    // send a stop bit
//  delayMicroseconds(bitDelay);
}

[mikethebee]

Peter Knight is @cathedrow on Twitter according to
http://www.tinkerlondon.com/who-we-are/peter-knight

[Peter Knight]

Hey folks.

Unfortunately I worked at Danfoss for their wireless thermostat, not
Drayton. And that was many years ago.

I can offer some insight into the protocol though if that helps.

Simple FM transmitters much prefer a bitstream with equal quantities
of '0' and '1', as it makes it much easier for the receiver to track
the mid-frequency. This improves signal to noise, and therefore range.

Here are the two codes from above.

AA AC 59 99 59 55 59 56 AA

AA AC 59 99 59 55 95 65 AA

In binary, with bits paired up:
10 10 10 10 10 10 11 00 01 01 10 01 10 01 10 01 01 01 10 01 01 01 01
01 01 01 10 01 01 01 01 10 10 10 10 10

10 10 10 10 10 10 11 00 01 01 10 01 10 01 10 01 01 01 10 01 01 01 01
01 10 01 01 01 01 10 01 01 10 10 10 10

There are four symbols used. Lets call them A-10 B-01 C-11 D-00. Note
that if you stick to A's and B's, you always have pairs of 0 and 1.
This modulation method is known as Manchester Encoding.

Now the messages look like this:
AAAAAA CD BBABABABBBABBB BBBBA BBBBA AAAA
AAAAAA CD BBABABABBBABBB BBABB BBABB AAAA

A few features to point out:
The AAAAAA is a lead-in. It is sent whilst the receiver is locking
into the signal.
The CD is a sync pulse. It breaks the lead-in pattern, and ensures the
receiver knows how bits are paired. It deliberately breaks the '01' or
'10' rule to make detection easy.
The BBABABABBBABBB is the unit identification number. This is what is
learnt during pairing.
The BBBBA or BBABB is the on / off code. It is sent twice, once for
verification.
The AAAA is the lead-out, as the transmitter is switched off.


Just a random ramble - but hope it helps.


Peter

[yellowpark]

Thanks for posting this Peter. Makes a lot of sense in terms of
extending the range and giving the receiver a fighting chance of
hearing and dealing with the message. I'm going to try and add this
methodology to the door alarm I am doing. I had found that if the
door was closed for a period of time, it would miss the open, but
catch every other door state. So I think waking the device up with a
lead-in, followed by the sync pulse and the rest of it will probably
fix this issue.

Thanks for posting :)

[Ken Boak]

Peter,

Thanks for the useful insight. I had suspected that splitting into bytes was not revealing the whole story, but at the time I just needed a quick and dirty method of expressing the packets so that they could be regenerated easily.

Manchester encoding makes sense for these low cost am wireless links.

I've now got it working with the Arduino with a modified bit-banging serial routine.   Transmission is always the easy part - writing code to receive and decode this packet stream will be the next task.



Ken

[Laura Cowen]

Wow - really interesting threads! Thanks everyone.

I don't know when I'll get to have a go at this but I'm already
learning just by reading the posts. And I'll follow with interest in
any progress anyone else makes in the meantime.

:-)

Laura

[Toby Evans]

Hi everyone,

just been listening to Mike the Bee's podcast and remembered about this, and realised I hadn't replied

For measuring external temperature, the building industry standard is "Degree Days", which as I recall is an index of how cold a place is, based on how far below 15C it is (the temperature below which a house requires heating). You can then add these up, so you can judge "how cold" a winter has been - this gives you an idea of the relative efficiency of your house/insulation

you can get more information, including recent stats and the formulas, at: http://www.vesma.com/ddd/index.htm

I've also got formula as a SQL Server function, it's fairly simple


Mike was pointing out that you can get micro-climates which won't be reflected in such general stats as degree days, so how about either using a usb-connected home weather station (Maplin have loads), or using something like http://www.wunderground.com, where you can pull down fairly detailed weather stats, so you can finer grained detail about external temperatures


I'm terrrible with hardware, but write server-side energy monitoring applications for kicks (I wrote my own interface to Powermeter a while ago), so I'd be delighted to work with anybody on putting all the pieces together

Toby

--
You received this message because you are subscribed to the Google Groups "homecamp" group.
To post to this group, send an email to home...@googlegroups.com.
To unsubscribe from this group, send email to homecamp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/homecamp?hl=en-GB.

--
http://2cheap2meter.blogspot.com/
http://communergy.codeplex.com