VBus-Decoder: Unterschied zwischen den Versionen

Aus Hobbyelektronik.org
(Die Seite wurde neu angelegt: „In unserer Solaranlage arbeitet ein Viessmann Vitosolic 200, der die Regelung der Anlage übernimmt. Nach kurzer Recherche stellte sich heraus, dass es sich um ei…“)
 
(→‎Python: Umbruch)
 
(49 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
In unserer Solaranlage arbeitet ein Viessmann Vitosolic 200, der die Regelung der Anlage übernimmt.
+
[[Bild:Vbus regler.jpg|thumb|Das Corpus Delicti]]
 +
Bei der Solaranlage meiner Eltern übernimmt ein Viessmann Vitosolic 200 die Regelung.  
 
Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de RESOL DeltaSol® M] handelt.
 
Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de RESOL DeltaSol® M] handelt.
  
Statt der RS232-Schnittstelle hat das Teil einen Anschluss für den Viessmann-eigenen KM-Bus, zu dem es keinerlei Informationen gibt.
+
Statt der RS-232-Schnittstelle hat das Teil einen Anschluss für den Viessmann-eigenen KM-Bus, zu dem mir keinerlei Informationen bekannt sind.
  
Beim VBus sieht es schon ein wenig anders aus. In der [http://www.mikrocontroller.net/topic/96431 Diskussion] auf Mikrocontroller.net bin ich auf den Beitrag von [http://www.mikrocontroller.net/topic/96431#1231974 Daniel Wippermann] gestoßen, woraufhin ich an die angegebene Adresse eine E-Mail geschickt habe.  
+
Beim VBus sieht es deutlich besser aus. In der [http://www.mikrocontroller.net/topic/96431 Diskussion] auf Mikrocontroller.net bin ich auf den Beitrag von [http://www.mikrocontroller.net/topic/96431#1231974 Daniel Wippermann] gestoßen, woraufhin ich an die angegebene Adresse eine E-Mail geschickt habe.  
  
 
Keine zweieinhalb Stunden später habe ich die Dokumentation (inklusive der Erlaubnis zur Veröffentlichung, siehe Download) zum Protokolls erhalten.
 
Keine zweieinhalb Stunden später habe ich die Dokumentation (inklusive der Erlaubnis zur Veröffentlichung, siehe Download) zum Protokolls erhalten.
  
=Hardwareschnittstelle=
+
Irgendwann nach der Erstveröffentlichung dieses Artikels entstand eine deutlich erweiterte Dokumentation auf den [https://danielwippermann.github.io/resol-vbus/vbus-specification.html Github-Seiten von Daniel Wippermann]. Nicht nur das, sondern auch eine Implementierung des Protokolls in Javascript.
 +
 
 +
=Hardware-Schnittstelle=
 
[[Bild:Resol sch.png|thumb|Wo Rx und Tx ist, muss erraten werden ;)]]
 
[[Bild:Resol sch.png|thumb|Wo Rx und Tx ist, muss erraten werden ;)]]
Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die zwar Ähnlichkeiten zu RS485 hat, diesem aber nicht entspricht.
+
Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die - entgegen mancher Meinungen - überhaupt keine Ähnlichkeiten mit RS-485 hat.
  
Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2V und 35mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen.
+
'''Bei ein paar Reglern scheint Resol eine RS-485-Schnittstelle mit VBus-Protokoll zu verwenden, die mit den hier vorgestellten Schaltungen nicht kompatibel ist. Bitte vor dem Nachbau der Hardware prüfen, um welches System es sich handelt. Das kann entweder durch das Anleitung erfolgen (Angabe der Spannung und Strom, bei RS-485 ist üblicherweise keine Stromversorgung) oder durch Nachmessen: An den VBus-Klemmen sollte eine (zappelnde) Spannung von etwa 8 V anliegen.'''
 +
 
 +
Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2 V und 35 mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen.
 
Mit der Schaltung auf Seite 5 des PDFs kann auf dem Bus sowohl gelesen, als auch geschrieben werden. Im Bild rechts meine Interpretation der Schaltung (in der noch die Abblockkondensatoren fehlen).
 
Mit der Schaltung auf Seite 5 des PDFs kann auf dem Bus sowohl gelesen, als auch geschrieben werden. Im Bild rechts meine Interpretation der Schaltung (in der noch die Abblockkondensatoren fehlen).
  
Über die Buchse links kann man sich mit UART (nicht RS232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.
+
Über die Buchse links kann man sich mit UART (nicht RS-232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.
 +
 
 +
Der in meiner Schaltung verwendete FET für die bidirektionale Kommunikation ist übrigens ein BS170; wobei der Typ nicht kritisch ist, solange er den Bus kurzschließen kann, ohne dabei in Rauch aufzugehen.
  
 
=Protokoll=
 
=Protokoll=
 
Das Protokoll des VBus ist in seiner Version 1.0 ziemlich gut handzuhaben.
 
Das Protokoll des VBus ist in seiner Version 1.0 ziemlich gut handzuhaben.
  
 +
Folgendes Daten habe ich zum Testen verwendet:
  
Folgendes Daten habe ich zum Testen verwendet:
+
<code>
<pre>
+
<span class="he0"><span class="hb1">0xAA</span>, <span class="hb2">0x10, 0x00</span>, <span class="hb3">0x21, 0x73</span>, <span class="hb4">0x10</span>, <span class="hb5">0x00, 0x01</span>, <span class="hb6">0x12</span>, <span class="hb7">0x38</span></span>, <br />
0xAA, 0x10, 0x00, 0x21, 0x73, 0x10, 0x00, 0x01, 0x12, 0x38,  
+
0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39, <br />
0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39  
+
0x45, 0x01, 0x38, 0x22, 0x04, 0x5B, <br />
0x45, 0x01, 0x38, 0x22, 0x04, 0x5B  
+
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46  
+
0x6C, 0x01, 0x38, 0x22, 0x05, 0x33, <br />
0x6C, 0x01, 0x38, 0x22, 0x05, 0x33  
+
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46  
+
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br />
0x38, 0x22, 0x38, 0x22, 0x05, 0x46  
+
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F  
+
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F  
+
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F
+
0x38, 0x0F, 0x00, 0x00, 0x01, 0x37, <br />
0x38, 0x0F, 0x00, 0x00, 0x01, 0x37  
+
0x47, 0x00, 0x00, 0x00, 0x00, 0x38, <br />
0x47, 0x00, 0x00, 0x00, 0x00, 0x38  
+
0x64, 0x64, 0x00, 0x00, 0x00, 0x37, <br />
0x64, 0x64, 0x00, 0x00, 0x00, 0x37  
+
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F  
+
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F  
+
0x00, 0x00, 0x43, 0x00, 0x00, 0x3C, <br />
0x00, 0x00, 0x43, 0x00, 0x00, 0x3C  
+
0x00, 0x00, 0x02, 0x00, 0x00, 0x7D, <br />
0x00, 0x00, 0x02, 0x00, 0x00, 0x7D  
+
0x01, 0x03, 0x60, 0x02, 0x04, 0x15, <br />
0x01, 0x03, 0x60, 0x02, 0x04, 0x15  
+
0x02, 0x00, 0x00, 0x00, 0x00, 0x7D, <br />
0x02, 0x00, 0x00, 0x00, 0x00, 0x7D
+
</code>
</pre>
+
 
 +
Zu allererst wird ein <span class="he0">10 Byte langer Kopf</span> gesendet, der mit einem eindeutigen <span class="hb1">Sync-Wort (0xAA)</span> beginnt. Eindeutig heißt: An keiner anderen Stelle im Protokoll wird dieses Zeichen verwendet (bzw. das MSB belegt). Man kann sich also zu jedem beliebigen Zeitpunkt in den Bus einklinken!
 +
 
 +
Gefolgt vom Sync-Wort kommen <span class="hb2">Ziel-</span> und <span class="hb3">Quelladresse</span> (<span class="hb2">0x0010</span> <= <span class="hb3">0x7321</span>), <span class="hb4">die Protokollversion (0x10)</span>, der <span class="hb5">ausgeführte Befehl (0x0100)</span> und die Anzahl der danach folgenden <span class="hb6">Nutzdatenframes (0x12)</span>. Abschließend wird eine <span class="hb7">Prüfsumme (0x38)</span> der zuvor gesendeten Daten übertragen.
 +
 
 +
Im Anschluss an den Header wird die im Header angegebene <span class="hb6">Anzahl an Datenframes</span> mit je 6 Byte Länge geschickt (Auszug von oben):
  
Zu allererst wird ein 10 Byte langer Kopf gesendet, der mit einem eindeutigen Sync-Wort (0xAA) beginnt. Eindeutig heißt: An keiner anderen Stelle im Protokoll wird das MSB belegt. Man kann sich also zu jedem beliebigen Zeitpunkt in den Bus einklinken!
+
<code>
 +
<span class="hb1">0x5E, 0x04, 0x5E, 0x01</span>, <span class="hb2">0x05</span>, <span class="hb3">0x39</span>,
 +
</code>
  
Gefolgt vom Sync-Wort kommen Ziel- und Quelladresse (0x0010 <= 0x7321), die Protokollversion (0x10), der ausgeführte Befehl (0x0100) und die Anzahl der danach folgenden Nutzpakete (0x12). Abschließend wird eine Prüfsumme (0x38) der zuvor gesendeten Daten übertragen.
+
Die ersten 4 enthalten <span class="hb1">Nutzdaten</span>, im 5. wird ein <span class="hb2">Septett</span> geschickt und abschließend erfolgt wieder eine <span class="hb3">Prüfsumme</span>.
  
Im Anschluss des Headers werden n Datenframes mit je 6 Byte Länge geschickt. Die ersten 4 enthalten Nutzdaten, im 5. wird ein Septett geschickt und abschließend erfolgt wieder eine Checksum.
+
Das Septett ist eine Ergänzung der zuvor gesendeten Nutzdaten. Da, wie oben erwähnt, das MSB nur im Sync-Wort vorkommen darf, ist es für die folgende Daten kein verboten - dieses findet sich jeweils in diesem zusätzlichen Byte.
  
Das Septett ist eine Ergänzung der zuvor gesendeten Nutzdaten. Da, wie oben erwähnt, das MSB nur im Sync-Wort vorkommen kann, dürfen folgende Daten kein höchstwertiges Bit enthalten. Dieses findet sich jeweils im Septett.
+
Die Prüfsumme der einzelnen Nachrichtenteile wird mittels CRC8 berechnet.
  
Das ist auch schon das gröbste.
+
Das ist auch schon das Gröbste.
 
Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.
 
Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.
  
==Hintergrund==
+
==Adressen==
Noch eine kleine Hintergrundinformation, worum es sich bei der Ziel- und Quell-Adresse handelt.
+
Wie in vielen Bussystemen verwendet auch der VBus Pakete für die Nachrichten. Zu den Informationen in der PDF-Spezifikation sei an der Stelle auch auf die [https://danielwippermann.github.io/resol-vbus/vbus-packets.html Paketbeschreibung] verwiesen.
  
Die Quelladresse ist selbstverständlich der Regler (0x7321 = Vitosolic 200 [Regler]), die Zieladresse (0x0010) wird in der kompletten Dokumentation nur als DFA beschrieben. Dabei handelt es sich nicht um eine komische Umschreibung für einen Broadcast, sondern um die Daten für ein zusätzliches Gerät, der '''D'''aten'''f'''ern'''a'''nzeige.
+
Die für den bei uns eingesetzten Regler lautet die Adresse 0x7321 (Vitosolic 200 [Regler]), die für das Logging relevanten Daten gehen an 0x0010 und werden in der Dokumentation lediglich als DFA beschrieben. Dabei handelt es sich nicht um eine komische Umschreibung für einen Broadcast, sondern um die Daten für ein zusätzliches Gerät - der Datenfernanzeige.
  
 
An diese sendet der Regler alle von ihm gemessenen Werte. Neben der Regler-Identität hat der Vitosolic 200 noch die Identitäten WMZ1 und WM2 (Wärmemengenzähler).
 
An diese sendet der Regler alle von ihm gemessenen Werte. Neben der Regler-Identität hat der Vitosolic 200 noch die Identitäten WMZ1 und WM2 (Wärmemengenzähler).
  
(to be continued...)
+
=Hardware=
 +
Im Laufe der Zeit haben sich mehrere Schaltungen ergeben. Um diesen Artikel übersichtlich zu halten, wurden die verschiedenen Varianten auf Unterseiten aufgeteilt:
 +
 
 +
(Die Links zu den Unterseiten sind befinden sich jeweils in den Überschriften)
 +
 
 +
==[[VBus-Decoder/Adapter für RS-232|Adapter für RS-232]]==
 +
Wenn man noch einen PC oder Adapter hat der RS-232 spricht, kann sich dieser Hardware bedienen.
 +
 
 +
Der Zugriff ist nur lesend möglich und es gibt keine galvanische Trennung zwischen Bus und DTE.
 +
 
 +
<gallery>
 +
  Bild:Vbus_rxo_brd.png|thumb|Layout der PC-Hardware
 +
</gallery>
 +
 
 +
==[[VBus-Decoder/Adapter Nano|Adapter Nano]]==
 +
Die vermutlich universellste Variante - schön klein, galvanische Trennung und funktioniert auf der Empfängerseite ab 3,3 V.
 +
 
 +
<gallery>
 +
  resol_nano_0.1_assy.jpg|Bestückte Leiterkarte
 +
</gallery>
 +
 
 +
==[[VBus-Decoder/Adapter für den Raspberry Pi|Adapter für den Raspberry Pi]]==
 +
Wer Geräte ins Netzwerk bringen will, hat meistens auch einen Einplatinencomputer der Raspberry Pi Foudation auf der Liste.
 +
 
 +
<gallery>
 +
    Vbuspi 1.0 bare.jpg|Unbestückte Leiterkarte (v1.0)
 +
    Vbuspi 1.1 assy zero.jpg|Bestückte Leiterkarte auf einem Raspberry Pi Zero W
 +
</gallery>
 +
 
 +
Achtung: Es ist empfehlenswert, entweder [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Version 1.3]] oder zumindest [[VBus-Decoder/Adapter_für_den_Raspberry_Pi#Die Enttäuschung - Teil 2|1.2b]] nachzubauen.
 +
 
 +
==[[VBus-Decoder/Adapter_Nano#Troubleshooting|Troubleshooting]]==
 +
Für die Schaltung des Adapter Nano gibt es eine Troubleshooting-Anleitung, die in Teilen auch für die 5 V-Version der Raspberry-Pi-Variante gültig ist.
 +
 
 +
=[[VBus-Decoder/FAQ|FAQ]]=
 +
(bitte auf die Überschrift klicken)
 +
 
 +
=Software=
 +
==[[VBus-Decoder/AVR8-Software|AVR8]]==
 +
Zur Datenauswertung und für einfache, zusätzliche, Regelaufgaben (wie zum Beispiel Deaktivieren der Heizung, wenn die Solaranlage den Speicher belädt) - oder um die Anlage ins Internet of Things zu bekommen sind Mikrocontroller sehr geeignete Komponenten.
 +
 
 +
Eine Implementierung für die [[VBus-Decoder/AVR8-Software|AVR8-Plattform]] findet sich auf der entsprechenden Unterseite.
 +
 
 +
==Python==
 +
Nicki hat sich die Arbeit gemacht und einen Code zum Auswerten der Nachrichten in Python portiert. Ich hatte selbst noch keine gute Gelegenheit, ihn zu testen - daher ohne Garantie, Gewährleistung oder Support:
 +
 
 +
* [[Datei:VBus-Python.zip]]
 +
 
 +
Oliver hat basierend auf dem Code von Nicki eine Schnittstelle zur [https://www.volkszaehler.org/ Volkszähler]-Middleware gebaut:
 +
 
 +
<pre>
 +
Der Code nutzt die Resol-Decoder-Lib von Nicki, die ist auch mit dabei.
 +
In der config.py stellt man die Adresse der Middleware in seinem Netzwerk,
 +
sowie die UUID der Kanäle ein, damit man die Daten referenzieren kann.
 +
(Zum Test kann man auch simulierte Daten nutzen, oder die Ausgabe in ein File schreiben lassen)
 +
</pre>
 +
 
 +
* [[Datei:Vbus_volkszaehler.zip]]
 +
 
 +
==Protokoll-Analysator==
 +
 
 +
Da es mehrere Anfragen zur Untersuchung des Protokolls gab, habe ich vor einer Weile einen kleinen Protokollanalysator zusammengestrickt. Dieser unterstützt aktuell Protokollversion 1.0 und ist als "gefährliche Beta" anzusehen: [https://hobbyelektronik.org/tools/vbus-analyzer/ Resol Protocol Analyzer]
 +
 
 +
=Downloads=
 +
* [[Datei:VBus-Protokollspezifikation.pdf]] Stand: 20.04.2009
 +
* (Die Downloads für die Hardware befindet sich auf der jeweiligen Unterseite)
 +
 
 +
'''An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!'''
 +
 
 +
=Weblinks=
 +
* [http://www.mikrocontroller.net/topic/96431 Diskussion auf Mikrocontroller.net] (gleicher Link wie in der Einleitung)
 +
* [http://www.resol.de RESOL - Elektronische Regelungen GmbH]
 +
* [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de DeltaSol® M] Regler, der dem Viessmann Vitosolic 200 "alt" in ziemlich genau entspricht
 +
* [https://danielwippermann.github.io/resol-vbus/vbus-specification.html Github-Seiten von Daniel Wippermann]
 +
 
 +
[[Kategorie:AVR]]
 +
[[Kategorie:Energieerfassung]]
 +
[[Kategorie:Solaranlage]]
 +
[[Kategorie:VBus]]

Aktuelle Version vom 4. Juli 2021, 21:13 Uhr

Das Corpus Delicti

Bei der Solaranlage meiner Eltern übernimmt ein Viessmann Vitosolic 200 die Regelung. Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des RESOL DeltaSol® M handelt.

Statt der RS-232-Schnittstelle hat das Teil einen Anschluss für den Viessmann-eigenen KM-Bus, zu dem mir keinerlei Informationen bekannt sind.

Beim VBus sieht es deutlich besser aus. In der Diskussion auf Mikrocontroller.net bin ich auf den Beitrag von Daniel Wippermann gestoßen, woraufhin ich an die angegebene Adresse eine E-Mail geschickt habe.

Keine zweieinhalb Stunden später habe ich die Dokumentation (inklusive der Erlaubnis zur Veröffentlichung, siehe Download) zum Protokolls erhalten.

Irgendwann nach der Erstveröffentlichung dieses Artikels entstand eine deutlich erweiterte Dokumentation auf den Github-Seiten von Daniel Wippermann. Nicht nur das, sondern auch eine Implementierung des Protokolls in Javascript.

Hardware-Schnittstelle

Wo Rx und Tx ist, muss erraten werden ;)

Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die - entgegen mancher Meinungen - überhaupt keine Ähnlichkeiten mit RS-485 hat.

Bei ein paar Reglern scheint Resol eine RS-485-Schnittstelle mit VBus-Protokoll zu verwenden, die mit den hier vorgestellten Schaltungen nicht kompatibel ist. Bitte vor dem Nachbau der Hardware prüfen, um welches System es sich handelt. Das kann entweder durch das Anleitung erfolgen (Angabe der Spannung und Strom, bei RS-485 ist üblicherweise keine Stromversorgung) oder durch Nachmessen: An den VBus-Klemmen sollte eine (zappelnde) Spannung von etwa 8 V anliegen.

Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2 V und 35 mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen. Mit der Schaltung auf Seite 5 des PDFs kann auf dem Bus sowohl gelesen, als auch geschrieben werden. Im Bild rechts meine Interpretation der Schaltung (in der noch die Abblockkondensatoren fehlen).

Über die Buchse links kann man sich mit UART (nicht RS-232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.

Der in meiner Schaltung verwendete FET für die bidirektionale Kommunikation ist übrigens ein BS170; wobei der Typ nicht kritisch ist, solange er den Bus kurzschließen kann, ohne dabei in Rauch aufzugehen.

Protokoll

Das Protokoll des VBus ist in seiner Version 1.0 ziemlich gut handzuhaben.

Folgendes Daten habe ich zum Testen verwendet:

0xAA, 0x10, 0x00, 0x21, 0x73, 0x10, 0x00, 0x01, 0x12, 0x38,
0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39,
0x45, 0x01, 0x38, 0x22, 0x04, 0x5B,
0x38, 0x22, 0x38, 0x22, 0x05, 0x46,
0x6C, 0x01, 0x38, 0x22, 0x05, 0x33,
0x38, 0x22, 0x38, 0x22, 0x05, 0x46,
0x38, 0x22, 0x38, 0x22, 0x05, 0x46,
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F,
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F,
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F,
0x38, 0x0F, 0x00, 0x00, 0x01, 0x37,
0x47, 0x00, 0x00, 0x00, 0x00, 0x38,
0x64, 0x64, 0x00, 0x00, 0x00, 0x37,
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F,
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F,
0x00, 0x00, 0x43, 0x00, 0x00, 0x3C,
0x00, 0x00, 0x02, 0x00, 0x00, 0x7D,
0x01, 0x03, 0x60, 0x02, 0x04, 0x15,
0x02, 0x00, 0x00, 0x00, 0x00, 0x7D,

Zu allererst wird ein 10 Byte langer Kopf gesendet, der mit einem eindeutigen Sync-Wort (0xAA) beginnt. Eindeutig heißt: An keiner anderen Stelle im Protokoll wird dieses Zeichen verwendet (bzw. das MSB belegt). Man kann sich also zu jedem beliebigen Zeitpunkt in den Bus einklinken!

Gefolgt vom Sync-Wort kommen Ziel- und Quelladresse (0x0010 <= 0x7321), die Protokollversion (0x10), der ausgeführte Befehl (0x0100) und die Anzahl der danach folgenden Nutzdatenframes (0x12). Abschließend wird eine Prüfsumme (0x38) der zuvor gesendeten Daten übertragen.

Im Anschluss an den Header wird die im Header angegebene Anzahl an Datenframes mit je 6 Byte Länge geschickt (Auszug von oben):

0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39,

Die ersten 4 enthalten Nutzdaten, im 5. wird ein Septett geschickt und abschließend erfolgt wieder eine Prüfsumme.

Das Septett ist eine Ergänzung der zuvor gesendeten Nutzdaten. Da, wie oben erwähnt, das MSB nur im Sync-Wort vorkommen darf, ist es für die folgende Daten kein verboten - dieses findet sich jeweils in diesem zusätzlichen Byte.

Die Prüfsumme der einzelnen Nachrichtenteile wird mittels CRC8 berechnet.

Das ist auch schon das Gröbste. Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.

Adressen

Wie in vielen Bussystemen verwendet auch der VBus Pakete für die Nachrichten. Zu den Informationen in der PDF-Spezifikation sei an der Stelle auch auf die Paketbeschreibung verwiesen.

Die für den bei uns eingesetzten Regler lautet die Adresse 0x7321 (Vitosolic 200 [Regler]), die für das Logging relevanten Daten gehen an 0x0010 und werden in der Dokumentation lediglich als DFA beschrieben. Dabei handelt es sich nicht um eine komische Umschreibung für einen Broadcast, sondern um die Daten für ein zusätzliches Gerät - der Datenfernanzeige.

An diese sendet der Regler alle von ihm gemessenen Werte. Neben der Regler-Identität hat der Vitosolic 200 noch die Identitäten WMZ1 und WM2 (Wärmemengenzähler).

Hardware

Im Laufe der Zeit haben sich mehrere Schaltungen ergeben. Um diesen Artikel übersichtlich zu halten, wurden die verschiedenen Varianten auf Unterseiten aufgeteilt:

(Die Links zu den Unterseiten sind befinden sich jeweils in den Überschriften)

Adapter für RS-232

Wenn man noch einen PC oder Adapter hat der RS-232 spricht, kann sich dieser Hardware bedienen.

Der Zugriff ist nur lesend möglich und es gibt keine galvanische Trennung zwischen Bus und DTE.

Adapter Nano

Die vermutlich universellste Variante - schön klein, galvanische Trennung und funktioniert auf der Empfängerseite ab 3,3 V.

Adapter für den Raspberry Pi

Wer Geräte ins Netzwerk bringen will, hat meistens auch einen Einplatinencomputer der Raspberry Pi Foudation auf der Liste.

Achtung: Es ist empfehlenswert, entweder Version 1.3 oder zumindest 1.2b nachzubauen.

Troubleshooting

Für die Schaltung des Adapter Nano gibt es eine Troubleshooting-Anleitung, die in Teilen auch für die 5 V-Version der Raspberry-Pi-Variante gültig ist.

FAQ

(bitte auf die Überschrift klicken)

Software

AVR8

Zur Datenauswertung und für einfache, zusätzliche, Regelaufgaben (wie zum Beispiel Deaktivieren der Heizung, wenn die Solaranlage den Speicher belädt) - oder um die Anlage ins Internet of Things zu bekommen sind Mikrocontroller sehr geeignete Komponenten.

Eine Implementierung für die AVR8-Plattform findet sich auf der entsprechenden Unterseite.

Python

Nicki hat sich die Arbeit gemacht und einen Code zum Auswerten der Nachrichten in Python portiert. Ich hatte selbst noch keine gute Gelegenheit, ihn zu testen - daher ohne Garantie, Gewährleistung oder Support:

Oliver hat basierend auf dem Code von Nicki eine Schnittstelle zur Volkszähler-Middleware gebaut:

Der Code nutzt die Resol-Decoder-Lib von Nicki, die ist auch mit dabei.
In der config.py stellt man die Adresse der Middleware in seinem Netzwerk, 
sowie die UUID der Kanäle ein, damit man die Daten referenzieren kann.
(Zum Test kann man auch simulierte Daten nutzen, oder die Ausgabe in ein File schreiben lassen)

Protokoll-Analysator

Da es mehrere Anfragen zur Untersuchung des Protokolls gab, habe ich vor einer Weile einen kleinen Protokollanalysator zusammengestrickt. Dieser unterstützt aktuell Protokollversion 1.0 und ist als "gefährliche Beta" anzusehen: Resol Protocol Analyzer

Downloads

An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!

Weblinks