OpenMQTTGateway
|
An dieser Seite wird momentan noch gearbeitet. |
Einführung
OpenMQTTGateway ist eine firmware für ESP8266 bzw. ESP32, mit der sich neben verschiedenen Sensoren (BME280 u.a.) auch Infrarot- und 433MHz-Signale empfangen und senden lassen. In FHEM steht derzeit hauptsächlich die Auswertung diverser BLE-Geräte im Vordergrund.
Setzt man einen ESP32 ein, genügt hierzu das blanke Board ohne Zusatzhardware, es kann eine vorkompilierte Firmware geflasht werden (USB-Seriell-Wandler erforderlich).
Sobald man die Zugangsdaten zum MQTT2_SERVER eingetragen hat, sollte ein entsprechendes MQTT2_DEVICE-Gerät automatisch erstellt werden.
Mit set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU wird dieses Gerät als zentrales Empfangsgerät konfiguriert, das dann über die bridgeRegexp die eingehenden Informationen (ggf. nicht nur BTLE) jeweils in separate MQTT2_DEVICE-Instanzen verteilt.
Erst wenn dieses Device konfiguriert wurde, werden weitere attrTemplate geladen, die dann im Folgenden Verwendung finden.
OpenMQTTGateway und BTLE
oMQTTgw_BT
Eine der genannten bridgeRegexp sorgt zunächst dafür, dass alle von irgendeinem OpenMQTTGwateway empfangenen BTLE-Informationen an ein weiteres zentrales Gerät weitergegeben werden, das als ClientID oMQTTgw_BT erhält. Dieses ist seinerseits ist auch nur eine Art Zwischen- oder Sammeldevice. In ihm landen einfach alle Infos, die alle OMG im Lauf eines Tages so einsammeln. Damit dies einigermaßen überschaubar bleibt, werden regelmäßig alle Readings (bis auf wenige Ausnahmen wie associatedWith) gelöscht, die älter sind als 24 Stunden, wenn man das mit dem BT-scanner-attrTemplate konfiguriert Dabei hilft "scanner", die eingehenden Infos so vorzuverarbeiten, dass man sieht, was eigentlich zusammengehört. Daneben kann man eben ein paar BT-spezifische Befehle absetzen, die nicht auf ein bestimmtes BT-Gerät bezogen sind, sondern auf das GW. Man könnte diesen Teil auch auf das MCU-attrTemplate "umziehen", dann aber optional, weil ja nicht alle OMG überhaupt BT-Optionen haben müssen... MAn. sollte man jedenfalls so oder so auch dieses "scanner"-Zwischendevice haben und die dortigen Readings ggf. einfach im laufenden Betrieb ignorieren.
Erst die weiteren (BT-) Geräte, die man dann (mit Hilfe des scanners) erstellt, indem man mit dem passenden attrTemplate die BT-Adresse angibt, sind dann die eigentlichen Nutz-Devices. Anders als sonst bei MQTT2_DEVICE gewohnt, werden diese weiteren Instanzen von MQTT2_DEVICE nicht automatisch erstellt, sondern können nur halbautomatisiert erstellt werden, indem man das passende attrTemplate anwendet und diesem die passende BT-ID mitteilt.
Beispiel für z.B. einen MiFlora-Sensor: set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_mi_flora_sensor
Es folgt die Anfrage der zum gewünschten Gerät gehörenden BT-ID; diese kann man den Readings aus oMQTTgw_BT entnehmen. Entsprechend verfährt man für andere Geräte.
Anwendungsbeispiele
Temperatur und Luftfeuchtigkeit
Es werden diverse Temperatur- und Luftfeuchtesensoren unterstützt, u.A. praktisch alle Xiaomi-Cleargrass und Mijia. Für die LYWSD03MMC kann dabei eine alternative Firmware aufgespielt werden.
Anwesenheitserkennung mit Gigaset Keeper G-Tag
Zielsetzung:
Die Anwesenheit von Gigaset Keeper Tags soll mittels OpenMQTTGateway erkannt werden. Der Anwesenheitsstatus dieser Tags kann dann zur einem Status Anwesenheit zusammengefasst werden und für weitere Auswertungen genutzt werden.
Anlegen des OpenMQTTGateway in FHEM:
Via autocreate wie oben beschrieben oder manuell:
defmod MQTT2_OpenMQTTGateway_ESP32_BLE MQTT2_DEVICE OpenMQTTGateway_ESP32_BLE
MQTT2_OpenMQTTGateway_ESP32_BLE ist hier der Name des MQTT2 Device und kann frei gewählt werden.
Anlegen der einzelnen G-Tags als MQTT2 Device
Die zu verwendenden MAC-Adressen der G-Tags sollten bereits bekannt sein und werden ohne Trennzeichen angegeben. z.B. FFFFC424A123.
Folgende Zeile wird für jeden einzelnen Tag ausgeführt.
set MQTT2_OpenMQTTGateway_ESP32_BLE attrTemplate OpenMQTTGateway_BT_gtag <MAC Adresse>
Im Raum MQTT2_DEVICE taucht jetzt ein neues Device OMG_<MAC Adresse> auf. Diesem wurde per Template ein Temperatur Icon zugewiesen. Dieses kann leicht über Select icon am unteren Rand der Device-Übersicht geändert werden, alternativ über die Attribute:
attr OMG_<MAC Adresse> icon gtag_kontur
Wem die Bezeichnung OMG_<Mac Adresse> zur unübersichtlich ist, kann das Device umbenennen oder über die Attribute auch ein alias zuweisen.
Anlegen der Presence Devices
Folgende Zeile wird für jeden einzelnen Tag ausgeführt.
defmod <MAC Adresse>_presence PRESENCE function { my $maxage = AttrVal("OMG_<MAC Adresse>","maxPresenceAge","300");;;; ReadingsAge("OMG_<MAC Adresse>","last_IO","100000") < $maxage ? 1 : 0 }
Wichtig ist hier, dass der DEVICE_NAME angegeben wird, in diesem Fall OMG_<MAC Adresse>.
Zusammenfassen der einzelnen Anwesenheiten in einer structure
Dies ist nur notwendig, sofern mehr als ein Tag verwendet wird.
defmod Anwesenheit structure <identifier> <MAC Adresse 1>_presence <room> <MAC Adresse 2>_presence
<identifier> ist ein Gruppierungsmerkmal, unter dem die Anwesenheiten der Tags angelegt wurden.
Wichtig für die Funktion sind noch folgenden Attribute:
attr Anwesenheit clientstate_behavior relative attr Anwesenheit clientstate_priority present absent
Damit sind auch alle nötigen Schritte erfolgt. Der Status der structure Anwesenheit kann dann für weitere Auswertungen genutzt werden.
OpenMQTTGateway und 433MHz
Thread zur Verwendung als 433MHz-Interface mit rolling code