Openhab 5 - Timer funktionieren nicht mehr

[nw378]

Ändere mal

Code: Alles auswählen

 
 logInfo("lueften-test-udo.rules","Timer: Durchlauf aller Fenster")

in

Code: Alles auswählen

logInfo("lueften-test-udo.rules","TimOut:"+i.toString + ":" +  iTimeout.toString)

um zu sehen, ob auch jeweils ein gültiger Wert für die nächste if-Abfrage vorliegt.

[technick90]

Heute morgen lief die Regel. Das sperritem war nicht konsistent und der Wert dadurch nach einem Neustart nicht mehr gesetzt.
Und wenn das item keinen Wert hat, greift die Regel wohl nicht.
Bewegungsmelder geht auch wieder und heute abend sehe ich ob die Beschattung von alleine herunterfährt.

Aktuell denke ich das alles passen sollte. Kernfehler wahrscheinlich das die Persistenz nicht funktioniert hat und zuletzt die falsche Java Time.

Ich bedanke mich erstmal für die Hilfe und schreib heute Abend nochmal ein Update.

[technick90]

Update:
Beschattung fährt herunter. Benachrichtigung für das offene Fenster kommt aber auch obwohl das Sperrzeitfenster auf 120min konfiguriert ist.
Werde echt noch verrückt.
Folgende Ausgabe von deiner geforderten Logzeile:

Code: Alles auswählen

TimOut:MQTTSensor_Wohnzimmer_Kontakt (Type=StringItem, State=Offen, Label=Terrassentür Wohnzimmer, Category=contact, Tags=[Point], Groups=[Fenstersensoren, Fenstersensoren_Wohnzimmer, PersistentRestore]):120

[udo1toni]

Ich nehme an, Du meinst Timer: Durchlauf aller Fenster der von Dir angegebenen Text wird nicht im Log auftauchen (jedenfalls nicht mit der geposteten Rule).
Evtl. hast Du noch eine zusätzliche Leerzeile in der Datei, jedenfalls nehme ich an, das sich der Fehler auf die Variable iTimeout bezieht.
Andererseits ist das ein einfacher Wert. Es könnte auch an der Timestamp selbst liegen...

Code: Alles auswählen

[...]
            Fenstersensoren.members.filter[s|s.state.toString == "Offen"].forEach[i|
                logInfo("lueften","Item {} wird abgearbeitet",i.name)
                val tTimestamp = i.lastChange()
                val strID = i.name.split("_").get(1)
                val iTimeout = (Fenstersensoren_Sperrzeitfenster.members.filter[s|s.name.contains(strID)].head.state as Number).intValue 
                logInfo("lueften","ermittelte Timestamp {} und Timeout mit Namenteil {}",tTimestamp,iTimeout,strID)
                if(iTimeout === null || tTimestamp === null) {
                    logWarn("lueften","Fehler beim Ermitteln des Timeout!",i)
                    return;
                }
                if(tTimestamp.plusMinutes(iTimeout).isBefore(now)) {
                     logInfo("lueften-test-udo.rules","Timer überschritten...")
                     sb.append(i.label + " ")
                }
            ]
[...]

sollte hier nähere Infos bringen.

Zu den log-Befehlen...
Der erste angegeben String ist der letzte Teil des Loggernamens. Der vollständige Loggername lautet org.openhab.core.model.script.<übergebener String>, also z.B. org.openhab.core.model.script.lueften. Deshalb ist es Unsinn, in den String noch ".rules" mit hinzuschreiben, denn die sind schon durch den ersten Teil eindeutig identifizierbar. Je kürzer der angegebene String, umso weniger Zeichen werden vornedran abgeschnitten, insgesamt werden maximal die letzten 36 Zeichen des Loggernamens ausgegeben, wobei der fixe Teil schon 30 Zeichen ausmacht. Bei mehr als 6 Zeichen wird also ein Teil des Loggernamens abgeschnitten, was nicht tragisch ist, aber evtl. gut zu wissen Der Namensteil "model.script" im Loggernamen ist übrigens (bisher) eindeutig für die DSL Rule Logger, denn alle anderen Scripting Engines nutzen "automation.script".
Im zweiten String funktioniert die Substitution, so dass man sehr bequem Variableninhalte mit ins Log schreiben kann- wie hier die Information, bei welchem Item und mit welchen Werten die Abfrage schief geht.
Falls einer der beiden Werte tTimestamp oder iTimeout ungültig ist, wird anschließend der Test zu einem Fehler führen, entsprechend kann man das abfangen und eine eigene Fehlermeldung ausgeben. Davon funktioniert die Rule nicht, aber zumindest ist der Fehler besser dargestellt

[technick90]

Die angepasste Regel wirft folgenden Fehler aus, wird aber trotzdem abgearbeitet.

Code: Alles auswählen

Validation issues found in configuration model 'Lueften.rules', using it anyway: The operator '===' is undefined for the argument types int and null

Nach Ablauf des Timers (120 Minuten aber ja nicht überschritten) kommen folgende Log-Einträge:

Code: Alles auswählen

Item MQTTSensor_Wohnzimmer_Kontakt wird abgearbeitet
ermittelte Timestamp 2025-09-08T18:37:11.333+02:00[Europe/Berlin] und Timeout mit Namenteil 120
Timer überschritten...

Wie kommt da 18:37 Uhr ins Log?
logInfo("Test", now.toString)
führt doch korrekt zu:

Code: Alles auswählen

2025-09-08T20:49:39.954086809+02:00[Europe/Berlin]