Protokoll

Übersicht

Wenn jemand die Möglichkeit hat die Kommunikation mit einer Raumstation oder Steuersoftware mitzuschneiden, ist das für gesuchte Aktionen sehr hilfreich. Ein entsprechendes Dump-Tool liegt im git Repository. Ein Anleitung findet sich unter Mitmachen.

Die Werte in den Logs (z.B. 90) sind jeweils zwei Zeichen = ein Byte in Hexadezimal-Schreibweise, also 90 = 0x90.

Beobachtet wurde bisher ein festes sich wiederholendes Muster für eine Steuerung ohne Raumstation:

eine Folge aus 19 mal 5 gleich Byte zu Synchronisation
5 mal ein Datagram mit jeweils 41 Bytes, das je eine Nachricht zu Temperaturen und sonstigen Werten enthält plus Separatoren zwischen den Nachrichten
5 mal ein Datagram mit jeweils 18 Bytes, das je eine Nachricht zu Datum und Uhrzeit enthält plus Separatoren zwischen den Nachrichten

Eine Raumstation beginnt während der Synchronisation Bytes zu senden, näheres siehe unter Raumstation.

Beispiel:

00 a3 a3 a3 a3 a3 11 11 11 11 11 12 12 12 00 00 12 12 93 93 93 93 93 14 14 14 14 14 95 95 95 95 95 96 96 96 96 96 17 17 17 17 17 18 18 18 18 18 99 99 99 99 99 9a 9a 9a 9a 9a 1b 1b 1b 1b 1b 9c 9c 9c 9c 9c 1d 1d 1d 1d 1d 1e 1e 1e 1e 1e 9f 9f 9f 9f 9f

ff 82 10 20 20 04 97 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 00 00 00 00 00 00 00 00 00 00 00 73 0a 73 aa 03

fc 82 10 20 09 05 00 53 51 16 11 74 14 05 07 b7 7c 03

00 a3 a3 a3 a3 a3 11 11 11 11 11 12 12 12 00 00 12 12 93 93 93 93 93 14 14 14 14 14 95 95 95 95 95 96 96 96 96 96 17 17 17 17 17 18 18 18 18 18 99 99 99 99 99 9a 9a 9a 9a 9a 1b 1b 1b 1b 1b 9c 9c 9c 9c 9c 1d 1d 1d 1d 1d 1e 1e 1e 1e 1e 9f 9f 9f 9f 9f

Achtung: Die Datagramme sind häufig identisch, müssen es aber nicht sein!

Synchronisation: Sync Bytes

Es werden regelmäßig folgende Bytes übertrage, 19 mal 5 gleich Byte, die keine Informationen enthalten und daher wohl zur Synchronisierung und zusätzlicher Erkennung von Störungen auf der Leitung dienen. Zwischen den Bytes wird jeweils eine Pause gemacht.

90 90 90 90 90 21 21 21 21 21 22 22 22 22 22 a3 a3 a3 a3 a3 11 11 11 11 11 12 12 12 12 12 93 93 93 93 93 14 14 14 14 14 95 95 95 95 95 96 96 96 96 96 17 17 17 17 17 18 18 18 18 18 99 99 99 99 99 9a 9a 9a 9a 9a 1b 1b 1b 1b 1b 9c 9c 9c 9c 9c 1d 1d 1d 1d 1d 1e 1e 1e 1e 1e 9f 9f 9f 9f 9f

Datagramme

Datagramme bestehen aus einer Byte-Folge mit einem Header (vorneweg) und der Nachricht und der Checksumme (hinten). Zusätzlich gibt es Separatoren, eine Bytefolge zwischen den Nachrichten.

Separatoren

Werden NICHT bei der Checksumme berücksichtigt

Bisher wueder ein bis vier Bytes zwischen den Datagrammen gesehen

Beispiel: $TT 82 vor Datagram

Position 1: $TT - ein Byte, anscheinend abhängig vom Nachrichten-Typ, oder von der Reihenfolge der Nachrichten?

Position 2: 82 - Ende immer statisch (?)

