Ich versuche es 'mal "in ganz groben" Zügen mit extremen Vereinfachungen zu beschreiben (ersetzt keinesfalls das Lesen und Verstehen der Dokumentationen zu FHEM: commandRef und Wiki's zu diesem Thema, sowie von MQTT selbst) :
Vorab
Es gibt mehrere Wege ein MQTT sendendes / empfangendes Gerät in FHEM einzubinden.
Entweder man bindet einen externen Broker mit dem das Gerät kommuniziert über ein FHEM IO Device vom Typ MQTT_SERVER ein und definiert dann manuell die gewünschten FHEM devices vom Typ MQTT_DEVICE, oder, man definiert ein FHEM Device vom Typ MQTT2_SERVER als IO device, das sich "nach außen" genau wie ein "echter" MQTT Broker verhält. Dann kann man die Vorteile der automatischen Anlage von FHEM devices vom Typ MQTT2_DEVICE und der automatisierten Pflege des readingsList Attributes nutzen.
MQTT2_SERVER und MQTT2_DEVICE (Empfehlung, macht den Einstieg leichter):
Das definierte MQTT2_SERVER device verhält sich gegenüber externen Geräten wie ein MQTT-Broker und empfängt MQTT Messages oder sendet MQTT messages an Subscriber (kann also einen Broker wie z.B. mosquitto weitgehend ersetzen)!
Ist das "autocreate" Attribut des MQTT2_SERVER device nicht explizit ausgeschaltet, legt dieser automatisch für alle eingehenden MQTT Nachrichten dieses Gerätes (MQTT ClientID) ein entsprechendes FHEM-device vom Typ MQTT2_DEVICE mit dem entsprechenden readingsList Attribut an.
Die Elemente (Zeilen) des readingsList Attributs des FHEM-devices vom Typ MQTT2_DEVICE entsprechen den MQTT subscriptions. Sie werden auf Basis der in jeder Zeile definierten Regeln in readings zu diesem FHEM-device ausgegeben.
Ist das Attribut "autocreate" des FHEM-devices von Typ MQTT2_DEVICE nicht explizit deaktiviert, wird jede eingehende MQTT Nachricht, die von diesem sendenden Gerätes (die Identifikation erfolgt über die ClientID dieses Gerätes) automatisch im readingsList Attribut ergänzt.
Dabei wird der gesendete Inhalt (MQTT: payload) analysiert und, im Fall eines einzelnen Wertes String, Boolean, number, einem einzelnen reading zugeordnet, oder, im Fall von gültigem json in mehrere readings ausgegeben (json2namevalue(...)).
Im Attribut "setList" des FHEM-devices können möglich MQTT publish commands zu diesem Gerät eingetragen werden.
Verwendest man den MQTT2_SERVER werden viele notwendigen Schritte zu möglichen "subscriptions" in FHEM weitgehend automatisiert angelegt.
Spezielle Aufbereitungen z.B. zur Darstellung, Interpretation/Aufbereitung von payloads und der möglicherweise geeigneten MQTT publish Commands (setList) werden für viele bekannte Geräte (u.A. auch shelly3em) als attrTemplate als mögliche Vorlage zur Definitionsanpassung des FHEM-devices vom Typ MQTT2_DEVICE angeboten.
Schritte zum Kopieren in Kommandozeile bzw. in Multiline Command :
1. MQTT2_SERVER anlegen (= MQTT Broker):
define mqtt MQTT2_SERVER 1883 global
2. [optional] basicAuth für mqtt anlegen
(Hinweis: Ist in den MQTT Eingaben am Gerät als username und password zu erfassen):
define allowed_mqtt allowed
attr allowed_mqtt validFor mqtt
set allowed_mqtt basicAuth <username> <password>
3. Anschliessend am Shelly 3 EM unter Internet & Security - ADVANCED - DEVELOPER SETTINGS unter:
- X Enable MQTT
- Username: <username>
- Password: <password>
- Server: <ip vom FHEM Server>:1883
- Custom MQTT prefix:
- X Use custom MQTT prefix
- <shelly3em_01>
- Min reconnect timeout 2
- Max reconnect timeout: 60
- Keep alive: 60
- O Clean Session
- X Retain
- Max QoS 0
mit Save speichern. Anschließend bootet der shelly neu und sendet nachdem hochfahren die ersten Daten an dem MQTT Broker (hier: FHEM)
Aufgrund des aktiven "autocreate" wir in FHEM im Raum MQTT2_DEVICE ein neues Device (wahrscheinlich: MQTT2_<shelly3em_01> angelegt.
Automatisch werden alle eingehenden MQTT Nachrichten, die mit der ClientID an den MQTT Broker (hier: FHEM) in dem readingsList Attribut eingetragen und die entsprechenden readings angelegt bzw. aktualisiert.
4. Jetzt kann man ggf. mit dem FHEM-Befehl:
set MQTT2_<shelly3em_01> attrTemplate shelly3em
ein Template zu diesem Shelly 3 EM Gerät ausführen.
Danach sollten weitgehend nachvollziehbare attribute an diesem FHEM-device gesetzt worden sein und die FHEM-web Darstellung sinnvoll aufbereitet werden.
Diese Vorlagen sind jedoch nur Vorschläge/Möglichkeiten zur FHEM-Device Definition, damit unerfahrene Benutzer einfacher geeignete Ergebnisse erhalten.
5. Logging
Das FHEM-FileLog ist das, was Du irrtümlich als MQTT Messaging interpretiert hast. FHEM devices vom Typ FileLog erstellen Text Datei(en) im Filesystem aus allen FHEM Ereignissen, die durch eine geeignete Regex gefiltert wurden. In den von Dir herangezogenen Beiträgen des "Sammelthreads" geht es darum, ob bei allen oder nur ausgewählten Änderungen ein Ereignis (Event) erzeugt werden soll, das in dann zur Summen-/Differenzermittlung in userReadings verwendet werden und je nach FileLog Definition auch zu einem Eintrag im FileLog führt. (siehe Beispiel von helmi55)
Im Übrigen wird ein Standard FileLog Device (FileLog_MQTT2_...) automatisch bei dem Ereignis der ersten MQTT Message eines neuen Gerätes (mit neuer ClientID) angelegt. Dieses FileLog ist häufig die Basis für die grafisch Darstellung.
Weitere Hilfe gerne in einem neuen Thema im fhem Forum unter MQTT ...