VBus-Decoder: Unterschied zwischen den Versionen

Aus Hobbyelektronik.org
(Python-Implementierung)
 
(30 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
[[Bild:Vbus regler.jpg|thumb|Das Corpus Delicti]]
 
[[Bild:Vbus regler.jpg|thumb|Das Corpus Delicti]]
{{Infobox AVR
+
Bei der Solaranlage meiner Eltern übernimmt ein Viessmann Vitosolic 200 die Regelung.  
| Typ  = ATmega32
 
| Takt  = 12
 
| FuseH = CF
 
| FuseL = FF
 
}}
 
In unserer Solaranlage arbeitet ein Viessmann Vitosolic 200, der die Regelung der Anlage übernimmt.
 
 
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 keinerlei Informationen verfügbar sind.
+
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 Protokoll 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 - entgegen diverser Meinungen - überhaupt keine Ähnlichkeiten zu RS485 hat.
+
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. Dies kann entweder mit Hilfe des Handbuchs in Erfahrung gebracht werden (Angabe der Spannung und Strom, bei RS-485 ist üblicherweise keine Stromversorgung vorhanden) oder durch Messung ermittelt werden: An den VBus-Klemmen sollte eine (zappelnde) Spannung von ca. 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
+
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=
Zeile 30: Zeile 28:
  
 
Folgendes Daten habe ich zum Testen verwendet:
 
Folgendes Daten habe ich zum Testen verwendet:
<pre>
 
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
 
</pre>
 
  
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="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 />
 +
0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39, <br />
 +
0x45, 0x01, 0x38, 0x22, 0x04, 0x5B, <br />
 +
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br />
 +
0x6C, 0x01, 0x38, 0x22, 0x05, 0x33, <br />
 +
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br />
 +
0x38, 0x22, 0x38, 0x22, 0x05, 0x46, <br />
 +
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
 +
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
 +
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
 +
0x38, 0x0F, 0x00, 0x00, 0x01, 0x37, <br />
 +
0x47, 0x00, 0x00, 0x00, 0x00, 0x38, <br />
 +
0x64, 0x64, 0x00, 0x00, 0x00, 0x37, <br />
 +
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
 +
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, <br />
 +
0x00, 0x00, 0x43, 0x00, 0x00, 0x3C, <br />
 +
0x00, 0x00, 0x02, 0x00, 0x00, 0x7D, <br />
 +
0x01, 0x03, 0x60, 0x02, 0x04, 0x15, <br />
 +
0x02, 0x00, 0x00, 0x00, 0x00, 0x7D, <br />
 +
</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.
+
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!
  
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.
+
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.
  
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.
+
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):
  
Das ist auch schon das gröbste.
+
<code>
Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.
+
<span class="hb1">0x5E, 0x04, 0x5E, 0x01</span>, <span class="hb2">0x05</span>, <span class="hb3">0x39</span>,
 +
</code>
  
==Hintergrund==
+
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>.
Noch eine kleine Hintergrundinformation, worum es sich bei der Ziel- und Quell-Adresse handelt.
 
  
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.
+
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.
  
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).
+
Die Prüfsumme der einzelnen Nachrichtenteile wird mittels CRC8 berechnet.
  
=Software=
+
Das ist auch schon das Gröbste.
Die Software ist, wie immer, in C geschrieben.
+
Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.
Über den Befehl Vbus_ProcessChar() kann ein Zeichen von der seriellen Schnittstelle übergeben werden. Im einfachsten Fall kann die ISR-Routine wie folgt aussehen:
 
  
<source lang="c">
+
==Adressen==
ISR (USART_RXC_vect) {
+
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/#/vsf Paketbeschreibung] verwiesen.
Vbus_ProcessChar(UDR);
 
}
 
</source>
 
  
Vorher muss noch der UART initialisiert werden (9600 8N1, sei() nicht vergessen!).
+
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.
  
