Hallo zusammen,
nachdem sich (v.a.) in letzter Zeit die Anfragen gehäuft haben, die Titel trugen wie
-
Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE (mit einer sehr guten Darstellung von @gadget im 2. Beitrag!)
-
MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen -
Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone?-
Fhem von Android steuern mit MQTT-
Zwei FHEMs mit MQTT2 verbinden?
-
Status Rücklesen Dummy (ebenfalls Loxone-Anbindung)
-
Node-Red als Frontend (ok, der ist schon älter, aber jüngst wieder aufgegriffen worden)
haben Rudi, hexenmeister und meinereiner etwas an der MQTT_GENERIC_BRIDGE gebastelt, so dass zum einen die Zusammenarbeit mit MQTT2_CLIENT und MQTT2_SERVER mit diesem Querschnittsmodul
verbessert wird, zum anderen hat hexenmeister auch die Anregung aufgegriffen, AttrTemplate-support einzubauen.
Viele werden attrTemplate vermutlich schon von MQTT2_DEVICE oder einem der anderen Module her kennen, die das supporten.
Der Grundgedanke von AttrTemplate ist der, (sinnvolle) Vorschläge für die Konfiguration von Devices zu machen, um damit v.a. den Usern das Leben zu erleichtern, die sich nicht unbedingt vertieft mit jedem Modul und/oder jeder Untiefe diverser firmwares (oder externer Dienste) auseinandersetzen wollen.In diesem Thread hier soll es daher darum gehen, gewisse - v.a. auch aus Sicht der bisherigen Nutzer der MQTT_GENERIC_BRIDGE sinnvolle - Standards so in attrTemplate-Form zu gießen, dass nachfolgende Generationen von Usern es einfacher haben. Ergo baue ich auch auf die Rückmeldung derjenigen, die hier Erfahrung haben - ich habe die nämlich z.B. nicht, was die optimale Übergabe von Daten an Abnehmer wie Homeassistant oder NodeRed angeht.
Gerade die zu Beginn des NodeRed-Thread zu findende "SYS_MQTT"-notify-Lösung scheint eine Art "Ur-Vater" vieler Klone zu sein, der nach wie vor in den Weiten des Internets zu finden sind, obwohl vermutlich alle der damals Beteiligten zwischenzeitlich die deutlich sichere Lösung MQTT_GENERIC_BRIDGE verwenden...
Wie dem auch sei:
Ziel ist es, einen Satz attrTemplate als eine sinnvolle Möglichkeit anzubieten. Dass man alles auch immer irgendwie anders machen kann, steht dabei außer Frage, niemand MUSS es so machen, und optimalerweise ist das ganze so aufgebaut, dass jeder User es auf einfache Weise auf seine Bedürfnisse anpassen kann, falls er das für erforderlich ansieht.
Im Moment scheinen mir folgende Dinge sinnvoll bzw. notwendig:
- Es muss verschiedene Topics für die Sende- und Empfangsrichtung geben;
- Der Device-Name in FHEM sollte im Topic auftauchen.
Beides
kann man dadurch bewerkstelligen, indem man in dem MQTT_GENERIC_BRIDGE-Device globale Einstellungen vornimmt, z.B.:
attr <mqtt_generic_bridge-devicename> globalDefaults sub:base={"FHEM/MQTT_2FHEM/$device"} pub:base={"FHEM/FHEM_2MQTT/$device"} pub:qos=0 sub:qos=2 retain=0
attr <mqtt_generic_bridge-devicename> globalDefaults sub:base={"FHEM/set2FHEM/$device"} pub:base={"FHEM/$device"} pub:qos=0 sub:qos=2 retain=0
attr myMGB globalDefaults sub:base={"myMGB/command/$device"} pub:base={"myMGB/$device"} pub:qos=0 sub:qos=2 retain=0
Damit stellen sich die ersten Fragen:
- Soll $device über globalDefaults/base in den Topic vercoded werden, oder soll das erst in den einzelnen Devices der Fall sein (und damit dort ggf. der Gesamt-Topic leichter anzupassen sein)
- sollte der Name der MQTT_GENERIC_BRIDGE (per default) im Topic auftauchen oder nicht?
- soll es einen Topic-Anteil für die Senderichtung geben, der "fromFHEM" signalisiert, oder reicht für den Status jeweils der kurze Topic...
Damit das ganze nicht zu akademisch wird, anbei auch eine attrTemplate-File für die, die das ausprobieren wollen.
Da oft zu lesen ist "ich will einfach alle Readings in MQTT haben", gibt's dafür (unabhängig von meinen persönlichen Vorbehalten gegenüber solchen pauschalen Vorgehensweisen) auch ein attrTemplate, das das (auf Einzel-Device-Basis!) erledigt. Das attrTemplate fragt dann nach dem Device-Namen (devspec sollte möglich sein), von dem man alle Readings nach MQTT bringen will, wenn man an der MQTT_GENERIC_BRIDGE folgenden Befehl absetzt:
set myMGB attrTemplate mgb_send_all_readings
Dazu (vorläufig) die .template aus dem Anhang laden und (mit den passenden Rechten!) unter fhem/FHEM/lib/AttrTemplate abspeichern. (In FHEMWEB) dann diesen Befehl absetzen:
{AttrTemplate_Initialize()}
In der mittleren Perspektive wäre dann zu klären, wie man bestimmte Dinge ggf. vereinheitlicht, so dass z.B. verschiedene Heizkörper-Thermostate dann via MQTT sich "gleich anfühlen", wenn man sie über diesen Weg nach MQTT bringt. Wer Popcorn liebt, kann dazu hier schon was nachlesen bzw. ggf. auch (als Tester) Vorschläge machen:
DevelopmentGuidelinesReadings - weitere Vorschläge für künftige Module.
Wer sich erst orientieren muss: Es gibt
einen sehr guten Thread mit vielen Beispielen von hexenmeister. Wer sich neu einarbeiten will, sollte hier eigentlich schon mal viel "Baumaterial" finden.
Bin dann mal auf eure Rückmeldungen gespannt!
Grüße, Beta-User
PS: in der via svn verteilten attrTemplate-File "general_use" sind noch ein paar Vorläuferversionen drin. Die bitte löschen, sonst kommt das in Konflikt; dazu kann auch das 2. file aus dem Anhang verwendet werden...