Beispiel: 03 nach Datagram

Position 1: 03 - Ende immer statisch (?) Es schein aber auch 06 03 am Ende zu geben

Header

Beispiel: 10 20 $LL

Position 1-2: 10 20 - z.Z immer statisch (?). Wird bei der Checksumme berücksichtigt. Gute Kandidaten für die Quell- und Ziel-Adresse?!

Position 3: $LL - ein Byte, das die Länge des Inhalts bestimmt. Ist nullbasiert, also plus 1 weiterlesen für den Inhalt. Plus 2 weitere Bytes für die Checksume. Für das gesamte Datagram also $LL+3 Bytes weiter lesen.

Nachricht

Die eigentlichen Daten, je nach Nachrichten-Typ unterschiedlich, siehe dort.

Checksumme

Bei der Checksummen Berechnung werden der Header (vermutlich die Quell- und Ziel-Adresse und die Nachrichten-Länge) und die Nachricht selber berücksichtigt.

Beispiel Datagram: fc 82 - 10 20 09 --- 05 00 41 13 14 17 80 15 01 08 --- 5f 2f - 03

Verwendet für die Berechnung: 10 20 09 --- 05 00 41 13 14 17 80 15 01 08

Checksumme: 5f 2f

Als Algorithmus wird CCITT KERMIT verwendet

Polynom: 0x11021
Reversed: True
Init-value: 0x0000
XOR-out: 0x0000

Zum ausprobieren: https://www.lammertbies.nl/comm/info/crc-calculation.html oder https://www.tahapaksu.com/crc/ öffnen und HEX als Modus auswählen, "10200905004113141780150108" als Nachricht eintragen und die Checksumme berechnen lassen. Der Wert bei der Kermit Variante sollte "0x5F2F" annehmen...

Addressen

Laut der Anleitung kann man an der Heizungssteuerung eine Bus-Adresse zwischen 1 und 5 einstellen, Default ist 1. Zusätzlich gibt es ein festes Schema für 16 Mischerkreisläufe. Das müsste dann auch in den verbleibenden unbekannten Bytes (10 20) im Header als Sende- und Empfanges-Adresse auftauchen. Da nur die durch die Checksumme abgesichert ist, ist das der aussichtsreiche Kandidat. Gefunden wurden bisher folgende Kombinationen: 10 20, 10 ff, 10 aa, 21 aa, 23 aa, 21 10, 21 20, 23 10, 23 20.

21 und 23 wurden jeweils nur bei unterschiedlichen Raumstationen gefunden.

Nicht geklärt: Es scheint so, als ob die Raumstation aber auch Nachrichten mit 10 aa sendet?

Nachrichten-Typen für den Betrieb ohne Raumstation

Datum und Zeit (0905)

Nachrichten-Typ 0905 Länge ohne Footer: 0x09 = 9 plus 1 => 10

Anmerkung Wird eine Position als "in Hex" bezeichnet, interpretiert man den Hex-Wert direkt als Dezimal Wert. Beispiel: 0x20 ist 20, 0x42 ist 42, und nach 0x49 kommt 0x50 ;)

Beispiel: fc 82 - 10 20 09 --- 05 00 41 13 14 17 80 15 01 08 --- 5f 2f 03

Beispiel: 7d 82 - 10 20 09 --- 05 02 06 31 22 13 a0 14 01 10 --- 1e a2 03

Beispiel nur Inhalt: 05 00 41 13 14 17 80 15 01 08

Position 1: Nachrichten-Typ 05

Position 2: Bisherige Beobachtung: Immer 00 wenn die Heizungssteuerung die Uhrzeit im normalen Rhythmus sendet. Wird die Uhrzeit an der Heizungssteuerung geändert wird der Wert auf 02 gesetzt.

Position 3: Sekunden der Uhrzeit, in Hex

Position 4: Minuten der Uhrzeit, in Hex

Position 5: Stunden der Uhrzeit, 24 Stunden basiert, in Hex

Position 6: Tag im Monat, in Hex

