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:
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:
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
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.
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
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...
ZitatMQTT2_SERVER ist eher dafür gemacht, viele "Kleindevices" automatisiert zu verwalten und einem als Anfänger da das Leben zu erleichtern,
Stimmt.
Zitatwenn 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.
Sorry, hatte das erst überlesen:
Zitat von: antonwinden am 15 Februar 2021, 17:24:27
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...
Zitat von: rudolfkoenig am 15 Februar 2021, 17:58:29
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
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):
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.
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
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:
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):
myBroker:/StromAktuellWattOtto/state
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
Zitat von: antonwinden am 16 Februar 2021, 17:30:02
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.
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
Wow, das ging wirklich fix...
Falls Fragen sind: bitte melden!