"Dummy switch" zum Empfangen eines Status und Verwendung in Regel?

[FelixK]

Hallo,

ich steuere eine Hühnerklappe über zwei Skripte: Das eine steuert den Motor (hoch, stop, runter), das andere überwacht zwei Fenstersensoren, die den Zustand der Klappe (offen oder geschlossen) überwachen. Die Skripte und OpenHab kommunizieren über Mqtt.

Damit ich morgens und abends weiß, ob die Klappe korrekt geschlossen und geöffnet wurde, will ich mir deren Zustand per Telegram schicken lassen, sobald die Klappe offen bzw. geschlossen ist.

Was mich nicht interessiert ist, wenn der Hühnerklappen Switch in OpenHab seinen Zustand ändert. Darüber will ich nicht per Telegram informiert werden. Deshalb habe ich zuerst meinem Hühnerklappen Thing einen weiteren Channel hinzugefügt, der lediglich ein State Mqtt Topic hat, an das das Sensorskript den Status (Open|Close) der Fentersensoren schickt. Aus diesem Thing habe ich mir wiederum einen "Dummy Switch" in OpenHab gebaut, der so aussieht

Code: Alles auswählen

Switch Garden_Chickens_Coop_Door_State "Hühnerklappen Status []" <garagedoor> { channel="mqtt:topic:717196b863:coop_door:coopdoor-state" }

Diesen Dummy Switch will ich nun in einer Regel nutzen, damit mir über Telegram eine Nachricht geschickt wird, wenn die Klappe offen bzw. geschlossen wird. Mein Gedanke war, dass sich der Zustand dieses "Dummy Switches" nur ändert, wenn mein Sensorskript eine Mqtt Nachricht veröffentlicht. Da mich auch interessiert, ob der Zustand offen oder geschlossen ist, habe ich gleich zwei Regeln gebaut - ansonsten war mir nicht klar, wie ich den Zustand in die Telegram Nachricht bekomme. Pro Zustand eine. Hier eine davon:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Garden_Chickens_Coop_Door_State
      state: CLOSE
      previousState: OPEN
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: >-
        val telegramAction = getActions("telegram",
        "telegram:telegramBot:MEINBOT")
          telegramAction.sendTelegram("Hühnerklappe erfolgreich geschlossen")
    type: script.ScriptAction

[udo1toni]

Hast Du eine konkrete Frage?

Bezüglich der Rule, es gibt in jeder Rule, die über das changed Ereignis getriggert wurde eine implizite Variable, die den neuen Status enthält. Eine weitere Variable enthält den alten Status.
Da Du hier JavaScript verwendest (was ich nicht nutze) kann ich nicht zu 100 % sicher sagen, ob die Variablen exakt so verwendet werden können, aber als Beispiel, wie das aussehen könnte:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Garden_Chickens_Coop_Door_State
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: >-
        val telegramAction = getActions("telegram", "telegram:telegramBot:MEINBOT")
        var message = "Hühnerklappe erfolgreich ge"
        if(newState == CLOSED) message = message + "schlossen"
        if(newState == OPEN)   message = message + "öffnet"
        telegramAction.sendTelegram(message)
    type: script.ScriptAction

Du lässt also die Eingrenzung der Status beim Trigger weg. Stattdessen fragst Du den aktuellen Status ab. Falls Du bei einem Neustart die Meldung unterdrücken willst (der Item Status kommt dann von NULL) kannst Du das mit einer weiteren Bedingung abbilden:

Code: Alles auswählen

if(previousState == NULL) return;

Falls der Status zuvor NULL war, wird die weitere Verarbeitung der Rule abgebrochen.
Wie gesagt, ich arbeite nur selten mit JavaScript, es kann also sehr gut sein, dass in obigem Codebeispiel der eine oder andere Fehler lauert, aber das Prinzip sollte klar sein.
Ansonsten hier noch als DSL Rule:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Garden_Chickens_Coop_Door_State
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: >-
        if(!(previousState instaneof OpenClosedType)) return;
        if(!(newState instaneof OpenClosedType)) return;
        val telegramAction = getActions("telegram", "telegram:telegramBot:MEINBOT")
        var message = "Hühnerklappe erfolgreich ge"
        if(newState == CLOSED) message = message + "schlossen"
        if(newState == OPEN)   message = message + "öffnet"
        telegramAction.sendTelegram(message)
    type: script.ScriptAction

Mitsamt der (besseren) Prüfung, ob der alte Wert bereits vom Typ OpenClosed war. Ist das nicht der Fall, muss keine Meldung ausgegeben werden.
Außerdem wird auch der gleiche Check für newState ausgeführt, nur für den Fall, dass zwischendurch mal ein ungültiger Wert rein kommen soolte.
Der Code ist fast identisch, bei DSL bin ich mir allerdings ziemlich sicher, dass der Code funktioniert, wohingegen ich bei JavaScript probieren müsste

[FelixK]

Danke dir für die ausführliche Antwort.

Vor lauter schreiben habe ich die "Frage" vergessen bzw. da es nicht funktioniert ging es mir eher darum, ob man das überhaupt so machen kann und OpenHab das dann auf die Reihe bekommt, dass ein Switch-Item nur einen Status, aber kein Kommando hat, oder ob das direkt als "invalid" markiert und gar nicht weiter berücksichtigt wird.

So, wie dich verstehe, geht das aber grundsätzlich, wenn auch mit Optimierungspotential.

Ich werde das dann heute Nachmittag/Abend mit einem gesonderten Magneten am Sensor testen.

[udo1toni]

Also, ein Item hat zwei Funktionen, die erst mal völlig unabhängig voneinander sind.
Salopp könnte man von den zwei Kommunikationsrichtungen sprechen (also rein/raus), das stimmt so aber nicht. In Wahrheit sind die beiden Dinge zum einen der Status und zum anderen der Befehl. Beide Eigenschaften des Items sind zunächst völlig unabhängig voneinander.
Ein Contact Item hat z.B. auch völlig unterschiedliche Status und Befehle (bzw. gibt es nur exakt einen Befehl), als Status gibt es OPEN, CLOSED, NULL und evtl. noch UNDEF, als Befehl gibt es REFRESH, aber keinen der genannten Status (und der Befehl kann nicht als Status auftreten).
Beim Switch ist es nicht so eindeutig, aber auch da gibt es zusätzlich zu den Status ON und OFF noch NULL und evtl. UNDEF, als Befehle aber lediglich ON, OFF und REFRESH (und letzterer ist eher unüblich...)

Nur ein Befehl wird auch an einen verlinkten Channel weitergeleitet. Empfängt ein Channel einen Wert, wird dieser gewöhnlich immer als Status gewertet, nicht als Befehl. Bei einigen Addons kann man dieses Verhalten aber ändern (z.B. mqtt, isCommand).

Die Krux aus Support-Sicht (wenn ich mich mal als Support einstufen darf ): openHAB möchte gerne eine möglichst "flotte" Bedienung ermöglichen. Deshalb sendet es nicht nur einen Befehl, sondern setzt anschließend schon mal das zugehörige Item auf den zu erwartenden Status. In den meisten Fällen wird das auch klaglos funktionieren, manchmal geht es auch schief, aber vor allem erweckt openHAB damit den Eindruck, als seien Staus und Befehl "irgendwie das gleiche", in Wahrheit sind sie aber fundamental verschieden.
Man kann openHAB (pro Item) auch anweisen, nie von sich aus Status zu setzen, weil es einen Befehl gesendet hat, der entsprechende Parameter heißt autoupdate und befindet sich in den Metadaten des Items.

Du kannst ein Item immer beliebig auch nur für eine der beiden Funktionen nutzen, also z.B. ein Item, welches ausschließlich zum Senden von Befehlen verwendet wird, oder ein Item, welches ausschließlich einen Status anzeigt.

Das wird allerdings nicht das eigentliche Problem sein

Switch Items kennen als Status wie erwähnt ausschließlich ON, OFF, NULL und evtl. noch UNDEF, Contact Items kennen ausschließlich OPEN, CLOSED, NULL und evtl. UNDEF. Ein Switch Item kennt keinen Status CLOSE oder OPEN, ein Contact Item kennt kein CLOSE als Status, sondern lediglich CLOSED.
Ein String Item könnte CLOSE und OPEN als Status annehmen, oder auch Open oder Close, besser wäre es aber, das korrekt umzusetzen, das wäre dann, als Rückmeldung ein Contact Item zu verwenden (mit CLOSED/OPEN) und ganz wichtig, an dieser Stelle zu verstehen, dass damit aus openHAB-Sicht ein elektrischer Kontakt gemeint ist, nicht zwingend der Zustand der Hühnerklappe. Man kann aber natürlich definieren,dass der Kontakt geöffnet ist, wenn auch die Hühnerklappe geöffnet ist und dann passt es zufällig...

Möchte man das Ganze mit möglichst wenig Aufwand (auf openHAB-Seite) abbilden, so kann man natürlich auch einen switch Channel definieren, der bei ON die Klappe öffnet und bei OFF die Klappe schließt. Als Rückmeldung kann man dann genauso ON und OFF verwenden (separates Topic...) und man bekommt die Rückmeldung auf das selbe Item, welches man auch zum Steuern verwendet. Dann muss sich halt die externe Logik um die eigentliche Steuerung kümmern.