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:
ebusd/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:
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?
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...
...damit kein Missverständnis entsteht: Ich warte nicht darauf, dass [...]
...paßt schon! War grade am Tippen.
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!