Vaillant X6 Schnittstelle: Unterschied zwischen den Versionen
Mali (Diskussion | Beiträge) |
Mali (Diskussion | Beiträge) |
||
Zeile 51: | Zeile 51: | ||
===Prüfsumme=== | ===Prüfsumme=== | ||
− | Die Berechnung der Prüfsumme ist | + | Die Berechnung der Prüfsumme hat mich einige Zeit gekostet. Das Verfahren ist aber nicht wirklich schwierig: |
− | + | sub checksum | |
− | + | { | |
+ | my $string = $_[0]; | ||
+ | my $checksum; | ||
+ | |||
+ | for (my $i = 0; $i < length($string); $i++) | ||
+ | { | ||
+ | if ($checksum & 0x80) | ||
+ | { | ||
+ | $checksum = ($checksum << 1 | 1) & 0xFF; | ||
+ | # ??? | ||
+ | $checksum = $checksum ^ 0x18; | ||
+ | } | ||
+ | else | ||
+ | { | ||
+ | $checksum = $checksum << 1; | ||
+ | } | ||
+ | $checksum = $checksum ^ ord(substr($string, $i, 1)); | ||
+ | } | ||
+ | return $checksum; | ||
+ | } | ||
− | + | Den Quelltext darf gerne mal jemand in C konvertieren ;-) ... Beim Finden des Algorithmus' waren kurze Nachrichten wie 03 03 05 und 03 01 07 nützlich. Es fiel dann aber auf, dass die Berechnung immer dann zu einem anderen Ergebnis führt, wenn die Zwischen-Prüfsumme im Verlauf der Berechnung größer als 127 wird. In der Nachricht 07 00 00 00 98 05 CC ist dies erst beim letzten Datenbyte der Fall. Von dort konnte man also zurückrechnen, was man an der Zwischen-Prüfsumme ändern muss, um letztendlich auf die gleiche Prüfsumme zu kommen wie das Gerät. Diese Änderung ist genau ein XOR mit 18h. Siehe auch [http://coding.derkeiler.com/Archive/General/comp.arch.embedded/2008-06/msg00256.html] und [http://www.gamefaqs.com/console/nes/file/563408/47175]. | |
− | |||
− | |||
− | |||
− | und | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===Befehle=== | ===Befehle=== |
Version vom 6. Jänner 2010, 20:51 Uhr
Auf der mit X6 beschrifteten Buchse liegt ein RS232-Signal mit TTL-Pegeln an. Die Geräte kommunizieren mit 9600 Baud (8N1, keine Flusskontrolle). Normalerweise wird über diese Buchse ein PC angeschlossen, auf dem das Programm vrDIALOG ausgeführt wird, oder ein Kommunikationsmodul für das vrNetDIALOG-System.
Eine Beta-Version des Programms vrDIALOG findet man mit Google (Stand 06.01.10). Die Kommunikation des Programms mit dem Heizgerät lässt sich mit entsprechenden Tools beobachten.
Solange es kein spezielles Modul für das Ethersex-System gibt, kann YPort verwendet werden. Das Heizgerät kann dann von eigener Software aus oder mit Hilfe eines gemappten COM-Ports auch von vrDIALOG aus angesprochen werden.
Inhaltsverzeichnis
- 1 Belegung
- 2 Protokoll
- 2.1 Aufbau der Nachrichten
- 2.2 Prüfsumme
- 2.3 Befehle
- 2.3.1 07 02 00 00 00 04 C4
- 2.3.2 07 00 00 00 01 02 E0
- 2.3.3 07 00 00 00 03 01 E7
- 2.3.4 07 00 00 00 04 02 EA
- 2.3.5 07 00 00 00 05 01 EB
- 2.3.6 07 00 00 00 06 0E EA
- 2.3.7 07 00 00 00 17 03 CD
- 2.3.8 07 00 00 00 18 03 D3
- 2.3.9 07 00 00 00 26 0A A6
- 2.3.10 07 00 00 00 39 02 90
- 2.3.11 07 00 00 00 42 01 65
- 2.3.12 07 00 00 00 44 01 69
- 2.3.13 07 00 00 00 48 01 71
- 2.3.14 07 00 00 00 49 01 73
- 2.3.15 07 00 00 00 53 01 47
- 2.3.16 07 00 00 00 55 02 48
- 2.3.17 07 00 00 00 58 01 51
- 2.3.18 07 00 00 00 98 05 CC
- 2.4 Anworten des Geräts
- 2.5 Kodierung von Werten
Belegung
+---------+ 6 --- | GND 5 --- +--+ TXD 4 --- | RXD 3 --- | 2 --- +--+ 1 --- | +---------+ Blick auf die Buchse (!)
Protokoll
Die Kommunikation scheint immer vom angeschlossenen PC (oder Ethersex?) auszugehen. Die Nachrichten in beide Richtungen haben ein ähnliches Format:
Es gibt kein Zeilenende wie CR oder CR+LF.
Aufbau der Nachrichten
Alle Nachrichten haben ein gemeinsames Format:
Bytes 1 2 3 ... n-1 n +-----+-----+---- ---+-----+ | Len | ? | Data | Chk | +-----+-----+---- ---+-----+ Byte 1 Gesamtlänge der Nachricht ("n" Bytes, Längenbyte, Nachrichtentyp und Prüfsumme sind dabei mitgezählt) Byte 2 Evtl. sowas wie ein Nachrichtentyp oder eine Zieladresse: 0x00 Normale Nachrichten 0x01 Fehlermeldungen? 0x02 ? - Verwendet bei der Abfrage der Version des Heizgeräts 0x0a ? - Verwendet bei der Abfrage der Version des Reglers Byte 3 Daten, beinhalten die eigentliche Anforderung an das Gerät, die angeforderten .. n-1 Werte, oder sonstige Informationen. Byte n Prüfsumme, siehe weiter unten
Prüfsumme
Die Berechnung der Prüfsumme hat mich einige Zeit gekostet. Das Verfahren ist aber nicht wirklich schwierig:
sub checksum { my $string = $_[0]; my $checksum; for (my $i = 0; $i < length($string); $i++) { if ($checksum & 0x80) { $checksum = ($checksum << 1 | 1) & 0xFF; # ??? $checksum = $checksum ^ 0x18; } else { $checksum = $checksum << 1; } $checksum = $checksum ^ ord(substr($string, $i, 1)); } return $checksum; }
Den Quelltext darf gerne mal jemand in C konvertieren ;-) ... Beim Finden des Algorithmus' waren kurze Nachrichten wie 03 03 05 und 03 01 07 nützlich. Es fiel dann aber auf, dass die Berechnung immer dann zu einem anderen Ergebnis führt, wenn die Zwischen-Prüfsumme im Verlauf der Berechnung größer als 127 wird. In der Nachricht 07 00 00 00 98 05 CC ist dies erst beim letzten Datenbyte der Fall. Von dort konnte man also zurückrechnen, was man an der Zwischen-Prüfsumme ändern muss, um letztendlich auf die gleiche Prüfsumme zu kommen wie das Gerät. Diese Änderung ist genau ein XOR mit 18h. Siehe auch [1] und [2].
Befehle
Alle bisher bekannten Befehlsnachrichten sind 7 Byte lang, Nach Abzug des Headers und der Prüfsumme bleiben demnach 4 Bytes für den eigentlichen Befehl.
Es scheint, als gebe das letzte Byte des Befehls die Anzahl der zurückzuliefernden Datenbytes an. Ob man einen Wert wahlweise in 1-Byte- oder 2-Byte-Darstellung abfragen kann, lässt sich erst überprüfen, wenn die Prüfsumme verstanden ist.
07 02 00 00 00 04 C4
Fragt nach angeschlossenen Geräten? In meinem Fall meldet das Gerät anscheinend seine Versionsnummer, die von vrDIALOG als "0153_07.00" angezeigt wird:
08 00 00 99 07 00 14 96
Bei diesem Befehl ist die Anzahl der zurückgelieferten Bytes nicht gleich dem als viertem Bytes gesendeten Wert "04".
07 00 00 00 01 02 E0
Fragt Sollwert Brauchwassertemperatur ab. Der Temperaturwert ist in den Bytes 3 und 4 wie unten beschrieben kodiert (hier: 35°C):
05 00 02 30 1C
07 00 00 00 03 01 E7
Unbekannter Statuswert.
04 00 F0 E0
07 00 00 00 04 02 EA
Fragt Sollwert Speichertemperatur ab (hier: 15°C, ausgeschaltet):
05 00 00 F0 D8
07 00 00 00 05 01 EB
Fragt Status des Flammsignals ab (hier: aus):
04 00 F0 E0
Der Sensor erkennt, ob der Brenner brennt. Vermutlich wird dieser Sensor für einen Sicherheitsmechanismus verwendet: Wenn das Gasventil geöffnet ist und der Zünder gezündet hat, sollte innerhalb bestimmter Zeit die Flamme da sein, sonst strömt Gas aus.
07 00 00 00 06 0E EA
Unbekannt
12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4A
07 00 00 00 17 03 CD
Fragt die Speichertemperatur ab (Bytes 3,4), das Statusbyte "AA" zeigt an, dass die Verbindung zu Sensor unterbrochen ist:
06 00 FF 21 AA 5F
07 00 00 00 18 03 D3
Fragt Vorlauftemperatur ab (hier: 22.375°C). Das Statusbyte "00" sagt "Kein Fehler".
06 00 01 66 00 A8
07 00 00 00 26 0A A6
Evtl Fehlerspeicher?
0D 00 64 64 64 64 64 64 64 64 64 64 A2
07 00 00 00 39 02 90
Fragt Sollwert Vorlauftemperatur ab (hier: 1.6875°C), scheint hier - wegen über Klemmen 7-8-9 angeschlossenem Raumthermostat - nur zwischen 0 und Max zu springen, der Sprung wird durch ein Tiefpassfilter stark geglättet:
05 00 00 1B 33
07 00 00 00 42 01 65
?
04 00 00 10
07 00 00 00 44 01 69
Interne Heizungspumpe, Komischerweise scheint hier zu gelten 00=aus 01=an ...
04 00 00 10
07 00 00 00 48 01 71
Fragt Status Gasmagnetventil ab (hier: nicht aktiv):
04 00 F0 E0
07 00 00 00 49 01 73
Fragt Status Zünder ab, wird jeweils nur kurz aktiv beim Einschalten des Gasmagnetventils (hier: nicht aktiv):
04 00 F0 E0
07 00 00 00 53 01 47
Fragt irgendeinen Status ab:
04 00 F0 E0
07 00 00 00 55 02 48
Irgendein Analogwert?
05 00 00 02 2A
07 00 00 00 58 01 51
?
04 00 00 10
07 00 00 00 98 05 CC
Liefert unter anderem die Rücklauftemperatur (Bytes 3+4, hier: 23.25°C), evtl einen weiteren Temperaturwert (Bytes 5+6, hier -23,00) und ein Statusbyte, das "Kein Fehler" meldet:
08 00 01 74 FE 8B 00 75
Welche Aussage kann das Statusbyte haben, -23,00°C scheint nicht wirklich ein gültiger Messwert zu sein.
Anworten des Geräts
Nachrichtenlänge | Datenlänge | Inhalt |
---|---|---|
3 | 0 | Nachricht enthält keine Daten, Fehlermeldung |
4 | 1 | Zustandwert oder Analogwert |
5 | 2 | Analogwert (Sollwert?), zB. Temperatur |
6 | 3 | Analogwert (Istwert?) und Status des Sensors. |
7 | 4 | Zwei Analogwerte |
8 | 5 | Versionsmeldung, Analogwert und weitere Bytes? |
10 | 7 | ? |
18 | 15 | ? |
Kodierung von Werten
In den Antworten des Heizgeräts sind verschiedene Informationen kodiert. Vermutlich ist das Format der zurückgelieferten Daten eindeutig mit dem anfordernden Befehl verbunden.
Temperaturen
Es scheint zwei Möglichkeiten zu geben, Temperaturen zu kodieren. Sollwerte (Grenzwerte?) sind teilweise in einem Byte kodiert, während andere Sollwerte und Messwerte in zwei Bytes kodiert sind: Das zuerst gesendete Byte ist das höherwertige Byte. Der erhaltene Zahlenwert entspricht der Temperatur in 1/16°C. Negative Werte werden in Zweikomplement-Darstellung übertragen.
Beispiel
52h = 82d => 82 °C 0230h = 560d => 560/16 °C = 35,00 °C FF21h = -223d => -223/16 °C = -13,94 °C
Sensorstatus
00 = kein Fehler 55 = Kurzschluss AA = Unterbrechung
Schaltzustand
0F = Aktiv F0 = Inaktiv