Die empfangenen und dekodierten Daten werden in der Variable vbus_outdata gespeichert.
+
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).
In dieser Variable muss auch angegeben werden, ob ein Paket gelesen werden soll:
 
<pre>
 
vbus_outdata.update = 1;
 
</pre>
 
 
 
Ist ein Paket vollständig angekommen, wird die valid-Eigenschaft auf 1 gesetzt. Im Demo-Code wird nach erfolgreichem Empfang das komplette Datenpaket am UART ausgegeben (bitte nicht an den Regler zurückschicken, sondern möglichst an den PC!):
 
 
 
<source lang="c">
 
int main() {
 
 
 
  ...
 
 
 
  while(1) {
 
    if(vbus_outdata.valid == 1) {
 
      vbus_outdata.valid = 0;
 
      VBus_Show_Values();
 
      vbus_outdata.update = 1;
 
    }
 
  }
 
}
 
</source>
 
 
 
 
 
 
 
==Debug-Ausgabe==
 
[[Bild:Vbus debug.jpg|thumb|Anzeige auf dem Display. die ICs unten und rechts gehören nicht zur Schaltung]]
 
Der Debug in der Software gibt einige Informationen zur Dekodierung auf einem LC-Display aus.
 
 
 
Dieser Modus kann in der Datei vbus.h Zeile 35 aktiviert werden (standardmäßig deaktiviert).
 
 
 
Über UART würde eine Ausgabe kaum sinn machen, da man durch das langsame Senden den Empfang der Daten verpasst.
 
 
 
Zugegebenermaßen: ich habe einen Exoten mit LC7980-Controller und einer Auflösung von 240x40 Pixel verwendet. Die Routinen lassen sich aber halbwegs einfach auf einen anderen Displaycontroller anpassen.
 
Die Ausgabe auf dem Display sieht wie folgt aus:
 
 
 
Bei jedem Erhalt eines Sync-Wortes wird "Sync" angezeigt.
 
 
 
Wurde der Head empfangen, wird der Displayinhalt gelöscht und folgendes ausgegeben:
 
 
 
<pre>
 
D:<Ziel-Adresse> S:<Quell-Adresse> V:<Protokoll-Version> C:<Befehl> F:<Anzahl Frames> X:<Prüfsumme ok|nok>
 
</pre>
 
  
Danach wird, wenn die Prüfsumme ok ist jedoch das falsche Protokoll angegeben wurde, die Meldung "!V1.0->dropped " ausgegeben.
+
=Hardware=
Hat das Paket das "falsche" Adress-Pärchen, wird "Wrong addr->dropped " angezeigt.
+
Im Laufe der Zeit haben sich mehrere Schaltungen ergeben. Um diesen Artikel übersichtlich zu halten, wurden die verschiedenen Varianten auf Unterseiten aufgeteilt:
  
Kommen diese beiden Meldungen nicht, werden Informationen über die dekodierten Frames ausgegeben:
+
(Die Links zu den Unterseiten sind befinden sich jeweils in den Überschriften)
  
<pre>
+
==[[VBus-Decoder/Adapter für RS-232|Adapter für RS-232]]==
F<Frame-Index><Prüfsumme ok|nok>
+
Wenn man noch einen PC oder Adapter hat der RS-232 spricht, kann sich dieser Hardware bedienen.
</pre>
 
  
Nachdem alle Frames empfangen wurden, wird ein "AFR" (all frames received) ausgegeben
+
Der Zugriff ist nur lesend möglich und es gibt keine galvanische Trennung zwischen Bus und DTE.
  
Im Ganzen kann solch eine Ausgabe wie folgt aussehen:
 
<pre>
 
Sync [Display wird geleert]
 
D:0x0010 S:0x7321 V:1 C:0x0100 F:18 X:ok F0ok F1ok F2ok F3ok F4ok F5ok F6ok F7ok F8ok F9nok F10ok F11ok F12ok F13ok F14nok F15ok F16ok F17ok AFR
 
