MQTT in FHEM the easy way

Begonnen von TL60, 21 Januar 2021, 13:14:05

Vorheriges Thema - Nächstes Thema

TL60

Hallo
ich hoffe mal das ich das hier richtig plaziert habe, ansonsten Bescheid sagen, weil es wäre vielleicht auch im Wiki Bereich passend.
Inspiriert durch diesen https://forum.fhem.de/index.php/topic,117960.msg1124003.html#msg1124003 Forumsbeitrag habe ich mich mal hingesetzt und versucht einen für unbedarfte Einsteiger passenden Leitfaden für den ersten Kontakt mit MQTT zu schreiben
ZitatMQTT in FHEM – the (very) easy Way

Allen die Geräte oder Gerätegruppen, wie z.Bsp. Zigbee2MQTT oder Tasmota, um nur die bekanntesten zu nennen, über MQTT in FHEM einbinden wollen, sei die MQTT2_... Familie (MQTT2_SERVER, MQTT2_CLIENT, MQTT2_DEVICE) sehr ans Herz gelegt. Diese Module machen die Integration von MQTT-fähigen Geräten sehr einfach.
Normalerweise reicht ein define [meinmqttgeraet] MQTT2_SERVER global vollkommen aus. Danach dann in den Einstellungen des Gerätes, welches in FHEM eingebunden werden soll die notwendigen MQTT Einstellungen vornehmen. Unter Host, Broker oder  Server etc. die IP-Adresse des FHEM Rechners eintragen und das Gerät neu starten – Fertig!
Das gut ausgeklügelte Autocreate System von MQTT2 legt in den allermeisten Fällen automatisch ein neues Gerät an, welches man an seine eigenen Bedürfnisse anpassen kann. Thats all.
Einzelheiten findet man im FHEM-Wiki zu den einzelnen Modulen. Hier sind dann auch Informationen zu finden zum attrTemplate, welches die weiter Einbindung in FHEM nochmal vereinfacht.
Aber auch Benutzer, die vor längerer Zeit die Einbindung mit externen MQTT-Brokern, wie als Beispiel  Mosquitto mit den Modulen mqtt und MQTT_Device gemacht haben, sei bei der Neuanlage von Geräten die MQTT2 Variante empfohlen, wenn man  einige Punkte berücksichtigt kann man MQTT2 auch parallel zu einer existierenden Mosquitto Anbindung nutzen. Vor allen Dingen ist hierbei darauf zu achten, das, sollte Mosquitto oder jeder andere Broker und FHEM  auf derselben Hardware laufen für einen von beiden der Port zwingend zu ändern ist. Am einfachsten geht das, indem man das define des MQTT2_Server ändert, also anstatt wie oben mit Standartport angegeben sowas wie:  define [meinmqttgeraet] MQTT2_SERVER 1884 global. Wichtig ist die Angabe des Portes (hier1884). Dieser muss frei sein und sich vom Port des anderen MQTT-Broker ( Standard:1883) unterscheiden. Natürlich ist diese Portangabe auch im neu anzulegenden Gerät einzutragen.
Sollte die Einbindung von neuen Geräten so geklappt haben, kann man Stück für Stück auch seine vorhandenen Geräte umziehen indem man einfach im Gerät die Einstellungen für MQTT auf den MQTT2_Server ändert.
Hierzu hätte ich gerne Meinungen gehört, ob sowas sinnvoll ist ober ob man das besser sein lässt und natürlich wohin es soll. Also Feuer frei  :)
Gruß Thomas

TL60

Dann schreibe ich mir selber mal  ;)
Ich habe zwischendurch gesehen das Beta-User schon einiges von dem was ich geschrieben hatte, vorher im Wiki zu MQTT ergänzt hatte, das war mir durchgegangen, sorry dafür. Was aber bleibt ist der 2.Teil mit dem (vorrübergehenden) Parallelbetrieb Mosquitto FHEM2_SERVER. Ich denke das diese Möglichkeit auch deutlich dargestellt werden soll. Ich habe gestern abend in diesem Thread https://forum.fhem.de/index.php/topic,114027.msg1123224.html#msg1123224 ab Antwort 31 ff dem Benutzer auch helfen können, obwohl er eine ältere Installation von einer anderen Internetseite hatte und an dieser MQTT Implementierung nichts ändern wollte, aus Angst das seine anderen Komponenten nicht mehr funktionieren. Gemeinsam haben wir dann eine Parallelinstallation durchgeführt und nur das neue Gerät (erstmal) auf MQTT2_Server eingerichtet. Es wird sicherlich mehrere Benutzer geben, die mit älteren auf irgendwelchen anderen Seiten zusammengesuchten MQTT Implementionen unterwegs sind. Diese Benutzer verlieren vielleicht eher die Scheu wenn sie erstmal sehen, wie einfach das eigentlich geht und das sie mit den MQTT2_... Modulen grosse Vorteile haben.