Position 7: Monat und Tag der Woche. Als Hex Wert 0x$M$T betrachtet ist die erste Ziffer $m der Monat (Monat einsbasiert), die zweite Ziffer $T der Tag in der Woche (Tag nullbasiert). Beispiel 0xa1 => 0xa = zehntner Monat(eins-basiert), 0x1 = zweiter Tag (null-basiert!), also Dienstag

Position 8: Die letzen beiden Ziffern des Jahres, 14 => 2014, in Hex

Position 9: Tag im der Woche, eins-basiert, 01 = Montag

Position 10: Monat, in Hex

Temperatur und andere Werte (2004)

Nachrichten-Typ 2004 Länge ohne Footer: 0x20 = 32 plus 1 => 33

Beispiel: ff 82 10 20 20 --- 04 88 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 00 00 00 00 00 00 00 00 00 00 00 5e 0a --- 73 98 03

Beispiel nur Inhalt: 04 88 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 00 00 00 00 00 00 00 00 00 00 00 5e 0a

In dem letzen dreiviertel Jahr wurden folgende Werte gesehen. Ohne Garantie, neue Auswertung läuft...

Position 1: Nachrichten-Typ 04

Position 2: Außen-Temperatur, berechnet mit int(value, 16)/2.0 - 52.0

Position 3: unbekannter Wert, immer 0x10

Position 4: unbekannter Wert, bisher entweder 0x00 oder 0x02 oder 0xff

Position 5: unbekannter Wert, bisher entweder 0x00 oder 0x10

Position 6-16: unbekannter Wert, immer 0x00

Position 17: Temperatur, berechnet mit int(value, 16)/2.0, kann auch 0 sein, scheinbar nur wenn der Brenner aktiv ist größer 0

Position 18: unbekannter Wert, bisher entweder 0x00 oder 0x10

Position 19: z.Z immer 0xf1, selten auch mal 0x01

Position 20: z.Z immer 0x10

Position 21-29: z.Z immer statisch 0x00

Position 30: unbekannter Wert, bisher entweder 0x00 oder 0x10

Position 31: unbekannter Wert, bisher entweder 0x00 oder 0x01

Position 32: Kesseltemp, berechnet mit int(value, 16)/2.0

Position 33: unbekannter Wert, bisher im Bereich von 0x0A bis 0x51 (Notiz:5.0-40.5 als Temp?)

Kommunikation mit einer Raumstation

Hier werden die Nachrichten für die Kommunikation mit der Raumstation dokumentiert.

Arbeitshypothese

Änderungen Stand 22.20.2015 (werden erst noch auf den gesamten Artikel nachgezogen)

Ein Datagram sind alle Bytes, die mit der Checksumme überprüft werden können, inklusive der Checksummen
Nachrichten sind die "Nutzdaten" des Datagram, ohne die ersten drei Bytes und ohne Checksumme. 1. Byte Datagram und 2. Byte Datagram: Adresse; 3. Byte Datagram: Länge Nachricht
Bis klar ist, wie die Adressierung passiert und wer was wann schickt: Nachrichten werden beschrieben als "Nachricht an eine Adresse" (1. Byte Datagram und 2. Byte Datagram). Beispiel: Nachrichten an 1020, oder an 2110, oder an 2310 oder an 10aa
Nachrichten werden nach ihrer Länge (3. Byte Datagram) und dem 4. Byte Datagram typisiert. 1.Beispiel ´10 20 10 05´ -> Nachrichtenart: 1005 2.Beispiel ´23 10 01 01´ -> Nachrichtentyp: 0101
Wenn Raumstationen verbunden sind, kommen je Raumstation Nachrichten an folgende Adressen dazu:
- XX10, XX20, 10aa, XXaa wobei XX aus dieser Liste ist:
  - 21 für die Busadresse 1 der Raumstation
  - 22 für die Busadresse 2 der Raumstation
  - 23 für die Busadresse 3 der Raumstation
  - 1b für die Busadresse 0 der Raumstation (Hier scheint es, als ändert sich die Sync-Bytes Rheinefolge etwas und es kommen auch neue Sync-Bytes(acacacacac): 1b1b1b1b1b,acacacacac,1414141414,9595959595,9696969696,1717171717,1818181818,9999999999,9a9a9a9a9a,1b1b1b1b1b,9c9c9c9c9c,1d1d1d1d1d,1e1e1e1e1e,9f9f9f9f9f)

