MQTT2 Verständnisproblem

[antonwinden]

Versuche gerade auf MQTT2 Server umszustellen. Da verstehe ich derzeit nur mehr Bahnhof:
Vorher hab ich auf einer 2. Fheminstanz MQTT definiert und dann eine Bridge mit den Daten angelegt:

Code Auswählen Erweitern

Internals:
   DEF        ToniRedmi
   FUUID      5fe35065-f33f-95d3-deeb-03737be6fc56578e
   IODev      oldBroker
   NAME       mqtt_ToniRedmi
   NOTIFYDEV  ToniRedmi
   NR         26
   NTFY_ORDER 50-mqtt_ToniRedmi
   STATE      ???
   TYPE       MQTT_BRIDGE
   publishState SLAVE1/ToniRedmi/state
   READINGS:
     2021-02-15 15:25:34   transmission-state subscription acknowledged
   message_ids:
   publishReadings:
     device_name SLAVE1/ToniRedmi/+device_name
     model      SLAVE1/ToniRedmi/+model
     presence   SLAVE1/ToniRedmi/+presence
     state      SLAVE1/ToniRedmi/+state
   subscribe:
     SLAVE1/ToniRedmi/state/set
   subscribeExpr:
     ^SLAVE1\/ToniRedmi\/state\/set$
   subscribeQos:
     SLAVE1/ToniRedmi/state/set 0
   subscribeSets:
     SLAVE1/ToniRedmi/state/set:
       cmd       
       name       
Attributes:
   IODev      myBroker
   publish-topic-base SLAVE1/ToniRedmi/+
   publishReading_.absenceThresholdCounter SLAVE1/ToniRedmi/+.absenceThresholdCounter
   publishReading_.presenceThresholdCounter SLAVE1/ToniRedmi/+.presenceThresholdCounter
   publishReading_device_name SLAVE1/ToniRedmi/+device_name
   publishReading_model SLAVE1/ToniRedmi/+model
   publishReading_presence SLAVE1/ToniRedmi/+presence
   publishReading_state SLAVE1/ToniRedmi/+state
   publishState SLAVE1/ToniRedmi/state
   subscribeSet SLAVE1/ToniRedmi/state/set
und auf dem anderen Fhem das MQTT Device über ein externen mosquitto und das für alle Devices getrennt (obwohl sie von einem Fhem kommen - insgesamt hab ich 4 Fhem auf verschiedenen Plätzen mit Funktionen die ich von anderen aus steuern will) die ich sehen und steuern wollte.
Mit dem MQTT2 Server auf Fhem kriege ich aber alle Bridges die vom anderen Fhem kommen in ein automatisch angelegtes Device zusammengewürfelt.
schaut dann z.B. so aus:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        myBroker
   DEF        myBroker
   DEVICETOPIC MQTT2_myBroker
   FUUID      6029813c-f33f-d8e8-8a6c-bf6c68d16047d798
   IODev      myBroker
   LASTInputDev myBroker
   MSGCNT     1920
   NAME       MQTT2_myBroker
   NR         7804
   STATE      165.940 W
   TYPE       MQTT2_DEVICE
   myBroker_MSGCNT 1920
   myBroker_TIME 2021-02-15 16:27:34
   READINGS:
     2021-02-15 16:26:50   KWH             24968.30 kw/h
     2021-02-15 16:27:34   getG1           165.940 W
     2021-02-15 16:27:34   last-sender     1/2/20
     2021-02-15 16:27:34   state           165.940 W
     2021-02-15 15:25:35   subscriptions   #
Attributes:
   IODev      myBroker
   readingList myBroker:SLAVE1/StromZaehlerOtto/state:.* state
myBroker:SLAVE1/StromAktuellWattOtto/state:.* state
myBroker:Watt/StromAktuellWattOtto/state:.* state
myBroker:SLAVE1/heuteberegnet/state:.* state
myBroker:/StromAktuellWattOtto/getG1:.* getG1
myBroker:/StromAktuellWattOtto/last-sender:.* last-sender
myBroker:/StromAktuellWattOtto/state:.* state
myBroker:/StromZaehlerOtto/getG1:.* getG1
myBroker:/StromZaehlerOtto/last-sender:.* last-sender
myBroker:/StromZaehlerOtto/state:.* state
myBroker:/StromZaehlerOtto/KWH:.* KWH
   room       MQTT2_DEVICE
was mache ich da falsch? Bzw wie krieg ich die readings da raus die ich haben will? Sollte nicht automatisch readings für jedes was in der readingslist ist angelegt werden? derzeit kommt alles in state an und weiter passiert nichts.
zusätzlich habe ich noch DELoCK Steckdosen über Mqtt angebunden. Hat mit externem mosquitto perfekt funktioniert - mit fhem mqtt2 Server ist das jetzt wesentlich komplexer und für mich nicht wirklich verständlich. Wenn ich als template tasmota_POW angebe dann kriege ich jede Menge unnötiger Readings und "webcmd on:off" muß ich erst anlegen damit ich sie schalten kann.
Irgendwie fehlt mir komplett der Plan oder auch nur eine verständliche Erklärung wie man von MQTT auf MQTT2 umsteigen kann wo anhand von praktischen Beispielen wie man das tatsächlich macht...
gruß anton

[Beta-User]

MAn. kommen die Fragen hauptsächlich daher, dass alles, was über eine "Quelle" kommt, bei MQTT2_SERVER dann in einem Device landet. Hier also alles, was von der 2. Installation kommt...

Erschwert wird das ganze dadurch, dass du MQTT_BRIDGE im Einsatz hast, obwohl du erst einsteigst...?

Was ich verstanden habe: Du willst getrennte FHEM haben und dann die Brücke zwischen beidem via MQTT herstellen, FHEM_A soll eine Art zentraler Instanz sein, auf der alles zusammenläuft, FHEM_B (bis _X) dient z.B. dazu, irgendwelche Hardware (ggf. wg. blocking-Themen) zu verwalten und dann die Ergebnisse an die Zentrale abzuliefern?

Dann würde ich folgendes setup empfehlen (warum da noch ein mosquitto genannt ist, verstehe ich nicht):
MQTT2_SERVER (M2S) auf FHEM_A (scheint ok zu sein)
MQTT2_CLIENT (oder 00_MQTT) auf FHEM_B, dazu aber MQTT_GENERIC_BRIDGE als "Vermittler".

Dann hast du das beschriebene Problem, dass alles, was von FHEM_B kommt in einem MQTT2_DEVICE landet. Das kannst du verhindern, indem du eine Art "Sortierdevice" dazwischenschaltest, ähnlich wie das für MQTT2_CLIENT im Wiki zu findende Device mit dem attrTemplate MQTT2_CLIENT_general_bridge. Das würde dann einfach alle Messages von Topics beginnend mit "SLAVE1/" in eigene Devices umleiten.

Falls du von irgendwo anders her noch Anweisungen via MQTT senden willst, brauchst du zusätzlich noch eine ignoreRegexp am M2S.
Das ganze wird ggf. etwas klarer, wenn du folgendes liest:
Etwas Theorie: https://forum.fhem.de/index.php/topic,116162.msg1104338.html#msg1104338 (nur der eine Beitrag)
Angewandte Praxis wäre dann ab hier zu finden: https://forum.fhem.de/index.php/topic,115279.msg1123309.html#msg1123309 (da gibt's dann auch noch ein paar Links zu anderen aktuellen Threads rund um MQTT_GENERIC_BRIDGE).

Generell: MQTT2_SERVER ist eher dafür gemacht, viele "Kleindevices" automatisiert zu verwalten und einem als Anfänger da das Leben zu erleichtern, wenn man eher komplexe Strukturen schaffen will, braucht es etwas mehr Handarbeit bzw. Hilfsmittel wie bridgeRegexp und ignoreRegexp.

[antonwinden]

Nicht ganz:
Ich hatte MQTT und MQTT Bridge mit externem mosquitto erfolgreich im Einsatz und das hat auch gut funktioniert . meine Probleme begannen erst als ich auf MQTT2 Server in Fhem umstieg. Hat lustigerweise ein paar Tage ohne Änderung an den liefernden Fhem Instanzen funktioniert warum auch immer.

Zu dem Link hab ich zuerst mal die Fragen:
was ist mqttGeneric?  wenn ich das so in mein Fhem eingebe gibt es eine Fehlermeldung das ich mqttGeneric zuerst definieren soll..
dann soll man sich um MQTT2_lb_mosquitto kümmern was natürlich wieder mit einer Fehlermeldung quittiert wird.
Es wird auch von einer MGB gesprochen nur nie gesagt was das sein soll...
ich fürchte da werden Dinge vorausgesetzt wo allerdings die Quelle nicht angegeben ist - nicht gerade zum Verständnis beitragend außer man weiß wo es herkommt.
Sorry wenn ich das so schreibe aber der Unterschied zur vorherigen funktionierenden externen mosquitto Lösung ist dermaßen groß und nicht so einfach nachvollziehbar - für mich derzeit eigentlich gar nicht...
danke anton

[Beta-User]

OK, dann mal viel Erfolg.

Btw.: bei dem Tasmota müßte das devStateIcon eigentlich ausreichend sein, um zu schalten; daher ist da webCmd im attrTemplate so spartanisch...

[rudolfkoenig]

MQTT2_SERVER ist eher dafür gemacht, viele "Kleindevices" automatisiert zu verwalten und einem als Anfänger da das Leben zu erleichtern,

Stimmt.

wenn man eher komplexe Strukturen schaffen will, braucht es etwas mehr Handarbeit bzw. Hilfsmittel wie bridgeRegexp und ignoreRegexp.

Oder man schaltet autocreate aus, und legt alle MQTT2_DEVICE Instanzen manuell an, genauso wie bei dem alten MQTT_DEVICE Modul.
Wegen attrTemplate hat man selbst mit dieser Methode deutlich weniger Arbeit.

[Beta-User]

Sorry, hatte das erst überlesen:

Zu dem Link hab ich zuerst mal die Fragen:
was ist mqttGeneric?  wenn ich das so in mein Fhem eingebe gibt es eine Fehlermeldung das ich mqttGeneric zuerst definieren soll..
dann soll man sich um MQTT2_lb_mosquitto kümmern was natürlich wieder mit einer Fehlermeldung quittiert wird.
Es wird auch von einer MGB gesprochen nur nie gesagt was das sein soll...
ich fürchte da werden Dinge vorausgesetzt wo allerdings die Quelle nicht angegeben ist - nicht gerade zum Verständnis beitragend außer man weiß wo es herkommt.
Sorry wenn ich das so schreibe aber der Unterschied zur vorherigen funktionierenden externen mosquitto Lösung ist dermaßen groß und nicht so einfach nachvollziehbar - für mich derzeit eigentlich gar nicht...
danke anton

Also: Diese Beiträge beschäftigen sich mit MQTT_GENERIC_BRIDGE, "mqttGeneric" könnte der Name dieses Devices sein, "MQTT2_lb_mosquitto" ist mit ziemlicher Sicherheit auch einfach ein (automatisiert erstellter) Device-Name.

MQTT_GENERIC_BRIDGE (kurz: MGB) an sich hat nichts mit den MQTT2-Modulen zu tun, es ist einfach ein Ersatz für MQTT_BRIDGE, der es erlaubt, eine 1:n-Zuordnung zu machen, statt für jedes einzelne FHEM-Device je eine Instanz des MQTT_BRIDGE zu erstellen. Das ganze noch garniert damit, dass man Topic und Payload recht universell vorverarbeiten kann und vieles an einer zentralen Stelle vorzubereiten. Die funktioniert auch mit 00_MQTT...
Wer eine etablierte Installation hat, auf der das alles mit MQTT_BRIDGE funktional ist, braucht da nichts umzustellen (es sei denn, er will weg von der Abhängigkeit von externen Perl-libs). Nur neu anfangen sollte man nicht mehr mit MQTT_BRIDGE...

[antonwinden]

Stimmt.
Oder man schaltet autocreate aus, und legt alle MQTT2_DEVICE Instanzen manuell an, genauso wie bei dem alten MQTT_DEVICE Modul.
Wegen attrTemplate hat man selbst mit dieser Methode deutlich weniger Arbeit.

Mag ja stimmen wenn es ein passendes Template gibt nur was ist wenn nicht? Bei der alten Version arbeitet man mit subscribeset und publishset nur was das bei MQTT2 entspricht habe ich bis jetzt nicht gefunden.
Ist sicher so das mit der neuen Versipon von vornherein mehr möglich ist nur ist es mühsam bis ziemlich frustrierend wenn die einfachen Funktionen gut versteckt oder einfach für einen Umsteiger vom "normalen" mqtt auf das "neue bessere" mqtt2 nur nach ewigen Suchen zu finden sind.
sorry anton

[Beta-User]

Der Spur nach:
die subscribe.*-Attribute aus der "alten Welt" entsprechen dem readingList-Attribut bei M2D (MQTT2_DEVICE), publish.*-Anweisungen schreibt man bei M2D in setList (oder nach getList, v.a., wenn es asynchrone Abfragen sind).

Dein ToniRedmi könnte dann in FHEM_A (vereinfacht) etwa so aussehen (RAW-Import):

Code Auswählen Erweitern


defmod MQTT2_ToniRedmi MQTT2_DEVICE
attr MQTT2_ToniRedmi setList\
absent SLAVE1/ToniRedmi/state/set absent\
present SLAVE1/ToniRedmi/state/set present
attr MQTT2_ToniRedmi readingList\
  SLAVE1/ToniRedmi/presence presence\
  SLAVE1/ToniRedmi/state state

