Recent site activity

Communication Protocols


Protocols
There are at three protocols involved in the heating system, communicating between:
  • temperature sensors and the CPU is called the "1-wire" protocol, which is fairly simple and covered elsewhere, using a driver chip, it's exposed over UART.
  • communicate between the CPU and the 16pin I/O multiplexers (I2C) to command the zone value and boiler relays. 
  • between the CPU and the user display panel. This is the most complex I2C protocol because it encapsulates the following:
    • joystick
    • LCD screen. 
    • The LCD driver has it's own protocol over a bus of 10 wires. I don't want to interface with this directly, so I use the I2C chip to convert this to a serial device over I2C (this is as-yet unimplemented). 
  • Finally a "user protocol" to configure and inspect the device from a PC. This is currently over RS232, although I have has some success using USB serial emulation to communicate.

Client/host protocol

The client/host protocols allows the following:
  • basic salutation/login
  • exchange of clock/set clock
  • set/get time period config
  • set/get zone config
  • get state history
  • engineer vale test mode
To transfer temperatures, I follow the scheme used by the DS18B20, ie. a two byte signed short, being the value in degrees multiplied by 16. The device resolution is therefore one sixteenth of a degree. For zone switch times, there are 86,400 seconds between midnight and midnight, but this is larger then the range of a signed short, so I've used mionutes since midnight, ie 0..1440 packed into a short.


The server maintains a state machine. This is initialised and reset (timeout) to the idle state:

Idle => Command =>

Idle state
Client:   0x01 solicitation byte
Host:    0x01 reply
=> state: command