MQTT für FHEM

[bjoernhoefer]

Hallo,

wie John vor einigen Tagen angesprochen ist MQTT eine recht gute Plattform um sich mit anderen Systemen auszutauschen.

Da ich gerne auch etwas für das System das ich schon seit mehr als zwei Jahren verwende beitragen möchte, mach ich das jetzt ;-)

Ich habe schon länger in NodeJS einen FHEM-Listener gebaut - dieser Listener verbindet sich mittels telnet auf den FHEM Server und verwendet dort dann das inform modul um Änderungen mit zu bekommen. Diese Änderungen "schreit" er dann in die MQTT Message Queue raus und dort kann man dann damit machen was man will (in meinen Fall NodeRED der dann ein ESP8266 Modul schaltet - dazu aber mehr).

Weiters habe ich eine "Inventory" Routine (auch schon länger her) gebaut welche alle Geräte und div. Stati in die Message Queue reinhaut.

Was noch kommt
Ein MQTT-Listener, der die Geräte von FHEM kennt und dann FHEM schaltet.

Was mich dazu getrieben hat
Inital wollte ich ein komplett neues FHEM Frontend (NodeJS basierend) machen - das hab ich dann aber aufgrund div. Probleme bei der Umsetzung wieder links liegen gelassen - seit dem schlummerten die Funktionen auf meinen Festplatten munter vor sich hin...

Was ich damit erreichen möchte
FHEM ist eine so tolle Plattform und es gibt so viele Module, leider ist es wie überall, dass jeder teilweise sein eigenen Süppchen kocht. Da sich im IoT-Umfeld MQTT immer mehr zum Standard mausert und fast alle anderen Plattformen das unterstützen, kann man mit einer vollständigen MQTT-Implementierung nur am richtigen Weg sein ;-)

Was ich damit nicht erreichen will
FHEM soz. Kopflos zu machen - das FHEM nur eine Gateway Software zu irgendwelchen Geräten ist.



So, nachdem vielen Texten ein bisschen was zum Anschauen: https://github.com/bjoernhoefer/nodefhem_mqtt - dort findet man die Sourcen, inkl. Installationsanleitung.


Beispiel 1
Ich habe bei mir folgendes Umfeld aufgebaut:
RaspberryPi 2 mit Raspbian, Mosquito (MQTT Server), NodeRed
Als "Testclients" habe ich zwei ESP8266 Module (http://www.mikrocontroller.net/articles/ESP8266) mit einer LED und MQTT Client (mit Arduino IDE gebastelt...)

NodeRED entscheidet wenn sich ein FHEM dummy ändert - dass er den ESP8266ern bescheid geben soll, das sie sich einschalten sollen -> Verzögerung für den gesamten Workflow weit unter einer Sekunde.

Beispiel 2
Da viele ja einen Raspberry Pi verwenden und die Speicherkarten durch das Protokollieren nicht besser werden könnte man hier auf eine InMemory Datenbank umstellen (Redis für die aktuellen Werte, MongoDB/ElasticSearch/InfluxDB/etc. für Langzeit) welche viel besser mit Speicherkarten umgehen, da diese Datenbanken nur Snapshots in Intervallen auf die Karte speichern.
Das habe ich teilweise auch schon mit NodeRED umgesetzt - recht straightforward...
Wie man dann die Daten in FHEM reinbekommt (on demand) ist natürlich eine andere Sache - ich gehe da den Weg eigene Web-Interfaces dafür zu verwenden (Kibana/Grafana...)


Meine Bitte
Da ich ja hier im "Kreis der Weisen" vorspreche würde ich gerne eure Meinung zu dem ganzen Thema (MQTTm bzw. Öffnung in andere Systeme/Protokolle), bzw. natürlich auch gerne Verbesserungsvorschläge udgl. einholen.


Danke und ich hoffe mit meinen ersten Post nicht meine gesamte Reputation zu zerstören...


Björn

[rudolfkoenig]

Meiner Ansicht nach waere es noch wichtig klarzustellen, was der Unterschied zum MQTT Implementation von Norbert ist (00_MQTT.pm, 10_MQTT_BRIDGE.pm, 10_MQTT_DEVICE.pm).

[bjoernhoefer]

Hallo rudolf,

es ist nicht all zu viel Unterschied ;-)

soweit ich das jetzt verstanden habe, muss man ein Device (Topic) anlegen und damit schalten, bzw. es informiert die Topics damit.

Den größten Unterschied den ich erkenne ist das über die Module von Norbert alles einzeln konfiguriert werden muss (ein Device -> ein Topic) und bei mir wird einfach jede Aktion in MQTT rein geschrieben.

Die Inventory-Funktion von mir ist im Modul von Norbert nicht inkludiert.

[bjoernhoefer]

Hallo rudolf,

ich bin leider erst jetzt dazu gekommen, nochmal über das ganze nach zu denken....

Der größte Unterschied zw. der Lösung von Norbert und meiner ist das bei mir jedes Gerät eine MQTT Message auslöst - das müsste bei 10_MQTT_BRIDGE.pm/10_MQTT_DEVICE mit einen MQTT-Device pro FHEM-Device und einen notify gemacht werden.

Da das bei 2 Geräten kein Problem ist, kann das bei 20+ Geräten recht viel werden.

Weiters ist mein Ansatz "Konfigurations-los" - da man auf FHEM nix konfigurieren muss (Username und Passwort in der NodeFHEM_MQTT Konfig reicht aus).


Mein Ziel war einfach FHEM komplett in meine MQTT Umgebung einzubinden (FHEM->MQTT) - soweit ich das Modul von Norbert verstehe bindet er MQTT in FHEM ein (MQTT -> FHEM).

[John]

ich denke das Modul von Bjoern entspricht einem generalisiertem MQTT_Bridge Modul, das
uneingeschränkt alle FHEM-Objekte publisched.

Es ersetzt jedoch nicht das MQTT_Device Modul, das externe MQTT-Topics in FHEM verfügbar macht.

@Börn
hier solltest du überlegen, ob du nicht eine Art Blacklist/Whiteliste für einzelne Module (z.B. via Regexp) einführst,
um bestimmte Objekte auszuschliessen (in jedem Fall MQTT_Device).
Eine via MQTT-Device importierte Information würde von deinem Modul erneut nach MQTT unter einem anderen Topic exportiert werden.
Dies führt zu Unklarheiten und redundanten Informationen.

Inwieweit die dauerhafte Belegung des Telnetports, im Sinne des Erfinders ist, kann ich nicht beurteilen.
Weiterhin ergibt sich für FHEM sicher eine Mehrbelastung, da jeder Event umgehend einen Web-Request an FHEM zur Folge hat.
Wie gravierend diese Mehrbelastung  ist, bleibt noch zu beurteilen.


John

[rudolfkoenig]

dauerhafte Belegung des Telnetports
 jeder Event umgehend einen Web-Request an FHEM zur Folge hat

Kannst du bitte diese beiden Punkte etwas detaillieren, das was ich z.Zt. darunter vorstelle stimmt naemlich nicht.

[John]

Das Modul von Bjorn öffnet den Telnet-Port von FHEM und belegt diesen dauerhaft.

Code: [Auswählen]

    // Connect via telnet to FHEM Server and start inform to get notified by a device-changes
    client.connect(fhem_telnet_port, fhem_server, function() {
        client.write('inform on\n');
    });
Das Modul bezieht die Information zu welcher Instanz sich etwas geändert hat über die Inform-Ausgaben.
Danach wird folgender Request an FHEM abgesetzt, um detaillierte Informationen zu erhalten

Code: [Auswählen]

        path: '/fhem?cmd=jsonlist+'+devicename+'&XHR=1',
        ...

John

[rudolfkoenig]

Dann habe ich den ersten Punkt richtig verstanden.
Du kannst soviele telnet-Verbindungen zu FHEM aufmachen, wie du willst (ok, max etwa 60000).

jsonlist sehe ich auch als Problem an, eigentlich muesste man am Anfang jsonlist einma fuer alle Geraete aufrufen, und danach nur die Events auswerten. Teilweise bekommt man 10+ Events fuer Schalter umlegen (bei HM ist das besonders ausgepraegt), dafuer 10-mal jsonlist aufzurufen ist sicher nicht optimal.