hardware:vaillantvrt340f_protocol
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision | ||
hardware:vaillantvrt340f_protocol [2017/05/05 10:43] – reinhold | hardware:vaillantvrt340f_protocol [2017/05/11 19:23] – reinhold | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Vaillant CalorMatic 340f (868MHz) PART 2: Decoding the wireless protocol of the heating control | ====== Vaillant CalorMatic 340f (868MHz) PART 2: Decoding the wireless protocol of the heating control | ||
+ | - [[hardware: | ||
+ | - [[hardware: | ||
+ | - // | ||
After we investigated the wireless signal that was sent by the Vaillant CalorMatic 340f over the 868MHz frequency and extracted the binary contents [[hardware: | After we investigated the wireless signal that was sent by the Vaillant CalorMatic 340f over the 868MHz frequency and extracted the binary contents [[hardware: | ||
Zeile 81: | Zeile 84: | ||
Why least significant bit first? That took me a while, too, and it stems from the way the checksum is calculated. | Why least significant bit first? That took me a while, too, and it stems from the way the checksum is calculated. | ||
- | Our sixteen base signals from above now become: | + | Our sixteen base signals from above now become |
^Heat.^Wat.^Rep.^Bat.| '' | ^Heat.^Wat.^Rep.^Bat.| '' | ||
Zeile 187: | Zeile 190: | ||
What we also observe is that the heating will still be turned on for target temperatures up to 1°C below the current room temperatur (i.e. no need to heat up the room, because it's already warm enough!), but with a low value of the heating byte. And for target temperatures above current temperature + 1°C, the heating byte will not change any more (0x5A = 90 decimal), indicating that the maximum heating intensity is already reached for target temperature of room temperature plus 1°C. | What we also observe is that the heating will still be turned on for target temperatures up to 1°C below the current room temperatur (i.e. no need to heat up the room, because it's already warm enough!), but with a low value of the heating byte. And for target temperatures above current temperature + 1°C, the heating byte will not change any more (0x5A = 90 decimal), indicating that the maximum heating intensity is already reached for target temperature of room temperature plus 1°C. | ||
- | The final indication that we need can be found in the diagnosis mode of the control: The manual states that when diagnosis mode is initiated, the boiler will be instructed to heat the water for the heating to exactly 50° C. When enabling diagnosis mode (pressing | + | Let's print all observed values |
+ | The values of this chart were observed for room temperatures of 22, 22.5, 23, 23.5 and 24°C, but the current room temperature has no influence on the heating | ||
- | '' | + | The possible (decimal) values of the byte range from 0 (for OFF) to 90 (for fully ON). So, are these percentage values (i.e. 0% heating to 90%) of the capacity of the boiler? |
+ | |||
+ | |||
+ | The final indication that we need to fully understand the byte can be found in the diagnosis mode of the control: The manual states that when diagnosis mode is initiated, the boiler will be instructed to heat the water for the heating to exactly 50° C. When enabling diagnosis mode (pressing the " | ||
+ | |||
+ | '' | ||
0x00 00 7E 6D F6 00 20 00 01 80 32 00 FD CA FF 00'' | 0x00 00 7E 6D F6 00 20 00 01 80 32 00 FD CA FF 00'' | ||
Zeile 195: | Zeile 204: | ||
This can't be a coincidence! The heating byte must be the target temperature of the heating water. | This can't be a coincidence! The heating byte must be the target temperature of the heating water. | ||
- | This makes perfect sense: The values observed (for " | + | This makes perfect sense: The values observed (for " |
If 2-point mode is enabled, bit 8 is set and bits 1-7 carry a value of 52°C, in analogue mode bit 8 is never set and bits 1-7 carry the target heating water temperature. | If 2-point mode is enabled, bit 8 is set and bits 1-7 carry a value of 52°C, in analogue mode bit 8 is never set and bits 1-7 carry the target heating water temperature. | ||
Zeile 216: | Zeile 225: | ||
|::: ^9 | 0x00/01 | Repeat: 0x00 for original signal, 0x01 for repeat signal (bit 1) | | |::: ^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) | | |::: ^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 manual | + | |::: ^11 | 0xB4/00/... | Heating: 0x00 for OFF, 0xB4 for ON, Target heating water temperatur for analogue |
|::: ^12 | 0x00 | Battery: 0x00 for OK, 0x01 for LOW (bit 1) | | |::: ^12 | 0x00 | Battery: 0x00 for OK, 0x01 for LOW (bit 1) | | ||
|::: ^13-14 | 0xFD .. | 2-byte Checksum (signed integer): negative of the sum of bytes 4-12 | | |::: ^13-14 | 0xFD .. | 2-byte Checksum (signed integer): negative of the sum of bytes 4-12 | | ||
^15 || 0xFF | End of Signal indicator | | ^15 || 0xFF | End of Signal indicator | | ||
^16 || 0x00 | Epilogue (no data any more) | | ^16 || 0x00 | Epilogue (no data any more) | | ||
+ | {{: | ||
All bytes are converted to a bit sequence with least-significant bit first. | 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, | 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, | ||
Zeile 228: | Zeile 239: | ||
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). | 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). | ||
- | ===== RF detection ===== | + | ==== Setup Mode: RF detection |
+ | Playing around with the operator and installation modes of the Vaillant VRT340f, all signals I found fit perfectly well into the protocol described in the last section, except for one signal: | ||
+ | |||
+ | '' | ||
+ | 0x00 00 7E FF FF 00 FF 00 F1 FF FF 6D F6 20 00 02 00 F8 8F FF 00'' | ||
+ | |||
+ | As one can see, the signal is longer, but it still follows the same pattern of the begin and end of frame bytes. Also, bit-stuffing is still used, and the checksum is calculated just like in all other packets. However, there are some differences: | ||
+ | |||
+ | ^Byte ^^ Value ^Description ^ | ||
+ | ^1-2 || 0x00 00 | Preamble (square wave to synchronize clocks with the receiver) | | ||
+ | ^3 || 0x7E | Begin of frame/data (Constant) | | ||
+ | ^ 4-19 || Data content of the frame with 2-byte checksum attached || | ||
+ | | ^4-5 | 0xFF FF | Indicates broadcast | | ||
+ | |::: ^6-8 | 0x00 FF 00 | Unknown (constant) | | ||
+ | |::: ^9 | 0xF0/F1 | Repeat: 0xF0 for original signal, 0xF1 for repeat signal (bit 1, bits 5-8 always set) | | ||
+ | |::: ^10-11 | ||
+ | |::: ^12-13 | ||
+ | |::: ^14-17 | ||
+ | |::: ^18-19 | 0xF8 .. | 2-byte Checksum (signed integer): negative of the sum of bytes 4-17 | | ||
+ | ^20 || 0xFF | End of Signal indicator | | ||
+ | ^21 || 0x00 | Epilogue (no data any more) | | ||
+ | |||
+ | |||
+ | |||
+ | ====== Implementing support for the device in rtl_433, rflink and/or OpenHAB ====== | ||
+ | Now that we understand both the physical layer of the signal, as well as the structure of the protocol, we can go on to [[hardware: |
hardware/vaillantvrt340f_protocol.txt · Zuletzt geändert: 2017/05/11 19:28 von reinhold