ebus Weishaupt MQTT im Zusammenspiel

Begonnen von rob, 13 Juli 2021, 17:33:38

Vorheriges Thema - Nächstes Thema

rob

Hallo zusammen.

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

Startpunkte:

Datenkette:





Weishaupt Gastherme WTC-15AebuseBUS Adapter 3.0 ETHERNET (W5500)USR-ES1: Lanebus Dockercontainer john30/ebusd:v21.2MQTTFHEM: 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
attr myMQTT_Server autocreate no


  • MQTT2_Device neu angelegt
define MyEbus_MQTT MQTT2_DEVICE ebusd


  • ebus splitter Template angewandt
set MyEbus_MQTT attrTemplate eBus_daemon_splitter


  • autocreate im MQTT2_Server aktiviert
attr myMQTT_Server autocreate complex


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


  • 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)

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


Die RAW-Definitionen in FHEM:
Splitter - MyEbus_MQTT

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"


Device 1 - MQTT2_ebusd_21.2_1

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/#


Device 2 - MQTT2_ebusd_sc

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


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:38ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }\
ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
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:
attr <device> event-min-interval 120
attr <device> event-on-change-reading .*

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

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) }

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
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:

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

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 [...]
...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...
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!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

Zitat von: Beta-User am 14 Juli 2021, 08:12:54
Vielleicht vorab ein paar Anmerkungen bzgl. "autocreate":
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...
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!)
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?
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.
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.
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?
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.

Beta-User

Zitat von: rudolfkoenig am 14 Juli 2021, 10:23:40
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.
(Ohne jetzt im Code geschaut zu haben), gehe ich davon aus, dass das "immer" so gemacht wird und daher unproblematisch ist, ok.
(OT-Anmerkung: Ich sehe zwar das theoretische Problem speziell mit dem Punkt, glaube allerdings nicht, dass der auch proaktisch ein Problem darstellt).

[OT2 @Rudi]
Wir werden sowieso jsonMap brauchen, aber dieses "permanente .*_value"-Namensgebung (die aus der inneren Struktur des JSON kommt) ist eigentlich unnötig. Vielleicht hast du irgendeine Idee, wie man das auf elegantem Weg gleich vor/bei j2nv() "umbiegen" könnte?
[/OT2]

Komisch ist und bleibt, dass da keine Readings zu sehen sind; scheint so, dass der "JSON" schlicht leer ist, oder?

Zitat von: rob am 14 Juli 2021, 10:01:52
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 :)
...deine Frage war ja auch, ob man was im Wiki ändern sollte...
MAn. sollte man, aber möglichst in enger Abstimmung mit @Reinhart (=> gesonderter Thread im Wiki-Bereich mit Hinweis an ihn an geeigneter Stelle?). Ist zwar u.A. auch an dem Punkt nicht "zwingend" aber eben unnötig kompliziert. Der Spur nach wäre meine persönliche Meinung: autocreate auf "default" (=simple) lassen, und (auch für eBus!) nur ändern, wenn man es mit "speziellen" bzw. noch unbekannten Themen zu tun hat. Zum Hintergrund: Argument 2 ("prefix") hilft, um rauszufinden, wo was herkommt, und kann (bei Bedarf!) dazu genutzt werden, ansonsten (vermeintlich) identische Informationen auseinanderzuhalten, die aus verschiedenen Quellen kommt. Argument 3 ($JSONMAP) macht nur Sinn, wenn man auch ein entsprechende Mapping vornimmt => entweder attrTemplate oder der User muss sowieso aktiv werden...

Zitat[...] Würde das helfen?
Betr. der Kodierungsfrage ist es geklärt, und ansonsten sehe ich bisher keine Konflikte. Das darf also gerne so bleiben - die "praxisnahe Mischung" sorgt ggf. dafür, dass Schwachpunkte eher auffallen ;) .


Bzgl. dem "Set": Sollte man erst mal nicht dramatisieren, ist nur sehr komisch, auch weil ich die CID nicht so recht nachvollziehen kann. Es scheint eine "Pseudo-CID" (aus bridgeRegexp) zu sein, und bei der Gelegenheit muss ich mich auch nochmal ansehen, ob da Klarstellungsbedarf besteht hinsichtlich der Wechselwirkung aus einer ggf. gesetzten bridgeRegexp, wenn M2C im Spiel ist... (nicht verwirren lassen, ist mehr für mich selbst).




ZitatJa, 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 :)
Das eilt (FHEM-seitig) nicht, FHEM ist es "im Prinzip egal", wie die Readings heißen, und jedenfalls solange sie nicht identisch sind, ist es auch für die hier relevante Verarbeitungskette egal, ob "knwon" oder "Uknx"...

ZitatWoher kenne ich die Topics um sie via get zu holen [...]
Generell: Häufig über die "subscriptions". Hier aber schwierig, weil der ebus-daemon einfach alles haben will:
Zitatsetstate MQTT2_ebusd_21.2_1 2021-07-12 14:35:13 subscriptions ebusd/#
Konkret (aber aus dem Kopf): Die Abfragepfade kann man aus Readings-Topics ableiten, oder? (Bitte mal die "at"-Pfade und die readingList von den vorhandenen attrTemplate vergleichen). Es müßte dazu auch Info in den älteren Threads zu finden sein; es gibt afaik auch die Option, alle vorhandenen Register auszulesen, das ist nur nicht (dauerhaft) zu empfehlen, weil der Bus dadurch stark belastet wird.
Dazu bitte ggf. einfach auch nochmal bei den ebus-Experten nachfragen, wie man das am besten macht.

"Ernsthafte Verletzungsgefahr" besteht aber mAn. bis dato nicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

#6
OK, Alarm beendet. Ich bin da etwas nervös - dafür kann natürlich keiner was, der Ball liegt bei mir  ::) :)
Das "Set_" scheint also nur ein Prefix zu sein analog dem "ACT_". Ich hatte das gedanklich mit einem MQTT set im publish verwechselt (sowas wie "set myMQTT_Server publish ebus/blabla/set")

Zitat von: Beta-User am 14 Juli 2021, 11:29:53
...mal die "at"-Pfade und die readingList von den vorhandenen attrTemplate vergleichen ...
Dazu bitte ggf. einfach auch nochmal bei den ebus-Experten nachfragen, wie man das am besten macht.
Genau da liegt der Hase im Pfeffer: alles was ich bisher fand ist auf Vaillant oder Wolf abgestimmt. Weishaupt ist wohl nicht so verbreitet und das heißt alles anders in den Topics. Aber fragen kost nix - mach ich natürlich.

So, das Log müsste erst mal reichen (hab den Winter kurz vorgezogen). Den Uptime-Krams hab ich rausgeworfen.

Client mosqsub/16320-OpenWRT sending CONNECT
Client mosqsub/16320-OpenWRT received CONNACK
Client mosqsub/16320-OpenWRT sending SUBSCRIBE (Mid: 1, Topic: ebusd/#, QoS: 0)
Client mosqsub/16320-OpenWRT received SUBACK
Subscribed (mid: 1): 1
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/signal', ... (4 bytes))
true
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/version', ... (18 bytes))
"ebusd 21.2.v21.2"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/running', ... (4 bytes))
true
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/updatecheck', ... (4 bytes))
"OK"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
"finished"

Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.605},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.617},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.617},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.621},
     "SupplySetTemp": {"value": 8}}

---docker restartet ----

Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/version', ... (18 bytes))
"ebusd 21.2.v21.2"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/running', ... (4 bytes))
true
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (9 bytes))
"running"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.35/', ... (126 bytes))
{
     "MF": {"value": "Kromschroeder"},
     "ID": {"value": "W "},
     "SW": {"value": "2726"},
     "HW": {"value": null}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.f6/', ... (131 bytes))
{
     "MF": {"value": "Kromschroeder"},
     "ID": {"value": "WWST?"},
     "SW": {"value": "1200"},
     "HW": {"value": "0302"}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
"finished"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (2 bytes))
16
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/signal', ... (4 bytes))
true
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (9 bytes))
"running"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/hc1/Set', ... (259 bytes))
{
     "Status": {"value": "hotwater"},
     "Action": {"value": "stopconsumer"},
     "SetTemp": {"value": 5.00},
     "SetPressure": {"value": null},
     "OutputDegree": {"value": null},
     "DHWSetTemp": {"value": 48.0},
     "Fueltype": {"value": null}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
"finished"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (2 bytes))
32
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.621},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (2 bytes))
48
Client mosqsub/16320-OpenWRT sending PINGREQ
Client mosqsub/16320-OpenWRT received PINGRESP
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.625},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.08/', ... (128 bytes))
{
     "MF": {"value": "Kromschroeder"},
     "ID": {"value": "W "},
     "SW": {"value": "1200"},
     "HW": {"value": "0302"}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (9 bytes))