Es gibt zum Ganzen zwischenzeitlich sehr viele Beispiele (in den attrTemplate), was eventuell auch unübersichtlich zu sein scheint, wenn man was spezielles sucht, aber man erhält in der Regel auch eine Antwort, wenn man eine Lösung für eine spezielle Situation sucht.

Deine Topic-Struktur hat halt m.E. den Nachteil, dass sie in Teilen zu flach ist (direkt der Device-Name ohne Quelle), außerdem scheint das Beispieldevice ToniRedmi zum einen viele (unnötige?) Infos weiterzusenden, und das teils doppelt (state). Sowas sollte man so oder so bereinigen bzw. von vornherein vermeiden, unabhängig von der konkreten Implementierung.

[antonwinden]

und nachdem ich auf der Seite die mir die Daten schickt für jedes Device einen eigenen Client eingerichtet habe ist es auch wie am Schnürchen gelaufen. Damit werden dann nicht alle Werte in ein Device zusammengewürfelt sondern nur die gewünschten Werte...
Darauf muß man allerdings erst kommen.
Danke
anton

[Beta-User]

Sorry, aber zumindest auf die Schnelle klingt das für mich nach einer reichlich verbogenen "Lösung" (oder eher nach einem üblen workaraound).

Vielleicht noch ein Hinweis zum Thema (MQTT2-) autocreate: Das Kriterium, nachdem die Geräte sortiert bzw. gefunden werden ist "CID". M2S sortiert - wie bereits erwähnt - (ohne weitere Vorgaben) alles in ein Device rein, was aus einer Quelle kommt. Daher klappt das mit den vielen separaten Clients, jeder meldet sich da eben mit "seiner" ClientID.

Wie du vielleicht bemerkt hast, war in meinem Beispiel-Device GAR KEINE CID angegeben, und auch die CientID-Angaben finden sich nicht in der readingList. Dann landen die Daten, die über die readingList-Topics dieses Devices kommen auch in diesem Gerät und sonst nirgends, und - mangels CID - auch nichts zusätzliches/anderes.

Will man Automatismen nutzen, ist es m.E. besser, entsprechende bridgeRegexp zu setzen, also ein M2D (mit der CID des einen Client auf der Gegenseite) als "Sortierdevice" zu verwenden, und dann anhand der Topic-Struktur "Pseudo-CIDs" zu erzeugen. Das würde dann z.B. so aussehen:

Code Auswählen Erweitern

attr MQTT2_myBroker bridgeRegexp \
  SLAVE1/([^/]+)/.*:.* "$1"
 

Das würde dir zumindest alle "auseinanderklamüsern", was über "SLAVE1/#" kommt.
Das Problem ist aber, dass das mit dieser sehr flachen Topic-Struktur nicht wirklich gut mit sowas umgehen kann, (und negative Regexe sind nicht so einfach):

Code Auswählen Erweitern

myBroker:/StromAktuellWattOtto/state

[antonwinden]

stimmt - mit bridgeRegexp ... erzeugt es dann für jedes ein eigenes Device.

Gibt es einen anderen Weg die Topic-Struktur anders zu gestalten?

danke anton

[Beta-User]

Gibt es einen anderen Weg die Topic-Struktur anders zu gestalten?

Na ja,die Topic-Struktur legst du ja mittels MQTT_BRIDGE "auf der anderen Seite" fest. Falls du also keine anderen Lösungen hast, die auf diese Topic-Struktur angewiesen sind, würde ich einfach empfehlen, das mittelfristig umzustellen. Wobei ich an der Stelle nochmal "Werbung" für MQTT_GENERIC_BRIDGE machen würde: Da kannst du sowas einfach an einer zentralen Stelle hinterlegen, das wäre dann _eine_ Änderung an $base gewesen (bzw. ggf. zwei, eine für sub, eine für pub)...
Von daher würde ich die Umstellung an den "entfernten FHEM" gleich nach MQTT_GENERIC_BRIDGE machen, wenn man's mal verstanden hat, ist das viel komfortabler als viele MQTT_BRIDGE-Devices, und da du dieses Modul (MQTT_BRIDGE) kennst, sollte es eigentlich überhaupt kein Hexenwerk sein.

[antonwinden]

hab ich schon alle auf generic-bridge umgestellt. allerdings ohne viel einzustellen. Bei den einfachen Strukturen wie Anzeige der aktuell konsumierten Watt hat es auf Anhieb funktioniert.
für mehr werde ich mich mal einlesen und experimentieren müssen
danke anton

[Beta-User]

Wow, das ging wirklich fix...

Falls Fragen sind: bitte melden!