Vaillant CalorMatic 340f (868MHz) PART 3: Implementing support for the device in applications like rtl_433, rflink or OpenHAB
The Full Data Frame Specification
Remember the results of our decoding project that we did in parts 1 and 2 of our little series:
The remote control sends only the following data to the boiler, all other smart logic resides in the wireless controll (i.e. smart control, dumb boiler):
- Heating On/Off (in analogue mode: heating water temperature)
- Warm water pre-heating On/Off
- Battery OK/LOW
The data is sent in frames of 16 bytes, where the actual data is contained in bytes 4-12, and bytes 13-14 are a 2-byte checksum.
|1-2||0x00 00||Preamble (square wave to synchronize clocks with the receiver)|
|3||0x7E||Begin of frame/data (Constant)|
|4-14||Data content of the frame with 2-byte checksum attached|
|4-5||0x6D F6||Device ID (Constant for each device)|
|6-8||0x00 20 00||Unknown (constant, bit 6 of byte 7 always set)|
|9||0x00/01||Repeat: 0x00 for original signal, 0x01 for repeat signal (bit 1)|
|10||0x80/88||Pre-heated Water: 0x80 for ON, 0x88 for OFF (bit 8 always set, bit 4 indicates water)|
|11||0xB4/00/…||Heating: 0x00 for OFF, 0xB4 for ON, Target heating water temperatur for analogue mode|
|12||0x00||Battery: 0x00 for OK, 0x01 for LOW (bit 1)|
|13-14||0xFD ..||2-byte Checksum (signed integer, most significant byte first): negative of the sum of bytes 4-12|
|15||0xFF||End of Signal indicator|
|16||0x00||Epilogue (no data any more)|
All bytes are converted to a bit sequence with least-significant bit first.
For transmission over the 868,275MHz frequency, the data contents (bytes 4-14, but NOT bytes 3 and 15) are bit-stuffed (i.e. after five consecutive one bits, one extra zero bit is inserted). The resulting bit sequence is then encoded using differential Manchester encoding (1 is encoded as a transition, 0 as no transition) based on an underlying square wave of frequency 303Hz. Each bit period will be a half-wavelength, i.e. there will be 606 bit periods per second. After each bit period, a state transition is guaranteed and does not contain any information, and in the middle of each bit period there will be a state transition for a binary 1 and no transition or binary 0.
Each signal is first sent with byte 9 set to 0x00 and shortly afterwards repeated with byte 9 set to 0x01 (and the checksum updated correspondingly).
Implementing support for the device in rtl_433
Adding support for the heating control in rtl_433 is actually quite easy, once you realize that OOK_PULSE_CLOCK_BITS is actually differential Manchester encoding. Unfortunately, bit-unstuffing and changing bytes from least-significant-bit first to last needs to be done manually.
All this can be seen in my Pull request for the rtl_433 github repo: https://github.com/merbanan/rtl_433/pull/532/
If you clone this PR (or use the latest rtl_433 once it is merged), one can tune rtl_433 to 868MHz and see the captured signals analyzed:
reinhold@laptop:~/Software/rtl_433$ ./src/rtl_433 -f 868275000 [...] Registering protocol  "Vaillant calorMatic 340f Central Heating Control" [...] Registered 59 out of 79 device decoding protocols Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! Sample rate set to 250000. Bit detection level set to 0 (Auto). Tuner gain set to Auto. Reading samples in async mode... Tuned to 868275000 Hz. 2017-05-11 19:19:52 : Vaillant VRT340f Central Heating Thermostat Device ID: 0x6DF6 Heating Mode: ON (2-point) Heating Water Temp.: 52 Pre-heated Water: ON Battery: Ok 2017-05-11 19:20:12 : Vaillant VRT340f Central Heating Thermostat Device ID: 0x6DF6 Heating Mode: OFF Heating Water Temp.: 0 Pre-heated Water: ON Battery: Ok
Implementing support for the device in RFLink
Yet to come (I don't have a 868MHz receiver for RFLink yet, and RFLink does not support both 433MHz and 868MHz receivers at the same time, so I'm waiting until they implement support for the CC1101).