"running"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (3 bytes))
208
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
"finished"
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.629},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.637},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.641},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.645},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 17},
     "TrendTemp": {"value": 16.648},
     "SupplySetTemp": {"value": 8}}
Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
{
     "Status1": {"value": 1},
     "Operatingphase": {"value": "BrennerAus"},
     "Ukn2_1": {"value": 1},
     "Ukn2_2": {"value": 1},
     "Ukn2_3": {"value": 1},
     "Flame": {"value": 0},
     "GasValve1": {"value": 0},
     "GasValve2": {"value": 0},
     "Pump": {"value": 0},
     "Error": {"value": 0},
     "Ukn3_1": {"value": 0},
     "SoWi": {"value": "Summer"},
     "Ukn3_3": {"value": 0},
     "Ukn3_4": {"value": 0},
     "Ukn3_5": {"value": 0},
     "Ukn3_6": {"value": 0},
     "Ukn3_7": {"value": 0},
     "SettingUV": {"value": "Heating"},
     "Load": {"value": 0},
     "SupplyTemp": {"value": 44.0},
     "FlueGasTemp": {"value": null},
     "DHWTemp": {"value": 48.0},
     "UknTemp": {"value": 0.0},
     "ExternalTemp": {"value": 18},
     "TrendTemp": {"value": 16.648},
     "SupplySetTemp": {"value": 8}}


Edit: ja, war zu lang. In der Vorschau sah alles gut aus.

Beta-User

(Formatierung ist leider kapput, war wohl zu viel Info => ggf. künftig lieber als txt-Anhang?)

Was das "Set" angeht: vermutlich ist das so als Topic konfiguriert (indirekt über die csv?), es scheint sich um die aktuellen settings zu handeln. Ich finde das "unglücklich", also falls du die richtige Stelle findest, um das anzupassen, wäre die Frage, ob das geht, ohne Inkompabilitäten heraufzubeschwören?

Was die "scan"-Sachen angeht, müßten jetzt Werte vorhanden sein, oder?
Was jeweils gescannt wird, scheint nach diesem Beitrag v.a. davon abzuhängen, welche csv's vorhanden sind?
Zitatalles was ich bisher fand ist auf Vaillant oder Wolf abgestimmt. Weishaupt ist wohl nicht so verbreitet und das heißt alles anders in den Topics.
Jein... Nach meinem (evtl. falschen!) Verständnis ist es prinzipiell nicht wichtig, welcher Hersteller dahinter steht. ebusd als zentraler Dienst übersetzt das dann jeweils, wird aber seinerseits immer durch dieses Anhängsel "/get" aufgefordert, die am jeweiligen Ort vorhandenen (!) Werte auszuliefern. Welche Topics/Werte vorhanden sind, müßte man eigentlich aus den csv's rekonstruieren können. Und die sind dann auch wieder eigentlich "relativ" standardisiert, was die Struktur an sich angeht - es schreibt nur eben jeder "irgendwas" rein, was er jeweils für sinnvoll erachtet, z.B. Texte wie "hotwaterinheating" oder "BrennerAus"...
(Das ist ein anderes Thema, aber m.E. wäre es u.A. auch wünschenswert, hier standardisiertere (englische) Werte zu verwenden, ohne allerdings sagen zu können, wie die im Detail aussehen könnten).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

Zitat von: Beta-User am 14 Juli 2021, 12:24:29
Was die "scan"-Sachen angeht, müßten jetzt Werte vorhanden sein, oder?
In Fhem sehe ich keine Veränderung. Habe autocreate auf simple und ebus-docker restartet. (oecr habe ich vorsichtshalber raus). Keine neuen Devices, keine neuen Readings.

list -r .*[E|e]bus.* sagt:

define FileLog_MQTT2_ebusd_21.2_1 FileLog ./log/MQTT2_ebusd_21.2_1-%Y-%m-%d.log MQTT2_ebusd_21.2_1
attr FileLog_MQTT2_ebusd_21.2_1 group Gastherme
attr FileLog_MQTT2_ebusd_21.2_1 logtype text
attr FileLog_MQTT2_ebusd_21.2_1 room 12_Heizraum,MQTT2_DEVICE

