MQTT 2.4.0 Binding wofür das "State Topic"

[FelixK]

Hallo,

ich habe das MQTT 2.4.0 Binding nun zum Laufen gebracht und meine Ventilsteuerung, die auf einem anderen Raspberry läuft, damit eingebunden. Es funktioniert auch alles so weit.

Ich habe es nun so gelöst, dass ich für alle Ventile ein Topic "/garden/irrigation" habe. Je nach Ventil wird ein JSON als Message geschickt: {'"valve":1,"pin":7,"state'"ON"}. Die Message wird auf dem zweiten Pi ausgewertet und entsprechend des gesendeten Pin wird der State auf "ON" oder "OFF" gesetzt.

Das Problem bei dem Observable Pattern ist ja, dass man nicht weiß, ob wirklich jemand auf den Event / die Nachricht hört. Da dachte ich kommt das "State Topic", das ich zu jedem Channel konfigurieren kann, ins Spiel. Also habe ich z.B. für den Ventil 1 Channel das Topic "/garden/irrigation/valve-1" eingetragen und auf dem zweiten Raspberry in dieses Topic 1 oder 0 gepublished. Je nachdem, ob ich das Ventil geöffnet oder geschlossen habe.

Ich wäre nun davon ausgegangen, dass auf OpenHab-Seite darauf reagiert wird. Testhalber habe ich auch einfach mal immer 0 zurückgegeben, um einen Fehler vorzutäuschen.

Könnt ihr mir helfen, wofür dieser State genau da ist und wie/wo ich den ggf. auswerte?

[udo1toni]

Das stateTopic ist das Topic, auf dem ein Gerät seinen Status sendet.
Normalerweise baut man die Nachrichten in mqtt so auf, das jedes Gerät ein eigenes Topic hat. In Deinem Fall z.B. garden/irrigation/valve1/ Man beachte das Fehlen eines führenden Slashes, welcher zwar auch zu Beginn erlaubt, aber unnötig und auch nicht empfohlen ist.
Unterhalb dieses Topic würde man dann z.B. ein topic state und ein topic command anlegen, also so:

Code: Alles auswählen

garden/irrigation/valve1/state
garden/irrigation/valve1/command

Das obere Topic wird dann von openHAB abonniert. Das Ventil (bzw. die Steuersoftware) sendet auf diesem Topic den Status des Ventils, z.B. ON/OFF oder OPEN/CLOSED, während die Steuersoftware für das Ventil das untere Topic abonniert und auf die Steuerbefehle reagiert, die (z.B. von openHAB) an dieses Topic gesendet werden.
Man kann natürlich auch andere Arten der Kommunikation einsetzen, z.B. per JSON oder XML, aber dann gibt es jedenfalls keine Möglichkeit, die Daten direkt auszuwerten und einem einzelnen Ventil zuzuordnen, stattdessen muss man dann das JSON per Rule analysieren und die Items per postUpdate() beeinflussen.

[FelixK]

Hallo udo1toni,

sorry, dass ich erst jetzt antworte. Ich war im Kurzurlaub...

Vielen Dank für die ausführliche Erklärung. Dann werde ich das so entsprechend nochmal umbauen. Testhalber für ein Ventil hatte ich es so in der Art ja schon, da machte es aber keinen Unterschied, ob ich OFF oder ON als state zurückgegeben habe und was ich über den Switch im OpenHab gesetzt hatte. -> z.B. Switch auf "ON", aber das state topic gibt OFF zurück. Dann hätte ich einen Fehler erwartet, oder dass der Switch automatisch auf OFF gesetzt wird.

Muss ich das dann per rule machen? Muss ich für mein Python Script ein eigenes Log haben oder geht es auch irgendwie, dass ich eventuelle Fehler an OpenHab zurückgebe und OpenHab sie mir ausgibt (im Log oder auf der Oberflöche)?

[udo1toni]

Da Du ohnehin MQTT verwendest, kannst Du eventuelle Fehler im Klartext über MQTT als String übertragen - in einem eigenen Topic, welches Du auf openHAB-Seite nur einem Item zuordnen musst (mit stateTopic). Das funktioniert natürlich nur, solange der Fehler nicht eine fehlerhafte Verbindung zum MQTT Server ist
Das Item (also der Switch) sollte durch den Status OFF auch wieder auf den Status OFF wechseln, der Status kann ja nur nach dem Befehl kommen.
Ansonsten kannst Du das Item mittels autoupdate="false" darauf konfigurieren, dass openHAB den Status des Items nicht selbst ändert. Wenn Du dann den Befehl ON sendest, bleibt der Status des Items unverändert, selbst wenn der Status NULL sein sollte. Nur ein postUpdate() oder der Empfang eines stateTopic wird dann den Status ändern.

[FelixK]

Vielen Dank für die Erklärung. Das mit dem eigenen Topic + Item ist eine sehr gute Idee. Das mit dem Status werde ich im Zuge des Umbaus dann auch nochmal testen und mir auch die autoupdate-Funktion anschauen - klingt sehr interessant und macht aus meiner Sicht auch Sinn, es in dem Fall zu verwenden.

[udo1toni]

Grundsätzlich ist autoupdate="false" immer die bessere Wahl, sobald man einen echten Status vom betreffenden Binding erhält. Leider ist bisher nicht vorgesehen, das zu automatisieren.

[FelixK]

Die autoupdate-Funktionalität konnte ich aus zeitlichen Gründen bisher leider noch nicht einbauen. Den Status sende ich jetzt aber immer. Ich gehe so vor, dass ich mir ein JSON als command schicke mit den Informationen pin, valve, state. Anhand der pin und state Information wird der richtige Pin am Raspberry auf den state geschalten. Anschließend baue ich mir das Topic dynamisch zusammen bzw. ersetze einen Platzhalter in meinem Topic-Namen

Code: Alles auswählen

'garden/irrigation/valve-{}-state'.format(valve)

an das ich dann wiederum den nun geschalteten state publishe.

Da ich meine Gartenbewässerung um noch mindestens 7 weitere Ventile ergänzen möchte ich das für mich nach aktuellem Ermessen übersichtlicher, als es für jedes Ventil separat zu implementieren.

Je mehr ich mit OpenHab mache, umso begeisterter bin ich eigentlich. Klar habe ich jetzt hier auch einiges an Hilfe bekommen, aber auch über Google wird man sehr schnell zu vielen Themen fündig und generell ist es sehr intuitiv. Wenn man einmal ein Binding / Thing / Item / Sitemap angelegt hat, dann funktioniert das meiste nach dem selben Prinzip. Mittlerweile ist auch mein Photovoltaik-Inverter und meine Temperatur- und Luftfeuchtigkeit-Sensoren Teil meiner OpenHab-Umsetzung. Dazu noch OpenWeatherMap. Heute kommt hoffentlich noch ein Durchflussventil dazu, das ich im Sommer dann an die Pumpe anschließen möchte und mit Regeln wie "wenn Ventil X offen, aber durch das Durchflussventil fließt kein Wasser, dann Telegram-Nachricht an mich" automatisieren will.
-> Sorry, wenn ich abschweife, aber ich find's cool!