KM-Bus

Inhalt





Grundsätzliches

Alles, was hier dargestellt wird stammt aus Messungen und Analsyse der Software folgender Geräte und damit zusammenhängenden Schlußfolgerungen:

Gerät
Funktion
CPU
Kommentar
Vitotronic 200KW2
Heizungssteuerung
M30612MC
SW läßt sich mit etwas Aufwand über Optolink auslesen, Code ca. 128 KByte
Vitotrol 200A/300
Fernbedienung
M37510EF
SW läßt sich bequem über einen EPROM Brenner auslesen, Code ca. 48 KByte
Funktionserweiterung 1...10V
Zusatzgerät
ST7FLITE09
Fluses nicht gesetzt -> einfach auslesbar, code ca. 1,5 KByte ;-)
Gerade die Vitotronic enthält relativ viel Software (Disassembly ca. 57000 Zeilen Code. Es besteht also durchaus die Möglichkeit, dass ich etwas übersehen habe.
Die Analyse ist noch lang nicht beendet.
Im Gegensatz dazu sind die lächerlichen 1214 Zeilen von der Funktionserweiterung geradezu übersichtlich und lieferten doch wertvolle Informationen.





Warnung:
  • Es wird keine Garantie auf Richtigkeit und Vollständigkeit gegeben
  • Für Schäden, die an Geräten entstehen ist der Anwender selbst verantwortlich
  • Patent- und Eingentumsbelange werden in diesem Artikel nicht berücksichtig (bitte beachten, wenn kommerziell gearbeitet wird !)





Einführung

Der KM-Bus ist eine elektrische Schnittstelle bei Viessmann Heizungssteuerungen um verschiedene Zusatzgeräte anzuschschliessen.





Elektrische Eigenschaften

Elektrisch ist der KM-Bus mit dem M-Bus (Meter-Bus) vergleichbar.

Der Bus-Master sendet durch Änderung der Spannung:
Die Ruhespannung ist ca. 28.8V, wenn gesendet wird, wird der Pegel auf ca.14.4V für eine Null abgesenkt.

Der Slave sendet durch Änderung der Stromaufnahme.

Für den M-Bus (und damit auch für die elektrische Schnittstelle des KM-Bus) gibt es spezielle Bausteine, z.B. TSS721A


Kommuniziert wird auf dem KM-Bus mit 12008E1 (1200 bps; 1 Start-Bit (low), 8 Datenbit, gerade Parität, 1 Stopp-Bit (high))
Die Kommunikation entspricht der des M-Bus. Hier gibt es eine gute Doku mit erläuternden Bildern:
http://www.m-bus.com/files/w4a21021.pdf





Protokoll

Grundsätzliches:

Der Master kontrolliert immer den Bus.
Ein Slave kann nur auf ein Telegramm des Masters Antworten, er darf nicht spontan senden.

Ähnlich einigen Befehlen der Protokolle der Optolink-Schnittstelle wird auch hier mit "virtuelle Adressen" gearbeitet.
Das heisst, im Protokoll werden Adressen verwendet, die unterschiedlichen Funktionen im Slave zugeordnet sind.
Teilweise stehen einfache Speicheradressen dahinter, Teilweise Ports oder ganze Funtionen.

Die "Funktionserweiterung 0...10V" hat z.B intern Folgende Adressen:

virtuelle Adresse
physikalische Adresse
Lesen
Schreiben
Bedeutung
0x00
0x8B
X

write once flag für 0x82
0x01
0x8C
X


0x10
0x8D
X
X
set/clear PortA0 (Pumpe)
0x11
0x8E
X
X
Muster für PortA0
0x20
0x8F
X

invertierter Status von PortA0
0x22
0x82
X


0x23
PortA 3-1,PortB0
X

PortPins Rohdaten





0x30-0x3F
RAM (0x80-0x8F)
X

RAM Rohdaten





0x40-0x4F
Datenflash 0x1000-0x100F
X
X
Datenflash





0x50
0x89

X
hier muß ein MagicWord (0x5A) geschrieben werden um ein Schreiben auf das Datenflash zu ermöglichen.





0xF8-0xFB
N/A
X

ID bytes: 0x04 0xE0 0x01 0x01
0xFC-0xFF
N/A
X

0xFF 0xFF 0xFF 0xFF
(die Zuordnung habe ich noch nicht vollständig geklärt, die Tabelle dient nur zur Veranschaulichung)

Die Vitrotrol unterstützt dagegen nur die Adressen 0x00 (wird anscheinend immer mit 0x00 beantwortet) und 0xF8 (ID bytes).



Kommuniziert wird mit Telegrammen. Ein Telegramm ist wie folgt aufgebaut:

[DK][SK][CMD][LEN][DSL][SSK][...][CRC1][CRC2]

Dabei bedeutet:

DK
Zielgeräte Klasse
SK
Source Geräte Klasse
CMD
Command
LEN
Länge des gesammten Telegramms
DSL
interner Slot
SSK
Source-Subklasse
[...]
ggf. Daten
CRC1
Low Byte CRC16
CRC2
High Byte CRC16

Die CRC wird über das gesamte Telegramm gebildet. Die CRC ist vom Typ CRC-CCITT (Kermit).

Daten
Polynom: 0X1021

Init: 0x0000

Ref In: True
Ref Out: True
Xor Out: 0x0000
Länge: 16bit



Vorteil bei dieser CRC:
Zur Kontrolle kann die CRC über die gesamte Telegramm länge gebildet werden, hierbei muss das Ergebnis = 0x00 sein.
Eine andere Variante ist das Empfangene Telegramm ohne die 2 CRC Bytes zu testen und danach die generierte CRC und
die Empfangene CRC zu vergleichen.

Nützliche Tools:
http://www.lammertbies.nl/comm/info/crc-calculation.html

http://www.zorc.breitbandkatze.de/crc.html



Mögliche Busteilnehmer


Bei der Vitotronic 200KW2 sind folgende Befehle grundsätzlich möglich:
CMD
Bedeutung
Länge
Kommentar
0x00
PING
8

0x31
Leseanforderung 1 Byte
9

0x33
Leseanforderung N Byte
9

0x3F
Leseanforderung Datensatz N
10

0x43
???

wird weder von Funktoinserweiterung noch von Vitotrol verwendet
0x80
PONG
8

0xB1
Datensendung 1 Byte
10

0xB3
Datensendung N Byte
10 + 2 * N

0xBF
Datensendung Datensatz N
11 + X

0xC3
???

wird weder von Funktoinserweiterung noch von Vitotrol verwendet

Ist Bit 7 im Befehl gelöscht, handelt es sich um einen Datenanforderungs-Befehl.
Ist Bit 7 im Befehl gesetzt, handelt es sich um einen Datensende-Befehl.

Bisher habe ich nicht beobachtet, dass der Slave Befehle mit gelöschtem Bit7 gesendet hat.

Es bilden sich somit Befehls-Paare:

Master sendet
Slave antwortet
Kommentar
0x31
0xB1
Der Master fordert vom Slave ein Byte
0x33
0xB3
Der Master fordert vom Slave N Bytes
0x3F
0xBF oder nichts
Der Master fordert vom Slave Datensatz N
0x00
0x80 oder 0xBF
Der Master gibt dem Slave die Möglichkeit, Daten zu senden.
Der Slave antwortet nur, wenn er Daten zu senden hat.
0xB1
nichts
Der Master schickt dem Slave ein Byte
0xB3
nichts
Der Master schickt dem Slave N Byte
0xBF
nichts
Der Master schickt dem Slave Datensatz N


Die Befehle im Einzelnen:

0x31 / 0xB1:

Master: [DK][SK][0x31][0x09][DSL][SSK][ADR][CRC1][CRC2]
Slave: [DK][SK][0xB1][0x0A][DSL][SSK][ADR][DAT][CRC1][CRC2]

ADR ist dabei die zu lesende Adresse, DAT das Datenbyte

0x33 / 0xB3:

Master: [DK][SK][0x33][0x0A][DSL][SSK][ADR][N][CRC1][CRC2]
Slave: [DK][SK][0xB3][0x08+N*2][DSL][SSK][ADR_0][DAT_0][ADR_1][DAT_1]...[ADR_N-1][DAT_N-1][CRC1][CRC2]

ADR: die Startadresse der Daten
N: die Anzahl der Daten (aufeinanderfolgend)

z.B lesen der ID:
M: 01 00 33 0A 01 01 F8 04 31 B4
S. 00 11 B3 10 01 01 F8 11 F9 38 FA 00 FB 05 36 13

Es werden 4 Byte von der Adresse 0xF8 angefordert, der Slave antwortet mit dem Inhalt 11 38 00 05

0x3F / 0xBF:

Master: [DK][SK][0x3F][0x09][DSL][SSK][N][CRC1][CRC2]
Slave: [DK][SK][0xBF][0x08 + N +1][DSL][SSK][N][DAT_0][DAT_1]...[DAT_X][CRC1][CRC2] oder nichts

Der Master fordert Datensatz N vom Slave an. Der Slave sendet den Datensatz DAT_0 - DAT_X

0xB1:

Master: [DK][SK][0xB1][0x09][DSL][SSK][ADR][DAT][CRC1][CRC2]
Der Master schreibt 1 Byte (DAT) an Adress ADR

0xB3:

Master: [DK][SK][0xB3][0x08+N*2][DSL][SSK][ADR_0][DAT_0][ADR_1][DAT_1]...[ADR_N-1][DAT_N-1][CRC1][CRC2]
Der Master schreibt N Byte ab Adresse ADR

0xBF:

Master: [DK][SK][0xBF][0x08 + N +1][DSL][SSK][N][DAT_0][DAT_1]...[DAT_X][CRC1][CRC2]

Der Master schickt einen Datensatz

0x00:

Master: [DK][SK][0x00][0x08][DSL][SSK][CRC1][CRC2]
Slave: [DK][SK][0x80][0x08][DSL][SSK][CRC1][CRC2] oder [DK][SK][0xBF][0x08 + N +1][DSK][SSK][N][DAT_0][DAT_1]...[DAT_X][CRC1][CRC2]

Der Master schickt eine Art PING oder Token. Hat der angesprochene Slave Daten, so kann er diese jetzt schicken. Wenn nicht antwortet er mit einem Leeren Telegram (PONG)

0x43 & 0xC3:

Dieses Kommando-Paar wird anscheinend weder von der Funktionserweiterung noch von der Vitotrol unterstützt.






Die Vitotronic 200KW2 kennt folgende Klassen und Unterklassen:
Tabelle
Klasse
interner Slot
ID2
Geräte
CMD1
CMD2
CMD3
Kommentar
1
0x11
0x01
0x34,0x38
Vitotrol200A/300
X
X
X

2
0x11
0x02
0x34,0x38

X
X
X

3
0x11
0x03
0x34,0x38

X
X
X

4
0x11
0x00
0x34,0x38



X

5
0x20
0x02
0x71

X
X


6
0x20
0x03
0x71

X
X


7
0x01
0x01
0x11

X
X


8
0x01
0x02
0x11

X
X


9
0x01
0x03
0x11

X
X


10
0x20
0xEE
0x81

X
X
X

11
0x04
0x01
0x11,0x12
Funktionserweiterung (?)
X
X



In der SW der 200KW2 gibt es 11 Tabellen.
In diesen Tabellen sind zu jeder Teilnehmerklasse Daten wie
  • Klasse
  • interne Slot Nr
  • mögliches ID2 byte
  • verfügbare Kommandos (CMD1-3)
  • etc.

enthalten.

Wir ein Telegram vom Master versendet, so bedient er sich beim Zusammenbau aus dieser Tabelle.
Als Ziel (erstes Telegamm Byte) wird die Klasse verwendet, als Byte Nr.5 der interne Slot.
So kann die 200KW2 z.B. 3 Vitotrol verwalten, aber nur eine Funktionserweiterung.

Eine Besonderheit scheint 0x20 Slot 0xEE darzustellen.
Diese scheint intern angeschlossen zu sein. Es werden nämlich Daten von diesem Gerät gelesen, obwohl nichts angeschlossen ist.

[todo: weitere Zuordnung für Klassen 0x20 und 0x01]

Commands

CMD1:
Ist für jede Tabelle ausser für 4 möglich.

Für die Tabellen 1,2,3,5,6,7,8,9 und 11 ist dieses Kommondo anscheinend das gleiche:
es wird versucht, die ID zu lesen

In Tabelle 10 ist das Kommando fast identisch, mit dem Unterschied, dass die ID sofort aus dem Speicher gelöscht wird, wenn die Buskommunikation einmal nicht klappt.

CMD2:
Gleiche Kommandos für
  • Tabellen 1-3
  • Tabellen 5,6
  • Tabellen 7-9
  • Tabelle A

Für Tabelle 4 ist diese Kommando nicht verfügbar. Die SubKlasse "0" der Tablle 4 deutet schon darauf hin, dass es sich um eine Art Broadcast handelt.
Schaut man z.B. in der SW zur Vitotrol, so sieht man, dass diese auf auf die SubKlass 1-3 und auf 0 reagiert.
Die Funktionserweiterung reagiert auf 0x10 und 0.

Das es wird für die Geräte dieser Klasse immer die selbe Routine angesprungen.
z.B Klasse 1-3: dort wird der Befehl 0x3F (Lese Datensatz) gesendet.
Das lässt darauf schließen, dass Geräte der Klassen 1-3 funktionsgleich sind.

CMD3:
Auch hier werden wieder Gruppen gebildet:
  • Tabellen 1-3
  • Tabelle 4
  • Tabelle A

Tabelle 1-3 erhält über dieses Kommando regelmäßig ein Update für Themperaturen sowie Pumpen und Fehlerstati mit dem Befehl 0xBF.
Für Tabelle 4 ist hier auf das Kommando 0xBF vorgesehen. Scheint ein Broadcast an die Tabllen 1-3 zu sein.
An Tablle A wird hier z.B regelmäßig das Telegram 20 00 B3 0C EE 01-10 98 11 00-33 01 gesendet. (Schreibe 0x98 an Adressse 0x10 und 0x00 an 0x11).

Die ID

Jedes Gerät hat eine 4 Byte ID.

Aufbau der ID:
ID1
ID2
ID3
ID4
Klasse
interner Slot
SerienNummer 1
SerienNummer 2

Meine Vitrotrol hat z.B. die ID 11 38 00 05
Meine Funktionserweiterung hat die ID 04 E0 01 01

Vergleicht man die ID der Funktionserweiterung (F) mit der Tabelle der Vitotronic, so erkennt man, dass F von der Vitotronic nicht erkannt wird. In der Klasse 04 wird nur die Subklasse 01, nicht aber die SubKlasse E0 akzeptiert.

Die Vitotronic sendet ca. alle 5 Minuten Befehle aus, um die ID Bytes möglicher Busteilnehmer zu lesen:
Ein Ausschnitt:
Telegram
Bedeutung
11 00 33 0A 03 01-F8 04-3F D6
read ID 4 bytes from device 110.3
20 00 33 0A 02 01-F8 04-B3 A6
read ID 4 bytes from device 20.02
01 00 33 0A 01 01-F8 04-31 B4
read ID 4 bytes from device 01.01
01 00 33 0A 02 01-F8 04-FC 91
read ID 4 bytes from device 01.02
01 00 33 0A 03 01-F8 04-47 8D
read ID 4 bytes from device 01.03
20 00 33 0A EE 01-F8 04-0D 85
read ID 4 bytes from device 20.EE




Ein Beispiel:
-> 01 00 33 0A 01 01-F8 04-31 B4

Zielklasse 01, Quellklasse 00
Command 33 (mehrere Bytes lesen)
Länge: 10 Byte
ZielSubKlasse 01, QuellSubKlasse 01
Adresse der angeforderten Daten: 0xF8
Länge der angeforderten Daten: 4
Die beiden letzen Byte sind die CRC

Ist ein Gerät der entsprechenden Klasse angeschlossen (bei mir die Vitotrol) so antwortet dieses mit folgenden Telegram:

<- 00 01 B3 0C 01 01 F8 11 F9 38 FA 00 FB 05 + 2Byte CRC

Die Vitotrol schickt also vor jedem Datenbyte die zugehörige Adresse.
Soweit die ersten Messungen.

Mein Ziel ist es, das Logging der Temperaturen und Brennerzustände über den KM-Bus anstelle der Optolink Schnittstelle vorzunehmen.

Die Daten sollten verfügbar sein, da z.B. die Vitotrol alle benötigten Daten (T-Aussen, T-Kessel, T-Wasser etc.) anzeigen kann.





Zusatzgeräte:

Als KM-Bus Teilnehmer kommen in Frage: (Liste unvollständig):

Name
Bestell-Nr.(zur Identifizierung)
ID
unterstützte Kommandos
Vitotrol 200
7450 017


Vitotrol 300
7248 907


Funktionserweiterung 0 - 10 V
7174 718


Vitocom 100, Typ GSM mit / ohne SIM
Z004594 / Z004615


Schaltmodul-V



Vitosolic 200
7170 926