MQTT State Topic ändert OpenHab Switch nicht

[FelixK]

Hallo,

ich weiß nicht, ob ich einen Denk- bzw. Verständnisfehler habe, aber ich würde erwarten, dass, wenn ich beim MQTT Thing im MQTT State Topic ein Topic eintrage, an das bei einer Statusändrung Open oder Closed geschickt wird, dass sich dann auch der dazugehörige Switch ändert.

Und zwar ist es so, dass ich per MQTT ein Skript ansteuere, das wiederum einen Motor ansteuert Wenn dieser seine Endposition erreicht hat, dann merkt ein weiteres Skript, das Fenstersensoren abfrägt, dass diese erreicht ist und sendet an das MQTT State Topic "Open" oder "Closed". So lange ich den Motor über OpenHab steuere ist das State Topic wohl egal, ich möchte an den Raspberry Pi aber auch Schalter anschließen, damit ich den Motor manuell steuern kann.

Wenn sich nun die Position des Motors geändert hat, weil die Schalter betätgt wurden, dann soll das auch in OpenHab abgebildet werden. Ich teste das, in dem ich den Motor gar nicht über OpenHab steuere und aktuell fix in der Open Position habe. In OpenHab stelle ich den Switch auf Closed und hätte erwartet, dass der Switch sich auf Open stellt, sobald der Sensor das erste Mal abgefragt wurde. Dem ist aber nicht so.

Ist das so richtig oder sollte es wie von mir erwartet verhalten?

Vielen Dank und viele Grüße

[udo1toni]

openHAB kennt für Contact Items die Status OPEN und CLOSED.
Ein auf ein Contact Item verlinkter Channel muss also exakt OPEN und CLOSED liefern, nicht Open oder Closed.

Wie ist Dein Channel definiert (Code Ansicht, Text kopieren und hier als Code markiert einfügen)
Was ist die exakte Payload (Groß-/Kleinschreibung für jeden Buchstaben beachten).

Da es sich um ein Motor getriebenes Fenster handelt: Ich habe selbst ein motorisiertes Fenster und steuere es über ein Rollershutter Item an. Ich nutze als Rückmeldung die Werte 0 - 100. Das entsprechende Icon funktioniert bei mir über ein Proxy Item - ich nutze das schon seit openHAB1.1 so und habe es nie für nötig erachtet, das noch mal zu ändern. Die Prozentanzeige ermöglicht es mir, das Fenster nur teilweise zu öffnen und dennoch den genauen Zustand zu kennen - ok, nutze ich nicht (mehr), aber es ginge...

[FelixK]

Danke dir.

Kurz zur Vorabinfo: Ich nutze den Linearmotor nicht für ein Fenster, sondern für eine Hühnerklappe. Die beiden Fesntersensoren verwende ich, damit ich mir per Telegram Nachricht schicken lassen kann, ob/dass die Klappe geöffnet wurde. In 99,9% der Fälle bin ich sowieso daheim und stelle morgens sicher, dass die Klappe offen und Abends geschlossen (+ alle Hühner drin) ist. Im Fall von Urlaub, o.ä., wenn man ggf. den "Hühnersittern" Bescheid geben muss, will ich das schon wissen.

Wie dem auch sei. Ich habe den Status nun komplett in Großschreibung geändert. So sieht das Thing aus:

Code: Alles auswählen

UID: mqtt:topic:717196b863:coop_door
label: Hühnerklappe
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:717196b863
location: Garten
channels:
  - id: open_close
    channelTypeUID: mqtt:switch
    label: Open/Close
    description: Opens and closes the chicken coop door
    configuration:
      commandTopic: garden/chickens/coopdoor
      stateTopic: garden/chickens/coopdoor/state
      off: '{"state": "CLOSE"}'
      on: '{"state": "OPEN"}'

Als Zusatzinfo: Ich habe zwei Raspberry Pis. Auf dem einen im Garten läuft u.a. meine Beregnungssteuerung und die Steuerung der Hühnerklappe über Skripte, auf dem anderen läuft OpenHabian und der Mosquitto Broker. Auf dem "Garten Pi" laufen für die Hühnerklappe zwei Skripte: das eine ist dafür da, den Motor zu steuern und Befehle von OpenHabian zu bekommen, den Motor hoch oder runterzufahren. Das andere überwacht die Fenstersensoren und schickt den Status im Payload an das stateTopic garden/chickens/coopdoor/state. Sowohl das Motorskript, um den HIGH GPIO Pin auf LOW zu setzen, als auch OpenHabian sollen auf dieses Topic hören. Beim Motorskript kommt die Info an.

[udo1toni]

Ah. Nun ja, ob nun Fenster oder Hühnerklappe bleibt sich eh gleich, allenfalls, dass es bei der Hühnerklappe tatsächlich keinen Grund geben dürfte, die Klappe teilweise zu öffnen.

Kurzer Schwenk zu Begrifflichkeiten: Ein Linearmotor wird das nicht sein , sondern ein Linearantrieb. Letzterer arbeitet mit einer Spindel, die durch den Motor gedreht wird. Da die Spindel als Gewindestange ausgelegt ist, wird die Drehung mittels Mutter in eine lineare Bewegung umgesetzt.
Ein Linearmotor hingegen funktioniert ähnlich einem Schrittmotor, nur nutzt er eine Schiene, auf der immer abwechselnd Nord- und Südpol eines Permanentmagneten angebracht sind. Mittels dreier Spulen wird dann der Schlitten direkt linear angetrieben, es gibt keinerlei Drehbewegung.
Das wird z.B. in (äußerst teuren) CNC Maschinen verwendet. Das Funktionsprinzip ist ähnlich wie bei der Magnetschwebebahn

Wie muss den die Payload des commandTopic aussehen, tatsächlich {"state":"CLOSE"} bzw. {"state":"OPEN"}?
Oft braucht es für den Befehl gar kein JSON, "sauber" sähe die Definition so aus:

Code: Alles auswählen

UID: mqtt:topic:717196b863:coop_door
label: Hühnerklappe
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:717196b863
location: Garten
channels:
  - id: open_close
    channelTypeUID: mqtt:switch
    label: Open/Close
    description: Opens and closes the chicken coop door
    configuration:
      commandTopic: garden/chickens/coopdoor
      stateTopic: garden/chickens/coopdoor/state
      transformationPattern: JSONPATH:$.state
      formatBeforePublish: '{"state": "%s"}'
      off: "CLOSE"
      on: "OPEN"

Ankommend wird also die JSONPATH Transformation genutzt, um den Wert im Feld state auszuwerten.
Abgehend wird der zu sendende String über formatBeforePublish definiert. Die beiden Werte OPEN und CLOSE werden anstatt ON und OFF verwendet.

Der Unterschied: Du kannst nun beim Senden ein ganz anderes Format verwenden, z.B. auch nur die "rohen" Werte OPEN und CLOSE, oder auch ein anderes JSON. Außerdem kann es auch passieren, dass die Gegenstelle das JSON anders formatiert, z.B. die Leerzeichen weg lässt oder Umbrüche einbaut. In beiden Fällen würde die Variante ohne transformationPattern bzw. formatBeforePublish mindestens nicht zuverlässig funktionieren.

[FelixK]

Falls du/ihr euch meine Antwort nicht komplett durchlesen wollt: Es funktioniert jetzt mit dem State, siehe Text unterhalb des letzten Zitats.

Ah. Nun ja, ob nun Fenster oder Hühnerklappe bleibt sich eh gleich, allenfalls, dass es bei der Hühnerklappe tatsächlich keinen Grund geben dürfte, die Klappe teilweise zu öffnen.

Nein, das darf tatsächlich nie passieren. Entweder ganz auf, dass die Hühner sicher und einfach rauskommen, ohne sich auch bei einem etwaigen Gedränge zu verletzen, oder komplett zu, damit weder sie raus (oder beim Reinigen rein), noch irgendein Räuber hinein kommt. Deshalb sind mir die Sensoren auch ziemlich wichtig.

Kurzer Schwenk zu Begrifflichkeiten: Ein Linearmotor wird das nicht sein , sondern ein Linearantrieb. Letzterer arbeitet mit einer Spindel, die durch den Motor gedreht wird. Da die Spindel als Gewindestange ausgelegt ist, wird die Drehung mittels Mutter in eine lineare Bewegung umgesetzt.
Ein Linearmotor hingegen funktioniert ähnlich einem Schrittmotor, nur nutzt er eine Schiene, auf der immer abwechselnd Nord- und Südpol eines Permanentmagneten angebracht sind. Mittels dreier Spulen wird dann der Schlitten direkt linear angetrieben, es gibt keinerlei Drehbewegung.
Das wird z.B. in (äußerst teuren) CNC Maschinen verwendet. Das Funktionsprinzip ist ähnlich wie bei der Magnetschwebebahn

Danke für die Klarstellung. Auch, wenn die Hühner fast luxuriöser leben als ich, ist es doch "nur" der günstigere Linearantrieb. Ich kann es nichtmal auf das große "A" schieben, da die es korrekt ausgezeichnet haben.

Wie muss den die Payload des commandTopic aussehen, tatsächlich {"state":"CLOSE"} bzw. {"state":"OPEN"}?
Oft braucht es für den Befehl gar kein JSON

Ja, das wird von meinem Motorsteuerungsskript so erwartet, allerdings dachte ich damals noch, dass ich vielleicht noch andere Befehle/Infos an die Tür senden will/muss und es so schon mal vorbereiten wollte.

Ich habe es aber jetzt so umgebaut, dass nur noch "OPEN" und "CLOSE" als Payload gesendet wird.

, "sauber" sähe die Definition so aus:

Code: Alles auswählen

UID: mqtt:topic:717196b863:coop_door
label: Hühnerklappe
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:717196b863
location: Garten
channels:
  - id: open_close
    channelTypeUID: mqtt:switch
    label: Open/Close
    description: Opens and closes the chicken coop door
    configuration:
      commandTopic: garden/chickens/coopdoor
      stateTopic: garden/chickens/coopdoor/state
      transformationPattern: JSONPATH:$.state
      formatBeforePublish: '{"state": "%s"}'
      off: "CLOSE"
      on: "OPEN"

Danke. Interessant zu sehen, auch, dass man über den Code das Formular "manipulieren" und Formularfelder "freischalten"/sichtbar machen kann.

Ankommend wird also die JSONPATH Transformation genutzt, um den Wert im Feld state auszuwerten.
Abgehend wird der zu sendende String über formatBeforePublish definiert. Die beiden Werte OPEN und CLOSE werden anstatt ON und OFF verwendet.

Der State im stateTopic wurde bisher immer nur als OPEN/CLOSED, ohne das JSON außenherum zurückgeschickt. Von daher benötige ich das transformationPattern nicht. Auch die formatBeforePublish Konfiguration habe ich entefernt, da ich jetzt nur noch OPEN und CLOSE schicke.

Der Unterschied: Du kannst nun beim Senden ein ganz anderes Format verwenden, z.B. auch nur die "rohen" Werte OPEN und CLOSE, oder auch ein anderes JSON. Außerdem kann es auch passieren, dass die Gegenstelle das JSON anders formatiert, z.B. die Leerzeichen weg lässt oder Umbrüche einbaut. In beiden Fällen würde die Variante ohne transformationPattern bzw. formatBeforePublish mindestens nicht zuverlässig funktionieren.

Heißt das, dass die Open/Close Werte dann sowohl für den State, als auch für das Command (wenn ich den Switch nach links/rechts schiebe) gelten? Ich habe es nämlich zum Laufen gebracht, indem ich statt OPEN/CLOSED nur noch ON und OFF schicke. Jetzt funktioniert es einwandfrei. Heißt aber, es müsste auch mit OPEN/CLOSE (nicht CLOSED) gehen?!
Da ich gerade daran bin, mein Skript so umzubauen, dass nicht bei jeder Abfrage des Sensors ein Statuswechsel geschickt wird, sondern nur, wenn dieser sich wirklich geändert hat, kann ich das rerst nachher probieren.

Auf jeden Fall bin ich froh, dass ich eine Baustelle weniger habe und jetzt weiterbasteln kann. Vielen Dank nochmals!!!

[udo1toni]

Wichtig ist halt, dass der ankommende und der abgehende Wert "identisch" ist. Ein von ON oder OFF abweichender Wert (beim switch Channel) wird über die Parameter on und off gesetzt. Über formatBeforePublish sorgt man dafür, dass die Payload erst noch erweitert wird, bevor der Text aus on bzw. off gesendet wird, über das transformationPattern kann man die ankommende Payload so manipulieren, dass entweder der on-Wert oder der off-Wert geliefert wird.
Die exakte Schreibweise ist einzuhalten (Groß/Kleinschreibung).
Wenn Du die Gegenstelle unter Deiner Kontrolle hast, ist es das einfachste, dort jeweils ein separates Topic und die Switch-Status (also ON und OFF) zu verwenden. Wenn Du weitere details über das selbe Topic zurückmelden willst, bietet sich JSON an, wobei Du auch dann ON/OFF als Wert bevorzugen solltest.
OPEN/CLOSED ist nicht identisch zu OPEN/CLOSE, da fehlt hinten das D. Wenn man die Situation so vorfindet und keinen Einfluss auf die Quelle hat, kann man sich hier aber mit einer verketteten Transformation behelfen (also zunächst den Wert per JSONPATH extrahieren und anschließend über eine Mapping das CLOSED gegen ein CLOSE austauschen, wenn CLOSE der zu sendende Befehl ist. Die Anpassung muss auf der Empfangsseite konfiguriert werden (wobei, es kann sein, dass man mit der outgoingValueTransformation auch den zu sendenden Wert noch manipulieren kann - ich bin mir aber nicht ganz sicher, was den "Signalfluss" innerhalb des Addons betrifft)

Was das "sichtbar machen" von Einträgen betrifft: Es gibt im Channel oben rechts ein Feld "Show Advanced", mit dem werden alle zur Verfügung stehenden Optionen angezeigt.