Bekannte Nachrichten, ohne Raumstation:

Nachrichten an 1020 vom Typ 0905: Datum und Zeit, siehe oben
Nachrichten an 1020 vom Typ 2004: Temperaturen, siehe oben

Beobachtete neue Nachrichten:

Daten Nachrichten (Vermutung!)
- Nachrichten an 1020 vom Typ 8001: Wird nicht immer gesendet
- Nachrichten an 1020 vom Typ 1005: Datum und Zeit, beinhaltet die gleichen Daten wie 0905, aber noch 7 Bytes mehr
- Nachrichten an 1020 vom Typ 2806: evtl Einstellungen?
- Nachrichten an 1020 vom Typ 3806: evtl Einstellungen? gleiche Daten wie 2806, aber noch 16 Bytes mehr
- Nachrichten an 1020 vom Typ 4002: Temperaturen? beinhaltet die gleichen Daten wie 2004, aber noch 32 Bytes mehr
Absprache Nachrichten, wer mit Senden dran ist (Vermutung!)
- Nachrichten an XXaa und 10aa vom Typ 0100: Werden vor und nach den Sync-Bytes gesendet. Bisher nur mit den Daten 00 oder 01 gesehen
Anfragen (Vermutung!)
- Nachrichten an XX10 vom Typ 0105 mit Daten 10: Danach kommt eine Nachricht an 1020 vom Typ 1005
- Nachrichten an XX10 vom Typ 0106 mit Daten 28: Danach kommt eine Nachricht an 1020 vom Typ 0628
- Nachrichten an XX10 vom Typ 0106 mit Daten 38: Danach kommt eine Nachricht an 1020 vom Typ 0638, gleiche Daten wie beim Typ 2806, aber 16 Bytes mehr
- Nachrichten an XX10 vom Typ 0102 mit Daten 40: Danach kommt eine Nachricht an 1020 vom Typ 0240
- Nachrichten an XX10 vom Typ 0101 mit Daten 80: Danach kommt eine Nachricht an 1020 vom Typ 0180
Schreiben von Werten (Vermutung!)
- Nachrichten an XX20 vom Typ 2806: Kommen nach einer Nachricht an 1020 vom Typ 2806
- Nachrichten an XX20 vom Typ 3806: Kommen nach einer Nachricht an 1020 vom Typ 3806, gleiche Daten wie beim Typ 2806, aber 16 Bytes mehr
Änderung von Werten, wenn man die Raumstation benutzt, z.B. Warmwasser-Sollwert ändern Nach dem obigem Schema:

eine Anfrage vom Typ 0114 80
Daten Nachricht vom Typ 8014: Der Inhalt sieht der vom Typ 8001 seht ähnlich
teilweise Nachrichten an XX20 vom Typ 8014 Auch noch gesehen:

eine Anfrage vom Typ 0111 80, dann Daten Nachricht vom Typ 8011, teilweise Nachrichten an XX20 vom Typ 8011
eine Anfrage vom Typ 0112 80, dann Daten Nachricht vom Typ 8012, teilweise Nachrichten an XX20 vom Typ 8012
eine Anfrage vom Typ 0113 80, dann Daten Nachricht vom Typ 8013, teilweise Nachrichten an XX20 vom Typ 8013

Nachrichten

Nachrichtentyp 2806

Vermutung: Position P02 XX Kandidat Aktuelle Temp an der Raumstation ??? (Null wenn Raumstation noch gerade angeschlossen wird)
Vermutung: Position P04 XX Kandidat Aktuelle Temp an der Raumstation ??? 0x2b->43 = 21,5
Vermutung: Position P10 YY Warmwasser Soll 0x64->100/2 = 50
Vermutung: Position P11 WW Warmwasser nachladen = 01 (geht danach auf 02)