define FileLog_MQTT2_ebusd_sc FileLog ./log/MQTT2_ebusd_sc-%Y-%m-%d.log MQTT2_ebusd_sc
attr FileLog_MQTT2_ebusd_sc group Gastherme
attr FileLog_MQTT2_ebusd_sc logtype text
attr FileLog_MQTT2_ebusd_sc room 12_Heizraum,MQTT2_DEVICE

define MQTT2_ebusd_21.2_1 MQTT2_DEVICE ebusd_21.2_1
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

define MQTT2_ebusd_sc MQTT2_DEVICE ebusd_sc
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

define 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 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 FileLog_MQTT2_ebusd_21.2_1 active
setstate FileLog_MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 linesInTheFile 14

setstate FileLog_MQTT2_ebusd_sc active
setstate FileLog_MQTT2_ebusd_sc 2021-07-14 12:55:50 linesInTheFile 1686

setstate MQTT2_ebusd_21.2_1 2021-07-14 08:49:26 IODev myMQTT_Server
setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_Action_value startconsumer
setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_DHWSetTemp_value 48.0
setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_SetTemp_value 5.00
setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_Status_value hotwater
setstate MQTT2_ebusd_21.2_1 2021-07-14 08:50:24 subscriptions ebusd/#

setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_DHWTemp_value 47.0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Error_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_ExternalTemp_value 20
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Flame_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_GasValve1_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_GasValve2_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Load_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Operatingphase_value BrennerAus
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Pump_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SettingUV_value Heating
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SoWi_value Summer
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Status1_value 1
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SupplySetTemp_value 8
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SupplyTemp_value 25.0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_TrendTemp_value 16.980
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn2_1_value 1
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn2_2_value 1
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn2_3_value 1
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_1_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_3_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_4_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_5_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_6_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_7_value 0
setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_UknTemp_value 0.0
setstate MQTT2_ebusd_sc 2021-07-14 08:49:26 IODev myMQTT_Server
setstate MQTT2_ebusd_sc 2021-07-12 14:35:13 associatedWith MyEbus_MQTT

setstate MyEbus_MQTT Status: \
1:true\
Signal: \
2:true\
<br>Uptime: 0 000 00:07
setstate MyEbus_MQTT 2021-07-14 08:49:26 IODev myMQTT_Server
setstate MyEbus_MQTT 2021-07-14 12:49:16 associatedWith MyEbus_MQTT
setstate MyEbus_MQTT 2021-07-12 14:32:29 attrTemplateVersion 20200824
setstate MyEbus_MQTT 2021-07-14 12:56:15 formatedUptime 0 000 00:07
setstate MyEbus_MQTT 2021-07-14 12:49:03 running true
setstate MyEbus_MQTT 2021-07-14 12:49:50 scan "finished"
setstate MyEbus_MQTT 2021-07-14 12:49:20 signal true
setstate MyEbus_MQTT 2021-07-12 14:32:29 state getKnown
setstate MyEbus_MQTT 2021-07-14 12:51:50 updatecheck "OK"
setstate MyEbus_MQTT 2021-07-14 12:56:15 uptime 432
setstate MyEbus_MQTT 2021-07-14 12:49:03 version "ebusd 21.2.v21.2"


Hätte ich die Devices löschen sollen?

VG
rob

beaune

Zur Info: ich hatte auch ein Problem mit der Codierung. Automatisch angelegt (vermutlich durch das Template eBus_Calormatic_TimeProgramm, kann ich aber nicht mehr im Detail nachvollziehen) wurde dieser Eintrag in der readingsList:
ebusd/f47/ccTimer\x5c\x2eMonday:.* { json2nameValue($EVENT, 'ccTimer.Monday_', $JSONMAP)}

So funktioniert das Reading nicht, jedenfalls nicht wenn man es so aktualisieren will:
set mqtt publish ebusd/f47/hcTimer.Monday/get. Ich hab daher die readingList manuell angepasst:
ebusd/f47/hcTimer.Monday:.* { json2nameValue($EVENT, 'hcTimer.Monday_', $JSONMAP) }

Das war übrigens eines der Dinge, die den Eindruck vermittelt haben, dass die Templates irgendwie unfertig sind und man sie lieber nicht verwenden sollte...

rob