Beta-User

 :)
Sorry für's "Schneller sein"...

Dachte erst, ich warte mal noch, wer sich ggf. hier meldet und was dazu schreibt, aber nachdem du mich mehr oder weniger direkt ansprichst...

Hat mich aber sehr gefreut, deine Zeilen hier zu lesen, und ein echter "Quick-Start mit MQTT2" wäre ggf. wirklich eine gute Idee!

Grade für "Umsteiger", ich hatte das ja auch schon ein paar mal erläutert (das sollte auch irgendwo unten in den Praxisbeispielen zu finden sein bzw. verlinkt), und es war am Ende nie eine größere Sache.

Von daher bin ich weiter gespannt, wer hier sonst noch was dazu schreiben mag, und würde neben meinen "Vollständigkeitsmonstern"  ::) eine geraffte Fassung durchaus hilfreich finden!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TL60

Hi, ich lese hier ja auch viel und häufig ist es so, das Benutzer irgendwann mal irgendwo was per copy+paste gemacht haben, was um Himmelswillen nicht geändert werden soll, da sonst nichts mehr funktioniert und wenn man dann aufzeigen kann, wie einfach das mit MQTT2, auch parallel zum Alten MQTT Broker geht, sind einige positiv überrascht und auch durchaus bereit zu wechseln, es stellt sich halt nur die Frage, wo man so eine Erklärung zum Vorgehen ablegt, das man eben bei einer Anfrage einfach sagen kann: Schau dir das mal an. Ich hoffe doch auch noch auf den ein oder anderen der sich hier meldet. Außerdem: Einer kann nur der Schnellste sein  :)

Homalix99

Hallo TL60,

also ich bin erst vor kurzem zu mqtt gekommen. Habe 3 ESP8266 mit ESPEasy und einen shelly-1PM auf meinem alten Fhem-System via MQTT2_SERVER zum Laufen gebracht. Die MQTT2_Devices werden auch alle schön automatisch angelegt.
Nebensächliche Frage: Kann man der autocreate Funktion z. B. via Attribut mitteilen, dass man keine Log_Devices haben möchte?
Das was ich bislang noch nicht gefunden habe ist, wie man über setreading einem ESPEasys device ein Kommando senden kann (z. B. Schalten eines Relais). Bräuchte dazu ein funktionierendes Beispiel. Templates für shellies sind vorhanden und damit funktioniert es auch, aber nicht mit ESPEasy (habe schon alles Mögliche ausprobiert).


So und jetzt zu mqtt bei meinem Docker-Projekt:

Habe mir einen RPi-4 zugelegt und fhem, sowie mosquitto in einem separaten Docker Container zum Laufen gebracht.
Die ESP-WLAN devices schlagen im Mosquitto server auf und das Fhem Objekt

defmod myMQTT2Client MQTT2_CLIENT RPI-Docker.fritz.box:1883

hat sofort eine Verbindung zum mosquitto server aufgebaut und via autocreate das erste Objekt (als MQTT2_DEVICE) angelegt:

defmod MQTT2_myMQTT2Client MQTT2_DEVICE myMQTT2Client
attr MQTT2_myMQTT2Client DbLogExclude .*
attr MQTT2_myMQTT2Client IODev myMQTT2Client
attr MQTT2_myMQTT2Client readingList myMQTT2Client:/ESP-Test/status/LWT:.* LWT\
myMQTT2Client:/ESP-Test/gpio12/Total:.* Total\
myMQTT2Client:/ESP-Test/gpio12/Time:.* Time\
myMQTT2Client:/ESP-Test/gpio12/Count:.* Count\
myMQTT2Client:/ESP-Test/inp14/inp_state:.* inp_state\
myMQTT2Client:/ESP-Test/LED/LED_state:.* LED_state\
myMQTT2Client:/GasWaterMeter/status/LWT:.* LWT\
myMQTT2Client:/GasWaterMeter/GasCounter/Gas_Zeit:.* Gas_Zeit\
myMQTT2Client:/GasWaterMeter/WaterCount/Wasser_Delta:.* Wasser_Delta\
myMQTT2Client:/GasWaterMeter/WaterCount/Wasser_Total:.* Wasser_Total\
myMQTT2Client:/GasWaterMeter/WaterCount/Wasser_Zeit:.* Wasser_Zeit\
myMQTT2Client:/GasWaterMeter/Status/uptime:.* uptime\
myMQTT2Client:/GasWaterMeter/Status/RSSI:.* RSSI\
myMQTT2Client:/GasWaterMeter/Status/:.* Status\
myMQTT2Client:/GasWaterMeter/GasCounter/Gas_Delta:.* Gas_Delta\
myMQTT2Client:/GasWaterMeter/GasCounter/Gas_Total:.* Gas_Total