</pre>
 
 
Gleiches Beispiel mit meinen Testdaten, nur dass hier (im Gegensatz zu den Daten!!) Frame 9 und 14 ungültig sind.
 
 
==Zuordnung der Datenfelder==
 
Die Zuordnung der empfangenen Daten kann man relativ einfach zu den entsprechenden Feldern zuordnen.
 
 
Im der Datei %ProgramFiles%\RESOL\ServiceCenterFull\eclipse\plugins\de.resol.servicecenter.vbus.<Device>\VBusSpecification<Device>.xml
 
 
findet man alle Zuordnungen der Felder. Achtung: es kann Lücken geben - dadurch sind in meinem Code die "unknown"-Felder entstanden.
 
 
==Bekannte Fehler/Macken==
 
[[Bild:Vbus_putty_vs_rss.png|thumb|Daten meiner Auswertung (links) und die des Resol ServiceCenters]]
 
Folgendes wurde noch nicht getestet/ist unbekannt:
 
*Einstrahlung
 
*Werte hinter der Fehler- & Warnungsmaske (muss ich noch in den XML-Dateien nachlesen)
 
*Unbekannt-Felder
 
** anscheinend immer 0x00
 
*Woher kommt der Wochentag bei der Systemzeit
 
 
Verbesserungswürdig an der Software:
 
*RAM-Belegung
 
*Unterstützung der weiteren Protokolle (Parametrisierung - werde ich aber vermutlich nicht in absehbarer Zeit implementieren)
 
*Es ist nicht ersichtlich, welche Daten durch Prüfsummenfehler ungültig sind
 
 
=Hardware für den PC=
 
Vor geraumer Zeit habe ich ein kleines Design zum Mitlesen auf dem VBus am PC gemacht. In leicht abweichender Form wurde es auch aufgebaut und hat funktioniert.
 
Das Leiterkärtchen ist etwa 27,5 x 23,2 mm groß und lässt sich direkt an einen D-Sub-Stecker anflanschen. Der MAX3232 erzeugt RS232-kompatible Pegel und die Versorgung wird vom VBus übernommen.
 
 
<gallery>
 
<gallery>
 
   Bild:Vbus_rxo_brd.png|thumb|Layout der PC-Hardware
 
   Bild:Vbus_rxo_brd.png|thumb|Layout der PC-Hardware
 
</gallery>
 
</gallery>
  
Die Daten für EAGLE befinden sich im Download-Bereich.
+
==[[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.
=VBus-Adapter Nano=
 
Die Hardware für den Empfang geht auch deutlich einfacher als in der Protokollbeschreibung und weiter oben auf der Seite gezeigt.
 
 
 
Mit einer geschickten Beschaltung eines Komparators braucht man für die Hysterese genau einen Komparator und keinen einzigen Schmitt-Trigger.
 
 
 
Das macht die Schaltung kompakt, billig und einfach aufzubauen. Ich hab einfach mal geschaut, wie klein man es machen kann, das Ergebnis lautet: 13x32,5 mm²:
 
  
 
<gallery>
 
<gallery>
  resol_nano_0.1_sch.png|Schaltplan
 
  resol_nano_0.1_assy_top.png|Bestückungsplan Oberseite
 
  resol_nano_0.1_assy_bot.png|Bestückungsplan Unterseite
 
 
   resol_nano_0.1_assy.jpg|Bestückte Leiterkarte
 
   resol_nano_0.1_assy.jpg|Bestückte Leiterkarte
 
</gallery>
 
</gallery>
  
Statt des Optokopplers OK1 und R1 sowie C1 können auch die 0-Ohm-Widerstände R10 und R11 bestückt werden, allerdings fällt dann die galvanische Trennung weg und es kann aufgrund der Vorwärtsspannung der Dioden zu einem GND-Offset kommen. Die Bestückungsoption ist allerdings nur der Vollständigkeit halber vorhanden, generell rate ich dazu, die nicht einmal 60 Cent zu investieren.
+
==[[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.
Die drei Halblöcher dienen zum Platzsparenden fixieren mit M2,5-Schrauben.
 
 
 
{| class="wikitable"
 
! Menge  || Referenz    || Wert          || Package    || Reichelt Bestellcode   
 
|-
 
| 1      || SV1        ||                || MA04-1    ||               
 
|-
 
| 2      || C2, C3      || 100n          || C0603      || X7R-G0603 100N 
 
|-
 
| 3      || R5, R7, R8  || 10k            || R0603      || RND 0603 1 10K 
 
|-
 
| 1      || C5          || 10u/16V        || C1206      || KEM X7R1206 10U
 
|-
 
| 1      || R4          || 15k            || R0603      || RND 0603 1 15K 
 
|-
 
| 1      || X1          || 1751248        || 1751248    || AKL 059-02     
 
|-
 
| 2      || R3, R6      || 18k            || R0603      || RND 0603 1 18K 
 
|-
 
| 1      || R9          || 1k            || R0603      || RND 0603 1 1K 
 
|-
 
| 2      || C1*, C4    || 1n            || C0603      || X7R-G0603 1,0N 
 
|-
 
| 1      || R1*        || 3k3            || R0603      || RND 0603 1 3,3K
 
|-
 
| 1      || R2          || 68k            || R0603      || RND 0603 1 68K 
 
|-
 
| 1      || OK1        || 6N136          || DIL08      || 6N 136         
 
|-
 
| 3      || D1, D2, D5  || BAV99          || SOT23      || BAV 99 NXP     
 
|-
 
| 1      || IC4        || LM393D        || SO08      || LM 393 D SMD   
 
|-
 
| 1      || IC1        || LP2985IM5-5.0  || SOT23-DBV  || LP 2985 IM5-5.0
 
|-
 
| 1      || D3          || P6SMB 15A      || SMBJ      || P6SMB 15A SMD 
 
|}
 
 
 
Zu den mit * markierten Bauteilen erhielt ich von Micha folgenden Hinweis:
 
<pre>
 
Ich musste am Ausgang den C entfernen und den PullUp auf 4.7k erhöhen - sonst hat der Raspi das Low nicht erkannt.
 
</pre>
 
 
 
'''Nachtrag vom 10.11.2019:''' Nach erneuten Messungen mit 3,3 V auf der Augangsseite stellte sich heraus, dass die Pegel deutlich besser werden, wenn für '''R1 ein 6,8 kOhm-Widerstand und für C1 ein 680 pF-Kondensator''' eingesetzt wird. Wie von Micha beschrieben, kann C1 auch einfach weggelassen werden. Mit dem Weglassen steigt allerdings die Gefahr von Glitches.
 
 
 
Ich sollte die untenstehenden [[#Messung|Messungen]] also nochmal mit 3,3 Volt wiederholen. Ebenso möchte ich IC1 durch "TS 5205 CX533" ersetzen, der ein gutes Stück günstiger ist.
 
 
 
==Aufbau==
 
Der Aufbau kann nach dem üblichen Vorgehen erfolgen, hier ein paar Hinweise, die es vereinfachen
 
* D3 vor D5 bestücken, da die Pads von D3 sehr klein ausfallen
 
* Die Oberseite kann komplett vor der Unterseite bestückt werden. Die Stiftleiste und Anschlussklemmen sind so gut wie gleich hoch
 
 
 
==Messung==
 
Kommt auch das raus, was rauskommen soll?
 
 
 
Die Spezifikation gibt ein paar Vorgaben:
 
 
 
* Maximale Strombelastbarkeit: 35 mA
 
* Schaltschwellen am Slave: 2,25 V Space, 2,00 V Mark
 
 
 
So die Theorie. In der Praxis hat die Schaltung eine Stromaufnahme von etwa 3 mA.
 
 
 
Den Rest musste ich an der echten Anlage messen, da in der Bastelecke weder ein Resol-Regler noch ein Protokollsimulator (der in diesem Fall relativ einfach ausfallen könnte) herumsteht.
 
Also das Oszi eingepackt und die Schaltung bei meinen Eltern fliegend angeklemmt.
 
 
 
Bei den Schaltschwellen sieht es wie folgt aus:
 
  
 
<gallery>
 
<gallery>
  resol_nano_0.1_meas_threshold.png|Ch1 hinter R8, Ch2 an ICE4A.1
+
    Vbuspi 1.0 bare.jpg | Unbestückte v1.0-Leiterkarte
 +
    Vbuspi 1.1 assy zero.jpg | Bestückte v1.1-Leiterkarte auf einem Raspberry Pi Zero W
 +
    Vbuspi 1.3 pers.jpg | v1.3-Bestückte Leiterkarte auf einem Raspberry Pi Zero W
 
</gallery>
 
</gallery>
  
Die Schaltschwelle für die steigende Flanke liegt bei etwa 1,96 V, die für die fallende bei 2,44 V. In Hinblick auf die Messgenauigkeit des Oszilloskops und Toleranzen der Widerstände ein mehr als zufriedenstellendes Ergebnis.
+
===Versionen===
 
+
* [[VBus-Decoder/Adapter für den Raspberry Pi v1.0|Version 1.0/1.1]]: Der erste Versuch - "never trust a x.0"
Der Optokoppler bringt leichte und vor allem asymmetrische Verzögerungen mit sich.
+
* [[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.2|Version 1.2]]: Besser, aber noch nicht gut
 +
* '''[[VBus-Decoder/Adapter_für_den_Raspberry_Pi_v1.3|Version 1.3]]: Die beste Version, die man aktuell haben kann ;)'''
  
Gemessen wird hier das Signal vor (Ch1 an OK1.3) und nach (Ch2 an OK1.6) dem Optokoppler. Als Stromversorgung auf der "rechten Seite" wurde eine Powerbank mit 5,1 V Ausgangsspannung verwendet. Als Schwellenwerte wurden jeweils 0,25 * Vcc und 0,75 * Vcc verwendet.
+
==[[VBus-Decoder/Adapter für den ESP8266|Adapter für den ESP8266]]==
 +
Noch etwas kleiner als für den Raspberry Pi: Ein Adapter mit ESP8266-Modulen.
  
 
<gallery>
 
<gallery>
  resol_nano_0.1_meas_rising.png|Verzögerung steigende Flanke
+
    vbusesp_top.jpg|Bestückte Leiterkarte
  resol_nano_0.1_meas_falling.png|verzögerung fallende Flanke
 
 
</gallery>
 
</gallery>
  
Bei steigender Flanke hängt der Ausgang 6,12 µs, bei fallender 8,68 µs hinterher.
+
==[[VBus-Decoder/Adapter_Nano#Troubleshooting|Troubleshooting]]==
Die Verzögerung selbst ist hier nicht das Problem, sondern der Verzögerungsunterschied, da dieser die UART-Interfaces der Empfänger durcheinanderbringen kann.
+
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.
  
Bei den verwendeten 9600 Baud entspricht eine Bitzeit ca. 104 µs. Die Verzögerungsdifferenz der Flanken beträgt mit 2,56 µs lediglich 2,5 % einer Bitzeit. Vernachlässigbar.
+
=[[VBus-Decoder/FAQ|FAQ]]=
 +
(bitte auf die Überschrift klicken)
  
Wichtig ist ebenfalls, dass die Versorgungsspannung stabil bleibt, da sich sonst die Schaltschwellen verschieben und somit Unsinn übertragen wird. Besonders die Tatsache, dass der Optokoppler bei niedriger Busspannung aktiv ist, kann problematisch werden.
+
=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.
  
Das Oszi-Bild mit Probe am 5V-Ausgang des Reglers und DC-Kopplung war so unspektakulär, dass ich gar keine Bildschirmaufnahme gemacht hab. Interessanter ist da die Betrachtung der Versorgung mit AC-Kopplung:
+
Eine Implementierung für die [[VBus-Decoder/AVR8-Software|AVR8-Plattform]] findet sich auf der entsprechenden Unterseite.
  
<gallery>
+
==Python==
  resol_nano_0.1_noise.png|Überblick
+
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:
  resol_nano_0.1_noise_zoom.png|Nahansicht
 
</gallery>
 
  
Bisschen hohe Spikes, wobei diese auch mit dem Probing selbst zusammenhängen können (2x 20 cm Dupont-Drähte und EZ-Hooks), ansonsten nur knapp 10 mV Ripple. Passt soweit.
+
* [[Datei:VBus-Python.zip]]
  
==Troubleshooting==
+
Oliver hat basierend auf dem Code von Nicki eine Schnittstelle zur [https://www.volkszaehler.org/ Volkszähler]-Middleware gebaut:
  
Nachdem ich schon ein paar Hilferufe erhalten habe, hier ein kleiner Troubleshooting-Guide - dazu am besten die beiden Bilder (oder zumindest das des Layouts) parallel öffnen:
+
<pre>
 
+
Der Code nutzt die Resol-Decoder-Lib von Nicki, die ist auch mit dabei.
<gallery>
+
In der config.py stellt man die Adresse der Middleware in seinem Netzwerk,
  Resol_nano_0.1_ts_sch.png|Schaltplan mit Messpunkten
+
sowie die UUID der Kanäle ein, damit man die Daten referenzieren kann.
  Resol_nano_0.1_ts_brd.png|Layout mit Messpunkten
+
(Zum Test kann man auch simulierte Daten nutzen, oder die Ausgabe in ein File schreiben lassen)
</gallery>
+
</pre>
 
 
Für die Messungen ist ein einfaches Multimeter und eine 9 V-Batterie ausreichend. Besser ist jedoch ein Labornetzteil.
 
  
Um eine Ferndiagnose zu vereinfachen, bitte alle gemessenen Spannungen und Ströme notieren
+
* [[Datei:Vbus_volkszaehler.zip]]
  
# Leiterkarte nochmal genau ansehen, irgendwelche Lötbrücken, wo keine sein sollten? (Ich weiß, sie ist verdammt eng)
+
==Protokoll-Analysator==
# Spannungsquelle auf 9 V einstellen, nachmessen und Spannung notieren. Sofern vorhanden sollte die Strombegrenzung auf etwa 20 mA eingestellt werden.
 
# Spannungsquelle über das Multimeter für eine Strommessung an X1 anschließen (die Polarität ist egal)
 
## Die Schaltung sollte im Ruhezustand nicht mehr als 3 mA aufnehmen. Ist es mehr oder riecht es "warm": sofort abstecken und nochmal alle Lötstellen prüfen und schauen, ob die richtigen Bauteile bestückt wurden
 
## Mit Pinzette R5 (<code>S3-G1</code>) kurzschließen, der Strom sollte auf etwa 6 mA ansteigen. Wenn ja: die Wahrscheinlichkeit ist groß, dass alles ok ist :) - wenn nein: Weitermachen
 
# Multimeter auf Spannungsmessung umstellen (umstecken nicht vergessen...)
 
# Spannung über D3 (<code>S1-G1</code>) messen, diese sollte um die Durchflussspannung zweiter Dioden (ca. 1,3 V) geringer als die Eingangsspannung sein. Bei 9 V am Eingang sind das etwa 7,7 Volt. Wenn die Spannung deutlich niedriger ist, sind es ggf. die falschen Dioden verbaut.
 
# Spannung über C5 (<code>S2-G1</code>) messen, sollte um die Durchflussspannung dreier Dioden (ca. 1,95 V) geringer sein als die Eingangsspannung. Bei 9 V am Eingang also um die 7 V. Wenn nicht, siehe letzter Punkt.
 
# Ausgangsspannung des Reglers über C3 (Marker vergessen) messen, sollte ziemlich genau 5,0 V sein. Wenn nicht: Regler checken.
 
# Spannung über C4 (<code>S3-G1</code>) messen, dieser sollte etwa der Hälfte der Sapnnung über D3 entsprechen. Ist der Wert grob daneben, die Widerstände R5 und R8 kontrollieren (2:1-Spannungsteiler) und prüfen, ob der Komparator (IC4) richtig eingelötet ist.
 
# Spannung über R4 (<code>S4-G1</code>) messen, diese sollte ca. 2,03 V betragen. Wenn nicht, R2, R3 und R4 sowie IC4 prüfen.
 
# Spannung über R7 (<code>S5-G1</code>) messen. Diese sollte ca. 1,79 V betragen. Wenn nicht: R6 und R7 sowie IC4 prüfen.
 
# Nun können zusätzlich an SV1.1 3,3 V (oder 5V) und an SV1.4 GND angelegt werden (z. B. vom Raspberry Pi).
 
## Im Ruhezustand sollte über C1 (<code>S6-G2</code>) 3,3 V anliegen, wenn nicht: R1 prüfen, C1 probehalber entfernen.
 
## Wird R5 (<code>S3-G1</code>) kurzgeschlossen, sollte die Spannung über über C1 (<code>S6-G2</code>) auf "nahe 0 V" abfallen. Wenn sie nur leicht abfällt, R1 prüfen oder OK1 prüfen/tauschen.
 
 
 
Sollte die Schaltung dennoch nicht funktionieren, bitte die notierten Spannungen sowie aussagekräftige Fotos (gut ausgeleuchtet, scharf, zugeschnitten) per E-Mail an mich senden.
 
 
 
==Leiterkarten==
 
Es liegen noch ein paar Leiterkarten herum. Wer eine möchte, kann sich gerne bei mir melden.
 
 
 
=[[VBus-Decoder/FAQ|FAQ]]=
 
(bitte auf die Überschrift klicken)
 
 
 
=Python-Implementierung=
 
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 und Gewährleistung:
 
 
 
* [[Datei:VBus-Python.zip]]
 
  
=Download=
+
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]
  
*[[Datei:VBus-Protokollspezifikation.pdf]] Stand: 20.04.2009
+
=Downloads=
*[[Datei:VbusDecode.zip]] Version 0.2beta vom 09.03.2010 ATmega32 @ 12MHz
+
* [[Datei:VBus-Protokollspezifikation.pdf]] Stand: 20.04.2009
*[[Datei:Vbus_rxo.zip]] Design-Daten für die PC-Hardware. Erstellt mit EAGLE 7.5.0
+
* (Die Downloads für die Hardware befindet sich auf der jeweiligen Unterseite)
*[[Datei:Vbus_nano.zip]] EAGLE-Dateien und LTspice-Simulationsdaten für den VBus-Nano
 
  
 
'''An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!'''
 
'''An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!'''
Zeile 344: Zeile 161:
 
* [http://www.resol.de RESOL - Elektronische Regelungen GmbH]
 
* [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
 
* [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 Github-Seiten von Daniel Wippermann]
  
 
[[Kategorie:AVR]]
 
[[Kategorie:AVR]]
 
[[Kategorie:Energieerfassung]]
 
[[Kategorie:Energieerfassung]]
[[Kategorie:Solar-Anlage]]
+
[[Kategorie:Solaranlage]]
 +
[[Kategorie:VBus]]

Aktuelle Version vom 25. August 2023, 22:09 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 Protokoll 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. Dies kann entweder mit Hilfe des Handbuchs in Erfahrung gebracht werden (Angabe der Spannung und Strom, bei RS-485 ist üblicherweise keine Stromversorgung vorhanden) oder durch Messung ermittelt werden: An den VBus-Klemmen sollte eine (zappelnde) Spannung von ca. 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.

Versionen

Adapter für den ESP8266

Noch etwas kleiner als für den Raspberry Pi: Ein Adapter mit ESP8266-Modulen.

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