Vermutung: jeweils ein Block für die Drei Programme? Noch zu Testen...

Vermutung: Position P21 Kandidat für TagesTemp?? 0x2a-> 42/2 = 21
Vermutung: Position P22 Kandidat für NachtTemp?? 0x20-> 32/2 = 16
Vermutung: Position P29 Kandidat für TagesTemp?? 0x2a-> 42/2 = 21
Vermutung: Position P30 Kandidat für NachtTemp?? 0x20-> 32/2 = 16
Vermutung: Position P37 Kandidat für TagesTemp?? 0x2a-> 42/2 = 21
Vermutung: Position P38 Kandidat für NachtTemp?? 0x20-> 32/2 = 16

Nachrichtentyp 8014 bzw. 8001

Vermutung: Position P36 Heizkennliniensteilheit Bereich 0.20 - 3.50 in 0.5 Schritten, Werkseinstellung 1.5
- Berechnung: Wert * 20

Nachrichtentyp 4002

Vermutung: Position P08 Warmwasser Temp
Vermutung: Position P11=Vorlauftemp.
Vermutung: Position P12=Kesseltemp. (gleicher Werte wie P64)

Beispiel in unterschiedlichen Schreibweisen für die Suchmaschinen

Beispiele in Hexadezimal 1

a3 a3 a3 a3 a3 11 11 11 11 11 12 12 12 00 00 12 12 93 93 93 93 93 14 14 14 14 14 95 95 95 95 95 96 96 96 96 96 17 17 17 17 17 18 18 18 18 18 99 99 99 99 99 9a 9a 9a 9a 9a 1b 1b 1b 1b 1b 9c 9c 9c 9c 9c 1d 1d 1d 1d 1d 1e 1e 1e 1e 1e 9f 9f 9f 9f 9f

ff 82 10 20 20 04 97 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 00 00 00 00 00 00 00 00 00 00 00 73 0a 73 aa 03

fc 82 10 20 09 05 00 53 51 16 11 74 14 05 07 b7 7c 03

a3 a3 a3 a3 a3 11 11 11 11 11 12 12 12 00 00 12 12 93 93 93 93 93 14 14 14 14 14 95 95 95 95 95 96 96 96 96 96 17 17 17 17 17 18 18 18 18 18 99 99 99 99 99 9a 9a 9a 9a 9a 1b 1b 1b 1b 1b 9c 9c 9c 9c 9c 1d 1d 1d 1d 1d 1e 1e 1e 1e 1e 9f 9f 9f 9f 9f

Beispiele in Hexadezimal 2

0xa3 0xa3 0xa3 0xa3 0xa3 0x11 0x11 0x11 0x11 0x11 0x12 0x12 0x12 0x00 0x00 0x12 0x12 0x93 0x93 0x93 0x93 0x93 0x14 0x14 0x14 0x14 0x14 0x95 0x95 0x95 0x95 0x95 0x96 0x96 0x96 0x96 0x96 0x17 0x17 0x17 0x17 0x17 0x18 0x18 0x18 0x18 0x18 0x99 0x99 0x99 0x99 0x99 0x9a 0x9a 0x9a 0x9a 0x9a 0x1b 0x1b 0x1b 0x1b 0x1b 0x9c 0x9c 0x9c 0x9c 0x9c 0x1d 0x1d 0x1d 0x1d 0x1d 0x1e 0x1e 0x1e 0x1e 0x1e 0x9f 0x9f 0x9f 0x9f 0x9f

0xff 0x82 0x0x10 0x20 0x20 0x04 0x97 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xf1 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x0a 0x73 0xaa 0x03

0xff 0x82 0x10 0x20 0x20 0x04 0x97 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xf1 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x0a 0x73 0xaa 0x03

0xfc 0x82 0x10 0x20 0x09 0x05 0x00 0x53 0x51 0x16 0x11 0x74 0x14 0x05 0x07 0xb7 0x7c 0x03