Was mich gestört hat, ist, dass alle ESP-WLAN Devices, die sich melden nicht als separate Device erscheinen (so wie beim alten Fhem-System) sondern
nur die Reading alle in dieses Fhem Objekt gemappt werden.

Diese Kombi als Lösung habe ich schnell wieder verworfen und weiß jetzt nicht mehr, welchen Weg ich gehen soll, denn es gibt ja mittlerweile so viele Kombi-Möglichkeiten.
1. Mosquitto als ext. Server -> MQTT_GENERIC_BRIDGE -> MQTT2_DEVICE(s)  => hat nicht funkt.
2. MQTT2_SERVER (ohne ext. mqtt-Server) -> MQTT2_DEVICE(s)   => hat bisher auch nicht funktioniert
Es werden keine Devices erkannt:

Internals:
   DEF        1884 global
   FD         32
   FUUID      60802cbd-f33f-6b52-0d2c-a6907aba2427fb19
   NAME       myMQTTBroker
   NR         1956
   PORT       1884
   STATE      Initialized
   TYPE       MQTT2_SERVER
   .attraggr:
   .attrminint:
   READINGS:
     2021-04-21 16:47:59   nrclients       0
     2021-04-21 16:47:59   state           Initialized
   clients:
   retain:
Attributes:
   DbLogExclude .*
   icon       mqtt@6020D0
   room       MQTT2_DEVICE

Die Ports 1883 und 1884 sind aber für die fhem Container "exposed".

Vielleicht kann ich hierüber etwas Orientierung und Hilfe erhalten, vielen Dank erstmal

Gruß

Alex



- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

Beta-User

1. "Easy Way" bedeutet: Verwende MQTT2_SERVER.
2. MQTT2_CLIENT ist zwar nicht viel schwieriger, aber man benötigt ein "Sortierdevice", das umso schwieriger zu gestalten ist, je individueller die Topics sind, auf die gepublischt wird. Zum Ganzen gibt es einen Wiki-Artikel, in dem auch die Info zu finden ist, wie man ein für "normale" Topics passendes "Sortierdevice" einrichtet (und sicherstellt, dass man nicht Kommandos an den jeweiligen Client statt der Rückmeldung von ihm auswertet (bridgeRegexp und ignoreRegexp)). Ergo: Du bist mit deinen individuellen Topics nicht unbedingt auf dem Weg, es dir einfach zu machen.
3. autocreate => FileLog ist kein spezielles Thema von MQTT2_DEVICE, sondern von "autocreate" ("help autocreate" sollte weiterhelfen, welches Attribut ggf. zu löschen ist)
4. MQTT_GENERIC_BRIDGE willst du vermutlich nicht haben, weil du es mit Geräten zu tun hast, die "nativ" MQTT sprechen.

5. Ohne einen Link zur Doku (wie bereits anderweitig angefragt!) wird es nicht gehen, wir sind keine Hellseher. Bei MQTT2_SERVER sollten wenigstens "subscriptions" zu sehen sein, dann hätten wir evtl. schon mal den Topic, an den zu senden wäre, aber leider noch keine Info zum Format der Payload.

(Ja, es ist mir bewußt, dass es in diesem Beitrag von Fachbegriffen wimmelt.)

Forensuche nach "espeasy mqtt2" liefert übrigens unter anderem: https://forum.fhem.de/index.php/topic,109124.0.html und https://forum.fhem.de/index.php/topic,98072.msg914058.html#msg914058
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Homalix99

Vielen Dank erstmal. Werde das mir zu Gemüte ziehen.
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

rudolfkoenig

Zitat2. MQTT2_CLIENT ist zwar nicht viel schwieriger, aber man benötigt ein "Sortierdevice", das umso schwieriger zu gestalten ist, je individueller die Topics sind, auf die gepublischt wird.
Alternativ macht man es komplett "haendisch", exakt wie bei dem guten alten MQTT Modul.
D.h. man legt alle MQTT2_DEVICE Instanzen an, und spezifiert das readingsList Attribut, ganz ohne autocreate.
Nicht dass ich das fuer erstrebenswert halte, ich wollte nur erwaehnen, dass frueher(TM) das ganz normal war.

Beta-User

Danke für den Hinweis, klar, "zu Fuß" geht immer...

(OT: auch MQTT_DEVICE kennt sowas wie "auto-suscriptions"; also "alles" musste man eigentlich auch schon mit diesem Modul nicht von Hand machen. Die "set"-Attribute aber sehr wohl).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors