RPi eBUS V2 Platine Wolf CGB-(K)-20 mit DWT

[copystring]

Hallöchen,

seit einigen Tagen nutze ich die RPi Platine von Reinhart. Diese läuft auch.
Nun beschäftige ich mich mit dem Interpretieren der Nachrichten bzw. Erstellen der eigenen .csv.
Es gibt ja schon welche (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de/wolf) diese nutze ich auch und funktioniert so einigermaßen.

Zum Anfang nutze ich erstmal GAEBUS.

Mein Problem ist, dass nur wenig bis keine Nachrichten automatisch in ein Update bekommen. Nur die langweiligen wie z.B.

Code Auswählen Erweitern

2018-12-16 23:21:38.822 [update notice] received write feuerung betrd QQ=10: Brauchwasser_Heizen;Verbraucheran;63.00;-;-;52.0;-
2018-12-16 23:21:43.806 [update notice] received write feuerung sollw QQ=10: 63.000;-11.000;0;13;52.000
2018-12-16 23:21:44.994 [update notice] received update-read broadcast sollw QQ=f1: 0.000;-11.000;-;60;0.000
2018-12-16 23:21:48.804 [update notice] received write feuerung betrd QQ=10: Brauchwasser_Heizen;Verbraucheran;63.00;-;-;52.0;-


Die Interessanten wie z.B.

Code Auswählen Erweitern

2018-12-16 23:23:03.852 [update notice] received read feuerung hg04 QQ=10: 209
2018-12-16 23:23:05.097 [update notice] received write feuerung sollw QQ=10: 63.000;-11.000;0;13;52.000
2018-12-16 23:23:06.285 [update notice] received update-read broadcast sollw QQ=f1: 0.000;-11.000;-;60;0.000
2018-12-16 23:23:07.576 [update notice] received read feuerung hg01 QQ=10: 8.0
2018-12-16 23:23:08.823 [update notice] received read feuerung hg04 QQ=10: 209
2018-12-16 23:23:10.025 [update notice] received write feuerung betrd QQ=10: Brauchwasser_Heizen;Verbraucheran;63.00;-;-;52.0;-
2018-12-16 23:23:11.229 [update notice] received read feuerung hg01 QQ=10: 8.0
2018-12-16 23:23:13.831 [update notice] received read feuerung hg04 QQ=10: 209
2018-12-16 23:23:15.032 [update notice] received write feuerung sollw QQ=10: 63.000;-11.000;0;13;52.000
2018-12-16 23:23:16.266 [update notice] received update-read broadcast sollw QQ=f1: 0.000;-11.000;-;60;0.000
2018-12-16 23:23:17.510 [update notice] received unknown MS cmd: 10085022030a000a / 021400
2018-12-16 23:23:18.865 [update notice] received read feuerung hg06 QQ=10: 0
2018-12-16 23:23:20.067 [update notice] received write feuerung betrd QQ=10: Brauchwasser_Heizen;Verbraucheran;63.00;-;-;52.0;-
2018-12-16 23:23:21.278 [update notice] received read feuerung hg07 QQ=10: 1
2018-12-16 23:23:23.852 [update notice] received read feuerung hg22 QQ=10: 75.0
2018-12-16 23:23:25.048 [update notice] received write feuerung sollw QQ=10: 63.000;-11.000;0;13;52.000
2018-12-16 23:23:26.236 [update notice] received update-read broadcast sollw QQ=f1: 0.000;-11.000;-;60;0.000
2018-12-16 23:23:27.491 [update notice] received read feuerung hg09 QQ=10: 7
2018-12-16 23:23:28.831 [update notice] received write feuerung betrd QQ=10: Brauchwasser_Heizen;Verbraucheran;63.00;-;-;52.0;-
2018-12-16 23:23:30.091 [update notice] received unknown MS cmd: 10085022037e5b0a / 020100
2018-12-16 23:23:31.835 [update notice] received unknown MS cmd: 1008502203e6bf0a / 020600
2018-12-16 23:23:31.945 [update notice] received update-read broadcast betrd QQ=03: 7;78;26;67.0;62;48;-40
2018-12-16 23:23:33.825 [update notice] received read feuerung hg15 QQ=10: 5.0


Kommen erst dann rein, wenn ich ans DWT gehe ich diese dort anzeigen lassen. Na gut, das ist nicht so schlimm, aufrufen der Werte kann ich auch in FHEM über GAEBUS.
Funktionieren tut alles soweit also.

Nun möchte ich aber den nächsten Schritt machen und die .csv-Dateien weiterführen.
Als erstes wollte ich die Fehler vom DWT auslesen.

Die Fehler erscheinen zwar via broadcast:

Code Auswählen Erweitern

[update notice] received update-read broadcast error QQ=30: E015 22:53
diese möchte ich jedoch auch von Hand abrufen können ohne immer ans DWT gehen zu müssen.

Die passende Nachricht zum Broadcast von oben ist:

Code Auswählen Erweitern

[bus notice] <30 fe fe01 0a4530 31352032323a353372

Ich dachte mir, ja cool. Da steht ja alles was ich brauche. Dies habe ich dann folgendermaßen umgewandelt:

Code Auswählen Erweitern

r,dwt,error,error message,,30,FE01,0a4530,error,,STR:10,,,,,,,,,,,,,,,,,,,,,

Die Antwort ist dann aber:

Code Auswählen Erweitern

[update notice] sent read dwt error QQ=31: 

Geht das überhaupt so oder ist mein Weg komplett falsch?

Die letzten Tage habe ich einiges im github von john30 gelesen und versucht alles so gut es geht zu verstehen. Dies fällt mir jedoch recht schwer.

[john30]

Die passende Nachricht zum Broadcast von oben ist:

Code Auswählen Erweitern

[bus notice] <30 fe fe01 0a4530 31352032323a353372
[/quote]
einen broadcast kann man per se nicht aktiv abfragen

[copystring]

OK. Broadcast abfragen geht nicht. Verstehe.
Wenn das jetzt z.B. ein read anstatt broadcast wäre, habe ich es dann richtig gemacht?
Ich meine damit das umwandeln der Nachricht.

Außerdem wundere ich mich wie z.B. die Brennerstarts vom DWT ausgelesen werden können. Dazu habe ich bisher keine Nachricht hervorrufen können.

Ohne die Nachricht gesehen zu haben stehen die Chancen schlecht oder?

Im Netz habe ich Beispiele zum Abfragen der Brennerstarts gefunden, diese funktionieren bei mir jedoch nicht.

Die passende Nachricht zum Broadcast von oben ist:

Code Auswählen Erweitern

[bus notice] <30 fe fe01 0a4530 31352032323a353372

einen broadcast kann man per se nicht aktiv abfragen

Gesendet von meinem Pixel 3 mit Tapatalk

[john30]

OK. Broadcast abfragen geht nicht. Verstehe.

also aktiv vom Bus abfragen meinte ich natürlich. Aus dem ebusd cache kannst Du natürlich immer den letzten Wert bekommen, dazu musst Du einfach nur einen timeout nehmen, der groß genug ist (siehe read command "-m" Parameter).

Wenn das jetzt z.B. ein read anstatt broadcast wäre, habe ich es dann richtig gemacht?
Ich meine damit das umwandeln der Nachricht.

nicht ganz, denn "0a" hinter "30 fe fe01" ist die Länger der Daten, die in der Definition nicht explizit anggegeben wird. Also einfach "0a" aus der ID in der Def rausnehmen, dann sollte es passen.

Außerdem wundere ich mich wie z.B. die Brennerstarts vom DWT ausgelesen werden können. Dazu habe ich bisher keine Nachricht hervorrufen können.

Ohne die Nachricht gesehen zu haben stehen die Chancen schlecht oder?

korrekt. Du könntest nur schauen, ob bei der Nachrichtendefinition insgesamt ein Schema zu erkennen ist, also ob alle IDs nachvollziehbar aufgebaut sind, und dann ein readallregisters.sh ähnlich wie für Vaillant basteln.

[copystring]

Okay. Das Interpretieren der Nachrichten verstehe ich nun. Danke für deine Hilfe! 

Nun habe ich mir die bereits bekannten IDs angeschaut. So wirklich ein Schema kann ich da kaum erkennen. Außer, dass zum Schreiben eines Wertes von der ID die ersten beiden zeichen durch 00 ersetzt werden müssen.
Also müsste ich mit dem Script bei 010000 anfangen um ein Überschreiben aller Werte zu vermeiden.
Die letzten beiden Ziffern sind bisher 00,01,02 oder 0a.

Hier sind die IDs aus der ebus Repo von dir für Wolf/Kromschröder.:

Code Auswählen Erweitern

1d3f01,201f00,241600,254101,280d00,295a01,316c01,5d5601,662802,6d6d01,794001,842200,9d4301,a56a01,aa2602,ad7801,b80200,b95501,c14201,cc0e00,cd5901,d5f601,de2a02,de8402,e40300,f42700,f57001,f96b01

Ich habe noch drei weitere IDs selbst gefunden:

Code Auswählen Erweitern

0a000a,7e5b0a,e6bf0a

Dann von 010000 bis ffffff alles durchprobieren oder doch lieber am Ende nur 00,01,02 und 0a anstatt ff lassen?

[john30]

Nun habe ich mir die bereits bekannten IDs angeschaut. So wirklich ein Schema kann ich da kaum erkennen. Außer, dass zum Schreiben eines Wertes von der ID die ersten beiden zeichen durch 00 ersetzt werden müssen.

probier doch mal, ob das erste byte beim lesen auch 00 sein kann. am einfachten hex aktivieren und dann "ebusctl hex 08502203005b0a"

[copystring]

Sieht nicht so aus.

Code Auswählen Erweitern

ebusctl hex 08502203005b0a
ERR: read timeout


[john30]

Sieht nicht so aus.

Code Auswählen Erweitern

ebusctl hex 08502203005b0a
ERR: read timeout


tja, das ist dann schwierig...

[john30]

Code Auswählen Erweitern

ebusctl hex 08502203005b0a
ERR: read timeout


ich hab mich gerade wieder daran erninnert, dass es ein issue für dieses spezielle byte gibt, das lediglich eine CRC8 über die nachfolgenden bytes ist.
es scheint wohl devices zu geben, die ohne korrekte CRC die Antwort verweigern, und das scheint bei dir auch der Fall zu sein.
Den Datentyp in ebusd einzubauen und die ID so zu erweitern, dass diese auch berechnete Felder enthalten kann, ist viel Arbeit und deshalb erstmal nicht in Sicht.
Du könntest aber ein Script schreiben, das für die eigentliche ID (2 Bytes) die CRC berechnet und dann die Abfrage macht.