(FHEM) 10 MQTT BRIDGE.pm: Unterschied zwischen den Versionen
(→#3) |
|||
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | [[#Module im Detail| [Zurueck Uebersicht | + | [[(FHEM) MQTT#Module im Detail| [Zurueck Uebersicht]]] |
=Steckbrief= | =Steckbrief= | ||
Zeile 26: | Zeile 26: | ||
=Erlaeuterugen= | =Erlaeuterugen= | ||
Aus dem [https://forum.fhem.de/index.php?topic=27532.0 Forumsbeitrag]: | Aus dem [https://forum.fhem.de/index.php?topic=27532.0 Forumsbeitrag]: | ||
+ | |||
+ | '''MQTT_DEVICE''' wird verwendet, wenn das physikalische Device (Sensor oder Aktor) über mqtt kommuniziert. (Kein dummy mehr nötig!) | ||
+ | '''MQTT_BRIDGE''' ist für den Fall, dass ein fhem-device existiert und dieses über mqtt sicht- bzw. steuerbar gemacht werden soll. | ||
Mit den Attributen 'publishState' und 'publishReading_<readingname> man kann Änderungen am State bzw. Readings nach mqtt publizieren. Der Attribut-wert ist immer das Topic an das die Message geschickt werden soll. Message-inhalt ist jeweils der neue Wert des Readings bzw. states. | Mit den Attributen 'publishState' und 'publishReading_<readingname> man kann Änderungen am State bzw. Readings nach mqtt publizieren. Der Attribut-wert ist immer das Topic an das die Message geschickt werden soll. Message-inhalt ist jeweils der neue Wert des Readings bzw. states. | ||
Zeile 53: | Zeile 56: | ||
Fuer Readings werden die Namen der betreffenden Readings als Teil des AttributeNames gesetzt. | Fuer Readings werden die Namen der betreffenden Readings als Teil des AttributeNames gesetzt. | ||
Damit erfaehrt man auf dem topic fhem/wohnzimmer/temperature, wenn sich das Reading 'mesured-temp' des fhem-Devices 'heizungwohnzimmer' aendert. Die Temperatur kann man einstellen, indem man messages mit dem gewünschten Temperaturwert an das Topic 'fhem/wohnzimmer/temperature/set' schickt. | Damit erfaehrt man auf dem topic fhem/wohnzimmer/temperature, wenn sich das Reading 'mesured-temp' des fhem-Devices 'heizungwohnzimmer' aendert. Die Temperatur kann man einstellen, indem man messages mit dem gewünschten Temperaturwert an das Topic 'fhem/wohnzimmer/temperature/set' schickt. | ||
+ | |||
+ | ==#3== | ||
+ | Alexander schreibt: | ||
+ | Also, ich habe folgendes angelegt: | ||
+ | <pre> | ||
+ | define lichtwohnzimmer dummy | ||
+ | define mqtt MQTT 127.0.0.1:1883 | ||
+ | define mqtt_licht_wohnzimmer MQTT_BRIDGE lichtwohnzimmer | ||
+ | attr mqtt_licht_wohnzimmer subscribeSet fhem/wohnzimmer/licht/set | ||
+ | attr mqtt_licht_wohnzimmer publishState fhem/wohnzimmer/licht | ||
+ | </pre> | ||
+ | |||
+ | testen: | ||
+ | mosquitto_pub -q 2 -t fhem/wohnzimmer/licht/set -m test100 | ||
+ | funktioniert. | ||
+ | |||
+ | dann | ||
+ | <pre> | ||
+ | sudo service mosquitto stop | ||
+ | sudo service mosquitto start | ||
+ | </pre> | ||
+ | und sofort danach | ||
+ | mosquitto_pub -q 2 -t fhem/wohnzimmer/licht/set -m test101 | ||
+ | Kommt nicht an. | ||
+ | Norbert: | ||
+ | ommt an, wenn nach dem Restart das MQTT-modul wieder reconnected und die topic-subscriptions erneuert hat, bevor die Message gesendet wurde. Der qos bezieht sich wohl nur auf aktuell verbundene Geräte und deren Subscriptions und stellt sicher, dass Messages vom Empfänger bestätigt und falls das ausbleibt ggf noch mal gesendet werden (Man kann einer offenen Socketverbindung ja nicht ansehen, ob die Software am anderen Ende noch läuft, oder ob gesendete Daten einfach im schwarzen Loch verschwinden...). So was wie 'persistente Subscriptions' scheint es nicht zu geben. | ||
+ | |||
+ | Dafür gibt es aber 'retain'. Messages, die mit diesem Flag an ein Topic geschickt werden, werden vom Broker gespeichert und jedem Client der neu verbindet und das Topic aboniert zugestellt, (unabhängig davon, ob der ursprüngliche Sender noch verbunden ist). | ||
+ | |||
+ | Schick die Message mal mit '-r' | ||
+ | |||
+ | '''Anmerkung:''' Hier haben die beiden die Bedeutung von QOS und RETAIN verwechselt. Wenn man sich meine [[MQTT#Quality of Service|QOS-Tabelle]] anschaut wird einem sofort klar wie QOS funktioniert. |
Aktuelle Version vom 9. August 2022, 09:13 Uhr
Inhaltsverzeichnis
Steckbrief
Das Modul ist seit der Version 6.1 veraltet (deprecated) und wurde in das Verzeichnis ./contrib/deprecated/ verschoben. Um es zu benutzen kann es in das Verzeichnis ./FHEM/ kopiert werden und mit einem Neustart von fhem aktiviert werden.
MQTT_BRIDGE verwendet man, wenn man bestehende fhem-devices (Aktoren und Sensoren) über mqtt steuern bzw. sichtbar machen will.
Fuer ein bestehendes FHEM-device wird eine Verbindung zum mqtt angelegt. Es wird die im IODev-attribute angegebne MQTT-verbindung verwendet. Die Verbindung funktioniert bidirektioinal.
Define
define <name> MQTT_BRIDGE <fhem-device-name>
Set
Get
Readings
Durch Attribute anzulegen
Attributes
subscribeSet [{Perl-expression}] [qos:?] [retain:?] <topic> subscribeSet_<reading> [{Perl-expression}] [qos:?] [retain:?] <topic> publishState <topic> publishReading_<reading> <topic> publish-topic-base <topic> retain <flag> or retain <topic> <flag> <topic> <flag> ... qos <flag> or qos <topic> <flag> <topic> <flag> ...
Erlaeuterugen
Aus dem Forumsbeitrag:
MQTT_DEVICE wird verwendet, wenn das physikalische Device (Sensor oder Aktor) über mqtt kommuniziert. (Kein dummy mehr nötig!) MQTT_BRIDGE ist für den Fall, dass ein fhem-device existiert und dieses über mqtt sicht- bzw. steuerbar gemacht werden soll.
Mit den Attributen 'publishState' und 'publishReading_<readingname> man kann Änderungen am State bzw. Readings nach mqtt publizieren. Der Attribut-wert ist immer das Topic an das die Message geschickt werden soll. Message-inhalt ist jeweils der neue Wert des Readings bzw. states.
Mit den Attributen 'subscribeSet' bzw. 'subscribeSet_<setcommand>' kann man mqtt-topics abonnieren. Immer wenn eine Nachricht auf dem abonnierten Topic eintrifft für das betreffende Device 'set <devicename> <setcommand> <messageinhalt> ausgeführt.
Beispiele
#1
define mqtt MQTT 127.0.0.1:1883 define mqtt_licht_wohnzimmer MQTT_BRIDGE lichtwohnzimmer attr mqtt_licht_wohnzimmer subscribeSet fhem/wohnzimmer/licht/set attr mqtt_licht_wohnzimmer publishState fhem/wohnzimmer/licht
Man kann z.B. mit 'mosquitto_pub -t fhem/wohnzimmer/licht/set -m on' ein 'set lichtwohnzimmer on' ausloesen, oder mit einem 'mosquitto_sub -t fhem/wohnzimmer/licht' erfahren, wenn sich der state von 'lichtwohnzimmer' veraendert.
#2
define mqtt_heizung_wohnzimmer MQTT_BRIDGE heizungwohnzimmer attr mqtt_heizung_wohnzimmer publishReading_mesured-temp fhem/wohnzimmer/temperature attr mqtt_heizung_wohnzimmer subscribeReading_desired-temp fhem/wohnzimmer/temperature/set
Fuer Readings werden die Namen der betreffenden Readings als Teil des AttributeNames gesetzt. Damit erfaehrt man auf dem topic fhem/wohnzimmer/temperature, wenn sich das Reading 'mesured-temp' des fhem-Devices 'heizungwohnzimmer' aendert. Die Temperatur kann man einstellen, indem man messages mit dem gewünschten Temperaturwert an das Topic 'fhem/wohnzimmer/temperature/set' schickt.
#3
Alexander schreibt: Also, ich habe folgendes angelegt:
define lichtwohnzimmer dummy define mqtt MQTT 127.0.0.1:1883 define mqtt_licht_wohnzimmer MQTT_BRIDGE lichtwohnzimmer attr mqtt_licht_wohnzimmer subscribeSet fhem/wohnzimmer/licht/set attr mqtt_licht_wohnzimmer publishState fhem/wohnzimmer/licht
testen:
mosquitto_pub -q 2 -t fhem/wohnzimmer/licht/set -m test100
funktioniert.
dann
sudo service mosquitto stop sudo service mosquitto start
und sofort danach
mosquitto_pub -q 2 -t fhem/wohnzimmer/licht/set -m test101
Kommt nicht an. Norbert: ommt an, wenn nach dem Restart das MQTT-modul wieder reconnected und die topic-subscriptions erneuert hat, bevor die Message gesendet wurde. Der qos bezieht sich wohl nur auf aktuell verbundene Geräte und deren Subscriptions und stellt sicher, dass Messages vom Empfänger bestätigt und falls das ausbleibt ggf noch mal gesendet werden (Man kann einer offenen Socketverbindung ja nicht ansehen, ob die Software am anderen Ende noch läuft, oder ob gesendete Daten einfach im schwarzen Loch verschwinden...). So was wie 'persistente Subscriptions' scheint es nicht zu geben.
Dafür gibt es aber 'retain'. Messages, die mit diesem Flag an ein Topic geschickt werden, werden vom Broker gespeichert und jedem Client der neu verbindet und das Topic aboniert zugestellt, (unabhängig davon, ob der ursprüngliche Sender noch verbunden ist).
Schick die Message mal mit '-r'
Anmerkung: Hier haben die beiden die Bedeutung von QOS und RETAIN verwechselt. Wenn man sich meine QOS-Tabelle anschaut wird einem sofort klar wie QOS funktioniert.