Ich bin von der Einfachheit überwältigt, mit der es möglich ist unterschiedliche Systeme, die auf MQTT basieren zu vermaschen.
Anbei mein Test-Aufbau bestehend aus
* MQTT-Broker (Mosquitto auf Rapsi)
* FHEM als MQTT-Client
* Arduino mit Ethernet-Shield als MQTT-Client (mit LED, Temperatur und Feuchte)
* Node-Red als Wire-Werkzeug auf Raspi
Da stelle ich mir die Frage, ob es nicht sinnvoller ist, in Zukunft Module als MQTT-Gateways zu entwickeln und auf FHEM spezifische Implementierung zu verzichten.
John
PS:Die Beschreibung der Logik findet sich im rechten Hinweisfeld der Grafik.
Klingt erstmal interessant! Auch wenn es natürlich alles bisherige auf den Kopf und in Frage stellt ;)
Ich werde meine zukünftigen Entwicklungen auf MQTT ausrichten und sehe folgende Vorteile:
- die Entwicklung ist nicht mehr FHEM-spezifisch sondern allgemeingültig, da MQTT ein offenes Protokoll ist und auch von anderen Homeautomation-Lösungen verwendet werden kann. (IOBroker)
- damit ist der Kreis der möglichen Nutzer weitaus höher
- man kann die beste Sprache für das Problem wählen und muss nicht verkrampft mit dem sperrigen Perl einen Lösung suchen
- Themen wie FHEM2FHEM gehören der Vergangenheit an, mit MQTT kann man 100 FHEM Server als Consumer nutzen.
- viele Lösungen im IOT-Umfeld unterstützen MQTT, damit verfügt die eigene Entwicklung um eine weitaus bessere Erweiterbarkeit
Die Liste lässt sich noch fortsetzen.
Ich bin gerade dabei mich mit MySensors zu beschäftigen.
Norbert hat für FHEM einen proprietären MySensors-Controller geschrieben, der natürlich nur in FHEM nutzbar ist.
Er hat vorher damit begonnen einen MQTT-Gateway für MySensors zu schreiben, der als Mauerblümchen verkümmert.
Das wäre meiner Sicht der richtige Weg, da der MQTT-Gateway völlig unabhängig von FHEM ist und alle Daten sofort in
IOT-Wiring-Tools wie Node-Red verwendbar wären
John