Benutzer-Werkzeuge

Webseiten-Werkzeuge


hardware:vaillantvrt340f_protocol

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
hardware:vaillantvrt340f_protocol [2017/05/05 13:25] reinholdhardware:vaillantvrt340f_protocol [2017/05/11 21:28] (aktuell) reinhold
Zeile 2: Zeile 2:
   - [[hardware:vaillantvrt340f|Part 1: The physical layer - Reading the wireless signal and extracting the bytes]]   - [[hardware:vaillantvrt340f|Part 1: The physical layer - Reading the wireless signal and extracting the bytes]]
   - [[hardware:vaillantvrt340f_protocol|Part 2: Decoding the protocol]]   - [[hardware:vaillantvrt340f_protocol|Part 2: Decoding the protocol]]
-  - __[[hardware:vaillantvrt340f_implementing|Part 3: Including the device in rtl_433 and potentially in RFLink or OpenHAB - Yet to be done]]__+  - //[[hardware:vaillantvrt340f_implementing|Part 3: Including the device in rtl_433 and potentially in RFLink or OpenHAB]]//
  
 After we investigated the wireless signal that was sent by the Vaillant CalorMatic 340f over the 868MHz frequency and extracted the binary contents [[hardware:vaillantvrt340f|in the first part of our series]], this second part will now deal with understanding the meaning of the bits and bytes sent to the boiler. After we investigated the wireless signal that was sent by the Vaillant CalorMatic 340f over the 868MHz frequency and extracted the binary contents [[hardware:vaillantvrt340f|in the first part of our series]], this second part will now deal with understanding the meaning of the bits and bytes sent to the boiler.
Zeile 84: 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 (again using a [[https://github.com/kainhofer/vaillant-calormatic340f/blob/master/Vaillant_decode_bitstuff_hex.c|little self-written utility]]):
  
 ^Heat.^Wat.^Rep.^Bat.| ''Byte1\ 2\ \ 3\ \ 4\ \ 5\ \ 6\ \ 7\ \ 8\ \ 9\ 10\ 11\ 12\ 13\ 14\ 15\ 16'' | ^Heat.^Wat.^Rep.^Bat.| ''Byte1\ 2\ \ 3\ \ 4\ \ 5\ \ 6\ \ 7\ \ 8\ \ 9\ 10\ 11\ 12\ 13\ 14\ 15\ 16'' |
Zeile 150: Zeile 150:
  
 ==== UPDATE: Making sense of the 0xFD byte 13 ==== ==== UPDATE: Making sense of the 0xFD byte 13 ====
-The byte 13 with unknown constant value 0xFD kept bothering me, and a few days after I understood the checksum byte I figured out its meaning too: As I mentioned, bytes 4-12 together with the checksum byte 14 summed up always yielded 0x0300. It seemed strange to me that the 0x03 byte of the sum was somehow ignored, until I realized that 0xFD is actually the binary complement of 0x03, i.e. the checksum is actually just byte 14, but the two-byte value of bytes 13 and 14. So, our assumption that bytes 13 with a value of 0xFD is some kind of End-Of-Data or separator byte was simply wrong, and it being constant is just a coincidence.+The byte 13 with unknown constant value 0xFD kept bothering me, and a few days after I understood the checksum byte I figured out its meaning too: As I mentioned, bytes 4-12 together with the checksum byte 14 summed up always yielded 0x0300. It seemed strange to me that the 0x03 byte of the sum was somehow ignored, until I realized that 0xFD is actually the binary complement of 0x03, i.e. the checksum is actually not just byte 14, but the two-byte value of bytes 13 and 14. So, our assumption that bytes 13 with a value of 0xFD is some kind of End-Of-Data or separator byte was simply wrong, and it being constant is just a coincidence.
  
-In short, bytes 13 and 14 are simply the binary negative of the sum of bytes 4-12, with most significant byte first, i.e. bytes 13+14 interpreted as a signed integer is -sum(byte 4-12). As we are summing up only 9 bytes, there will be no overflow, either (which was what was bothering me with the 0x03 when one understood only byte 14 as the checksum).+In short, bytes 13 and 14 are the binary negative of the sum of bytes 4-12, with most significant byte first, i.e. bytes 13+14 interpreted as a signed integer is -sum(byte 4-12). As we are summing up only 9 bytes, there will be no overflow, either (which was what was bothering me with the 0x03 when one uses only byte 14 as checksum).
  
  
Zeile 190: 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 the "P" button and the knob together for 3 seconds), the following signal is sent by the remote:+Let's print all observed values of the heating byte in correlation with the difference between target and current room temperature:{{:hardware:vaillant_calormatic340f:vaillant_calormatic340f_heatingbyte_tempdifference.png?direct|}} 
 + 
 +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 byte, only the difference to the target temperature. As observed above, the same temperature difference can lead to different heating bytes, but apparently, the possible intervals for each temperature difference are not overlapping. This is an indication that the wireless control displays the temperature only in 0.5°C steps, but measures the current room temperature (and thus the difference to the target) in higher accuracy. 
 + 
 +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 "P" button and the knob together for 3 seconds), the following signal is sent by the remote:
  
 ''0x00 00 7E 6D F6 00 20 00 00 80 32 00 FD CB FF 00\\ ''0x00 00 7E 6D F6 00 20 00 00 80 32 00 FD CB FF 00\\
Zeile 198: Zeile 205:
 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 "normal" room temperatures slightly above 20°C) are between 20 and 90 (decimal).+This makes perfect sense: The values observed (for "normal" room temperatures slightly above 20°C) are between 20 and 90 (decimal). Anything above 90°C for water is already dangerous considering the boiling temperature of 100°C.
  
 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 224: Zeile 231:
 ^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) |
 +{{:hardware:vaillant_calormatic340f:vaillant_calormatic340f_packetstructure_vertical.png?direct|}}
  
 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, 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.  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. 
Zeile 231: Zeile 240:
 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: RF detection
 + 
 +''0x00 00 7E FF FF 00 FF 00 F0 FF FF 6D F6 20 00 02 00 F8 90 FF 00\\ 
 +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: the Device ID does not appear at the beginning of the data, but somewhere in the middle. Instead the device ID is 0xFF FF, which probably indicates a broadcast. All other values are completely unknown to me, as they never change. 
 + 
 +^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  | 0xFF FF | Unknown (constant) | 
 +|::: ^12-13  | 0x6D F6 | Device ID of searching control (Constant for each device) |  
 +|::: ^14-17  | 0x20 00 02 00 | Unknown (constant) | 
 +|::: ^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:vaillantvrt340f_implementing|implementing support for it in applications like rtl_433 (part of GNUradio), rflink or OpenHAB in part 3 of our series]].
hardware/vaillantvrt340f_protocol.1493983535.txt.gz · Zuletzt geändert: 2017/05/05 13:25 von reinhold

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki