Weishaupt WTC am eBus mit ebusd

[timo74]

Hallo und einen wunderschönen guten Morgen,

nach viel lesen und (leider bisher) noch nicht ganz so viel verstehen bin ich zumindest so weit, dass ich im FHEM (habe die Anbindung an den ebusd mittels GAEBUS Modul realisiert) die Werte der Endanwenderebene der Heizung (also die eingestellten Temperaturen), sowie verschiedene Prozess- und Statistikwerte in einzelnen Readings darstellen kann.

Als nächstes möchte ich die Broadcast-Informationen darstellen, welche alle paar Sekunden am EBUS entlang huschen.
Im ebusd-Log werden diese bereits so dargestellt:
2017-01-24 07:58:52.107 [update notice] update broadcast IstWerte QQ=f1: 1;BrennerAus;71;18;0;63.0;-;64.0;0.0;-11;-11.934;8

Und die Tatsache, dass dort lesbare Werte (bspw. BrennerAus) und keine Hex-Telegramme stehen, lässt mich vermuten, dass die Übersetzung hier bereits mit der Datei "... kromschroeder/broadcast.csv" stattgefunden hat.

Eines irritiert mich jedoch und genau da komme ich aktuell nicht weiter:
Im FHEM kann ich aus der broadcast.csv leider nur die Darstellung der "Identifikation", jedoch nicht die "IstWerte" auswählen.

Worin besteht eigentlich der Zusammenhang/Unterschied zwischen der "broadcast.csv" im kromschroeder-Verzeichnis und der "brodcast.csv" eine Ebene höher?
Woher weiß der ebusd eigentlich, welche broadcast.csv gerade relevant ist? In dem Broadcast-Telegram ist doch kein Vendor-Code enthalten, oder doch?

Könnt Ihr eventuell eine Ressource empfehlen, wo der Aufbau der CSV-Dateien und die Zusammenhänge zu den anderen Dateien beschrieben ist?
Das (wirklich sehr gut geschriebene) Wiki bei GitHub von John habe ich bereits durch. Nur als Nicht-Programmierer fehlen mir noch ein paar Schritte/Windungen bis zum ultimativen Aha-Effekt.

Als potentielle Quick'n'Dirty Variante hatte ich auch bereits die Inhalte beider broadcast.csv's ineinander kopiert, jedoch ohne jeglichen Erfolg.

Über einen kleinen Schubser in die richtige Richtung würde ich mich wahnsinnig freuen.

Viele Grüße
Timo

[J0EK3R]

Hallo Timo! 

nach viel lesen und (leider bisher) noch nicht ganz so viel verstehen bin ich zumindest so weit, dass ich im FHEM (habe die Anbindung an den ebusd mittels GAEBUS Modul realisiert) die Werte der Endanwenderebene der Heizung (also die eingestellten Temperaturen), sowie verschiedene Prozess- und Statistikwerte in einzelnen Readings darstellen kann.

Das GAEBUS-Modul ist für mich Neuland!
Aus irgendeinem Grund habe ich mich damals für die Anbindung per ECMD-Modul entschieden und so ist es noch heute. 
Kann ich also wenig zu sagen, nur Vermutungen anstellen.
Aber interessieren würde mich das auch! 

Eines irritiert mich jedoch und genau da komme ich aktuell nicht weiter:
Im FHEM kann ich aus der broadcast.csv leider nur die Darstellung der "Identifikation", jedoch nicht die "IstWerte" auswählen.

Mit "FHEM" meinst Du das GAEBUS-Modul, oder?
Wie funktioniert das eigentlich? Greift das GAEBUS-Modul auf die dynamisch aufgebaute Liste der Variablen von ebusd zu?

So kommt man an alle Variablen und aktuellen Werte:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl f
broadcast datetime = 0.000;16:45:00;24.01.2017
broadcast error = no data stored
broadcast id = no data stored
broadcast IstWerte = 1;BrennerInBetrieb;127;82;46;54.0;-;49.0;0.0;0;-0.988;55
broadcast netloss = no data stored
broadcast netresetcfg = no data stored
broadcast netresetstate = no data stored
broadcast signoflife = no data stored
HK2->MI1 MI1.PD = 23.000;2;128;74;64;64;0;-;96;0;0;0;182
wwst? HK1 = no data stored
wwst? HK2 = no data stored
broadcast id = no data stored
hc1 Adaption = no data stored
hc1 DHWMin = no data stored
hc1 DHWMode = no data stored


Oder parst GAEBUS die CSV-Dateien der ebusd-Konfiguration?

Ansonsten per ebusctl read:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl r IstWerte
1;BrennerInBetrieb;127;82;42;55.0;-;47.0;0.0;-1;-0.961;55

pi@raspberrypi:~ $ ebusctl r -v IstWerte
broadcast IstWerte Status0=1;Betriebsphase=BrennerInBetrieb;Status2=127;Status3=82;Laststellung=42;T_Water=55.0;T_ECS=-;T_Temp1=47.0;T_Temp2=0.0;T_Out=-1;T_Trend=-0.961;T_Temp3=55

pi@raspberrypi:~ $ ebusctl r IstWerte Betriebsphase
BrennerInBetrieb

pi@raspberrypi:~ $ ebusctl r IstWerte T_Trend
-0.961


Worin besteht eigentlich der Zusammenhang/Unterschied zwischen der "broadcast.csv" im kromschroeder-Verzeichnis und der "brodcast.csv" eine Ebene höher?
Woher weiß der ebusd eigentlich, welche broadcast.csv gerade relevant ist? In dem Broadcast-Telegram ist doch kein Vendor-Code enthalten, oder doch?

Die /etc/ebusd/broadcast.csv enthält allgemeine Telegramme, die der ebus-Spezifikation definiert sind.

Laut eBus-Spec enthält ein 0704-Telegramm eine Hersteller-Identifikation (Manufacturer-Id).
Sobald ebusd mit Option "scanconfig" ein 0704-Telegramm empfängt, wird nach einem Unterverzeichnis mit entsprechendem Hersteller-Name gesucht (bei uns ist das 0x50=>Kromschoeder).
Dann werden pauschal aus diesem Verzeichnis die Dateien _templates.csv, general.csv, broadcast.csv und die scan.csv geladen (falls sie dort existieren).
Alle Telegramm-Definitionen, die dann geladen wurden, sind nun zusätzlich zu den bisher geladenen bekannt.
Das können auch Broadcast-Telegramme sein.
Wichtig ist nur, dass sie sich von den bisherigen Telegramm-Definitionen unterscheiden, sonst meckert ebusd mit der Meldung "duplicate entries".

Könnt Ihr eventuell eine Ressource empfehlen, wo der Aufbau der CSV-Dateien und die Zusammenhänge zu den anderen Dateien beschrieben ist?
Das (wirklich sehr gut geschriebene) Wiki bei GitHub von John habe ich bereits durch. Nur als Nicht-Programmierer fehlen mir noch ein paar Schritte/Windungen bis zum ultimativen Aha-Effekt.

Ich kenne nur das Wiki. Ich hab es auch mehrfach gelesen.
Hier gibt's Spezifikationen http://ebus-wiki.org/doku.php/ebus/ebusdoku
Ansonsten: frag doch einfach! 

[J0EK3R]

Hallo Misc2000! 

Da ich ja 2 externe Heizkreise mit je einem WCM-EM haben denke ich, muss ich noch die Datei 51.csv als Kopie mit dem Namen 52.csv für den 2. Heizkreis ablegen.
Richtig (Oder muss dafür noch mehr geändert werden)?

Prinzipiell richtig! 
Ich befürchte aber - die 51.csv ist aus meiner ebusd-Anfangszeit und noch nicht überarbeitet - dass ein Kopieren nicht ausreicht.
In den Telegramm-Default (die ersten Zeilen mit *b und *r) sind noch fest die Adressen (->51) drin, die musst Du anpassen (->52).
Und der Name (->MI1.PD) muss wohl auch geändert werden, damit er nicht doppelt vorkommt.
Bei Gelegenheit werde ich die Datei überarbeiten.

