Nutzt von Euch jemand MQTT mit SmartHomeNG?

[Msinn]

Hi,

ich bin gerade dabei ein EnOcean Gateway auf Basis eines Raspberry Pi zu erstellen.

Ich mache das auf einer anderen Hardware als die auf der SmartHomeNG läuft, da ich dort wo die SmartHomeNG steht suboptimale Sende-/Empfangsbedingungen für EnOcean habe. Das Gateway kann ich überall platzieren, wo ich WLAN Versorgung habe. Um das Gateway mit SmartHomeNG kommunizieren zu lassen, wollte ich auf ein Standardprotokoll zurückgreifen und bin bei MQTT gelandet.

Die MQTT Kommunikation auf dem Gateway habe ich implementiert und kann über Tools wie mqtt-spy über einen Broker (mosquitto) auch sauber mit einem Gateway kommunizieren.

Nun komme ich zur SmartHomeNG Seite. Es gibt ein mqtt Plugin. Es ist seit 2015 (Aufnahme in smarthome.py) nicht gepflegt worden. Weiterhin erscheint mir das Pluin etwas simpel gestrickt zu sein (ohne Anspruch auf Vollständigkeit):

• Empfangene Strings werden immer ale Byte-Array an SmartHomeNG weitergereicht.
  (Das sieht eher nach einer Python 2.7 kompatiblen Implementierung aus und macht innerhalb von SmartHomeNG zum Teil Probleme)
• Es wird immer die aufwendigste Kommunikation mit dem Broker gewählt (Quality of Service 2)
• Es gibt bei ausgehenden Messages keine Möglichkeit, diese als 'to be retained' zu kennzeichnen
• Es gibt keine Möglichkeit einen 'Last Will' zu setzen

Reicht Euch die Implementation des Plugins oder habt Ihr Wünsche/Vorstellungen zu einer Erweiterung?

-----------------------------------------------------------------------------------

Feature Liste für das neu zu entwickelnde Plugin (work in progress):

• Smart Plugin
• Multi Instance fähig
• Unterstützung aller drei QoS Varianten
• 'to be retained' Unterstützung für Nachrichten
• Möglichkeit für den Client einen 'Last Will' zu setzen
• Vollständiges Type-Casting für ein- und ausgehende Nachrichten
• evtl. Möglichkeit das Datenformat des ausgehenden Paketes zu beschreiben (für Type-Casting)
• Unterstützung für Verschlüsselung der Kommunikation
• Unterstützung für clean/persistent sessions
• Das Plugin öffnet nur eine Client Session zum Broker
• Items in der Item-Tree Struktur publizieren (Abhängig von einem acl Attribut des jeweiligen Items (no, ro, rw)

Ich bin mir nicht sicher ob und wie das Plugin mit großen binären Daten umgehen soll. MQTT unterstützt im Prinzip die Übertragung von Bildern, Dateien oder anderen komplexen Datentypen.

Wenn Ihr noch wünsche für die Feature Liste habt, raus damit!

[stromie]

Hallo Msinn
ich will das demnächst einsetzen. Dann kann ich mehr sagen

[Msinn]

Ich habe noch herausgefunden, dass das Plugin für jeden Topic den es subscribed eine eigene Client Instanz eröffnet. Mir fiel das auf, als ich die Anzahl aktiver Clients im Broker sah.

Ich bin mehr und mehr geneigt das Plugin neu zu schreiben.

[heckmannju]

Hi
ich hatte auch Interesse an beiden dem gateway und dem mqtt plugin. Vg Juergen

v

[heckmannju]

Hi mein einsatzweck sind easyesp steckdosen und sensoren
vg jueren

[walldi]

MQTT sollte möglichst "nativ" bzw transparent implementiert sein. (Item.conf mqtt=pub/sub/pubsub ... fertig) Das Plugin müsste am besten auch den Broker starten oder integrieren.
In Python3 gibt es zB http://hbmqtt.readthedocs.io/en/latest/index.html

[Msinn]

Den Broker zu integrieren sehe ich skeptisch. In meinem Netz wird der Broker nicht in der selben Security Zone stehen (können) wie SmartHomeNG.

Außerdem gibt es einen quasi-standard mit Mosquitto. Mosquitto ist simpel zu installieren und kann auch auf beliebigen anderen Systemen laufen. Bei mir b.B. auch auf einem der Gateways.

Ich stimme Dir zu, dass MQTT möglichst "nativ" implementiert sein sollte. Dann ist das aber leider etwas mehr als '(Item.conf mqtt=pub/sub/pubsub ... fertig)'. Bei einer möglichst "nativen" Implementierung muss man auch in der Lage sein Features wie Retain, Last-Will oder Quality-of-Service nach eigenem Bedarf einzusetzen.

Bei der Implementierung all dieser Fähigkeiten muss das Plugin selbstverständlich simpel konfigurierbar bleiben.

[Msinn]

Als Quick-Fix habe ich das existierende Plugin um Type-Casting erweitert. Empfangene Daten werden nun in den Datentyp des Items gewandelt. Statt wie bisher als Datentyp 'foo' anzugeben, kann jeder SmartHomeNG Datentyp in der items.conf/items.yaml angegeben werden und die empfangenen Daten werden soweit sinnvoll möglich in den entsprechenden Datentyp gewandelt.

[hmhofstede]

Hallo Martin,

Vielen Dank für den Quick-Fix. Bei mir ist der Anwendungsfall die Einbindung in Apple HomeKit (damit Siri in smarthomeNG Aktionen auslösen kann, bzw. über den Zustand der Items gefragt werden kann). Ich verwende dazu homebridge und homebridge-mqtt. homebridge-mqtt stellt die HomeKit API über MQTT zur Verfügung (Registrieren/Löschen von HomeKit "Datenbankeinträgen", Abfragen/Setzen von Werten etc.). Dazu wird über MQTT jedes mal eine JSON Datenstruktur übertragen, die den Namen des Datenbankeintrages in HomeKit und die zum Kommando (das ist das topic) passenden Attribute enthält.

Für das MQTT plugin sehe ich daher 2 Varianten:
1. Wie bisher ein oder mehrere Topic pro item um die Werte des Item über MQTT zu übertragen (pub/sub/pubsub). Damit sind einfache Anbindungen an abgesetzte Sensoren oder Aktoren einfach zu machen - wäre bei mir vermutlich irgendwann bei der Bewässerungssteuerung an der Reihe.
2. Eine Art API bei der es Topics für Lesen und Schreiben von Werten gibt. Dort ist das smarthomeNG item ein Parameter und kein Topic (ähnlich smartVISU websocket interface). Damit wäre die MQTT Schnittstelle universell einsetzbar und eher eine API zu smarthomeNG als ein gateway zu bestimmten Items.

Ähnlich dem homebridge-mqtt interface könnte ich mir vorstellen, daß es folgende topics geben sollten:
- smarthomeNG inbound: Setzen von Werten und Abfragen von Werten
- smarthomeNG outbound: Übertragen eines aktualisierten Wertes (sollte vielleicht auch das ACK auf das Setzen eines Wertes sein) - oder die Antwort auf eine Abfrage

Über item Attribute könnte man dann steuern auf welche items Lese/Schreibberechtigungen erteilt werden (ähnlich smartVISU websocket)

Mein Python ist nicht wirklich gut - ich würde aber an der 2. Variante gerne mitarbeiten.

PS: Ein MQTT Broker sollte nicht Teil von smarthomeNG werden. Mosquitto ist auf allen Platformen zu haben (https://mosquitto.org/download/) und lässt sich einfach als Service starten. Ich würde jedem der mit MQTT anfängt empfehlen auch node-red zu verwenden. Damit lassen sich Debugging and Manipulationen an der payload schnell und einfach realisieren.

Hendrik

[heckmannju]

Wäre das starten vom Mosquitto nicht aufgabe des Backendplugins?

[Msinn]

Ich verwende dazu homebridge und homebridge-mqtt. homebridge-mqtt stellt die HomeKit API über MQTT zur Verfügung (Registrieren/Löschen von HomeKit "Datenbankeinträgen", Abfragen/Setzen von Werten etc.). Dazu wird über MQTT jedes mal eine JSON Datenstruktur übertragen, die den Namen des Datenbankeintrages in HomeKit und die zum Kommando (das ist das topic) passenden Attribute enthält.

Das sollte mit der Version des Plugins die ich gestern gepushed habe funktionieren. Eingehend den Type des Items auf 'dict' setzen. 'dict' ist ein valider Datentyp in SmartHomeNG (nur selten genutzt). Auswerten müsstest Du diese eingehenden Messages am besten mit einer Logik. Ausgehend einfach einen String im Json Format in das entsprechende Item schreiben. (Ausgehende Unterstützung des type 'dict' habe ich noch nicht getestet).

1. Wie bisher ein oder mehrere Topic pro item um die Werte des Item über MQTT zu übertragen (pub/sub/pubsub). Damit sind einfache Anbindungen an abgesetzte Sensoren oder Aktoren einfach zu machen - wäre bei mir vermutlich irgendwann bei der Bewässerungssteuerung an der Reihe.

Das wäre die MQTT Funktionalität, die ich erstmal im neuen Plugin so sehen würde.

2. Eine Art API bei der es Topics für Lesen und Schreiben von Werten gibt. Dort ist das smarthomeNG item ein Parameter und kein Topic (ähnlich smartVISU websocket interface). Damit wäre die MQTT Schnittstelle universell einsetzbar und eher eine API zu smarthomeNG als ein gateway zu bestimmten Items.

Ich verstehe noch nicht ganz, worauf Du damit hinaus willst. Meinst Du, dass ein anderer MQTT Client quasi auf den gesamten Item-Tree in Form von MQTT Topics zugreifen kann und dort die Werte lesen und schreiben kann?

Wenn ja, so könnte man das zum Teil in einem zweiten Schritt als Erweiterung des Plugins implementieren.

Ähnlich dem homebridge-mqtt interface könnte ich mir vorstellen, daß es folgende topics geben sollten:
- smarthomeNG inbound: Setzen von Werten und Abfragen von Werten
- smarthomeNG outbound: Übertragen eines aktualisierten Wertes (sollte vielleicht auch das ACK auf das Setzen eines Wertes sein) - oder die Antwort auf eine Abfrage

Das ist etwas problematisch. MQTT kennt keine 'Abfrage'. Ich kann nur subscriben, wass ich an Messages empfangen will, die ein anderer Client published. Also müsste SmartHomeNG alle Items publishen (eher unpraktikabel) oder man müsste bei den Items ein Attribut wie 'mqtt_publish = True' setzen.

Mein Python ist nicht wirklich gut - ich würde aber an der 2. Variante gerne mitarbeiten.

Hilfe bei der Konzeption und beim Testen highly welcome. Ich würde das aber nicht als zwei Varianten sehen sondern als zwei Stufen der Implementierung, die aufeinander aufsetzen.

PS: Ein MQTT Broker sollte nicht Teil von smarthomeNG werden. Mosquitto ist auf allen Platformen zu haben (https://mosquitto.org/download/) und lässt sich einfach als Service starten.

Das war auch nie die Absicht. Walldi hatte nur eine Python Implementierung ins Spiel gebracht, die Client und Broker implementiert. Ich will mich lieber an die verbreitetsten Implementierungen (eclipse.paho für den Client und mosquitto für den Broker) halten und schrieb, dass Mosquitto (von jedem) leicht zu installieren ist.

Ich würde jedem der mit MQTT anfängt empfehlen auch node-red zu verwenden. Damit lassen sich Debugging and Manipulationen an der payload schnell und einfach realisieren.

Es gibt auch eine größere Anzahl graphischer Frontends, die diese Aufgabe erledigen können. Ich nutze 'mqtt-spy' (Java, läuft auf div. Plattformen) und MQTT.fx (MacOs Frontend).

[Msinn]

Wäre das starten vom Mosquitto nicht aufgabe des Backendplugins?

Darüber könnte man nachdenken, wenn es populär wird den Broker auf der SmartHomeNG Installation zu fahren. Je nach Netz Topologie (z.B. in Bezug auf Security Zonen) kann es sehr viel sinnvoller sein den Broker auf einem anderen System laufen zu lassen.

[heckmannju]

Ich denke da eher einfach und würde das auf einem Rechner in meinem Netzwerk mitlaufen lassen.
VG
Jürgen

[Msinn]

Ist für kleine Installationen ohne größeren Einsatz von IoT ohne weiteres valide.

[knxmfbp]

Ist für kleine Installationen ohne größeren Einsatz von IoT ohne weiteres valide.

Sehe ich genauso, für ein Einfamilienhaus mit Temperatur Sensoren in jedem Raum ist das von der Performance her absolut nutzbar. Wenn aber jemand das Plugin erweitern möchte, warum nicht. Ich selbst könnte mir viele schöne Anwendungen ausmalen wenn das Plugin als Alternative zu dem smartVisu websockets existieren würde.