[gelöst] MQTT2 (CLIENT): autocreate und mehrere Geräte mit bridgeRegexp

[Beta-User]

Hallo Rudi,

jetzt habe ich mal versucht, diese bridgeRegexp-Geschichten für den ebus zu ordnen. Dabei hatte ich allerdings ziemliche Schwierigkeiten, reproduzierbare Ergebnisse zu erzielen, genauer gesagt, ist mir das nicht gelungen...

Beispiel: drei Neustarts, jeweils mit _identischer cfg_ => jedesmal andere Geräte als Ergebnis, Screenshots anbei
Im wesentlichen waren beim Start vorhanden: ein MQTT2_CLIENT-Gerät (mit autocreate complex, clientId=mosqCLIENT), zwei MQTT2_DEVICEs (und ein drittes, ein Tasmota):

Code Auswählen Erweitern


define MQTT2_mosqCLIENT MQTT2_DEVICE mosqCLIENT
attr MQTT2_mosqCLIENT IODev ebusMQTT
attr MQTT2_mosqCLIENT autocreate 1
attr MQTT2_mosqCLIENT bridgeRegexp [^:]+:?tele[/]([^/]+)[/].*:.* "$1"\
[^:]+:?cmnd[/]([^/]+)[/].*:.* "$1"\
[^:]+:?shellies[/]([^/]+)[/].*:.* "$1"\
[^:]+:?(ESPClient_[^/]+)[/].*:.* "$1"\
[^:]+:?(ebus.)[^/]*[/][^/]+[/].*:.* "$1"\
mosqCLIENT:([^/]+)/([^/]+)/.*:.* "$1_$2"

Code Auswählen Erweitern


define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd bridgeRegexp .*ebus.*/bai/.*:.* "ebusy_bai"\
.*ebus.*/broadcast/.*:.* "ebusy_bai"\
.*ebus.*/([\d]+)/.*:.* "ebusy_$1"

Nachdem das nicht wollte, war die Vermutung, dass es evtl. daran liegt, dass die Geräte durch die bridgeRegepx's hintereinandergeschaltet wären und daher die Probleme kommen. Also habe ich versucht, die brigeRegexps in einem Gerät (mosqCLIENT) zusammenzuführen:

Code Auswählen Erweitern

attr MQTT2_mosqCLIENT bridgeRegexp [^:]+:?tele[/]([^/]+)[/].*:.* "$1"\
[^:]+:?cmnd[/]([^/]+)[/].*:.* "$1"\
[^:]+:?shellies[/]([^/]+)[/].*:.* "$1"\
[^:]+:?(ESPClient_[^/]+)[/].*:.* "$1"\
[^:]+:?(ebus.)[^/]*[/]([\d]+)[/].*:.* "$1y_$2"\
[^:]+:?(ebus.)[^/]*[/]bai[/].*:.* "$1y_bai"\
[^:]+:?(ebus.)[^/]*[/]broadcast[/].*:.* "$1y_bai"\
[^:]+:?(ebus.)[^/]*[/][^/]+[/].*:.* "$1
(hier habe ich das letzte Element von oben auch gleich weggelassen, da das nur zu noch mehr seltsamen Geräten geführt hat...)

Leider habe ich auch mit dieser Variante keine Ergebnisse, die konstent aussehen, mal landen bei Neustarts (auch jeweils wieder mit derselben config) auch die "bai"-Infos im "ebusd"-Gerät, mal im richtigen. Die Elemente habe ich auch mehrfach umsortiert, kann aber nach wie vor keine Logik hinter dem erkennen, warum mal das eine und mal das andere passiert...

Anbei ein Log, das zwei Starts des FHEM-Servers enthält; beim ersten war hinsichtlich des "bai"-Topics alles "richtig", (die 430-er Angaben sind aber im falschen Device gelandet), beim zweiten mal finden sich im "ebus"-Gerät auch "ebus_bai"-Elemente in der readingList.

Ich bin jetzt einigermaßen ratlos und für jeden Tip dankbar, wie das sinnvoll geordnet werden kann...

[rudolfkoenig]

- die bridgeRegexp Zeilen aller MQTT2_DEVICE Instanzen werden in einem globalen Hash gespeichert. Damit ist es egal, an wievielen Stellen man die Regexps eintraegt.
- wenn man das gleiche Regexp an mehreren Stellen verwendet, dann gewinnt der letzte Eintrag (das Eintragen ins Hash ist sequentiell).
- diese Regexps aus dem hash werden in zufaelliger Reihenfolge (keys %hash) gegen topic:message und cid:topic:message geprueft. Sobald es einen Treffer gibt, wird nicht mehr weitergreprueft.
- bridgeRegexp/autocreate kommt nur dann zum Zuge, wenn keiner der readingsList Attribute ein Treffer signalisiert hat.

Ich habe MQTT2_DEVICE erweitert, damit solche Probleme leichter entdeckt werden koennen. Bei

Code Auswählen Erweitern

mosquitto_pub -i xx -t ebusd/bai/Status01 -m blawird mit deiner bridgeRegexp ins FHEM-Log folgende Zeile reingeschrieben:

2019.03.06 18:08:19 1: MULTIPLE MATCH in bridgeRegexp for xx:ebusd/bai/Status01:bla: [^:]+:?(ebus.)[^/]*[/]bai[/].*:.*,[^:]+:?(ebus.)[^/]*[/][^/]+[/].*:.*

