Benutzer-Werkzeuge

Webseiten-Werkzeuge


hardware:vaillantvrt340f

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 [2017/04/23 00:12] – [Getting a file of 0/1 states] reinholdhardware:vaillantvrt340f [2017/05/11 21:46] (aktuell) reinhold
Zeile 1: Zeile 1:
 ====== Decoding the wireless heating control Vaillant CalorMatic 340f (868MHz) ====== ====== Decoding the wireless heating control Vaillant CalorMatic 340f (868MHz) ======
 +  - [[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_implementing|Part 3: Including the device in rtl_433 and potentially in RFLink or OpenHAB]]//
  
-In our appartment, we have a wireless heating control system made by Vaillant (probably 8-10 years old). Since I recently started into Smart Home and Home Automation (well, so far, i have mainly set up a huge net of all different kinds of sensors and some light bulbs, as I have hardly anything that could be controlled wirelessly), of course I wanted to figure out how the wireless device works and in particular whether I could include it into my OpenHAB-based home network of things...+{{:hardware:vaillant_calormatic340f:vaillant-thermostat-calormatic-340f-front.jpg?direct&400|}}
  
-To detect and analyze the wireless signals, I'm using an RTL282x-based DVB-T dongle together with the RTL-SDR software.+In our apartment, we have a wireless heating control system made by Vaillant (probably 8-10 years old). Since I recently started into Smart Home and Home Automation (well, so far, i have mainly set up a huge net of all different kinds of sensors and some light bulbs, as I have hardly anything that could be controlled wirelessly), of course I wanted to figure out how the wireless device works and in particular whether I could include it into my [[http://www.openhab.org|OpenHAB]]-based home network of things... 
 + 
 +To detect and analyze the wireless signals, I'm using an RTL282x-based DVB-T dongle together with the [[http://www.rtl-sdr.com/|RTL-SDR]] software.
  
 ===== Figuring out the Frequency ===== ===== Figuring out the Frequency =====
Zeile 125: Zeile 130:
 ===== Extracting the binary information ===== ===== Extracting the binary information =====
  
-Now we have the raw file containing the signal, let' +Now we have the raw file containing the signal, let'find out the binary interpretation of the signal. 
-===== What do the long and short pulses actually mean in binary? =====+
  