Supi, danke für den Wink.
Jetzt kommen neue Readings rein:

     2021-07-14 13:14:38   scan.35_ID_value W
     2021-07-14 13:14:38   scan.35_MF_value Kromschroeder
     2021-07-14 13:14:38   scan.35_SW_value 2726
     2021-07-14 13:14:25   scan.f6_HW_value 0302
     2021-07-14 13:14:25   scan.f6_ID_value WWST?
     2021-07-14 13:14:25   scan.f6_MF_value Kromschroeder
     2021-07-14 13:14:25   scan.f6_SW_value 1200


Einfach den Punkt setzen und gut.

VG
rob

Beta-User

@Rudi: M.E. ist "die Sache mit dem Punkt"  "unerwünschtes Verhalten" von M2D allgemein. Kannst du das bitte in die eine oder andere Richtung fixen? Bauchgefühl sagt: Punkt stehen lassen ist das kleinere Übel.

@rob
Hmm, irgendwie würde mich weiter interessieren, wo dieses ominöse Gerät "MQTT2_ebusd_21.2_1" entsteht. Konnte das grade jedenfalls nicht mit der in der file enthaltenen Topic/Payload-Kombi rekonsturieren. Gibt es in deiner Installation noch eine andere bridgeRegexp, aus der das kommen könnte?
list TYPE=MQTT2_DEVICE bridgeRegexp

MAn. kannst du diese beiden Geräte (M2D+fileLog) löschen.

@beaune:
Willkommen an Bord! (Und zur Klarstellung: ein "gutes attrTemplate" hätte das für dich gefixt ;) ... Erstellt wurde das Device übrigens durch die bridgeRegexp am "Zentraldevice" (und allgemeine M2DFunktionalität), nicht direkt durch attrTemplate)

@rob:
Bitte wirf in MQTT2_ebusd_sc den "Act_"-Prefix raus, sonst können wir da nicht mit "guten Readingnamen" weitermachen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

list TYPE=MQTT2_DEVICE bridgeRegexp sagt:

MyEbus_MQTT              (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"

Beim Testen auf dem Testsystem ohne autocreate complex usw. kam auch dieses Device (als einziges). Durch den Split steht das Warmwasser drin - scheint der WW-Pufferspeicher zu sein. Habs aber erstmal gelöscht.

Zitat von: Beta-User am 14 Juli 2021, 13:31:02
Bitte wirf in MQTT2_ebusd_sc den "Act_"-Prefix raus, sonst können wir da nicht mit "guten Readingnamen" weitermachen.
Ja, ist jetzt bereinigt. Sorry, hattest es schon geschrieben - ich aber nicht begriffen  ::)

VG
rob


rudolfkoenig

Zitat@Rudi: M.E. ist "die Sache mit dem Punkt"  "unerwünschtes Verhalten" von M2D allgemein. Kannst du das bitte in die eine oder andere Richtung fixen? Bauchgefühl sagt: Punkt stehen lassen ist das kleinere Übel.

Bevor ich irgendetwas unternehme, moeche ich das Problem verstehen.
Ich sehe naemlich noch gar kein Problem, nur falsche Theorien wegen Codierungsfehler.

Beta-User

Zitat von: rudolfkoenig am 14 Juli 2021, 13:57:23
Bevor ich irgendetwas unternehme, moeche ich das Problem verstehen.
Das "Problem" (bzw. die "konsolidierte Symptombeschreibung") sieht m.E. so aus:
- Ein Client publisht unter einem Topic, der Punkte enthält.
- M2D wandelt den beim automatischen Erstellen von readingList-Einträgen in "\x2e" um (vermutlich immer, in jedem Fall aber, wenn bridgeRegexp im Spiel ist).
- Spätere publishes dieses Gerätes unter demselben Topic gehen verloren bzw. erzeugen nicht die erwarteten Readings/Werte

Lösung also entweder: Der "eingehende Punkt" wird immer einheitlich konvertiert, (scheint derzeit irgendwie zu haken, sonst müsste es auch Readings geben), oder er bleibt halt stehen und kann mit einer "wildcard" verwechselt werden, so dass eventuell "zu viel" unter einem solchen Topic empfangen wird.

Kurz: Es sollte irgendwie einheitlich sein, aber irgendwo geht halt im Moment was schief...



@rob&beaune:
Evtl. kann es gegen dieses "Phantom-Device" helfen, die bridgeRegexp schärfer zu schneiden. Würde mal folgendes in den Raum stellen:
attr MyEbus_MQTT bridgeRegexp (ebus\S[^/]*?)/(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\S[^/]*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files