@Rudi:
Vielleicht hast du mitgelesen, wir sind grade dabei, die mqtt2.templates zu optimieren für den ebus (siehe hier (https://forum.fhem.de/index.php/topic,97989.0.html)).
Da dort die Langform von json2nameValue() (z.B.ebusd/bai/CirPump:.* { json2nameValue($EVENT, 'CirPump_', $JSONMAP) }\) tatsächlich sehr hilfreich zu sein scheint, die Frage, ob es eine größere Aktion wäre, diese von autocreate _in bestimmten Fällen ausnahmsweise_ automatisch anlegen zu lassen. Für den ebus bin ich einigermaßen optimistisch, dass wir das auch ohne hinbekommen (komofrtabler wäre es mit), aber ggf. ist es in ähnlichen Fällen zukünftig hilfreich.
Als Idee vielleicht über einen autocreate-Attributwert 2?
Danke vorab für's drüber nachdenken :) .
Gruß, Beta-User
ZitatAls Idee vielleicht über einen autocreate-Attributwert 2?
Bevor ich das falsch implementiere: bei welchem Geraet moechtest du dieses Attribut setzen?
Statt 2 wuerde ich "simple" und "complex" einfuehren, wobei 1 als synonym fuer "simple" steht.
Die Benennung ist "sprechend" vermutlich besser.
Im Prinzip würde ich es überall da erlauben, wo es bisher auch steht, also entweder beim IO (dann alle unbekannten Geräte) oder beim MQTT2_DEVICE (dann auch gültig für Geräte, die via bridgeRegexp angelegt werden).
Wenn "weitergereicht" oder vom IO her kommend: Maßgeblich sollte das sein, was das aufnehmende MQTT2_DEVICE meint. Also: MQTT2_SERVER steht auf "complex", MQTT2_DEVICE steht auf "simple" ergibt simple (und umgekehrt, also IO smple, DEVICE complex ergibt neue lange Form für neue Readinglist-Elemente an diesem Gerät). Wird ein neues MQTT2_DEVICE-Gerät angelegt, sollte die Vorgabe "vererbt" werden.
(Hoffe, das ist einigermaßen nachvollziehbar)...
Bei der Gelegenheit:
(Das ist aber auch kein wichtiges Thema...) Ich bin mir unsicher, ob ich das associatedWith gut finden soll, soweit es direkt das IO betrifft (für Geräte, die via bridgeRegexp angelegt werden, ist es super!). Da haben wir den Link ja eigentlich schon vom IO-Attribut her.
Frage: War das schon immer so, dass MQTT2_CLIENT nach den ersten beiden Elementen des Topic-Trees die Geräte-CID vergibt? (dann war die bisherige bridgeRegexp im 00-template schon immer ziemlicher Unsinn ;D )
ZitatIm Prinzip würde ich es überall da erlauben, wo es bisher auch steht, also entweder beim IO (dann alle unbekannten Geräte) oder beim MQTT2_DEVICE (dann auch gültig für Geräte, die via bridgeRegexp angelegt werden).
Haette lieber nicht fragen sollen, ich habe sowas wie 'nur hier' und nicht 'ueberall wo moeglich' erwartet :)
Ich habe den Vorschlag fuer MQTT2_CLIENT und MQTT2_SERVER eingebaut, weil fuer Bridge der Umbau zu viel bedeutet haette: autocreate bei MQTT2_DEVICE gilt nur fuer das Geraet selbst, und nicht fuer die per bridgeRegexp angelegten. Eigentlich muesste man fuer jeden bridgeRegexp-Ausdruck autocreate separat angeben, aber wie gesagt, das ist im Moment zu viel.
Wenn Erfahrung mit der bisherigen Implementation besteht, dann sehen wir weiter.
Zitat von: rudolfkoenig am 05 März 2019, 12:05:52
Haette lieber nicht fragen sollen, ich habe sowas wie 'nur hier' und nicht 'ueberall wo moeglich' erwartet :)
:) ;wenigstens scheint meine Antwort nachvollziehbar gewesen zu sein... ;D .
Vorab auf alle Fälle mal: DANKE!
Das bridgeRegexp-Problem sehe ich nicht; du hast zwar an sich recht, dass es sinnvoll wäre, wenn unterschiedliche Geräte, die die Infos sehr unterschiedlich "verpacken", "auf einmal" reinkommen. In der Praxis scheint das aber bisher nur der ebusd so zu machen, hinter dem dann wieder eine ziemlich komplexe und variantenreiche Landschaft denkbar ist. Aber innerhalb der Landschaft könnte es m.E. einheitlich sein. Anders gesagt: Wenn man da das autocreate bei einer "bridge" auf "complex" stellt, wird man tendenziell erwarten, dass das für die "dahinter liegende Landschaft" insgesamt gilt.
Hat man also die (entsprechend meinem anderen Beitrag dazu modifizierte) 00_GeneralBridge im Einsatz, wäre es zwar schön, die würde gleich "wissen", dass ebusd-Topics komplex sind, aber schlimm ist das nicht, wenn nicht, weil:
"simple" ist erst mal ok, um erst mal zu sehen, was grob so reinkommt. Beim ebusd wissen wir schon, dass das besser "complex" betrachtet wird, und klatschen ein attrTemplate drauf mit bridgeRegexp und "complex". Dann sind zum einen sowieso die "simple"-Einträge in der readingList weg (und werden "complex" neu angelegt), und zum anderen dürfte m.E. dahinter ruhig dann "complex" angelegt werden.
Da, wo wir das nicht benötigen, können wir auch die readingList per attrTemplate "bereinigen" (ich würde im Moment aber eher dazu tendieren, das einheitlich zu lassen, was aber mit dem Thema hier nicht unmittelbar was zu tun hat)
ZitatFrage: War das schon immer so, dass MQTT2_CLIENT nach den ersten beiden Elementen des Topic-Trees die Geräte-CID vergibt? (dann war die bisherige bridgeRegexp im 00-template schon immer ziemlicher Unsinn
Weiss nicht genau, was du meinst.
CID ist mWn:
- bei MQTT2_SERVER das "echte" MQTT-clientId
- bei MQTT2_CLIENT das clientId Attribut oder der eigene Name
- bei bridgeRegexp wird es explizit spezifiziert.
Zitat von: rudolfkoenig am 05 März 2019, 12:33:19
Weiss nicht genau, was du meinst.
Hatte am WE etwas rumgetestet, meine Beobachtungen habe ich mal hier zusammengefaßt: https://forum.fhem.de/index.php/topic,98126.msg915029.html#msg915029 (https://forum.fhem.de/index.php/topic,98126.msg915029.html#msg915029)
Es geht hier nur um MQTT2_CLIENT (und auch etwas darum, was MQTT2_DEVICE via bridgeRegexp weiterleitet (in diesem 2. Fall ist es egal, welches IO vorgeschaltet war)), MQTT2_SERVER kennt die CID des Ausgangsgeräts, das erleichtert es in der Regel (wenn man nicht "weiterleitet"), weil die Infos dann im "richtigen" Device landen.
Danach: entfernt MQTT2_CLIENT erst mal die CID-Info und erstellt für jede reinkommende message ein neues Gerät, die sich in den ersten zwei Elementen des TopicTrees unterscheidet. Als CID für die neuen Geräte wird dann jeweils $1_$2 aus den ersten beiden Elementen des topictrees gebildet. (Um den Teil $1_$2 ging es, das scheint mir ganz früher nicht so gewesen zu sein). Gibt es die CID schon, wird die readingList erweitert (as usual).
Wird via MQTT2_DEVICE irgendwas gebrückt, muß ja eine neue CID in der bridgeRegexp stehen (und bridgeRegexp "vorne" mind. $1 zurückliefern; das könnte btw. auch in der cref stehen; ich hatte erst gedacht, das ist ein einfaches regex-Matching und versucht, das hart zu codieren. In Verbindung mit einer vorangestellten [^:]+[:]-bridgeRegexp im 00_Bridge-MQTT2_Device hat das zu sehr seltsamen neuen Geräten geführt ;D ).
Ich behaupte, in diesem Fall ist gar keine Magie (dh versteckte Logik) vorhanden, man muss in bridgeRegexp immer ein CID spezifizieren.
Diese kann auf dem vorherigen Regexp zugreifen, wenn man da mit () die $1, etc Variablen befuellt hat, muss aber nicht.
Im cref Beispiel wird $1 wg. ([A-Za-z0-9]*) befuellt, das ist der "normale" Perl-Regexp-Mechanismus:
Zitatattr zigbee2mqtt bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
Zitat von: rudolfkoenig am 05 März 2019, 16:12:17[...]muss aber nicht.
Von Magie hatte ich nicht gesprochen, oder? (lach)
Ich hatte Versuche gemacht ohne $1-Rücklieferung (und auch ohne $1 in der Ergebnis-CID). Das hatte nicht funktioniert. Auch das Zusammenfassen mit normalen regex-Ausdrücken wie "(tele|cmnd)/([^/]+)[/].*" lieferte keine zufriedenstellenden Ergebnisse.
(Da wir grade dabei sind: der ebusd liefert auch irgendwelche seltsamen topictrees mit einem Punkt darin, und vielleicht auch einem "\" vor dem Punkt; das funktionierte irgendwie gar nicht richtig in der bridgeRegexp, das habe ich aber erst mal vertagt. Bei Interesse kann dich Reinhart ja mal auf das Testsystem lassen, ich habe mir da keine verbose 5-logs gezogen; habe ich erst hinterher gemerkt, dass das vielleicht hilfreich gewesen wäre, war aber zu dem Zeitpunkt erst mal nicht mein Interessenschwerpunkt gewesen...)
ZitatAuch das Zusammenfassen mit normalen regex-Ausdrücken wie "(tele|cmnd)/([^/]+)[/].*" lieferte keine zufriedenstellenden Ergebnisse.
In solchen Faellen brauche ich konkrete Werte: Topic+Message, bridgeRegexp, und vlt. was Du erreichen willst.
Und auf fremde System will ich lieber nicht :)
Zitat von: rudolfkoenig am 05 März 2019, 16:26:47
In solchen Faellen brauche ich konkrete Werte: Topic+Message, bridgeRegexp, und vlt. was Du erreichen willst.
Und auf fremde System will ich lieber nicht :)
Dachte ich mir, wie gesagt, ich hatte zu dem "Punkte"-Thema leider vergessen, die Daten abzugreifen, hole ich ggf. bei Gelegenheit nach.
Der ebus sendet beim Start des Dienstes bestimmte Servicedaten der Geräte einmalig, wobei da im ersten Teil des Topic-Strings dann ein Punkt und Zahlen auftauchen. Diese wollte ich auch an das ebus-Gerät brücken...
Bei "(tele|cmnd)/([^/]+)[/].*" handelt es sich um Tasmota-publishes. Jetzt finden sich halt beide Elemente gesondert in meinem bridgeRegexp-Vorschlag im ersten Beitrag des vorhin verlinkten Threads. Auch da habe ich keine Daten, da ich weder einen Tasmota-ESP habe noch eine CLIENT-Installation (lovl....).
Der Vorschlag sieht grade so aus:
attr MQTT2_testsystemMQTT2CLIENT bridgeRegexp tele[/]([^/]+)[/]?.*:.* "$1"\
cmnd[/]([^/]+)[/]?.*:.* "$1"\
shellies[/]([^/]+)[/]?.*:.* "$1"\
(ESPClient_[^/]+)[/]?.*:.* "$1"\
(ebus[^/])[/]([^/]+)[/].*:.* "$1"(sehe grade, dass evtl. ein "+" Sinn machen könnte, also das letzte Element so:
ebus[^/]+)[/]([^/]+)[/].*:.* "$1"(Mist, ich weiß grade nicht mehr, ob ich das auch ausgetetet hatte; muß evtl. tatsächlich Reinhart nochmal um Zugang zu dem Testsystem fragen, auch wenn ich sowas auch nicht besonders gerne mag.)
habe gerade wieder beide Ports mit gleichen Passwörtern geöffnet! Du kannst jederzeit aufs Testsystem mit dem eBus drauf!
Ich nehme an, Rudis Änderungen sind am morgigen Update dann verfügbar.
LG
Reinhart
So, habe die Dateien jetzt aus dem svn installiert:
Zitat00_MQTT2_CLIENT.pm 18794 2019-03-05 10:56:08Z rudolfkoenig
10_MQTT2_DEVICE.pm 18794 2019-03-05 10:56:08Z rudolfkoenig
00_MQTT2_SERVER.pm 18794 2019-03-05 10:56:08Z rudolfkoenig
An dem MQTT2_DEVICEs gibt es nach wie vor nur 0|1 für autocreate.
Habe das jetzt mal mit auf 1 und gelöschtem Attribut am MQTT2_Bridge-Device versucht, aber es gibt keine erweiterten json2nameValue-Angaben in den readingLists. Kann es sein, dass der Code von DEVICE da noch unvollständig ist in den Attribut-Optionen?
(@Reinhart: trotzdem habe ich jetzt noch etwas mit den bridgeRegexp-Angaben rumgespielt; das scheint jetzt noch besser zu sein, allerdings immer noch nicht perfekt. Gibt es eine Erklärung, warum im Moment überhaupt keine Werte unter dem Zahlen-Topic-Pfad kommen?)
Muß/will jetzt dann weg, werde das daher an der Stelle mal abbrechen.
Thx @all!
wenn du die ".8" meinst, dann restarte bitte den eBus Dämon in der Konsole (sudo service ebusd stop/start), beim Scan schickt er dann den besagten String.
Sollten aber auch bei "ebusctl scan full" (in der Konsole) kommen, dann brauchst den Dämon nicht neu starten. Er schreibt zwar gleich "done" aber der Scann läuft im Hintergrund schon fast 1-2 Minuten. Mit "ebusctl i" siehst du dann ob der Scan erfolgreich war und die CSV Files gefunden hat und da steht dann auch die "0.8" die dann im JSON String einmal daher kommt.
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
Kein Angst, es passiert im Heizsystem nichts weil dies am produktiven System läuft. Dieser Dämon bedient nur den Testadapter und ist bis auf den eBus isoliert.
LG
so sieht der JSON String aus der vom eBus gesendet wird.
Client mosqsub/11470-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.08/', ... (126 bytes))
ebusd/scan.08/ {
"MF": {"value": "Vaillant"},
"ID": {"value": "BAI00"},
"SW": {"value": "0518"},
"HW": {"value": "7401"}}
Client mosqsub/11470-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.08/id', ... (211 bytes))
ebusd/scan.08/id {
"prefix": {"value": ""},
"year": {"value": ""},
"week": {"value": ""},
"product": {"value": ""},
"supplier": {"value": ""},
"counter": {"value": ""},
"suffix": {"value": ""}}
Client mosqsub/11470-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.15/', ... (126 bytes))
ebusd/scan.15/ {
"MF": {"value": "Vaillant"},
"ID": {"value": "43000"},
"SW": {"value": "0215"},
"HW": {"value": "2002"}}
Client mosqsub/11470-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.15/id', ... (239 bytes))
ebusd/scan.15/id {
"prefix": {"value": "21"},
"year": {"value": "11"},
"week": {"value": "09"},
"product": {"value": "0020028515"},
"supplier": {"value": "0907"},
"counter": {"value": "006374"},
"suffix": {"value": "N5"}}
LG
ZitatKann es sein, dass der Code von DEVICE da noch unvollständig ist in den Attribut-Optionen?
Wie im anderen Thema geschrieben: MQTT2_DEVICE bleibt zunaechst unveraendert.
Das neue Wert (complex) kann nur im MQTT2_CLIENT oder MQTT2_SERVER gesetzt werden.
Zitat von: rudolfkoenig am 05 März 2019, 21:07:49
Wie im anderen Thema geschrieben: MQTT2_DEVICE bleibt zunaechst unveraendert.
Das neue Wert (complex) kann nur im MQTT2_CLIENT oder MQTT2_SERVER gesetzt werden.
OK, sorry, hatte ich erst nicht richtig interpretiert...
Nach etwas Rumprobieren im Testsystem finde ich das auch hinreichend, wenn man das am IO einstellen kann. Wem die Ergebnisse nicht gefallen, kann ja immer noch hergehen, und die ihm nicht genehmen Devices nach Umstellung des Attributs am IO eine neue readingList einfangen lassen. Paßt also...
Daher erst mal wieder: DANKE!