MQTT Topic/Payload Dokumentation

[Joe_D]

Hallo Zusammen,

habe bislang ein FHEM-System am laufen das ich eventuell mit iobroker ablösen möchte. An Hardware existiert bei mir

• ein AS1440 Stromzähler mit D0-Schnittstelle der Obis ausgibt aber kein SML spricht. Da FHEM nicht in der Lage war den Stromzähler "gescheit" auszulesen (den kann man von 300Baud auf 9600Baud umschalten) habe ich ein C-Programm geschrieben das dies vom Timing her richtig macht und an die Werte einfach auf die Konsole schreibt. Die werden dann mittels Pipe in FHEM geschrieben.
• eine Junkers Heizung mit Heatronic3-Protokoll das an einem USB-Adapter von Norbert S. hängt (https://www.mikrocontroller.net/topic/317004?page=single). Die wurde als einziges direkt von FHEM unterstützt, da Norbert S. etwas dafür geschrieben hatte.
• eine Junkers Lüftungsanlage die Modbus-TCP spricht aber leider ziemlich dämlich zu betreiben ist. Zum Beispiel kann man hier nicht einfach sagen "Stufe 4 für die nächsten 30 Minuten", sondern man muss per Modbus-TCP aus dem Automatikprogramm nach Manuell schalten. Dann die Stufe ändern. Dann einen Timer "außerhalb" (FHEM) setzen, der nach der Zeit die Kiste wieder ins Automatikprogramm setzt. Dafür musste ich in FHEM einen eigenen Modbus-Gerätetreiber schreiben
• 8 serielle Modbus Stromzähler DDS238-1ZN an einem Modbus2USB-Adapter. Die Zähler liefern 10 Werte, unter anderem den aktuellen Strom. Hier war es in FHEM nicht möglich alle 8 Zähler einfach so schnell wie möglich hintereinander abzufragen. Unter 10 Sekunden gab es immer wieder Fehler. Auch hier habe ich ein C Programm geschrieben das jetzt innerhalb einer Sekunde alle 8 Zähler auslesen kann und die Werte auf die Konsole schreibt wo diese mittels Pipe in FHEM geschrieben werden
• 1 seriellen Modbus für den Gaszähler-Impulszähler der direkt in FHEM alle 10 Sekunden ausgelesen wird
• Selbstbau IO-System mit 128 Eingängen und 128 Ausgängen das über USB gesteuert wird und auch über USB die aktuellen Stati ausgibt. Hierüber werden sämtliche Lampen an- und ausgeschaltet, Fenster- und Tür- und Klingelkontakte, Schlösser und Bewegungsmelder ausgewertet, Rollladen und Garagentor rauf- und runtergefahren. Dazu gab es ein serielles IO-Modul in FHEM das ich aber leider erst von Bugs befreien musste bevor ich es einsetzen konnte

Bei FHEM ist mir aufgefallen das diese SmartHome-Lösung eigentlich gar nicht in der Lage war dumme Hardware "intelligent" einzubinden. Ein Modbus der nur alle 10 Sekunden irgendwas pollen kann ist schön für ein Gerät das eine Super Schnittstelle über Modbus bietet und nur "bedient" werden muss aber eine Katastrophe für z.B. meine Junkers "Lüftungssteuerung".

Aber auch beim einfachen Auslesen von Stromzählern bin ich mit den Standardmodulen von FHEM sofort auf die Nase gefallen. Beim AS1440 muss man nachdem man auf 9600 Baud umschaltet 400ms warten. Das habe ich in Perl unter FHEM nicht sauber hingekriegt. Genauso das Auslesen von 8 Modbus Stromzählern "einfach so schnell wie möglich hintereinander", ist wohl schon eine Spezialanwendung.

So musste ich relativ viel sowohl an FHEM an Modulen rumbasteln und erstellen (Perl ) wie auch externe Programme schreiben die die Daten aufbereiten.

Diese (negativen) Erfahrungen brachten mich zu der Frage: Warum besteht eine Smarthome-Steuerung eigentlich nicht grundsätzlich nur aus einem MQTT-Broker der sämtliche Daten bereitstellt und externe Programme speisen einfach den MQTT-Broker? Super wäre in so einem Fall wenn Topic und Payload einfach irgendwie sein könnten und auf dem Adapter könnte man das einfach konfigurieren oder als Template hinterlegen.

Die Lösung nur mit MQTT-Broker möchte ich jetzt mit iobroker probieren.

Der iobroker läuft schonmal soweit, ein mosquitto ist installiert und auch der MQTT Broker/Client-Adapter ist einsatzbereit.

Aus meiner naiven Sicht muss ich also "nur noch" z.B. meinen beiden Zähler-Auslese-Programmen beibringen Ihre Daten an den MQTT-Broker zu senden.

Und nun meine Fragen:

• Kann der Adapter auf unterschiedliche Payloads oder Topics konfiguriert werden
• Braucht es einen bestimmten Aufbau vom Topic? Wenn ja, wo ist das dokumentiert?
• Braucht es einen bestimmten Aufbau vom Payload? Wenn ja, wo ist das dokumentiert?
• Wie funktioniert ein Mapping von Gerätearten? Also wie wird die Rückmeldung von einem Fenster erkannt? Wie die Rückmeldung einer Tür?
• Wie sieht Topic oder Payload für verschiedene Gerätearten aus? Fenster? Türen? Rollladen? Bewegungsmelder?

Ich habe dazu leider so gut wie nichts dazu gefunden unter https://github.com/ioBroker/ioBroker.mqtt/blob/master/README.md

Gruß

Jochen

[Gargano]

@joe_d Der mqtt Adapter nimmt die Topics entgegen, legt Datenpunkte an und schreibt die Werte rein. Eine Weiterverarbeitung muss dann mit anderen Adaptern oder JS erfolgen

[Homoran]

@joe_d sagte in MQTT Topic/Payload Dokumentation:

Die Lösung nur mit MQTT-Broker möchte ich jetzt mit iobroker probieren.
Der iobroker läuft schonmal soweit, ein mosquitto ist installiert und auch der MQTT Broker/Client-Adapter ist einsatzbereit.

wenn du bereits einen Broker hast, kannst du bei iobroker auch den MQTT-Client Adapter nehmen

[Joe_D]

@gargano Das bedeutet?

Bei Homeassistant z.B. gibt es bei MQTT ein "Discovery", wenn man Meldungen in dem Format sendet werden z.B. Lichter usw. angelegt (https://www.home-assistant.io/docs/mqtt/discovery). Das ist dort alles schön beschrieben.

[Joe_D]

@homoran Ja, ich kann auch den MQTT-Client Adapter nehmen. Und ich kann ja mit

mosquitto_pub -h 127.0.0.1 -t test/lampe/1/off -m "Lampe ist aus"

etwas an meinen Broker schicken. Was macht der MQTT-Client Adapter denn damit?

[Homoran]

@joe_d sagte in MQTT Topic/Payload Dokumentation:

Was macht der MQTT-Client Adapter denn damit?

er nimmt es an, legt einen Datenpunkt an und schreibt den Wert da hinein

Ist aber schon einige Jahre her, dass ich damit gearbeitet hatte

[Gargano]

@joe_d Der mqtt Adapter macht nichts weiter damit. Nur den Wert in den Datenpunkt schreiben. Bei mir werden die Heizungsdaten übermittelt. Die zeige ich dann in der Vis mit widgets und einer Grafik an.
Anderes Beispiel,, übermitteln der Stromdaten der Waschmaschine, und Bestimmung wann die Maschine fertig ist. Dies wird mit einenJavascript erledigt

[Joe_D]

@gargano sagte in MQTT Topic/Payload Dokumentation:

@joe_d Der mqtt Adapter macht nichts weiter damit. Nur den Wert in den Datenpunkt schreiben. Bei mir werden die Heizungsdaten übermittelt. Die zeige ich dann in der Vis mit widgets und einer Grafik an.

Ok, ist mir nun auch gelungen:

Nur fehlt mir jetzt echt irgendwie ein Leitfaden.

Wie kann ich eine schaltbare Lampe (am Besten automatisch) mit MQTT hinzufügen?

[Gargano]

@joe_d mit einem kleinem Script, der auf den Event triggert, also in JS ein on -Event. In dem Event dann setstate(dpname,wert) die Lampe schalten.
Du kannst es auch über Blockly machen, da kenn ich mich aber nicht aus. Ich bevorzuge JS, da weiß ich was der macht
Ansonsten gibt es noch den Szenen Adapter

[Joe_D]

@gargano Verstehe ich leider nicht wirklich. Gibt es irgendwo ein Beispiel für sowas? Also eine Lampe die dem MQTT-Broker ihren aktuellen Zustand meldet (und wie der zugehörige Payload aussehen muss/sollte) und in iobroker ein Lampenicon auf das man draufdrückt und das dann je nach Zustand dem MQTT-Broker "was" schickt.
Oder gibt es für solche Dinge keinen "Standard", d.h. muss man dies alles selbst progammieren?

[Gargano]

@joe_d muss man alles selber machen. Aber schau Dir mal den Szenen Adapter an

[hydrotec]

@joe_d

Hallo Jochen,

es gibt noch keine offizielle Dokumentation, in der Form wie du es gebrauchen könntest.
Derzeit arbeite ich an einer allgemeinen Dokumentation zu MQTT.
Hier kannst du dir mal ein Vorab ansehen, ist noch nicht ganz fertig.

@joe_d sagte in MQTT Topic/Payload Dokumentation:

Kann der Adapter auf unterschiedliche Payloads oder Topics konfiguriert werden

Ich gehe mal davon aus, das du den Adapter "MQTT Broker/Client" meinst, welcher in der Instanz als Client konfiguriert wird. Die Verbindung zu mosquitto hast du ja schon funktionabel hergestellt.
Innerhalb der Instanz hast du die Möglichkeit die gewünschten Topics anzugeben.
So kannst du mehrere Instanzen anlegen, welche auf unterschiedliche Topics hören.

Gruß, Karsten

[Joe_D]

@hydrotec Danke für die Infos.

Bislang schicke ich einfach irgendwelche Sachen an irgendwelche Topics, die werden "leider" nur als Zustandstyp Zeichenkette, Rolle variable angelegt:

Cool fände ich nun, wenn die rot umrandeten Felder per MQTT besetzt werden könnten:

Zum Beispiel über ein spezielles Topic, /iobroker/mqttconfig mit Inhalt:

{
  "common": {
    "name": "/devices/wb-adc/controls/lala1",
    "write": false,
    "read": true,
    "role": "switch",
    "type": "boolean"
  }
}

Das dann eben angelegt oder geändert wird sofern es das nicht gibt oder andere Werte enthält...

[hydrotec]

@joe_d

Denke nicht das es vorgesehen ist, da etwas zu ändern.
Generell funktionieren die Objekte ja so wie sie angelegt sind.
Aber du kannst gerne auf GitHub nachfragen.
https://github.com/ioBroker/ioBroker.mqtt

Nur für mich, aus Interesse, was möchtest du durch diese Änderung erreichen?

[mickym]

@joe_d Das macht keinen Sinn. mqtt kennt im Prinzip keine Datentypen und die Daten werden so weiter transportiert, wie sie reingekommen sind. Deswegen wird immer alles als String und Buffer interpretiert. Als Transport bieten sich JSON Strings an - damit kann ich dann im JS, Blockly oder Node Red wieder originale Datentypen draus machen.

[Joe_D]

@hydrotec Im Endeffekt wäre sowas wie https://www.home-assistant.io/docs/mqtt/discovery ganz hübsch:

@mickym Es geht mir ja auch nicht um MQTT selbst, das ist ja nur das Transportmedium, sondern um iobroker. iobroker hat doch unterschiedliche roles/types/write und read-Eigenschaften (die ich bislang noch nicht so ganz verstehe). Warum und wozu kann ich die manuell anpassen?

Wenn es keinen Sinn macht, dann müsste es doch eigentlich ausreichen alles über "variable String" zu erledigen und es bräuchte gar keine unterschiedlichen roles und types?

[mickym]

@joe_d Du sollst da drin auch nichts anpassen. In der Regel sind diese Felder nur dazu da, um Datenpunkte unter 0_userdata entsprechend zu konfigurieren. Alles andere sollten in der Regel die Adapter machen. Und der mqtt-Adapter interpretiert nun mal keine Datentypen (und sollte das meiner Meinung nach auch nicht).

[Joe_D]

@mickym Das iobroker Konzept verstehe ich noch nicht so ganz. Warum gibt es unterschiedliche roles und types? Wo werden die verwendet? In Jarvis konnte ich so einen mqtt-Datenpunkt auf ein Widget legen, musste es aber von Hand konfigurieren. Bislang konnte ich noch nicht rausfinden wie ein Datenpunkt beschaffen sein muss um automatisch z.B. als Schalter oder Licht dargestellt zu werden....

[mickym]

@joe_d Da gibt es sicher kompetentere Ansprechpartner als mich. In der Regel ist für einen Benutzer vorgesehen, Räume oder Funktionen über die Aufzählungen den Objekten zuzuordnen bzw. umgekehrt den Aufzählungen die Objekte zu zuordnen.

Diese Objekt Eigenschaften sind in der Regel (ausser userdata oder zur Fehlerbehebung) zum Beschreiben durch den Adapter gedacht.

Ich denke @Homoran, @paul53 oder @apollon77 können Dir das genauer erklären bzw. auf eine aktuelle Dokumentation hinweisen.
Ich gebe hier nur wieder, wie ich das System jetzt aus der Praxis verstanden habe. Bin aber auch kein Adapterentwickler.

[apollon77]

Also "roles" werden von Visualisierungs-UIs genutzt (bzw KÖNNEN!) um automatisiert richtige Widgets anzuzeigen ohne das dies durch den User konfiguriert wird. Material macht dies zB so. Andere Visus nutzen es nicht oder nutzen es nur teilweise. Genauso der "Type" kann in Verbidnung genutzt werden um zB eine Checkbox bei Boolean zu nutzen oder (in verbindung mit "states") eine Selection mit relevanten Werten oder ein Zahlenfeld mit hoch/runter-Buttons für Zahlen.

Die "Functions" (aka Funktionen) und "Rooms" (Räume) sind ein von Homematic übernommenes Konzept was eine Zweistufige Strukturierung der Geräte erlaubt. Visus, wie Material o.ä., nutzen diese um auch hier automatisiert Strukturen anzuzeigen.