Rule mit Bedingung eines Zeitfensters

[domjo75]

Hallo,

ich baue meine UI Rules gerade in Textform um. Das erscheint mir flexibler und übersichtlicher.

Nun probiere ich schon den ganzen Vormittag mit einer IF Bedingung rum, komme aber nicht so richtig weiter.

Ich möchte Lichter schalten, sobald die Helligkeit unter einen bestimmten Wert fällt. Aber nur in der Zeit zwischen 15:00 und 22:00
Das bekomme ich hin:

Code: Alles auswählen

if  (now.getHour >= 15 && now.getHour <= 22) {
        logInfo("Test", "15-22")
    }

Wie aber mache ich das, wenn ich ein Zeitfenster von 15:45 - 19:30 oder 15:00 - 19:45 möchte ?
Bis jetzt habe ich nur diese Lösung gefunden.

Code: Alles auswählen

    if (now.toLocalTime.getHour*60 + now.toLocalTime.getMinute >= 945 && now.toLocalTime.getHour*60 + now.toLocalTime.getMinute <= 1170) {
        logInfo("Test", "15:45 - 19:30")  
    }

bzw.

Code: Alles auswählen

    if (now.toLocalTime.getHour*60 + now.toLocalTime.getMinute >= 900 && now.toLocalTime.getHour*60 + now.toLocalTime.getMinute <= 1185) {
        logInfo("Test", "15:00 - 19:45")  
    }

So richtig schön finde ich das aber nicht. In einem halben Jahr habe ich wieder vergessen, dass ich das umrechnen muss.
Gibt es da nicht noch eine elegantere Lösung ?

Grüße

[udo1toni]

Mit Joda Time gab es getMinuteOfDay, daher kommt auch die Rechenarie. Jetzt ist es JavaTime und es gibt kein Pendant.

Der bessere Weg:

Code: Alles auswählen

val minuteOfDay = now.toLocalTime.getHour * 60 + now.toLocalTime.getMinute
if(minuteOfDay > 15 * 60 + 44 && minuteOfDay < 22 * 60)

Durch den sprechenden Namen der lokalen Konstanten ist klar, was da passiert.
Die Werte kann man ausrechnen oder als Rechnung hinschreiben, letzteres hat den Vorteil, dass man das auch nach Jahren noch verstehen kann.

[domjo75]

Hallo Udo,

Code: Alles auswählen

val minuteOfDay = now.toLocalTime.getHour * 60 + now.toLocalTime.getMinute

kann ich ja dann generell ganz oben in das Rules-File schreiben. Das macht es natürlich etwas übersichtlicher.

[peter-pan]

..noch eine Alternative:

Code: Alles auswählen

rule "StundeMinute" when
  Item Dummy_4 changed to ON
then
   var Number vHourMinuteNumber = Integer::parseInt(now.getHour().toString + now.getMinute().toString)
   if  (vHourMinuteNumber >= 315 && vHourMinuteNumber <= 1540) {
        logInfo("Test", "3:15-15:40")
    }
logInfo("StundeMinute 1", "wert vHourMinute ist {} ",  vHourMinuteNumber)
end

[HiG]

ich hatte das hier auch schon mal diskutiert. Bei mir war der Auslöser nur ein Bodysensor

viewtopic.php?p=40737

[udo1toni]

Hallo Udo,

Code: Alles auswählen

val minuteOfDay = now.toLocalTime.getHour * 60 + now.toLocalTime.getMinute

kann ich ja dann generell ganz oben in das Rules-File schreiben. Das macht es natürlich etwas übersichtlicher.

Nein. Das kannst Du nicht ganz oben ins Rulefile schreiben. Das Rulefile wird beim Systemstart und bei Änderungen am File gelesen, und genau zu dem Zeitpunkt wird auch die Konstante gesetzt. Das val in var zu ändern, bringt auch nichts. Zwar ist es dann eine Variable, die aber immer noch nicht berechnet wird, sondern einfach einen statischen Wert zugewiesen bekommt. Du musst diese Definition in jeder Rule an den Code-Anfang schreiben, wo Du sie verwenden willst. Dennoch wird aus dem Code sofort klar, worum es geht.

[domjo75]

Das habe ich gemerkt, nachdem sich im LOG der Wert von MinuteOfDay nicht geändert hat Habs dann so gemacht wie Du beschrieben hast.

Jetzt habe ich alle möglichen Lichter-Regel in das Rule-Files gebastelt. Meine HandleLights hat nun 220 Zeilen und umfasst 15 Regeln.
Bis eine Änderung eingelesen bzw. umgesetzt wird dauert es 2-3 Minuten.
Macht es Sinn die Datei in mehrere .Rules aufzuteilen? Beim Neustart sollte es ja eigentlich egal sein, ob er nun 1 große oder 15 kleine Dateien laden muss.

[udo1toni]

Zum Editieren einer Rule ist es meist sinnvoll, die Rule in eine leere Datei zu laden.
Für den täglichen Ablauf ist es egal, ob man mehrere Dateien nutzt oder nur eine, wobei es noch eine Einschränkung gibt: wenn man globale Variablen nutzt, müssen alle Rules, die die selbe globale Variable nutzen auch in der selben Datei angelegt sein.

Die beschriebene Verzögerung bezieht sich auf die Anzeige in VSCode, oder? Denn das Laden einer Rules-Datei dauert nur Bruchteile von Sekunden, das Initialisieren der Rules dauert ebenfalls nur Sekundenbruchteile. Die erste Ausführung einer Rule kann einige Sekunden dauern, da der Code erst in den Speicher nachgeladen wird. Anschließend sollte das aber keine Rolle mehr spielen, da die Rules gecached werden.

[domjo75]

Es kann natürlich auch VSCode sein, was die Verzögerung erzeugt. Ich schau parallel mit tail was so passiert und dabei ist mir aufgefallen, dass

Code: Alles auswählen

Loading model 'HandleLights.rules'

schon einen Moment braucht, wenn ich kurz hintereinander etwas ändere.

Der Einwand mit den Variablen leuchtet ein. Mir kam noch der Gedanke, dass ein Auftrennen sinnvoll wäre, damit im Fehlerfall (im Script) wenigstens ein paar Rules geladen werden.

[udo1toni]

Nein, nein, VSCode ist da nicht das Problem... Es ist der LSP Server, der leider jedes einzelne eingegebene Zeichen überträgt und damit auch Serverlast erzeugt.

Wie gesagt, im Normalbetrieb ist es bis auf die Sache mit den globalen Variablen egal, wie man die Rules speichert. Ein Fehler (im Script) kann ja nur auftreten, wenn man Code geändert hat. Oder man hat grundlegende Dinge missachtet, z.B. immer zu prüfen, ob ein Status auch zum Zieltyp eines Castings passt, bevor man castet. Also sowas:

Code: Alles auswählen

val Number nMyNumber = MyNumberItem.state as Number

Wenn MyNumberItem nun gerade keine gültige Zahl als Status hält (NULL, UNDEF...), knallt es. Deshalb immer so:

Code: Alles auswählen

val Number nMyNumber = if(MyNumberItem.state instanceof Number) (MyNumberItem.state as Number) else 0

oder so:

Code: Alles auswählen

var Number nMyNumber = 0
if(MyNumberItem.state instanceof Number) nMyNumber = (MyNumberItem.state as Number)

Ist beides gleichbedeutend, aber im ersten Fall wird eine lokale Konstante erzeugt, im zweiten Fall handelt es sich um eine lokale Variable.