Weishaupt WTC am eBus mit ebusd

[J0EK3R]

@John: Ich habe mich mit dem Problem beschäftigt, dass bei meinem Aufbau nur jede x-te Antwort der 0902-Nachrichten Werte enthält.

Und bin zu folgender Erkenntnis gelangt:
Der Dienst (0902) ist korrekt, meine EEPROM-Adressen stimmen.
Also muss es an der Anbindung zum eBus liegen!

Mein Verdacht ist, dass es an meinem eBus-Koppler liegt: ich habe ja einen mit Ethernet-Schnittstelle.
Ich könnte mir vorstellen, dass die Zeitverzögerung von ebusd über Ethernet zum eBus-Koppler und zurück zum Problem wird!

Das passive Mithören der Nachrichten zwischen den Reglern funktioniert bei mir ja problemlos.
Doch möchte der ebusd selbst senden, was bei den 0902-Nachrichten der Fall ist, dann muss er sich ja irgendwie auf den Bus aufsynchronisieren. Ich vermute, dass dabei wegen der Verzögerung etwas aus dem Takt läuft.

Was ist Deine Meinung dazu, hast Du Erfahrung mit dem eBus-Koppler Ethernet von eService-online?
https://www.eservice-online.de/shop/ebus/142/ebus-koppler-ethernet

Oder liegt es an einem Parameter des ebusd?

/etc/default/ebusd

Code Auswählen Erweitern


EBUSD_OPTS="--nodevicecheck --scanconfig --device=192.168.0.21:5000 --latency=10000 --receivetimeout=25000 --loglevel=notice --enablehex --lograwdatafile=/var/log/ebusrawdata.log --httpport=8001"


[john30]

Sicher? 

...bin zwar nicht der git-Experte, aber in datatype.cpp finde ich auch nach dem git pull besagten Typ "TTQ" nicht... 

Da hab ich vermutlich den push vergessen, sorry

[john30]

Code Auswählen Erweitern

[quote author=J0K3r link=topic=61017.msg540892#msg540892 date=1481901242]
Doch möchte der ebusd selbst senden, was bei den 0902-Nachrichten der Fall ist, dann muss er sich ja irgendwie auf den Bus aufsynchronisieren. Ich vermute, dass dabei wegen der Verzögerung etwas aus dem Takt läuft.

Was ist Deine Meinung dazu, hast Du Erfahrung mit dem eBus-Koppler Ethernet von eService-online?

[/quote]
Erhöhe doch mal die Latenz (--latency) locker auf 80000. Damit klappts mit meinem billig-ETH2USB Adapter ganz gut.
Ansonsten musst Du mal kurz "raw" absetzen und das Timing genau anschauen, wenn ebusd aktiv was lesen will. Dann kann man die Latenz entsprechend einstellen.

[J0EK3R]

Heureka!? 

Kann es sein, dass es an der eBus-Adresse des ebusd liegt, dass die 0902-Requests nicht funktionieren? 

Starte ich den ebusd mit eBus-Adresse 0xFF, dann bekomme ich immer eine gültige Antwort! 

Wie sieht das denn beim eBus eigentlich mit der Arbitrierung aus?
Normalerweise wird der ebusd ja mit Master-Adresse 0x31 gestartet; übernimmt da vielleicht ein anderes Gerät mit höherer Adresse das Kommando und versaut mir meinen Request!? 
Kann der ebusd diesen Fall behandeln?

Die Adresse 0xFF ist laut Spezifikation für den Master 25 "PC" mit Prioritätenklasse 4 vorgesehen.
Die Adresse 0x31 ist laut Spezifikation für den Master 8 "Businterface" mit Prioritätenklasse 1 vorgesehen.

[john30]

Starte ich den ebusd mit eBus-Adresse 0xFF, dann bekomme ich immer eine gültige Antwort! 

Interessant. Schau mal im ebusd Log nach, ob da ein Adresskonflikt drin steht (error "own [slave/master] address XX ist used by another participant).

Wie sieht das denn beim eBus eigentlich mit der Arbitrierung aus?

Gut, es wird arbitriert. Wenn allerdings die Adresse von einem anderen Gerät benutzt wird, kommt alles schön durcheinander...

[J0EK3R]

Hallo John, hallo Welt! 

Nun habe ich sehr viel herumprobiert und möchte meine Vermutungen/Erkenntnisse teilen und zur Diskussion stellen. 

Adresskonflikte kann ich ausschließen - es gibt weder verdächtige Einträge in der Log-Datei, noch bei der Ausgabe von ebusctl info und ich kenne mein System ja mittlerweile.

Da ich sämtliche freien Adressen mit allen Prioritäten von 0 bis 4  für den ebusd ausprobiert habe, schließe ich ein Arbitrierungsproblem ebenfalls aus.

Verlässliche Antworten auf meine 0902-Requests gibt es von den Heizkreisreglern (0x35, 0x75) nur dann, wenn die Anfragen von Master 1 mit Adresse 0x00 (Master 1 PC/Modem) oder Master 25 mit Adresse 0xFF (Master 25 PC) kommen.

Deshalb vermute ich, dass die Heizkreisregler einfach so programmiert sind, dass sie nur auf diese beiden Adressen vernünftig antworten. 

Die Weishaupt-Diagnosesoftware "WCMDiagnose" verwendet übrigens auch die Adresse 0xFF für die Parameteranfragen.

Jetzt stellt sich mir nur noch die Frage, ob ich den ebusd mit Adresse 0x00 oder 0xFF betreiben soll.
Ist die Adresse 0x00 nicht die, die jeden Arbitrierungswettstreit gewinnen würde? Damit könnte ich den Standard-eBus-Verkehr durcheinander bringen, oder?
John, was meinst Du?

[john30]

Jetzt stellt sich mir nur noch die Frage, ob ich den ebusd mit Adresse 0x00 oder 0xFF betreiben soll.
Ist die Adresse 0x00 nicht die, die jeden Arbitrierungswettstreit gewinnen würde? Damit könnte ich den Standard-eBus-Verkehr durcheinander bringen, oder?

Ich würde in der Tat eher 0xff verwenden, damit ebusd den Rest des Systems nicht stört.

[J0EK3R]

Hallo John! 

Ich würde in der Tat eher 0xff verwenden, damit ebusd den Rest des Systems nicht stört.

So werde ich das machen, vielen Dank! 

ebusd holt sich aus dem Dateinamen auch noch einen optionalen Suffix, z.B. für die Nr. des Heizkreises. Z.B. macht der Symlink 7c.rcc.6.csv -> 75.rcc.csv aus der default circuit "rcc" der 75.rcc.csv dann "rcc.6" für die Adresse 7c.
Ob das auch ohne die ID (im Beispiel "RCC") im Dateinamen klappt, weiß ich grad nicht. Probiers mal.

Nein, das geht (ohne Änderung im Quellcode) nicht!

Ich habe mich intensiv mit Deinem Quellcode auseinandergesetzt und bin dabei der Frage nachgegangen, warum das Setzen eines default circuits ohne ID im Dateinamen (Bsp.: 35..hk1.csv) nicht funktioniert.
Das Problem und gleichzeitig die Lösung findet sich in der statischen Funktion extractDefaultsFromFilename (Zeile 356 in filereader.h).

https://github.com/john30/ebusd/blob/master/src/lib/ebus/filereader.h#L356

Code Auswählen Erweitern


354 if (name.length()>1) {
355   pos = name.find('.', 1); // check for ".IDENT."
356   if (pos!=string::npos && pos>2 && pos<=6) { // up to 5 chars between two "."s, immediately after "ZZ."
357     ident = circuit = name.substr(1, pos-1);

Hier prüfst Du eine Mindeslänge für den ID-String ab: pos>2 bei einem Startposition von 1 - also mindestens 2 Zeichen.
Ist diese Bedingung nicht erfüllt, wird anschließend weder auf einen CIRCUIT noch auf einen SUFFIX geprüft und damit keine defaults gesetzt.

Ich habe den Code wie folgt gepatcht: pos>=1 -  damit waren meine ganzen Sorgen weg! 

Code Auswählen Erweitern


354 if (name.length()>1) {
355   pos = name.find('.', 1); // check for ".IDENT."
356   if (pos!=string::npos && pos>=1 && pos<=6) { // up to 5 chars between two "."s, immediately after "ZZ."
357     ident = circuit = name.substr(1, pos-1);


Was hälst Du davon, so eine Änderung in Deinen Quellen vorzunehmen?
Mach mich glücklich! 

[john30]

Mach mich glücklich! 

werde ich tun

[J0EK3R]

Hallo John! 

werde ich tun

...und ich freu mich drauf! 

Und ich komme wieder mit einer ganz speziellen Frage:
Gerade habe ich die Definitionen für den Fehlerspeicher gemacht (errorhistory.inc).
Der Fehlerspeicher an sich besteht aus sechs Fehlereinträgen mit jeweils zehn Feldern, in denen der Systemzustand zum jeweiligen Fehlerzeitpunkt festgehalten wird.
Leider ist es nicht so, dass ich einfach sechs gleich aufgebaute Telegramme definieren kann, die sich lediglich in der ID unterscheiden. 
Nein, es muss ein ganzer Speicherbereich ausgelesen werden, verteilt auf sechs Telegramme. Natürlich sind die Fehler-Strukturen innerhalb der sechs Telegramme verschoben... 

Da ich Dein Wiki quasi auswendig aufsagen kann  , weiß ich, dass es da doch etwas gibt: Message Chaining! 
Damit könnte ich mit nur einem Aufruf à la ebusctl r -f ErrorHistory den kompletten Fehlerspeicher auslesen und hätte leichten Zugriff auf die einzelnen Felder.

Hier ist ein Auszug der jetzigen Definitionen:

Code Auswählen Erweitern


r,,ErrorHistory1,Fehlerhistorie ,,,,"03029F8263",,s,skip,,, ,,s,UCH,,,Byte2 ,E4.ErrorCode,s,UCH,,,Fehlercode ,E4.OperatingPhase,s,operatingphase,,,Betriebsphase ,E4.LoadSetting,s,UCH,,,Ladestellung ,E4.SettingUV,s,settingUV,,,Stellung UV ,E4.SupplyTemp,s,temp0,,,Vorlauftemperatur ,E4.FlueGasTemp,s,temp0,,,Abgastemperatur ,IonisationSignal,s,UCH,,,Ionisationssignal ,E4.ExternalTemp,s,temp0,,,Außentemperatur ,E4.DHWTemp,s,temp0,,,WW-Temperatur
r,,ErrorHistory2,Fehlerhistorie ,,,,"A8B26C",,s,skip,,, ,E4.ThroughputValue,s,UCH,,,Durchflusswert ,E3.ErrorCode,s,UCH,,,Fehlercode ,E3.OperatingPhase,s,operatingphase,,,Betriebsphase ,E3.LoadSetting,s,UCH,,,Ladestellung ,E3.SettingUV,s,settingUV,,,Stellung UV ,E3.SupplyTemp,s,temp0,,,Vorlauftemperatur ,E3.FlueGasTemp,s,temp0,,,Abgastemperatur ,E3.IonisationSignal,s,UCH,,,Ionisationssignal ,E3.ExternalTemp,s,temp0,,,Außentemperatur ,E3.DHWTemp,s,temp0,,,WW-Temperatur ,E3.ThroughputValue,s,UCH,,,Durchflusswert ,E2.ErrorCode,s,UCH,,,Fehlercode


Schön wäre etwas in dieser Richtung (man beachte die durch Semikolon getrennten IDs der beiden Telegramme)

Code Auswählen Erweitern


#r,,ErrorHistory,Fehlerhistorie ,,,,03029F8263;A8B26C,,s,skip,,, ,,s,UCH,,,Byte2 ,E4.ErrorCode,s,UCH,,,Fehlercode ,E4.OperatingPhase,s,operatingphase,,,Betriebsphase ,E4.LoadSetting,s,UCH,,,Ladestellung ,E4.SettingUV,s,settingUV,,,Stellung UV ,E4.SupplyTemp,s,temp0,,,Vorlauftemperatur ,E4.FlueGasTemp,s,temp0,,,Abgastemperatur ,IonisationSignal,s,UCH,,,Ionisationssignal ,E4.ExternalTemp,s,temp0,,,Außentemperatur ,E4.DHWTemp,s,temp0,,,WW-Temperatur ,,s,skip,,, ,E4.ThroughputValue,s,UCH,,,Durchflusswert ,E3.ErrorCode,s,UCH,,,Fehlercode ,E3.OperatingPhase,s,operatingphase,,,Betriebsphase ,E3.LoadSetting,s,UCH,,,Ladestellung ,E3.SettingUV,s,settingUV,,,Stellung UV ,E3.SupplyTemp,s,temp0,,,Vorlauftemperatur ,E3.FlueGasTemp,s,temp0,,,Abgastemperatur ,E3.IonisationSignal,s,UCH,,,Ionisationssignal ,E3.ExternalTemp,s,temp0,,,Außentemperatur ,E3.DHWTemp,s,temp0,,,WW-Temperatur ,E3.ThroughputValue,s,UCH,,,Durchflusswert ,E2.ErrorCode,s,UCH,,,Fehlercode

Sollte das so funktionieren? Im Wiki-Beispiel verwendest Du IDs, die nur aus einem Byte bestehen.

[J0EK3R]

Hallo John!

...und noch ein Problem:
Ich habe in einem Telegramm einen Integer-Wert, der aus 3 Bytes besteht, beginnend mit dem Low-Byte: "C6 95 01" -> 103878
Das sind die Betriebsstunden.

...in datatype.cpp habe ich nichts passendes mit 24Bit gefunden...

Intuitiv habe ich ULG:3 probiert... 
...was aber nicht funktioniert hat.

Gibt es dafür denn einen passenden Datentyp?
Oder irgendeine andere Möglichkeit, den passenden Typ zu generieren?
Oder ist die einzige Option, weitere 24Bit-Integer-Typen grundsätzlich einzuführen? 

Dann habe ich noch eine Drehzahl, die in 60stel angegeben ist.
Die Field-Templates lassen einen Divisor zu, jedoch keinen Multiplikator.
Natürlich ging mein Versuch mit einem Divisor von 0.016 schief... 

Wäre es nicht ungemein nützlich, allgemein Brüche in der Form "Z/N" in das Feld für den Divisor eingeben zu können?

_templates.csv

Code Auswählen Erweitern


crpm60,UCH,60/1,Rpm,Drehzahl


[john30]

...und ich freu mich drauf! 

So, das ist nun drin, happy new year

Sollte das so funktionieren? Im Wiki-Beispiel verwendest Du IDs, die nur aus einem Byte bestehen.

IDs mit Länge größer 1 werden beim Chaining schon unterstützt, aber unterschiedliche Längen nicht. Da muss ich also im Moment sagen: geht nicht.
Das umzubauen ist bisschen schwierig, weil die chain IDs eh schon völlig aus der Reihe fallen. Da müsste man sich dann was eleganteres einfallen lassen. Daher im Moment nicht auf meiner Roadmap, aber Du kannst ja ein issue dafür aufmachen, dann fälltst nicht runter.

[john30]

Ich habe in einem Telegramm einen Integer-Wert, der aus 3 Bytes besteht, beginnend mit dem Low-Byte: "C6 95 01" -> 103878
Das sind die Betriebsstunden.
Gibt es dafür denn einen passenden Datentyp?
Oder ist die einzige Option, weitere 24Bit-Integer-Typen grundsätzlich einzuführen? 

Dafür bräuchte es wieder einen neuen Basis-Datentyp. Ist kein Problem. Vorschläge für nen Namen?
Spontan hätte ich 3BY/3BR oder TBY/TBR genommen für "3/three byte", aber so doll find ichs nicht.
EDIT: Nochmal drüber nachgedacht. Schlage U3N/U3R/S3N/S3R vor.

Dann habe ich noch eine Drehzahl, die in 60stel angegeben ist.
Die Field-Templates lassen einen Divisor zu, jedoch keinen Multiplikator.

Doch tun sie, die Schreibweise ist nur alles andere als intuitiv: negativer Divisor = Multiplikator.
Also für Faktor 60 einfach -60 hinschreiben.
Das wollte ich schon lange mal von der Syntax umstellen, aber wie das halt so ist...

Wäre es nicht ungemein nützlich, allgemein Brüche in der Form "Z/N" in das Feld für den Divisor eingeben zu können?

Ja, aber dann müsste man das wieder in der Implementierun so durchziehen. Momentan ist der Divisor ein einfaches int (positiv für Teiler und negativ für Faktor). Mit double könnte man alles abbilden, aber dann kommen Rundungsthemen zum Vorschein...

[J0EK3R]

Hallo John 

So, das ist nun drin, happy new year

Vielen Dank und auch Dir ein frohes Neues! 

Das umzubauen ist bisschen schwierig, weil die chain IDs eh schon völlig aus der Reihe fallen. Da müsste man sich dann was eleganteres einfallen lassen. Daher im Moment nicht auf meiner Roadmap, aber Du kannst ja ein issue dafür aufmachen, dann fälltst nicht runter.

Ist erledegt. 

Dafür bräuchte es wieder einen neuen Basis-Datentyp. Ist kein Problem. Vorschläge für nen Namen?
Spontan hätte ich 3BY/3BR oder TBY/TBR genommen für "3/three byte", aber so doll find ichs nicht.
EDIT: Nochmal drüber nachgedacht. Schlage U3N/U3R/S3N/S3R vor.

Habe ebusd abgerufen und neu gebaut: alles funktioniert super - die Benamsung der 24-Bit Integer ist genau richtig, entspricht dem Schema, das Du bisher auch verwendet hast. Super 

Doch tun sie, die Schreibweise ist nur alles andere als intuitiv: negativer Divisor = Multiplikator.
Also für Faktor 60 einfach -60 hinschreiben.

Hab ich das tatsächlich im Wiki überlesen!?
Aber: es tut wie es soll. Auch super!

Das wollte ich schon lange mal von der Syntax umstellen, aber wie das halt so ist...
Ja, aber dann müsste man das wieder in der Implementierun so durchziehen. Momentan ist der Divisor ein einfaches int (positiv für Teiler und negativ für Faktor). Mit double könnte man alles abbilden, aber dann kommen Rundungsthemen zum Vorschein...

Nein, double wäre keine gute Lösung. Wenn man das implementieren wollte, dann sollte man schon bei einem Integer-Bruch bleiben.
Abwärts-kompatibel möchtest Du bestimmt auch sein...
Hmm... dann müsste man eine Definition machen, wie man im Divider-Feld einen Bruch angeben kann. Vielleicht geklammert?

Code Auswählen Erweitern


crpm60,UCH,(1/60),Rpm,Drehzahl


[J0EK3R]

So, ich möchte den aktuellen Stand festhalten. 

Es geht um die Telegramme mit dem Dienst 5000. Diese Telegramme werden verwendet, um Werte aus dem WTC auszulesen; beispielsweise die Fehlerhistorie.
Die Fehlerhistorie wird, verteilt auf insgesamt sechs Telegramme, als Block ausgelesen. Der Aufbau der einzelnen Telegramme unterscheidet sich leider.

Die aktuelle Definition sieht folgendermaßen aus:

Code Auswählen Erweitern


# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field1,part (m;s),type / templates,divider / values,unit,comment,field2,part (m;s),type / templates,divider / values,unit,comment,field3,part (m;s),type / templates,divider / values,unit,comment,field4,part (m;s),type / templates,divider / values,unit,comment,field5,part (m;s),type / templates,divider / values,unit,comment,field6,part (m;s),type / templates,divider / values,unit,comment,field7,part (m;s),type / templates,divider / values,unit,comment,field8,part (m;s),type / templates,divider / values,unit,comment
*r,,,,,,"5000",,,,,,,
r,,ErrorHistory1,Fehlerhistorie ,,,,"03029F8263",,s,skip,,, ,,s,UCH,,,Byte2 ,E4.ErrorCode,s,UCH,,,Fehlercode ,E4.OperatingPhase,s,operatingphase,,,Betriebsphase ,E4.LoadSetting,s,UCH,,,Ladestellung ,E4.SettingUV,s,settingUV,,,Stellung UV ,E4.SupplyTemp,s,ctemp1,,,Vorlauftemperatur ,E4.FlueGasTemp,s,ctemp1,,,Abgastemperatur ,IonisationSignal,s,UCH,,,Ionisationssignal ,E4.ExternalTemp,s,ctemp1,,,Außentemperatur ,E4.DHWTemp,s,ctemp1,,,WW-Temperatur
r,,ErrorHistory2,Fehlerhistorie ,,,,"A8B26C",,s,skip,,, ,E4.ThroughputValue,s,UCH,,,Durchflusswert ,E3.ErrorCode,s,UCH,,,Fehlercode ,E3.OperatingPhase,s,operatingphase,,,Betriebsphase ,E3.LoadSetting,s,UCH,,,Ladestellung ,E3.SettingUV,s,settingUV,,,Stellung UV ,E3.SupplyTemp,s,ctemp1,,,Vorlauftemperatur ,E3.FlueGasTemp,s,ctemp1,,,Abgastemperatur ,E3.IonisationSignal,s,UCH,,,Ionisationssignal ,E3.ExternalTemp,s,ctemp1,,,Außentemperatur ,E3.DHWTemp,s,ctemp1,,,WW-Temperatur ,E3.ThroughputValue,s,UCH,,,Durchflusswert ,E2.ErrorCode,s,UCH,,,Fehlercode
r,,ErrorHistory3,Fehlerhistorie ,,,,"BCB278",,s,skip,,, ,E2.OperatingPhase,s,operatingphase,,,Betriebsphase ,E2.LoadSetting,s,UCH,,,Ladestellung ,E2.SettingUV,s,settingUV,,,Stellung UV ,E2.SupplyTemp,s,ctemp1,,,Vorlauftemperatur ,E2.FlueGasTemp,s,ctemp1,,,Abgastemperatur ,E2.IonisationSignal,s,UCH,,,Ionisationssignal ,E2.ExternalTemp,s,ctemp1,,,Außentemperatur ,E2.DHWTemp,s,ctemp1,,,WW-Temperatur ,E2.ThroughputValue,s,UCH,,,Durchflusswert ,E1.ErrorCode,s,UCH,,,Fehlercode ,E1.OperatingPhase,s,operatingphase,,,Betriebsphase ,E1.LoadSetting,s,UCH,,,Ladestellung
r,,ErrorHistory4,Fehlerhistorie ,,,,"40B284",,s,skip,,, ,E1.SettingUV,s,settingUV,,,Stellung UV ,E1.SupplyTemp,s,ctemp1,,,Vorlauftemperatur ,E1.FlueGasTemp,s,ctemp1,,,Abgastemperatur ,E1.IonisationSignal,s,UCH,,,Ionisationssignal ,E1.ExternalTemp,s,ctemp1,,,Außentemperatur ,E1.DHWTemp,s,ctemp1,,,WW-Temperatur ,E1.ThroughputValue,s,UCH,,,Durchflusswert ,E6.ErrorCode,s,UCH,,,Fehlercode ,E6.OperatingPhase,s,operatingphase,,,Betriebsphase ,E6.LoadSetting,s,UCH,,,Ladestellung ,E6.SettingUV,s,settingUV,,,Stellung UV ,E6.SupplyTemp,s,ctemp1,,,Vorlauftemperatur
r,,ErrorHistory5,Fehlerhistorie ,,,,"54B290",,s,skip,,, ,E6.FlueGasTemp,s,ctemp1,,,Abgastemperatur ,E6.IonisationSignal,s,UCH,,,Ionisationssignal ,E6.ExternalTemp,s,ctemp1,,,Außentemperatur ,E6.DHWTemp,s,ctemp1,,,WW-Temperatur ,E6.ThroughputValue,s,UCH,,,Durchflusswert ,E5.ErrorCode,s,UCH,,,Fehlercode ,E5.OperatingPhase,s,operatingphase,,,Betriebsphase ,E5.LoadSetting,s,UCH,,,Ladestellung ,E5.SettingUV,s,settingUV,,,Stellung UV ,E5.SupplyTemp,s,ctemp1,,,Vorlauftemperatur ,E5.FlueGasTemp,s,ctemp1,,,Abgastemperatur ,E5.IonisationSignal,s,UCH,,,Ionisationssignal
r,,ErrorHistory6,Fehlerhistorie ,,,,"18229C",,s,skip,,, ,E5.ExternalTemp,s,ctemp1,,,Außentemperatur ,E5.DHWTemp,s,ctemp1,,,WW-Temperatur


Vielleicht wäre es vorteilhaft, die Telegramme selbst neu zu definieren, damit sie gleich aufgebaut sind... 
Dazu hier das Knowhow!

Um die Telegramme zu verstehen und dekodieren zu können, habe ich folgende Annahme getroffen:
Unter der Vorraussetzung, dass es sich tatsächlich um einen Speicher-Block handelt, der ausgelesen werden soll, muss folglich im Request-Teil des Telegramms irgendwo eine Länge und eine Startadresse stehen. Die Startadresse des folgenden Telegramms sollte sich dann aus der Startadresse des vorherigen plus dessen ausgelesene Länge ergeben.

Die Länge der Telegramme ist bereits bekannt.

Schaut man sich den Identifier-Teil der Telegrammdefinitionen lange genug an, dann springt einem zumindest ein Teil der Lösung quasi an:
Man darf keine Bytes betrachten, sondern muss Halb-Bytes, also die Nibbles verwenden!
Die letzten drei Nibbles enthalten die Startadresse, das Nibble davor die Länge des auszulesenden Speicherbereichs (wobei ein Längen-Wert von 0 ein nutzbares Byte in der Anwort liefert).

ToDo: Das Byte davor wiederum muss ein Check-Byte sein, dessen Wert sich irgendwie ergibt.

Um meine These zu bestätigen, habe ich mir ein Skript erstellt, das bei vorgegebener Startadresse und Länge das Check-Byte so lange durchprobiert, bis eine Antwort vom WTC kommt.
Als Adressbereich habe ich den bekannten Bereich der Fehlerhistorie verwendet, um auch das Ergebnis validieren zu können.

Ein Aufruf sieht dann beispielsweise so aus:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl hex 0850000393129b
03000b04


Jetzt gilt es nur noch, den Algorithmus für den Check-Wert zu finden. Hier eine Tabelle mit verschiedenen Aufrufen und passendem Check-Byte:

Srv	Len	Chk	Len	Adr	Response
5000	03	23	0	29B	02000B
5000	03	93	1	29B	03000B04
5000	03	1F	2	29B	04000B0433
5000	03	AF	3	29B	05000B0433E4
5000	03	24	0	29C	020004
5000	03	94	1	29C	03000433
5000	03	18	2	29C	04000433E4
5000	03	A8	3	29C	05000433E406
5000	03	5C	4	29C	06000433E40600
5000	03	EC	5	29C	07000433E4060000
5000	03	60	6	29C	08000433E406000000
5000	03	D0	7	29C	09000433E40600000092

Ein weiteres Rätsel ist der Aufbau der ersten Telegrammdefinition "03029F8263" - werden hier zwei Speicherbereiche ausgelesen?
0 (also ein Byte) ab Adresse 29F und 8 (also 9 nutzbare Byte) ab Adresse 263 mit Check-Byte 03?

Hat jemand eine Idee, wie das Check-Byte berechnet wird?