A_00_MQTT2_CLIENT_general_bridge: Änderung der bridgeRegexp u.a.?

[Beta-User]

Hallo zusammen,

dank @Reinhart hatte ich am WE mal Gelegenheit, mit einer MQTT2_CLIENT-Installation zu spielen.

Vorhanden war ein Tasmota-Device und ein ebus-Gerät (Details zu diesem Aspekt hier), den Shelly und den ESPEasy habe ich mal dazuerfunden, der hat dabei jedenfalls nicht gestört, sollte aber auch funktionieren . (Nicht nur) für die Tasmotas sollte das dazu führen, dass sich eine MQTT2_CLIENT-Installation damit für die damit erfaßten Geräte ähnlich verhält wie eine mit MQTT2_SERVER (v.a., was die Vergabe der CID's angeht).

Code Auswählen Erweitern

attr MQTT2_testsystemMQTT2CLIENT bridgeRegexp tele[/]([^/]+)[/]?.*:.* "$1"\
  cmnd[/]([^/]+)[/]?.*:.* "$1"\
  shellies[/]([^/]+)[/]?.*:.* "$1"\
  (ESPClient_[^/]+)[/]?.*:.* "$1"\
  (ebus[^/]+)[/]([^/]+)[/].*:.* "$1"
(Nur für den Fall, dass das jemand auffällt: das einzige Element der bisherigen bridgeRegexp ist mit Absicht rausgefallen; die war schlicht wirkungslos ).
Meine Bitten in dem Zusammenhang:
- Weitere Tester wären willkommen, bevor ich das ins svn einchecke .
- Wenn jemand vor dem Hintergrund der obigen Beispiele jetzt Ideen haben sollte für weitere passende Elemente: Her damit...

Eine weitere Überlegung wäre, das Device dann ggf. auch in denselben Raum und dieselbe Gruppe zu verschieben wie das zugehörige IO-Device. Da damit aber - bei Fehlen - zwingend eine Abfrage/Neuvergabe verbunden wäre, wollte ich dazu eure Meinungen hören. Meine eigene Tendenz im Moment: Raum ja, Gruppe nein.

Gruß,

Beta-User

Edit: bridgeRegexp für ESPEasy@MQTT erweitert...
EDIT2: ursprüngliche Version für ebusd:

Code Auswählen Erweitern

(ebus[^/])[/]([^/]+)[/].*:.* "$1"Es kann sein, dass die geänderte Fassung nicht funktioniert...

[RaspiLED]

Hi,
Daumen hoch und falls der Raum leer ist halt MQTT als default!?
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[DasQ]

Ich kann dir noch nicht wirklich folgen, sag aber mal einfach ja. (In der Vergangenheit haben wir oft vom selben geredet, aber andere Worte und Begrifflichkeit für ein und das selbe verwendet)

Und zum testen, ich bin natürlich dabei, mit inzwischen über 15 MQTT2 Clients. (12 im produktiv Einsatz, der Rest in ständiger Entwicklung und stetig mehr werdend).

[Beta-User]

Habt ihr die bridgeRegexp jetzt schon getestet oder nicht?
Liest sich wie: haben's gelesen, finden es logisch, aber getestet hab' ich's noch nicht...

Daher eine Anleitung für ein Test-FHEM (aktuelle MQTT2-Module, versteht sich):
MQTT2_CLIENT-Device definieren, ein sinnvolles clientID-Attribut dafür vergeben (!) und einfach mal autocreate laufen lassen (ganz ohne "erstes bridge-MQTT2_DEVICE"!)...

Dann werden lauter MQTT2_DEVICEs angelegt, alles, was sich in den ersten beiden topic-tree-Angaben unterscheidet, ist jeweils ein eigenes Device (also: eine Tasmota-Hardware wird als zwei Geräte angelegt, wegen "cmnd" und "tele" vorneweg). Die CID der Geräte besteht jeweils aus den beiden ersten Angaben des topic-trees, verbunden mit einem "_"? Als "associatedWith"-Device wird das MQTT2_CLIENT-Device ausgewiesen?

Dann speichert das mal weg, deaktiviert autocreate am CLIENT, wendet das allg. 00-template an und ändert dann die bridgeRegexp wie im ersten Beitrag vorgeschlagen.
Dann bitte alle anderen MQTT2_DEVICES löschen, save, shutdown restart (nur zur Sicherheit), danach autocreate am CLIENT wieder aktivieren.

Ergebnis sollte sein:
Alles, was der bridgeRegexp entspricht, hat ggf. eine vereinfachte CID erhalten, die Tasmotas werden nicht mehr als zwei Geräte angelegt und alles, was der bridgeRegexp nicht entspricht, erhält (wie bisher) die oben genannte CID mit dem "_" und associatedWith mit dem CLIENT; die Geräte aus der bridgeRegexp sind dagegen "associatedWith" mit dem Device, das als General-Bridge genutzt wird?

Wenn das so ist, dann ist (fast) alles gut... (das einzige, was sich in dem Zusammenhang ggf. seltsam verhält ist der ebusd; der sendet Infos auch mit einem Punkt im Topic-tree, die Infos von dem landen ggf. in der GeneralBridge?!?.)

Ach so, noch was: Ich hatte auch Tests gemacht, und die bridgeRegexp mal mit "[^:]+:" begonnen (auch in der optionalen Variante "[^:]+:?"). Das "scheint" (beides) zu funktionieren, ergibt aber m.E. am Ende doch keine sinnvollen Strukturen. Wer es testen will, beachte bitte die sich ergebenden CID's und associatedWith-Angaben .

Bin mal gespannt auf eure Rückmeldungen.

[Beta-User]

So, ein update dazu:

Eben habe ich die überarbeitete Fassung für die GeneralBridge ins svn geschoben.

Die berücksichtigt vor allem auch die Erkenntnisse aus diesem Thread und holt sich jetzt ihren "room" aus dem IO.

Es sind auch einige Anwendungshinweise drin, insbesondere erscheint es mir sehr sinnvoll, erst eine copy des "Sammeldevices" anzulegen, das MQTT2_CLIENT bei aktiviertem autocreate generiert, und dann vor allem dessen DEF zu ändern.
Sonst landen wieder alle neuen readingList-Einträge in der GeneralBridge, was die Sache m.E. unübersichtlich macht. Ein Beinbruch ist es aber auch nicht.

Bin mal auf euer feedback gespannt.