Kannst du mir mal ein paar Weishaupt Beispiel Abfragen nennen um zu sehen ob ich mit meiner neueren SW die gleichen Antworten wie du bekomme?

Da müsstest Du nur eins der definierten Telegramme lesen.

Über ebusctl f bekommst Du alle definierten Telegramme angezeigt, die aktuell geladen sind.

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl f
broadcast datetime = 0.000;17:59:00;24.01.2017
broadcast error = no data stored
...
scan.08  = Kromschroeder;W ;0216;0101
scan.35  = Kromschroeder;;2633;0000
scan.51  = Kromschroeder;;3233;0001
scan.75  = Kromschroeder;;2633;0000
scan.f6  = Kromschroeder;WWST?;0216;0101
w Enduser = 22;22;20;55;25;15;125
w ErrorHistory = no data stored
w Manufacturer1 = no data stored
w Manufacturer2 = no data stored
w ProcessValues1 = no data stored
w ProcessValues2 = no data stored
w ProcessValues3 = no data stored
w ProcessValues4 = no data stored
w ProcessValues5 = no data stored
w ProcessValues6 = no data stored
w Prozess2 = no data stored


Daraus kannst Du dann welche abfragen:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl r -f -v Enduser
w Enduser NormalTempSetValue=22;LoweringTempSetValue=22;ChangeoverTempSummerWinter=20;DHWSetValueDay=55;NormalRoomTemp=25;LoweringRoomTemp=15;Byte=125

pi@raspberrypi:~ $ ebusctl r -f -v ProcessValues1
w ProcessValues1 Byte1=85;Byte2=229;Byte3=14;Byte4=-;Byte5=212;Byte6=111;Byte7=64;Byte8=70


Und kann ich ebusd so konfigurieren das ich den kompletten ebus Verkehr sehe?

Hmmm, weiß ich nicht - aber interessieren würde es mich auch! 

Toll wäre eine Ausgabemöglichkeit in der Art:

Code Auswählen Erweitern


18:10:18 AA AA AA AA AA AA AA AA
18:10:18 30 F1 05 07 09 BB 04 70 03 00 80 FF 65 FF 7A 00
18:10:19 AA AA AA AA AA AA AA AA AA AA
18:10:19 AA AA AA AA AA AA AA AA AA AA
18:10:19 AA AA AA AA AA AA AA
18:10:20 70 F1 05 07 09 BB FF 50 02 00 80 FF FF FF 8F 00
18:10:20 AA AA
18:10:20 70 51 50 10 04 66 17 02 80 6F 00 09 4A 40 40 00 FF 60 00 00 00 B6 00
18:10:20 AA AA AA AA AA AA AA AA AA AA


Da müsste man John fragen... 

Ich wollte an der FB einzelne Werte des WCM-EM Abfragen und dachte ich würde die passenden Befehle dann auf dem eBus sehen um dann zu verstehen wie ich die WCM-EM abfragen kann...

Schlauer Ansatz!

Und wenn ich etwas für dich testen soll um ggf. eine Vermutung von dir zu bestätigen melde dich einfach!
Nochmal Danke für die Hilfe

Vielen Dank, gerne und Grüße 

[timo74]

Hallo J0K3r,

Hallo Timo! 
Das GAEBUS-Modul ist für mich Neuland!
Aus irgendeinem Grund habe ich mich damals für die Anbindung per ECMD-Modul entschieden und so ist es noch heute. 

Ich würde vermuten, dass das GAEBUS-Modul ähnlich wie ECMD arbeitet. Zumindest wird in der Definition direkt der ebusd mit IP und seinem Port (default 8888) angegeben.
Das Besondere ist aber, dass die CSV-Dateien unterhalb /opt/fhem liegen müssen, weil sie von dort gelesen und dementsprechend auch durch das Modul interpretiert werden.
Ich habe heute im Laufe des Tages allerdings irgendwo hier im Forum gelesen, dass es trotzdem wichtig ist, dass auch der ebusd die selben CSVs zur Verfügung hat.
Da in meinem Fall ebusd und Fhem auf unterschiedlichen Systemen laufen, muss ich mir noch etwas in Bezug auf die Synchronisation einfallen lassen. Aber das sollte nicht das Problem sein.

So kommt man an alle Variablen und aktuellen Werte:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl f
broadcast datetime = 0.000;16:45:00;24.01.2017
broadcast error = no data stored
broadcast id = no data stored
broadcast IstWerte = 1;BrennerInBetrieb;127;82;46;54.0;-;49.0;0.0;0;-0.988;55
broadcast netloss = no data stored
broadcast netresetcfg = no data stored
broadcast netresetstate = no data stored
broadcast signoflife = no data stored
HK2->MI1 MI1.PD = 23.000;2;128;74;64;64;0;-;96;0;0;0;182
wwst? HK1 = no data stored
wwst? HK2 = no data stored
broadcast id = no data stored
hc1 Adaption = no data stored
hc1 DHWMin = no data stored
hc1 DHWMode = no data stored


Oder parst GAEBUS die CSV-Dateien der ebusd-Konfiguration?

Ansonsten per ebusctl read:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl r IstWerte
1;BrennerInBetrieb;127;82;42;55.0;-;47.0;0.0;-1;-0.961;55

pi@raspberrypi:~ $ ebusctl r -v IstWerte
broadcast IstWerte Status0=1;Betriebsphase=BrennerInBetrieb;Status2=127;Status3=82;Laststellung=42;T_Water=55.0;T_ECS=-;T_Temp1=47.0;T_Temp2=0.0;T_Out=-1;T_Trend=-0.961;T_Temp3=55

pi@raspberrypi:~ $ ebusctl r IstWerte Betriebsphase
BrennerInBetrieb

pi@raspberrypi:~ $ ebusctl r IstWerte T_Trend
-0.961


Interessant ist, dass ich bei einem "ebusctl f" leicht andere Ausgaben bekomme. So steht bei mir bspw. in der dritten Zeile "ident", statt "id" wie bei dir.

Code Auswählen Erweitern


pi@fhem-hwr:~ $ ebusctl f
broadcast datetime = no data stored
broadcast error = no data stored
broadcast ident = no data stored
broadcast IstWerte = 1;BrennerInBetrieb;127;82;32;66.0;-;63.0;0.0;-8;-10.562;8
broadcast signoflife = no data stored
wwst? HK1 = no data stored
wwst? HK2 = no data stored
IstWerte = no data stored
broadcast ident = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan.08  = Kromschroeder;W ;1200;0302
scan.f6  = Kromschroeder;WWST?;1200;0302
w Enduser = no data stored
w ErrorHistory = no data stored
w Manufacturer1 = no data stored
w Manufacturer2 = no data stored
w ProcessValues1 = no data stored
w ProcessValues2 = no data stored
w ProcessValues3 = no data stored
w ProcessValues4 = no data stored
w ProcessValues5 = no data stored
w ProcessValues6 = no data stored
w Prozess2 = no data stored
w Statistic1 = no data stored
w Statistic2 = no data stored
w Statistic3 = no data stored
w Statistic4 = no data stored
w Statistic5 = no data stored
w Statistic6 = no data stored
w Statistic7 = no data stored
wwst? SHC1 = no data stored
wwst? SHC2 = no data stored


Manuell kann ich die "IstWerte" auch abfragen. Nur GAEBUS scheint das nicht zu können. Ich glaube, ich werde mich dochmal ECMD zu Gemüte führen.

Viele Grüße
Timo

[J0EK3R]

Hallo Timo,

gutes Auge! 
"ident" wurde von John in "id" geändert - mein Abzug von ebusd-configuration war wohl davor!

Ich habe mir heute die Quellen von ebusd abgerufen und neu gebaut - irgendetwas geht jetzt nimmer, hab aber heute keine Lust mehr, vor den Rechner zu sitzen... 

[john30]

Woher weiß der ebusd eigentlich, welche broadcast.csv gerade relevant ist? In dem Broadcast-Telegram ist doch kein Vendor-Code enthalten, oder doch?

die CSVs sind einstufig hierarchisch aufgebaut, d.h. alle CSVs direkt im config Verzeichnis werden immer geladen und die aus den Hersteller-Unterverzeichnissen bei Bedarf, sprich wenn ein entsprechendes Gerät am Bus kommuniziert. Die in einem Hersteller-Verzeichnis liegenden _templates.csv und alle *.csv Dateien, die nicht mit einer Adresse "ZZ." beginnen, werden ebenfalls sofort eingelesen, sobald das erste Gerät des entsprechenden Herstellers entdeckt und gescannt wurde.

Könnt Ihr eventuell eine Ressource empfehlen, wo der Aufbau der CSV-Dateien und die Zusammenhänge zu den anderen Dateien beschrieben ist?
Das (wirklich sehr gut geschriebene) Wiki bei GitHub von John habe ich bereits durch. Nur als Nicht-Programmierer fehlen mir noch ein paar Schritte/Windungen bis zum ultimativen Aha-Effekt.

Hast Du auch Kapitel 4.7. Automatic configuration angeschaut? Vielleicht sollte ich noch einen beispielhaften Ablauf für das Einlesen der Dateien einbauen, damit man sieht, wie ebusd das handhabt.

[john30]

Toll wäre eine Ausgabemöglichkeit in der Art:

Code Auswählen Erweitern


18:10:18 AA AA AA AA AA AA AA AA
18:10:18 30 F1 05 07 09 BB 04 70 03 00 80 FF 65 FF 7A 00

Da müsste man John fragen... 

Das ist das raw logging, das sowohl beim ebusd Start als auch via ebusctl/TCP zur Laufzeit aktivierbar ist.
Die zusammengefassten Messages wie oben vorgeschlagen stehen schon als feature request drin.

[john30]

Ich habe mir heute die Quellen von ebusd abgerufen und neu gebaut - irgendetwas geht jetzt nimmer, hab aber heute keine Lust mehr, vor den Rechner zu sitzen... 

Wär cool wenn Du schauen könntest, was genau nicht mehr geht.

[J0EK3R]

Hallo John 

Wär cool wenn Du schauen könntest, was genau nicht mehr geht.

Das mach ich:
Mein Stand der ebusd-Quellen ist vom 24.01.2017 mit Commit 06b3fa3, also ebusd Version 3.0pre.06b3fa3.

Das Problem ist, dass Telegramme zwar dekodiert, (teilweise) jedoch nicht intern im ebusd gespeichert werden.

Ich habe beispielsweise die Definition für die Telegramme mit den Sollwerten, die von den Heizkreisreglern (0x30/0x70) zum Heizungsregler (0xF1) zyklisch geschickt werden.

Die Definition sieht so aus: /ets/ebusd/weishaupt/f6.csv

Code Auswählen Erweitern


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


Die Definitionen wurden auch eingelesen und sind vorhanden:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl f
broadcast datetime = -2.000;16:58:00;25.01.2017
broadcast error = no data stored
broadcast id = no data stored
broadcast IstWerte = 1;BrennerInBetrieb;127;82;57;55.0;-;48.0;0.0;-1;-1.969;55
broadcast netloss = no data stored
broadcast netresetcfg = no data stored
broadcast netresetstate = no data stored
broadcast signoflife = no data stored
hc1 SetValues = no data stored
hc2 SetValues = no data stored
HK2->MI1 MI1.PD = 22.699;2;128;74;64;63;-2;254;96;0;0;0;166
broadcast id = no data stored
hc1 Adaption = no data stored
hc1 DHWMin = no data stored
hc1 DHWMode = no data stored
...

Irritierend finde ich hier, dass bei dieser Ausgabe "broadcast id" doppelt vorhanden ist!?

Schaue ich mir das Log-File an, dann sehe ich dort, dass "SetValues" richtig dekodiert wird:

Code Auswählen Erweitern


2017-01-25 17:03:08.451 [update notice] update HK2->MI1 MI1.PD: 22.699;2;128;74;64;64;-1;254;96;0;0;0;184
2017-01-25 17:03:13.051 [update notice] update broadcast IstWerte QQ=f1: 1;BrennerInBetrieb;127;82;57;55.0;-;47.0;0.0;-1;-1.965;55
2017-01-25 17:03:17.010 [update notice] update hc1 SetValues: hotwaterinheating;startconsumer;55.00;-;-;50.5;-
2017-01-25 17:03:18.320 [update notice] update hc2 SetValues: hotwaterinheating;-;37.00;-;-;-;-
2017-01-25 17:03:18.571 [update notice] update HK2->MI1 MI1.PD: 22.699;2;128;74;64;64;-1;254;96;0;0;0;184
2017-01-25 17:03:27.017 [update notice] update hc1 SetValues: hotwaterinheating;startconsumer;55.00;-;-;50.5;-
2017-01-25 17:03:28.291 [update notice] update hc2 SetValues: hotwaterinheating;-;37.00;-;-;-;-
2017-01-25 17:03:28.480 [update notice] update HK2->MI1 MI1.PD: 22.699;2;128;74;64;64;-1;254;96;0;0;0;184


Dennoch werden die Werte nicht intern gespeichert!

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl r -c hc1 SetValues
ERR: no data stored

pi@raspberrypi:~ $ ebusctl r -c hc2 SetValues
ERR: no data stored


Gab es das Problem nicht schon einmal?

Komischerweise funktionieren andere Telegramme - wie man oben sieht, z.B. "broadcast IstWerte" und "MI1.PD".

BTW: Ich habe noch eine kleine Weishaupt-Besonderheit, die vielleicht irgendwie mit den Problemen zu tun hat - oder in Zukunft welche schafft.
Es ist die Id, die entweder gar nicht (0x35, 0x52, 0x75), schlampig (0x08) oder mit ungünstigen Zeichen -> "?" (0xF6) von den Geräten zurückgeliefert wird.

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl f
scan.08  = Kromschroeder;W ;0216;0101
scan.35  = Kromschroeder;;2633;0000
scan.51  = Kromschroeder;;3233;0001
scan.75  = Kromschroeder;;2633;0000
scan.f6  = Kromschroeder;WWST?;0216;0101


[J0EK3R]

Das ist das raw logging, das sowohl beim ebusd Start als auch via ebusctl/TCP zur Laufzeit aktivierbar ist.
Die zusammengefassten Messages wie oben vorgeschlagen stehen schon als feature request drin.

Momentan schreibt das raw-logging ja in das parametrierte Log-File...

Da könnte ich mir zwei weitere nützliche Szenarien vorstellen:

Eine Ausgabe der Roh-Daten über ebusctl - ähnlichen dem Kommando  ebusctl listen.

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl listen raw
18:10:18 AA AA AA AA AA AA AA AA
18:10:18 30 F1 05 07 09 BB 04 70 03 00 80 FF 65 FF 7A 00
18:10:19 AA AA AA AA AA AA AA AA AA AA
18:10:19 AA AA AA AA AA AA AA AA AA AA
18:10:19 AA AA AA AA AA AA AA
18:10:20 70 F1 05 07 09 BB FF 50 02 00 80 FF FF FF 8F 00
18:10:20 AA AA


Und das Durchreichen des kompletten eBus-Verkehrs an einen TCP-Port - damit könnte man mit einem externen Programm (das beispielsweise auf einem Windows-Rechner läuft und über einen virtuellen COM-Port über TCP/UDP mit dem ebusd verbunden ist), die Daten analysieren, usw...

[john30]

Das Problem ist, dass Telegramme zwar dekodiert, (teilweise) jedoch nicht intern im ebusd gespeichert werden.

Hm, das kann ich leider nicht nachvollziehen. Bei mir kommen die ordentlich rein mit dem aktuellen Sourcecode.
Schau doch mal im Logfile, ob die auch wirklich ankommen und dekodiert werden.

Also datetime kommt ja zumindest laut Deiner Ausgabe:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl f
broadcast datetime = -2.000;16:58:00;25.01.2017


Irritierend finde ich hier, dass bei dieser Ausgabe "broadcast id" doppelt vorhanden ist!?

Das liegt vermutlich daran, dass es sowohl eine "read" Message mit dem Namen gibt als auch eine "passive read".
"find -f -c broadcast id" wird Dir mehr darüber sagen können.

Schaue ich mir das Log-File an, dann sehe ich dort, dass "SetValues" richtig dekodiert wird:

Code Auswählen Erweitern


2017-01-25 17:03:08.451 [update notice] update HK2->MI1 MI1.PD: 22.699;2;128;74;64;64;-1;254;96;0;0;0;184
2017-01-25 17:03:13.051 [update notice] update broadcast IstWerte QQ=f1: 1;BrennerInBetrieb;127;82;57;55.0;-;47.0;0.0;-1;-1.965;55
2017-01-25 17:03:17.010 [update notice] update hc1 SetValues: hotwaterinheating;startconsumer;55.00;-;-;50.5;-
2017-01-25 17:03:18.320 [update notice] update hc2 SetValues: hotwaterinheating;-;37.00;-;-;-;-
2017-01-25 17:03:18.571 [update notice] update HK2->MI1 MI1.PD: 22.699;2;128;74;64;64;-1;254;96;0;0;0;184
2017-01-25 17:03:27.017 [update notice] update hc1 SetValues: hotwaterinheating;startconsumer;55.00;-;-;50.5;-
2017-01-25 17:03:28.291 [update notice] update hc2 SetValues: hotwaterinheating;-;37.00;-;-;-;-
2017-01-25 17:03:28.480 [update notice] update HK2->MI1 MI1.PD: 22.699;2;128;74;64;64;-1;254;96;0;0;0;184

Dennoch werden die Werte nicht intern gespeichert!

Beim read Kommando musst Du auf das Alter Nachrichten achten, denn ohne "-m SECONDS" werden passive Nachrichten nur mit einem Alter unter 5 Minuten ausgegeben.

BTW: Ich habe noch eine kleine Weishaupt-Besonderheit, die vielleicht irgendwie mit den Problemen zu tun hat - oder in Zukunft welche schafft.
Es ist die Id, die entweder gar nicht (0x35, 0x52, 0x75), schlampig (0x08) oder mit ungünstigen Zeichen -> "?" (0xF6) von den Geräten zurückgeliefert wird.

Ja das hab ich gesehen. Ist halt nicht Standard-konform...

[john30]

Eine Ausgabe der Roh-Daten über ebusctl - ähnlichen dem Kommando  ebusctl listen.
Und das Durchreichen des kompletten eBus-Verkehrs an einen TCP-Port - damit könnte man mit einem externen Programm (das beispielsweise auf einem Windows-Rechner läuft und über einen virtuellen COM-Port über TCP/UDP mit dem ebusd verbunden ist), die Daten analysieren, usw...

Kann man machen, aber sehe ich jetzt nicht high priority. Wenn Du das wirklich brauchst, dann mach Tickets dafür auf, dann gerät das nicht in Vergessenheit.

[J0EK3R]

Hallo John 

Nach stundenlanger Such-Arbeit habe ich den Fehler (wahrscheinlich) gefunden! 

Die Telegramme, die bei mir nicht mehr funktionieren, sind Master-Master-Telegramme, die von den Heizkreisreglen zum Heizungsregler (0x30 -> 0xF1 und 0x70 -> 0xF1) zyklisch geschickt werden. Ich hör da nur mit...

Code Auswählen Erweitern


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


Bei Deinem Commit 39c7678 ("always touch lastupdatetime when storing data of a write message" 39c7678406d31d7dad08e6c9d55137751f7e43c9) hast Du gerade diese Bedingung
partType == pt_masterData && isMaster(this->m_dstAddress)
herausgeworfen...

https://github.com/john30/ebusd/commit/39c7678406d31d7dad08e6c9d55137751f7e43c9

Code Auswählen Erweitern


result_t Message::storeLastData(const PartType partType, SymbolString& data, unsigned char index)
{
if (data.size() > 0
- && (this->m_dstAddress == BROADCAST || partType == pt_slaveData || (partType == pt_masterData && isMaster(this->m_dstAddress)))) {
+ && (m_isWrite || this->m_dstAddress == BROADCAST || partType == pt_slaveData)) {
time(&m_lastUpdateTime);
}
if (partType == pt_masterData) {


Füge ich in der message.cpp diese Bedingung wieder ein, dann funktioniert wieder alles! 

[john30]

Die Telegramme, die bei mir nicht mehr funktionieren, sind Master-Master-Telegramme, die von den Heizkreisreglen zum Heizungsregler (0x30 -> 0xF1 und 0x70 -> 0xF1) zyklisch geschickt werden.

Ah, Spezial-Spezial-Fall, da hatte ich nicht drangedacht.
Danke fürs rausfinden!

Füge ich in der message.cpp diese Bedingung wieder ein, dann funktioniert wieder alles! 

Ist eingecheckt.

[timo74]

Hallo zusammen,

ich will nur mal kurz von meinen Fortschritten berichten und nochmal die Gelegenheit nutzen, John und J0K3r zu danken!

Und zwar habe ich am eBusd auf dem abgesetzten Pi jetzt einfach die MQTT-Unterstützung verwendet, um die "IstWerte" der Weishaupt eventbasiert zu übermitteln.
Das ist insofern relevant, weil ein regelmäßiger Poll (wie bei ECMD oder GAEBUS) des Status ja ggf. durchaus Events übersehen könnte.
So habe ich zwar eine Menge an Daten (immerhin wird offensichtlich jeder Zustandsänderung ein Broadcast-Event erzeugt), aber dafür auch eine sehr granualare Auswertung.

Auf FHEM-Seite gibt es eine MQTT-Bridge, welche die IstWerte in einen Dummy schreibt. Dort nehme ich die einzelnen Werte mittels userReadings wieder auseinander und lasse einzelne Readings erzeugen bzw. mit Werten befüllen.

Wenn es jemanden interessiert, so siehts aus:

Code Auswählen Erweitern


define HWR.Weishaupt dummy
attr HWR.Weishaupt userReadings Status0 {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[0]},\
Betriebsphase {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[1]},\
Status2 {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[2]},\
Status3 {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[3]},\
Laststellung {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[4]},\
TempWater {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[5]},\
Temp1 {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[7]},\
Temp2 {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[8]},\
AussenTemp {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[9]},\
TempTrend {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[10]},\
Temp3 {my @a = split(";;",ReadingsVal("HWR.Weishaupt","state",0));;;; $a[11]}\

define mqtt_HWR.Weishaupt MQTT_BRIDGE HWR.Weishaupt
attr mqtt_HWR.Weishaupt IODev Mosquitto
attr mqtt_HWR.Weishaupt stateFormat transmission-state
attr mqtt_HWR.Weishaupt subscribeSet ebusd/broadcast/IstWerte


Jetzt muss ich "nur" noch die tatsächliche Bedeutung der Informationen (bspw. Status0,1,2 oder Temp1,2) herausfinden und kann dann ggf. wieder einzelne Readings entsorgen, sofern die Messdaten nicht interessant sind.

BTW: Mich würde mal interessieren, ob jemand ebenso wie ich ein Delta von ziemlich genau 6°C zwischen der tatsächlichen und der von der Weishaupt gemessenen Außentemperatur beobachtet hat.

Viele Grüße
Timo