Weishaupt WTC am eBus mit ebusd

Begonnen von J0EK3R, 19 November 2016, 13:51:45

Vorheriges Thema - Nächstes Thema

J0EK3R

#15
Hallo John,

ich versuche gerade, die Weishaupt csv-Dateien Deinen aus dem config-Repository "anzugleichen".
Zuerst habe ich den ebusd neu gebaut, damit ich auf dem aktuellen Stand bin (2.3.a991a37).

Ich verstehe immer mehr davon, wie Du Dir das mit den Nachrichten-Definitionen gedacht hast.  8)
...allerdings komme ich noch sehr schnell zu für mich unlösbaren Problemen  ;)

Momentan habe ich für jeden Parameter zwei Einträge in der 35.csv (Heizkreisregler 1) definiert: jeweils einen zum Lesen und Schreiben eines Parameters.
Bsp:

*r,,,,,,"0902",,,,,,,
*w,,,,,,"0903",,,,,,,

r,,HK1.T_Normal, ,,,,"050002",,,UIN,10,,Normaltemperatur Sollwert
w,,HK1.T_Normal, ,,,,"0500",,,UIN,10,,Normaltemperatur Sollwert

(Anm.: ein Leerzeichen als Kommentar zur Abgrenzung)

Es werden also die Services "EEPROM Daten lesen (0902)" und "EEPROM Daten schreiben (0903)" verwendet.
Dabei ist in diesem Beispiel die "0500" die Adresse und das folgende Byte "02" beim Lesen-Service die Länge der zu lesenden Datenbytes, also zwei. Der Roh-Aufruf mit ebusctl würe also folgendermaßen aussehen:

# Lesen
ebusctl hex 35090203050002
Antwort-> 02f000
#Schreiben
ebusctl hex 350903040500f000


Wie bekomme ich die Definition in der csv-Datei so hin, dass ich nur einen Eintrag für das Lesen und Schreiben brauche?

Dann ist da noch das Problem, dass nur alle paar Lese-Aufrufe brauchbare Werte in der Antwort stehen.
Sagt Dir das etwas, hast Du das schon einmal gesehen? Gibt es da eine Lösung?

john30

Zitat von: J0K3r am 02 Dezember 2016, 17:21:29
Wie bekomme ich die Definition in der csv-Datei so hin, dass ich nur einen Eintrag für das Lesen und Schreiben brauche?
Das ist mal wieder einer kleiner Spezialfall und im Moment so nicht im CSV abbildbar. Das wird erst dann möglich, wenn Konstanten im CSV definiert werden können (noch kein Zeitplan dafür).

Zitat von: J0K3r am 02 Dezember 2016, 17:21:29
Dann ist da noch das Problem, dass nur alle paar Lese-Aufrufe brauchbare Werte in der Antwort stehen.
Sagt Dir das etwas, hast Du das schon einmal gesehen? Gibt es da eine Lösung?
Hm, das habe ich bis jetzt noch nicht gesehen, aber vielleicht ist das Gerät mit zu häufigen Anfragen überfordert?
Verstehe ich das richtig, dass dann oft keine Antwort bzw. eine "00" (Antwort-Länge) kommt? Poste doch mal ein Beispiel.
author of ebusd

J0EK3R

Hallo John,

hier das traurige Beispiel mit den Null-Antworten. Schlimm ist, dass die Länge der Antwort korrekt ist, leider aber jedes Byte den Wert 0x00 enthält.

Erst der 12. Aufruf enthielt eine brauchbare Antwort!

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
020000

pi@raspberrypi:~ $ ebusctl hex 35090203050002
02f000


Ich frage mich, ob ich den richtigen Service verwende oder ob es eine andere Möglichkeit gibt, an die Parameter zu gelangen.
"EEPROM lesen" und "EEPROM schreiben" klingt schon gefährlich!  :o

john30

Zitat von: J0K3r am 03 Dezember 2016, 13:25:16
Erst der 12. Aufruf enthielt eine brauchbare Antwort!
Tja, das ist ernüchternd... Sicher dass der Wert an der Adresse im EEPROM nicht erst zum Zeitpunkt der 12. Abfrage etwas vernünftiges widerspiegelt?
author of ebusd

mcmuller

Hallo Leute,

ich stehe vor der "Aufgabe" eine Weishaupt WTC45 aus 2005 per ebusd und fhem erstmal zu überwachen. Aus einem anderen Projekt habe ich hier eine Software (Win) und ein USB-ebus-Interface liegen. Die Software hat ein Verzeichnis "Controllers", in dem offenbar Gerätedefinitionen liegen. Ich stehe noch ganz am Anfang von ebusd, aber sollte Interesse an den Dateien bestehen, könnt Ihr ja mal https://drive.google.com/drive/folders/0B6B4-rV5pWy8Q2lMYl9rWV9sbkk?usp=sharing einen Blick darauf werfen (.zip inside!).

Grüße,
mcmuller

J0EK3R

#20
Hallo John,

ich habe wieder viele Fragen!  ::)

Zitat von: john30 am 03 Dezember 2016, 14:18:55
Tja, das ist ernüchternd... Sicher dass der Wert an der Adresse im EEPROM nicht erst zum Zeitpunkt der 12. Abfrage etwas vernünftiges widerspiegelt?
...sicher bin ich mir mit nichts! :P Positiv scheint jedoch, dass die gesetzten Werte im Heizkreisregler über den 0903-Service scheinbar gleich angenommen werden.

SCAN-Service
Probleme gibt es aber weitere: Die Weishaupt-Geräte liefern beim SCAN-Service nicht alle eine brauchbare ID (siehe Beispiel) und eben die vermeintlich falsche Hersteller-Kennung! Damit ist die automatische Wahl der richtigen csv-Datei des ebusd auf die Adresse beschränkt.

pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 57
masters: 4
messages: 393
address 30: master #3
address 31: master #8, ebusd
address 35: slave #3, scanned "MF=Kromschroeder;ID=     ;SW=2633;HW=0000", loaded "kromschroeder/35.csv"
address 36: slave #8
address 51: slave, scanned "MF=Kromschroeder;ID=     ;SW=3233;HW=0001", loaded "kromschroeder/51.csv"
address 70: master #4
address 75: slave #4, scanned "MF=Kromschroeder;ID=     ;SW=2633;HW=0000", loaded "kromschroeder/75.csv"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST▒;SW=0216;HW=0101", loaded "kromschroeder/f6.csv"


Upgrade ebusd - Nachrichtendefinition
Dann gibt es noch ein weiteres Problem bei meinem Upgrade des ebusd von 2.1 auf 2.3: eine Nachrichtendefinition funktioniert mit ebusd 2.3 nicht mehr!
In der f6.csv habe ich zwei Nachrichtendefinitionen für "0507"-Nachrichten, die einmal vom Heizkreisregler 1 (MA-Adr 0x30) und vom Heizkreisregler 2 (MA-Adr 0x70) an den Heizungsregler (SL-Adr 0xF6) zyklisch (alle 10 Sekunden) verschickt werden - sie enthalten Sollwerte.
/etc/ebusd/weishaupt.f6.csv

*b,->HR,,,,F1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

b,,HK1,HK1->HR,30,,"0507",,Status,,opdataheat,,, ,Aktion,,opdataaction,,, ,Temp1,,temp,,, ,Solldruck,,press,,, ,stellgrad,,percent1,,, ,Temp2,,temp1,,, ,brennstoff,,fueltype,,,
b,,HK2,HK2->HR,70,,"0507",,Status,,opdataheat,,, ,Aktion,,opdataaction,,, ,Temp1,,temp,,, ,Solldruck,,press,,, ,stellgrad,,percent1,,, ,Temp2,,temp1,,, ,brennstoff,,fueltype,,,


Mit ebusd 2.1 konnte ich über ebustl die entsprechenden Werte auslesen:

pi@raspberrypi:~ $ ebusctl r HK1
hotwaterinheating;stopconsumer;29.62;-;-;40.0;-


In der aktuellen Version 2.3 funktioniert das nicht mehr!

pi@raspberrypi:~ $ ebusctl r HK1
ERR: no data stored


...und das, obwohl in /var/log/ebusd zu erkennen ist, dass die Nachricht über den Bus ging und auch richtig dekodiert wurde.

2016-12-04 11:12:51.878 [update notice] update ->HR HK1: hotwaterinheating;stopconsumer;29.62;-;-;40.0;-
2016-12-04 11:12:53.145 [update notice] update ->HR HK2: hotwaterinheating;-;37.00;-;-;-;-


Bug oder Feature? Was stimmt an meiner Nachrichtendefinition nicht?

john30

Zitat von: mcmuller am 04 Dezember 2016, 11:08:41
ich stehe vor der "Aufgabe" eine Weishaupt WTC45 aus 2005 per ebusd und fhem erstmal zu überwachen. Aus einem anderen Projekt habe ich hier eine Software (Win) und ein USB-ebus-Interface liegen. Die Software hat ein Verzeichnis "Controllers", in dem offenbar Gerätedefinitionen liegen. Ich stehe noch ganz am Anfang von ebusd, aber sollte Interesse an den Dateien bestehen, könnt Ihr ja mal https://drive.google.com/drive/folders/0B6B4-rV5pWy8Q2lMYl9rWV9sbkk?usp=sharing einen Blick darauf werfen (.zip inside!).
puh, ob man davon was nutzen kann.? ist viel arbeit und mit viel try-and-error verbunden. wenn du rausfinden kannst, welche der files für dein gerät benutzt wird, kommt man sicher etwas weiter. dann könnte man evtl. anhand einiger nachrichten, die mit dem controller abgeglichen sind, die struktur der files rausfinden, oder zumindest teile davon.
author of ebusd

john30

Zitat von: J0K3r am 04 Dezember 2016, 11:22:50
Probleme gibt es aber weitere: Die Weishaupt-Geräte liefern beim SCAN-Service nicht alle eine brauchbare ID (siehe Beispiel) und eben die vermeintlich falsche Hersteller-Kennung! Damit ist die automatische Wahl der richtigen csv-Datei des ebusd auf die Adresse beschränkt.
Nein, dafür lassen sich auch SW und HW Version nutzen.
Ich meine mich zu erinnern, dass für diese Geräte nur die SW Version relevant ist.

Zitat von: schka17 am 02 Dezember 2016, 14:19:07
In der aktuellen Version 2.3 funktioniert das nicht mehr!
Wie aktuell ist die denn? Da gab es einen Bug, der hierfür greifen sollte. Probier mal den letzten git Stand.
author of ebusd

J0EK3R

Hallo John,

der letzte Git-Stand (2.3.24d8e75) funktioniert, der Fehler ist beseitigt!  :D

Der neuste Stand der Releases (2.3.5bcc475) hat den Bug wohl noch...
https://github.com/john30/ebusd/releases/tag/v2.3

Ach übrigens: Vielen Dank für die schnelle Hilfe!  :)

john30

Zitat von: J0K3r am 04 Dezember 2016, 12:55:48
der letzte Git-Stand (2.3.24d8e75) funktioniert, der Fehler ist beseitigt!  :D
Dachte ich mir.

Zitat von: J0K3r am 04 Dezember 2016, 12:55:48
Der neuste Stand der Releases (2.3.5bcc475) hat den Bug wohl noch...
https://github.com/john30/ebusd/releases/tag/v2.3
Das ist üblicherweise so. Wenn man für jeden Patch ein neues Release macht, ist das ziemlich sinnbefreit ;)
author of ebusd

J0EK3R

Hallo mcmuller!

Herzlich willkommen im Weishaupt-Club!  ;D

Das reine Überwachen der WTC mit dem eBusd und FHEM sollte doch funktionieren! Wenn Du die Hardware - den eBus-Umsetzer - mit ebusd zum Laufen bringst, dann müsste man das doch hinbekommen.  ::)
Die Nachrichten, die per Broadcast an alle Teilnehmer und zwischen den Reglern auf dem eBus ausgetauscht werden, sind auch weitgehend entschlüsselt.

Hast Du die Weishaupt ServiceTool-Software ausprobiert und irgendwelche Erkenntnisse erlangt?

Wenn man sich die ControllerMap.ini anschaut, sind da nur "WRSol"-Geräte definiert.

[Controller]
15979= WRSol 2.0 V241
16149= WRSol V2.41
17928= WRSol 1.0 STD V251
17929= WRSol 2.0 STD V251
17973= WRSol 1.0 V242
17974= WRSol 2.0 V242
17983= WRSol 1.0 V243
17984= WRSol 2.0 V243
19145= WRSol 1.0 EXP1 V251
19146= WRSol 2.0 EXP1 V251
19147= WRSol 1.0 EXP2 V251
19148= WRSol 2.0 EXP2 V251
19149= WRSol 1.0 EXP3 V251
19150= WRSol 2.0 EXP3 V251
19151= WRSol 1.0 EXP4 V251
19152= WRSol 2.0 EXP4 V251
20598= WRSol 1.0 STD V252
20599= WRSol 2.0 STD V252
20600= WRSol 1.0 EXP1 V252
20601= WRSol 2.0 EXP1 V252
20602= WRSol 1.0 EXP2 V252
20603= WRSol 2.0 EXP2 V252
20604= WRSol 1.0 EXP3 V252
20605= WRSol 2.0 EXP3 V252
20606= WRSol 1.0 EXP4 V252
20607= WRSol 2.0 EXP4 V252

mcmuller

...richte mir gerade einen Raspberry mit ebusd und fhem dafür ein. Wäre ja schon schön, wenn plausible Daten zu lesen wären! Die zu überwachende Heizung steht leider 2500km entfernt - aber morgen habe ich Zugriff auf ein anderes Weishaupt-System hier in der Nachbarschaft zum Testen. Final will ich das dann per GSM-Stick als Fernwartungslösung.

J0EK3R

#27
Hallo!  :)

Inzwischen hab ich ein Repository auf github.com angelegt, in dem mein aktueller Stand der Konfigurationsdateien zu finden ist.  8)

https://github.com/J0EK3R/ebusd-configuration-weishaupt

@John: Ich habe mich beim Erstellen an Deinen beiden Repositories orientiert und sie natürlich auch verlinkt und einfach mal angefangen... Ich hoffe, das ist soweit in Ordnung. Git und Github sind komplettes Neuland für mich. Ansonsten, ruhig meckern...  ;)
Jetzt muss ich die Konfigurationsdateien nur noch "in Form" bringen! ;)

mcmuller

Hallo zusammen,

...ich kann berichten, daß mein "TEM ZIF 280" eBus-zu-USB nicht mit ebusd läuft. Kommt immer nur "No Signal". Jetzt warte ich auf das für ebusd empfohlene ebus-usb-device. Dann kann ich hier hoffentlich auch was Sinnvolles beitragen.

Grüße,
mcmuller

john30

Zitat von: mcmuller am 08 Dezember 2016, 18:34:09
...ich kann berichten, daß mein "TEM ZIF 280" eBus-zu-USB nicht mit ebusd läuft.
na das ist auch kein Wunder, weil das Teil Opentherm Protokoll spricht und nicht eBUS...
author of ebusd