-Having a transition from UP to DOWN or from DOWN to UP at regular intervals sounds a log like [[https://en.wikipedia.org/wiki/Manchester_code|Manchester Code]].+==== Manchester Encoding? ====
  
  
 +Above we noticed that the signal had periodic transitions from high to low and vice versa every. For signal processing hardware, this makes it easy to synchronize clocks at the receiver side. One of the most famous such encodings is [[https://en.wikipedia.org/wiki/Manchester_code|Manchester encoding]], where there is one transition in the center of each bit period (and potentially also between bit periods, but they are irrelevant). In particular, a 0->1 transition means a digital 0 and a 1->0 transition means a digital 1 (in IEEE 802.3). Let's check if our signal is Manchester encoded.
 +
 +Remember, the original signal was:
 +  11001100110011001100110011001100110101010101010010110101001010110....
 +
 +For Manchester decoding, let's split it up into bit periods that always contain a transition in their middle (add the 0 at the beginning, which we didn't transcribe above):
 +  01|10|01|10|01|10|01|10|01|10|01|10|01|10|01|10|01|10|10|10|10|10|10|10|01|01|10|10|10|01|01|01|10|....
 +We only have 01 (meaning 1) and 10 (meaning 0), so let's transcribe the signal with these replacements:
 +  101010101010101010000000....
 +
 +Transcribing the signal manually was way too cumbersome, so I wrote a little C program to do the Manchester decoding by piping the output of gnuradio-companion through it (or alternatively, any text file containing thesignal): [[https://github.com/kainhofer/vaillant-calormatic340f/blob/master/Manchester_decode.c|Manchester_decode.c]]
 +
 +Transcribing the whole signal and its repeat, we end up with:
 +  01010101010101010111111100111000100011111010101010101001010101010101010101010101101100011010101011000000111011011000000000101010101
 +  01010101010101010111111100111000100011111010101010101001010101010010101010101010010011100101010100111111001011011000000000101010101
 +
 +Hmm, a lot of alternating 1 and 0 sequences. And the "repeat" is quite different from the signal (albeit it is mainly just inverted). But for some signals I observed (in particular with low battery status), the inversion lasted almost until the end:
 +
 +  01010101010101010111111100111000100011111010101010101001010101010101010101011010010011100010101011000000110101011000000000101010101
 +  01010101010101010111111100111000100011111010101010101001010101010010101010100101101100011101010100111111000000111011111111101010101
 +
 +
 +This doesn't look too convincing. So, probably not Manchester code.
 +
 +==== XOR'ing with a 1100 base wave ====
 +
 +If we look at the signal again (11001100110011001100...), it starts with a perfect square wave that is responsible for the period transitions. After the initial preamble, the signal deviates, but the key feature of the underlying square wave is always present. What if the information is actually contained in the difference to the square wave 1100110011001100...? If we [[https://github.com/kainhofer/vaillant-calormatic340f/blob/master/Basewave_extract.c|XOR the signal with a perfect square wave]] 110011001100110011001100... we simply remove those periodic transitions that are only meant to help the receiver sync its clock. Does that lead to more useful data?
 +  0000000000000000000000000000000000011001100110000111100111100111111001111001100111111111111111111111111111100000000000000000000000000000000000000000000000000001111110000110000111111111111111111000011001100111100111111000000111100110011001100111111111111111111111
 +  0000000000000000000000000000000000011001100110000111100111100111111001111001100111111111111111111111111111100000000000000000000001111111111111111111111111111110000001111001111000000000000000000111100110011000011111111000000111100110011001100111111111111111111111
 +
 +Actually, the signal looks easier to understand visually, but the huge differences between the signal and its "repeat" are still there. Even worse: The 11001100110011 epilogue at the end of the signal is apparently NOT synchronized with a square wave starting with the square wave preamble, so we end up with 11111 at the end. 
 +
 +Again, this is probably also not the way to go.
 +
 +==== Transition or not? ====
 +
 +Since our signal appears to guarantee a transition every two digits, there cannot be any information encoded in those transitions. However, between those periodic transitions, sometimes there is another transition and for other periods there is no further transition. What if the information is actually encoded in whether there is a transition or not?
 +
 +Let's split our signal at the periodic transitions (Manchester encoding split it halfway in between, now we are splitting it differently!):
 +  11|00|11|00|11|00|11|00|11|00|11|00|11|00|11|00|11|01|01|01|01|01|01|00|10|11|01|01|00|10|10|11|0....
 +  0  0  
 +We now have four different parts, 00, 01, 10 and 11. 00 and 11 don't have a transition, so let's say this encodes 0 and 01 and 10 have a transition, which we understand as a binary 1. This leads to the transcription
 +  11|00|11|00|11|00|11|00|11|00|11|00|11|00|11|00|11|01|01|01|01|01|01|00|10|11|01|01|00|10|10|11|0....
 +  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  1  1  1  1  1  1  0  1  0  1  1  0  1  1  0   
 +
 +Again, I wrote a little C program to automate this decoding: [[https://github.com/kainhofer/vaillant-calormatic340f/blob/master/Vaillant_decode.c|Vaillant_decode.c]]
 +
 +Our signal and the "repeat" from above now become:
 +  00000000000000000111111010110110011011110000000000000100000000000000000000000001001011010000000010111110110010010111111110000000000
 +  00000000000000000111111010110110011011110000000000000100000000001000000000000001001011010000000010111110100010010111111110000000000
 +
 +
 +Not bad. In particular, the signal and its repeat only differ at two places (the two spots that we already identified in audacity)...
 +
 +It looks like we have extracted the actual binary information from the 868MHz signal.
 +
 +UPDATE: After some more reading, it seems that this type of encoding is also known as [[https://en.wikipedia.org/wiki/Differential_Manchester_encoding|Differential Manchester encoding]] or Bi-Phase Mark Code. 
  
  
  
 ===== Decoding the Messages ===== ===== Decoding the Messages =====
 +
 +Now that we know the binary contents of the messages sent by the thermostat to the boiler, the next step is to understand what these messages actually mean. [[hardware:vaillantvrt340f_protocol|I'll describe this decoding in a separate post.]] 
 +
 +
 +
 +===== UPDATE: Bit stuffing -- but WHY? =====
 +
 +During my tests of the wireless control, I collected various different signals. Trying to group them into octets for bytes, I ended up with a dilemma: I realized that the second-to-last byte should be 0xFF and the one before was probably some kid of checksum. That left me with 9 bits before that checksum byte:
 +
 +<html>
 +<pre>00000000 00000000 01111110 10110110 01101111 00000000 00000100 00000000 00000000 00010001 00101101 00000000 <span style="color: red; font-weight: bold">101111101</span> 10000010 11111111 000000000
 +00000000 00000000 01111110 10110110 01101111 00000000 00000100 00000000 10000000 00010001 00101101 00000000 <span style="color: red; font-weight: bold">101111101</span> 00000010 11111111 000000000
 +00000000 00000000 01111110 10110110 01101111 00000000 00000100 00000000 00000000 00010001 00000000 00000000 <span style="color: red; font-weight: bold">101111101</span> 10101111 11111111 000000000
 +00000000 00000000 01111110 10110110 01101111 00000000 00000100 00000000 10000000 00010001 00000000 00000000 <span style="color: red; font-weight: bold">101111101</span> 00101111 11111111 000000000
 +00000000 00000000 01111110 10110110 01101111 00000000 00000100 00000000 00000000 00000001 00000000 00000000 <span style="color: red; font-weight: bold">101111101</span> 10111110 11111111 <span style="color: red; font-weight: bold">1</span>000000000
 +00000000 00000000 01111110 10110110 01101111 00000000 00000100 00000000 00000000 00000001 01111100 00000000 <span style="color: red; font-weight: bold">010111110</span> 11111011 01111111 <span style="color: red; font-weight: bold">11</span>0000000 00
 +00000000 00000000 01111110 10110110 01101111 00000000 00000100 00000000 10000000 00000001 01111100 00000000 <span style="color: red; font-weight: bold">010111110</span> 10111110 01111111 <span style="color: red; font-weight: bold">11</span>0000000 00
 +</pre></html>
 +
 +The first four observations were among the most frequent signals.
 +
 +In this table, I already split the binary signal into octets, i.e. bytes. Since the full signal has 129-131 bits, some extra bits need to be included to form 9-bit parts somewhere.
 +
 +As my reasoning in part 2 shows, that extra byte must be before the final three bytes, but after the fifth-to-last one. So we have the 9-bit sequence 101111101 that we must make sense of. Even worse, the last two observations appear to be shifted by one additional bit after a bit sequence of 01111100.
 +
 +After some googling, I stumbled upon the [[https://en.wikipedia.org/wiki/High-Level_Data_Link_Control#Framing|framing approach in the High-Level Data Link Control]], where the frames start with 0x7e=01111110 and the bit stuffing in the data part means that after five consecutive 1 bits, an extra 0 bit is included, which must be removed at the receiving end. Indeed, the 101111101 bit sequence is the only appearance of five consecutive 1 bits in the first few examples. Some other signals also contained sequences of 5 (but not more) consecutive 1 bits, followed by a seemingly spurious zero... Bit stuffing would explain this spurious 0 bit and even demand to remove it before interpreting the signal. If we do bit unstuffing on our signals (again, using a little helper utility [[https://github.com/kainhofer/vaillant-calormatic340f/blob/master/Vaillant_decode_bitstuff.c|Vaillant_decode_bitstuff.c]]), suddenly the signal aligns perfectly into octets to form bytes:
 +
 +| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00101101\ 00000000\ 10111111\ 10000010\ 11111111\ 00000000'' |
 +| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00010001\ 00101101\ 00000000\ 10111111\ 00000010\ 11111111\ 00000000'' |
 +| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00000000\ 00000000\ 10111111\ 10101111\ 11111111\ 00000000'' |
 +| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00010001\ 00000000\ 00000000\ 10111111\ 00101111\ 11111111\ 00000000'' |
 +| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00000001\ 00000000\ 00000000\ 10111111\ 10111111\ 11111111\ 00000000'' |
 +| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00000001\ 01111100\ 00000000\ 10111111\ 11111101\ 11111111\ 0000000'' |
 +| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00000001\ 01111100\ 00000000\ 10111111\ 01111101\ 11111111\ 0000000'' |
 +
 +So, the pysical layer appears to be encoded using differential Manchester coding, after bit-stuffing. Somehow to me this does not make too much sense, as bit-stuffing  is used mainly to cause state transitions at last every five bits to allow the receiver to synchronize its clock. However, the underlying differential Manchester coding of our signal already ensures a transition after every bit, so there is no need in my eyes for additional bit-stuffing.
 +
 +But as the evidence is so overwhelmingly in favor of bit-stuffing, let's accept that the signal is bit-stuffed (except for the two final 0xFF 00 bytes) and then transmitted using differential Manchester coding. 
 +
 +
 +===== Finally: Decoding the Messages =====
 +
 +Now that we finally know the binary contents of the messages sent by the thermostat to the boiler, the next step is to understand what these messages actually mean. [[hardware:vaillantvrt340f_protocol|I'll describe this decoding in a separate post.]] 
 +
  
hardware/vaillantvrt340f.1492899176.txt.gz · Zuletzt geändert: 2017/04/23 00:12 von reinhold

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki