FHEM - Hausautomations-Systeme > MQTT

ebus Weishaupt MQTT im Zusammenspiel

(1/20) > >>

rob:
Hallo zusammen.

Hier möchte ich im Weishaupt-spezifischen Dschungel etwas lichten und ein paar Lianen abschlagen ;)

Startpunkte:

* alles rund um den ebus3 Adapter und dessen Inbetriebnahme - https://forum.fhem.de/index.php/topic,118143.0.html
* Weishaupt-spezifische CSV-files - https://forum.fhem.de/index.php/topic,61017.0.html
* ebus MQTT Templates - https://forum.fhem.de/index.php/topic,97989.0.html
Datenkette:
Weishaupt Gastherme WTC-15A❯ebus❯eBUS Adapter 3.0 ETHERNET (W5500)❯USR-ES1: Lan❯ebus Dockercontainer john30/ebusd:v21.2❯MQTT❯FHEM: myMQTT_Server (MQTT2_SERVER)❯FHEM: MyEbus_MQTT (MQTT2_DEVICE - splitter)❯FHEM: MQTT2_ebusd_21.2_1 (MQTT2_DEVICE 1)❯FHEM: MQTT2_ebusd_sc (MQTT2_DEVICE 2)
Zum Nachvollziehen, was habe ich an Schritten durchgeführt:
(Hardware-Krams außen vor, ist unter 1. bestens behandelt)

* autocreate im MQTT2_Server deaktiviert
--- Code: ---attr myMQTT_Server autocreate no
--- Ende Code ---


* MQTT2_Device neu angelegt
--- Code: ---define MyEbus_MQTT MQTT2_DEVICE ebusd
--- Ende Code ---


* ebus splitter Template angewandt
--- Code: ---set MyEbus_MQTT attrTemplate eBus_daemon_splitter
--- Ende Code ---


* autocreate im MQTT2_Server aktiviert
--- Code: ---attr myMQTT_Server autocreate complex
--- Ende Code ---


* J0EK3Rs Repo geladen
--- Code: ---git clone https://github.com/J0EK3R/ebusd-configuration-weishaupt.git /home/dietpi/ebus/weishaupt/
--- Ende Code ---

* aus john30s Repo die broadcast.csv und memory.csv geladen und im selben Pfad abgelegt (keine Ahnung, ob es das braucht - wurde aber von ebusd geladen)

* docker gestartet (für Raspi, latest klappt nur für amd64, da latest aktuell kein multiarch)
--- Code: ---docker run -d \
       --name=ebus \
       --restart=always \
       -v /etc/localtime:/etc/localtime:ro \
       -v /home/dietpi/ebus/weishaupt/:/etc/ebusd \
       -p 8888 \
john30/ebusd:v21.2 -f --scanconfig -d enh:192.168.0.188:9999 --latency=80 --accesslevel=* --address=ff --mqttport=1883 --mqttjson --mqtthost=192.168.0.11 --mqtttopic=ebusd/%circuit/%name --mqttchanges --configpath=/etc/ebusd

--- Ende Code ---

Die RAW-Definitionen in FHEM:
Splitter - MyEbus_MQTT

--- Code: ---defmod MyEbus_MQTT MQTT2_DEVICE ebusd
attr MyEbus_MQTT IODev myMQTT_Server
attr MyEbus_MQTT autocreate 1
attr MyEbus_MQTT bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|solar|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
attr MyEbus_MQTT comment NOTE: additional templates and code have been downloaded from svn (contrib).
attr MyEbus_MQTT devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr MyEbus_MQTT event-min-interval 120
attr MyEbus_MQTT event-on-change-reading .*
attr MyEbus_MQTT group Gastherme
attr MyEbus_MQTT icon sani_boiler_temp
attr MyEbus_MQTT model eBus_daemon_splitter
attr MyEbus_MQTT readingList ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/global/scan:.* scan\
ebusd/global/uptime:.* uptime\
ebusd/global/signal:.* signal\
ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }\
ebusd/global/updatecheck:.* updatecheck\
ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
attr MyEbus_MQTT room 12_Heizraum,MQTT2_DEVICE
attr MyEbus_MQTT setList getKnown:noArg ebusd/list onlyknown\
  getAll:noArg ebusd/list
attr MyEbus_MQTT stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MyEbus_MQTT userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
attr MyEbus_MQTT verbose 0

setstate MyEbus_MQTT Status: \
1:true\
Signal: \
2:true\
<br>Uptime: 0 001 02:16
setstate MyEbus_MQTT 2021-07-12 14:37:43 associatedWith MyEbus_MQTT
setstate MyEbus_MQTT 2021-07-12 14:32:29 attrTemplateVersion 20200824
setstate MyEbus_MQTT 2021-07-13 16:50:36 formatedUptime 0 001 02:16
setstate MyEbus_MQTT 2021-07-12 14:34:16 running true
setstate MyEbus_MQTT 2021-07-12 14:37:45 scan "finished"
setstate MyEbus_MQTT 2021-07-12 14:34:32 signal true
setstate MyEbus_MQTT 2021-07-12 14:32:29 state getKnown
setstate MyEbus_MQTT 2021-07-12 14:36:53 updatecheck "OK"
setstate MyEbus_MQTT 2021-07-13 16:50:36 uptime 94580
setstate MyEbus_MQTT 2021-07-12 14:34:16 version "ebusd 21.2.v21.2"

--- Ende Code ---

Device 1 - MQTT2_ebusd_21.2_1

--- Code: ---defmod MQTT2_ebusd_21.2_1 MQTT2_DEVICE ebusd_21.2_1
attr MQTT2_ebusd_21.2_1 event-min-interval 120
attr MQTT2_ebusd_21.2_1 event-on-change-reading .*
attr MQTT2_ebusd_21.2_1 group Gastherme
attr MQTT2_ebusd_21.2_1 readingList ebusd_21.2_1:ebusd/hc1/Set:.* { json2nameValue($EVENT, 'Set_', $JSONMAP) }
attr MQTT2_ebusd_21.2_1 room 12_Heizraum,MQTT2_DEVICE

setstate MQTT2_ebusd_21.2_1 2021-07-12 14:34:50 IODev myMQTT_Server
setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_Action_value stopconsumer
setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_DHWSetTemp_value 48.0
setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_SetTemp_value 5.00
setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_Status_value hotwater
setstate MQTT2_ebusd_21.2_1 2021-07-12 14:35:13 subscriptions ebusd/#

--- Ende Code ---

Device 2 - MQTT2_ebusd_sc

--- Code: ---defmod MQTT2_ebusd_sc MQTT2_DEVICE ebusd_sc
attr MQTT2_ebusd_sc event-min-interval 120
attr MQTT2_ebusd_sc event-on-change-reading .*
attr MQTT2_ebusd_sc group Gastherme
attr MQTT2_ebusd_sc readingList ebusd/sc/Act:.* { json2nameValue($EVENT, 'Act_', $JSONMAP) }
attr MQTT2_ebusd_sc room 12_Heizraum,MQTT2_DEVICE

setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_DHWTemp_value 48.0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Error_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_ExternalTemp_value 15
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Flame_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_GasValve1_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_GasValve2_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Load_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Operatingphase_value BrennerAus
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Pump_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SettingUV_value Heating
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SoWi_value Summer
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Status1_value 1
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SupplySetTemp_value 8
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SupplyTemp_value 39.0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_TrendTemp_value 19.055
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn2_1_value 1
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn2_2_value 1
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn2_3_value 1
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_1_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_3_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_4_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_5_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_6_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_7_value 0
setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_UknTemp_value 0.0
setstate MQTT2_ebusd_sc 2021-07-12 14:35:13 IODev myMQTT_Server
setstate MQTT2_ebusd_sc 2021-07-12 14:35:13 associatedWith MyEbus_MQTT

--- Ende Code ---

Wie ich an den Payload komme, weiß ich nicht so recht. Zumindest stehen die Readings oben dabei. In den Devices "MQTT2_ebusd_21.2_1" und "MQTT2_ebusd_sc" habe ich eine Auswahl an ebus-Templates ➜ rein namentlich will das aber noch nicht passen bzw. ich weiß ich nicht, welches ich anwenden soll.

Jetzt geht es darum, passende Templates zu finden oder angepasste/ andere Templates zu erfinden, die auch für Weishaupt simpel anwendbar sind.
Wer schon Visulalisierungen usw. für seine Weishaupt hat, kann diese hier gerne vorstellen. Vielleicht ließe sich dies zum Template machen?

Vorab schon einmal vielen Dank für Input und Unterstützung.

Viele Grüße
rob

rob:
...damit kein Missverständnis entsteht: Ich warte nicht darauf, dass mir jmd. tolle Sachen einflüstert, sondern wurschtle und teste meinerseits anhand der vorhandenen Templates dran rum. Wird aber ein wenig dauern, bis ich hier was posten kann.

Aktuell steht die Therme eh auf Sommerzeit, sodass da nicht allzuviel los ist an Readings. Ich denk mal dies ist der Grund... werde zum Testen auf Winterzeit stellen - mal schauen.

VG
rob

Beta-User:
Dann mal Willkommen!

[@Rudi: da scheint ein generelles (Codierungs-) Problem drin zu sein, s.u.]

Vielleicht vorab ein paar Anmerkungen bzgl. "autocreate":
- Kann man auf dem default (M2S - auch ohne Attribut: simple) lassen. Dann wird auch das "Zentraldevice" von autocreate erstellt, wenn der Dienst gestartet wird, weiter passiert da erst mal nichts.
- auf "complex" umzustellen war hier hilfreich, v.a. bei den Geräten, die mehrere Topics abonnieren, sieht man dann, welches Reading auf welchem Weg erzeugt wurde. Später werden wir die Präfixe aber meistens löschen (=> bitte erst mal nicht mit den jetzigen Namen zum Loggen etc. verwenden! die Reading-Namen werden sich voraussichtlich ändern!)


Die Payloads kann ich mir nun schon in etwa vorstellen, aber trotzdem kurz die Antwort darauf, wie man da drankommen kann:
- Meine eigene bevorzugte Methode ist, mit mosquittos_sub (aus dem Paket mosquitto-clients) schlicht die Topics (bzw. Topic-Strukturen) zu abonnieren. Installation ginge auch auf dem FHEM-Server(-Pi), dazu ein eigenes ssh-Terminal. Andere bevorzugen MQTT.fx, es geht prinzipiell auch mit irgendeinem beliebigen anderen Client.
- Man kann rawEvents am IO (hier myMQTT_Server) aktivieren (regex ggf. so anpassen, dass man nur das sieht, was einen interessiert, sonst ".*"), und dann im Event-Monitor die Events auf den Server beschränken;
- man kann auch"Klartextreadings" erstellen, indem man die readingList-Zeilen an den M2D doppelt und einen passenden Namen vergibt ("json_<Reading>").

Hier würde ich für eine externe Lösung plädieren, wir scheinen ein UTF-Codierungsproblem zu haben, und es würde mich interessieren, ob das schon auf der eBus-Seite angelegt ist, oder erst in FHEM (bei der bridgeRegexp) entsteht...


@Rudi, falls du hier mitliest: diese "scan\x2e.*"-Zweige sind doch ein UTF-Problem, oder täuscht mich das?
@rob: Ist dein FHEM ebenfalls "verdockert" oder anders gesagt: kannst du ein paar Infos zu deinem FHEM liefern? (Generell gehe ich davon aus, dass du up-to-date bist!)

Da wir bei dem Thema sind:

--- Zitat von: rob am 13 Juli 2021, 17:33:38 ---
--- Code: ---ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }\
ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }

--- Ende Code ---

--- Ende Zitat ---
Diese Zweige scheinen keine Readings  erzeugt zu haben, was sehr seltsam ist, weil FHEM erkannt hat, dass JSON-Payloads kommen...? Kann man das Provozieren, dass wieder ein scan ausgelöst wird? Wenn ja, sollte der möglichst "generisch" sein, also nicht nur eine einzelne Adresse manuell anschubsen).

Falls wir feststellen, dass darüber gar keine für FHEM relevanten Infos kommen, sollten wir versuchen, diese Topics direkt auszuknipsen...

Noch eine generelle Anmerkung bzw. Frage - wo kommen diese Attribute her:

--- Code: ---attr <device> event-min-interval 120
attr <device> event-on-change-reading .*
--- Ende Code ---
Bitte in der "Findungsphase" keine Attribute setzen, die die Ergebnisse verfälschen können! Es geht erst mal darum rauszufinden, was wann warum wie (automatisch) kommt, und welche pull-Anweisungen wir ggf. dann von FHEM aus starten müssen...

Jetzt zu den einzelnen Devices:

--- Zitat ---Device 1 - MQTT2_ebusd_21.2_1

--- Code: ---defmod MQTT2_ebusd_21.2_1 MQTT2_DEVICE ebusd_21.2_1
attr MQTT2_ebusd_21.2_1 readingList ebusd_21.2_1:ebusd/hc1/Set:.* { json2nameValue($EVENT, 'Set_', $JSONMAP) }

--- Ende Code ---

--- Ende Zitat ---
Da würde mich interessieren, wo das Device überhaupt herkommt... Die CID sieht irgendwie seltsam aus, es gibt gewisse Überschneidungen mit der Version, aber wie die da hinkommt?

Wie dem auch sei: Wenn ich ein "Set" (oä.) im Topic finde, bin ich erst mal "alarmiert", weil das in der Regel Anweisungen _an_ das Gerät sind, die man in FHEM nicht haben will (sondern erst die Reaktion der Hardware). Frage: hast du da von anderer Seite her was gepublisht?


--- Zitat ---Device 2 - MQTT2_ebusd_sc

--- Ende Zitat ---
Das scheint die eigentliche (Gas-) Therme zu sein, das Device an sich sieht schon mal ganz ok aus, du kannst m.E. direkt das "Act_" als Prefix aus j2nv() nehmen, dann sehen die "Roh-Readings" schon besser aus:

--- Code: ---attr MQTT2_ebusd_sc readingList ebusd/sc/Act:.* { json2nameValue($EVENT, '', $JSONMAP) }

--- Ende Code ---
Die "Act_.*"-Readings kannst du dann löschen und die sich dann ergebenden Readings  mit dem jsonMap-Attribut in was umbenennen, das dir sinnvoll erscheint. Dabei würde ich dringend empfehlen, "internationalisierte" Reading-Namen zu verwenden, also z.B. "temperature" statt "Temperatur".

Die "Ukn.*"-Readings dürften Hausaufgaben auf der csv-Seite sein. Vermutlich sind Werte über den Bus verfügbar, die nicht zugeordnet sind.

Als nächstes wären dann schon setList und getList _an diesem Gerät_ dran. Ich habe jetzt nicht in die vorhandenen templates geschaut, aber ggf. könnte es da bei den "bai"-templates schon was geben, das in die richtige Richtung geht...


--- Zitat von: rob am 14 Juli 2021, 07:40:20 ---...damit kein Missverständnis entsteht: Ich warte nicht darauf, dass [...]

--- Ende Zitat ---
...paßt schon! War grade am Tippen.


--- Zitat ---Aktuell steht die Therme eh auf Sommerzeit, sodass da nicht allzuviel los ist an Readings. Ich denk mal dies ist der Grund...

--- Ende Zitat ---
Vermutlich ist nicht das der Haupt-Grund, sondern man bekommt afaik beim eBus alle Infos nur "auf Anforderung". Es ist dazu ein "at" im Wiki beschrieben, mein Vorschlag wäre, das durch periodicCmd-Attribute an der jeweiligen Baugruppe zu ersetzen.

Soviel mal für's erste, CU!

rob:

--- Zitat von: Beta-User am 14 Juli 2021, 08:12:54 ---Vielleicht vorab ein paar Anmerkungen bzgl. "autocreate":

--- Ende Zitat ---
Alles gemäß WIKI durchgeführt https://wiki.fhem.de/wiki/EBUS-MQTT2#Vorbereitung_und_Definition_in_FHEM. Das Ergebnis daraus sehen wir unverändert - abgesehen von eocr und room :)


--- Zitat von: Beta-User am 14 Juli 2021, 08:12:54 ---- Meine eigene bevorzugte Methode ist, mit mosquittos_sub
...
Hier würde ich für eine externe Lösung plädieren...

--- Ende Zitat ---
Hab ich sogar bereits verfügbar ➜ auf meinen OpenWRT-Geräten. Nehm ich doch glatt das. Danke Dir.


--- Zitat von: Beta-User am 14 Juli 2021, 08:12:54 ---@rob: Ist dein FHEM ebenfalls "verdockert" oder anders gesagt: kannst du ein paar Infos zu deinem FHEM liefern? (Generell gehe ich davon aus, dass du up-to-date bist!)

--- Ende Zitat ---
Gerne:
Host: Raspi3 mit Dietpi (Debian) ➜ up to date
FHEM: direkt auf dem Host installiert ➜ up to date
MQTT: weitere Clients sind aktiv, insbesondere die YiCAM ist recht gesprächig (motion events)
ebusd: verdockert

Aufgrund der Datenkette scheint es imho einige Stelle zu geben, wo ich einen Fehler gemacht haben kann. Ich könnte sehr einfach mein Testsystem starten: clean FHEM in Docker und quasi jungfräulich alles step by step dort anlegen und prüfen. Dann wären Querolanten á la YiCAM außen vor. Würde das helfen?


--- Zitat von: Beta-User am 14 Juli 2021, 08:12:54 ---Wie dem auch sei: Wenn ich ein "Set" (oä.) im Topic finde, bin ich erst mal "alarmiert", weil das in der Regel Anweisungen _an_ das Gerät sind, die man in FHEM nicht haben will (sondern erst die Reaktion der Hardware). Frage: hast du da von anderer Seite her was gepublisht?

--- Ende Zitat ---
Nein, ich habe nichts gepublisht - Device angelegt wie im WIKI und eocr+room gesetzt. Gefällt mir garnicht. Ich bin auch alarmiert. Denn genau das ist es, was ich auf keinen Fall möchte. Ich möchte nur mitlesen am ebus und nix schreiben. Erst recht solange ich garnicht weiß, was es tut (bzgl. CSV).


--- Zitat von: Beta-User am 14 Juli 2021, 08:12:54 ---Die "Ukn.*"-Readings dürften Hausaufgaben auf der csv-Seite sein. Vermutlich sind Werte über den Bus verfügbar, die nicht zugeordnet sind.

--- Ende Zitat ---
Ja, J0EK3R schreibt auch, dass er die CSV nicht mehr pflegen kann und er Bedarf sieht. Das würde ich gerne top down halten und angehen, sobald ich MQTT-FHEM-seitig mehr Land sehe :)


--- Zitat von: Beta-User am 14 Juli 2021, 08:12:54 ---...man bekommt afaik beim eBus alle Infos nur "auf Anforderung". Es ist dazu ein "at" im Wiki beschrieben, mein Vorschlag wäre, das durch periodicCmd-Attribute an der jeweiligen Baugruppe zu ersetzen.

--- Ende Zitat ---
Ja, hab ich auch so gelesen/ verstanden. Mein Problem ist nur: Woher kenne ich die Topics um sie via get zu holen, wenn sie bislang nirgends published wurden? Würde ich aber zunächst hinten an stellen das rauszufinden. Das Attribut periodicCMD finde ich schon absolut klasse.

Die Template-Geschichte scheint mir auch erst einmal zweitrangig. Wichtiger ist mir zu verstehen, woher das "Set" kommt. Das lässt mich zweifeln, ob mein Bastelprojekt ebus richtig ist. Mag keine 5.000 Lehrgeld zahlen.

OK, bin jetzt am Loggen und starte Docker neu, das provoziert ggf. weitere Meldungen.

Viele Grüße
rob

rudolfkoenig:

--- Zitat ---@Rudi, falls du hier mitliest: diese "scan\x2e.*"-Zweige sind doch ein UTF-Problem, oder täuscht mich das?
--- Ende Zitat ---
Ich hoffe ja, sowohl was UTF, wie auch was Problem betrifft.
scan\x2e35 entspricht scan.35 (\x2e ist Punkt), und es wurde umgewandelt, damit beim Regexp keine Ueberraschungen gibt.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln