Rule und Zeit verzögern?

[Tüftler]

Hallo zusammen
Ich habe mich neu an Rules gewagt und es fast geschafft

In openHAB 3.4.3 hab ich über "Design" eine Rule erstellt.

rule.jpg

Ich habe geschafft, dass diese Rule mir ein Whatsapp schickt, wenn zwischen 20 Uhr und Mitternacht das Garagentor öffnet (jener Eingang von ON auf OFF wechselt).

Dies ergab folgenden Code:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Shelly_140_Garagentor_EingangTaste
      state: OFF
      previousState: ON
    type: core.ItemStateChangeTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      startTime: 20:00
      endTime: 23:59
    type: core.TimeOfDayCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: >-
        var HttpUtil = Java.type("org.openhab.core.io.net.http.HttpUtil")
        var urlmessage = encodeURI("Achtung, das Garagentor ist zu lange offen!")
        HttpUtil.executeUrl("GET", "https://api.callmebot.com/whatsapp.php?source=openHAB&phone=+41xxxxxxx&apikey=12345&text=" + urlmessage , 2000)
    type: script.ScriptAction

Eigentlich möchte ich aber die Nachricht bekommen, wenn das Garagentor nach 20 Uhr für ca. 10 Minuten offen ist.
Dann nämlich habe ich selbst (nicht etwa meine Kinder oder die Frau) es vergessen zu schliessen...
(nach 20 Uhr, da es am Tag öfters mal beim Spielen lange offen ist)
(und nicht nur von Zu auf Auf wechselt, sondern auch wenn es um 20 Uhr schon 10 Minuten offen war, also oben wohl nicht "ItemStateChangeTrigger")

Kann ich das über Design lösen?
Oder nur über den Code?
Oder muss ich gar eine zweite Rule erstellen?

[udo1toni]

Am besten löst Du das über ein Hilfsitem und drei Rules (sehr simpel) oder alternativ über eine Rule mit Code.
Das läuft folgendermaßen ab (simple Rule-Variante mit Hilfssitem):
Wird das Tor geöffnet, so wird das Hilfsitem auf ON gesetzt. Wird das Tor geschlossen, wird das Hilfsitem auf OFF gesetzt. (zwei Rules)
Das Hilfsitem hat in den Metadaten einen Expiration Timer eingetragen (10 Minuten, Command OFF).
Nach Ablauf der zehn Minuten wird das Hilfsitem also die dritte Rule über received command OFF triggern, und zwar zehn Minuten, nachdem das Tor geöffnet, aber nicht geschlossen wurde.
Die dritte Rule bekommt auch die zeitliche Einschränkung und sendet den Alarm
Einfacher (nur eine Rule) geht es mit Code:

Code: Alles auswählen

var Timer tGarage = null

rule "Garage Überwachung"
when
    Shelly_140_Garagentor_EingangTaste changed
then
    tGarage?.cancel
    if(newState == OFF)
        tGarage = createTimer(now.plusMinutes(10),[
            if(now.getHour > 19) {
                //Meldung ausgeben
            }
        ])
end

Ändert sich der Zustand des Items, so wird ein evtl. laufender Timer abgebrochen (tGarage?.cancel)
Ist der Zustand OFF (das Tor ist offen) so wird der Timer anschließend angelegt.
So ist sichergestellt, dass der Timer auf jeden Fall nur Alarm schlägt, wenn das Tor länger als 10 Minuten am Stück geöffnet ist.
Läuft der Timer ab, so wird Alarm gegeben, falls es nach 20 Uhr ist (getHour liefert den Stundenanteil als Integer Wert, um 19:59:59 Uhr also 19, um 20:00:00 Uhr 20.

Die Rule berücksichtigt nicht, falls das Tor schon vor 20 Uhr länger als 10 Minuten offen stand, dazu bräuchte es eine zweite (simpel: vierte) Rule, die um 20 Uhr prüft, ob das Tor bereits länger als zehn Minuten geöffnet ist..

[Tüftler]

Vielen Dank!
Ich hab noch etwas geübt, aber es hat geklappt!

Nach verschiedenen Versuchen habe ich es über drei simple Rules gelöst, wie Du empfohlen hast.
Wichtig war noch, dass in den beiden Rules beim Öffnen und Schliessen beim Hilfsitem "update an item state" gesetzt wird und nicht "send a command". Es sieht eigentlich gleich aus. Aber gab dann bei jedem Schliessen auch eine Meldung, weil man bei den Metadaten nur "send command" auswählen kann...
Euch Profis ist das wohl klar, mir war es nicht

Nichts desto trotz, coole Sache!

[udo1toni]

Es sieht eigentlich gleich aus.

Ja, aber nein. Es gibt einen fundamentalen Unterschied zwischen Command und State.

Punkt 1: Der Status ist der Status des Items. Ein Status wird grundsätzlich nicht in Richtung eines Channels veröffentlicht. Ein Command ist ein Befehl, der zunächst einmal ausschließlich in Richtung des/der verknüpften Channel gesendet wird. Der/die Channel antwortet/n dann meist mit einem Status Update, welches im Item landet. Allerdings versucht openHAB zu berechnen, welcher Status vermutlich aus dem Befehl folgt und setzt diesen dann schon mal. Das dient der Optimierung der gefühlten Geschwindigkeit der Oberfläche und hilft, wenn ein Gerät seinen Status nicht melden kann. Dieses Verhalten kann man aber unterbinden (Metadaten autoupdate=false).

Punkt 2: Nicht jeder Befehl existiert auch als Status. Beispiel: Ein Dimmer Item kennt die Befehle ON, OFF, INCREASE, DECREASE und 0 bis 100. Als Status liefert ein Dimmer Item aber grundsätzlich nur die Zahlen 0 bis 100. Mit getStateAs(OnOffType) kann man innerhalb einer Rule den Status auch als OFF (Wert 0) oder ON (Wert > 0) abbilden, das Item kann aber niemals den Status INCREASE oder DECREASE annehmen, weil dies keine Status sind.

Punkt 3: In Rules gibt es auf Items bezogen drei verschiedene Trigger:

• received update [STATUS] (triggert bei jedem Status Update, egal, ob sich der Status geändert hat oder nicht, falls [STATUS] angegeben wird, natürlich nur, wenn der Status auch [STATUS] entspricht).
• changed [from STATUS] [to STATUS] (triggert nur, wenn sich der Status gegenüber vorher verändert hat, wahlweise mit der Einschränkung, dass die Änderung von oder/und hin zu einem bestimmten Status erfolgt ist)
• received command [COMMAND] (triggert nur, wenn ein [wahlweise bestimmtes] Command empfangen wurde. Zur Erinnerung: Jede Eingabe über die UI löst ein Command aus)

Grundsätzlich werden ankommende Nachrichten aus Channels als Status gewertet, es sei denn, der Channel ist extra als Command konfiguriert (kommt auf das Addon an, ob und wenn ja wie das konfiguriert wird).
Der Trick bei den Rules von oben besteht nur darin, diese Unterschiede zum eigenen Vorteil zu nutzen Bei dem Hilfsitem, welches ja überhaupt keine Verbindung zu einem Channel hat, kommt der Unterschied aus Anwendersicht nur durch Punkt drei (unterschiedliche Trigger in Rules) zum Tragen.
Für eine sauber funktionierende Automation ist es aber unerlässlich, den Unterschied zwischen .postUpdate() und .sendCommand() verstanden zu haben.

[Tüftler]

Puh... dabei soll es ja noch ein Hobby bleiben
DANKE für die Erklärungen.
Ich werde noch oft an solchen "Details" anstehen. Aber mein "WAF" (Woman Acceptance Factor) hält sich dafür in Grenzen

[udo1toni]

Puh... dabei soll es ja noch ein Hobby bleiben

Ja, klar, aber die Grundlagen müssen sitzen. Jemand, der in seiner Freizeit in einem Chor singt, muss dennoch die Töne treffen (zumindest, wenn er dauerhaft im Chor mitsingen will)