Es wird aber nicht abgebrochen, sondern wie bisher, einer zufaellig gewaehlt.

[Beta-User]

Puh, schwere Geburt....

Danke für die Erläuterungen, das hat mir erst mal sehr weitergeholfen, ich hätte nicht vermutet, dass es tatsächlich Zufälligkeiten sind .

Eine - wie es aussieht auch über der Zeit verläßliche - Zuordnung habe ich jetzt so hinbekommen:

Code Auswählen Erweitern

(tele|cmnd)[/]([^/]+)[/].*:.* "$2"
shellies[/]([^/]+)[/].*:.* "$1"
(ESPClient_[^/]+)[/].*:.* "$1"
(ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"

Wie dem auch sei, ich hatte dabei einige Erkenntnisse, die vermutlich dazu führen, dass das General-Bridge-template zukünftig anders aussieht.
Es sollte sein: rename und Vergabe einer anderen clientId.
Dann werden nämlich weiterhin unbekannte topic-Pfade in einem neuen Device angelegt, auf die man dann "unbesorgt" wieder mit einem template "zerstören" kann. Dann müßten wir nicht alle user mit einem sehr komplexen bridgeRegexp-Ausdruck in der GeneralBridge behelligen, und z.B. die ebus-Dinge könnten dann einfach(er) am ebusd-Gerät zentral gesetzt werden, was für user von MQTT2_SERVER einfacher sein dürfte.

[Beta-User]

Hallo Rudi,

ich greif das hier nochmal auf, weil die Stichworte im Topic passen, auch wenn das Folgende mit der Lösung des Ausgangsproblem nichts zu tun haben dürfte....

Geht um die Probleme, die onkel-tobi hier im Zusammenhang mit der Nutzung von "Smarthome/..."-Topicstrukturen geschildert hat.

Ich wollte da eine bridgeRegexp vorschlagen, die auch den "Followern" dieses gelegentlich unglückliche Vorschläge machenden Videobloggers helfen könnte, und bin dabei aber kläglich gescheitert, weil sich die Kombi CLIENT/bridgeRegexp anders verhält wie vermutet.

Kurz zusammengefaßt: Hat man eine Topicstruktur, die mit "/" beginnt, berücksichtigt autocreate eingehende Messages unter dieser Struktur nicht mehr, sobald man irgendein bridgeRegexp definiert. (Vorher klappt das...)

Folgende Konstellation hatte ich genutzt, um zu testen, was passiert:
- Hauptsystem mit MQTT2_SERVER,
- Testsystem mit MQTT2_CLIENT, subscription geht auf MQTT2_SERVER (ohne weitere Einschränkung, kein subscr.-Attribut gesetzt)
- In der Ausgangslage ist kein MQTT2_DEVICE vorhanden, es wird aber natürlich sofort eines erstellt, weil alle vorhandenen MQTT2-Devices vom Hauptsystem in das Testsystem gemappt werden (wie gesagt eines, mit allen Zopiczweigen in der readingsList).

Sende ich jetzt mit mosquitto_pub was an MQTT2_SERVER unter "/Smarthome/..." gibt es auch ordnungsgemäß einen neuen readingList-Eintrag auf dem Testsystem, wie üblich wird die CID des CLIENT vorneweg eingetragen.
Wende ich jetzt das General-Bridge-Template an, wird bei "/Smarthome/..."- publishs nichts mehr erstellt; nicht im (Ausgangs-) Sammeldevice, nicht in der General Bridge, und es gibt auch dann kein neues Device, wenn ich die bridgeRegexp weniger komplex gestalte. Nehme ich testweise vorne den "/" raus, geht alles wieder, und auch die vorgeschlagene bridgeRegexp funktioniert dann.

Es kommt mir so vor, als ginge die Message in dieser Konstellation (also sobald irgend eine bridgeRegexp im Spiel ist) komplett verloren, sobald der "Durchlauf" durch die bridgeRegexp stattgefunden hat.

(Ich hoffe, das ist halbwegs verständlich geschildert; logs etc. habe ich erst mal keine, kann ich aber ggf. über das WE nachliefern, sofern benötigt; und mit der Frage, ob diese eventuell nicht standardkonforme Topic-Struktur jetzt sinnvoll ist, den Regeln entspricht usw., habe ich mich auch nicht beschäftigt; das ist halt leider so in der Welt und macht potentiellen Umsteigern das Leben schwer...)

[rudolfkoenig]

Kann ich nicht nachvollziehen (s.u.), brauche ein Step-Fuer-Step Anleitung.

Was ich gemacht habe:

Code Auswählen Erweitern

% mosquitto &
fhem> define mc MQTT2_CLIENT localhost:1883
fhem> attr mc autocreate simple
fhem> define ac autocreate
% mosquitto_pub -i SmartHome -t /SmartHome/Lampe/1 -m ON
=> MQTT2_mc wird angelegt.

fhem> attr MQTT2_mc attrTemplate A_00_MQTT2_CLIENT_general_bridge
% mosquitto_pub -i SmartHome -t /SmartHome/Lampe/1 -m OFF
=> MQTT2_mc kriegt automatisch:
- Attribut ReadingList: mc:/SmartHome/Lampe/1:.* Lampe_1
- Reading Lampe_1 OFF


[Beta-User]

Danke für's Nachstellen. Hab's eben auch mit einem Mosquitto mit demselben positiven Ergebnis nachgestellt.
K.A., warum die bisherigen Versuche erfolglos waren, sorry für den Aufwand...