Also, ein paar Dinge, an denen es hängen könnte:
1. Falsche default Persistence. Lösung: explizit die zu verwendende Persistence angeben (statt
i.lastChange() schreibst Du z.B.
i.lastChange("influxdb") hin, dann nimmt der die Daten aus der InfluxDB, egal welche Persistence als default gewählt ist.)
2. Daten werden nicht persistiert. Die Daten müssen natürlich zur Verfügung stehen. Auf Postgres zu wechseln, beinhaltet auch, eine Postgres Datenbank aufzusetzen. Gleiches gilt natürlich auch für InfluxDB. Wenn es heißt:
database not ready deutet es darauf hin, dass entweder die Datenbank gar nicht läuft, oder zumindest die Verbindung zur Datenbank nicht zustande kommt. Wenn InfluxDB in einem eigenen Container läuft, könnte sich z.B. der Port geändert haben, oder der Port ist von einem anderen Container blockiert, oder...
Die erste Rule (Fenster Status) sieht auf den ersten Blick unverdächtig aus. Zur weiteren Fehlereingrenzung musst Du Werte ausgeben lassen.
Im Zweifel z.B. so:
Code: Alles auswählen
Fenstersensoren.members.filter[s|s.state.toString == "Offen"].forEach[i|
logInfo("lueften","Filterschleife aktiv")
val tTimestamp = i.lastChange()
logInfo("lueften","Timestamp für {}: {}",i.name,tTimestamp)
also unmittelbar vor der "verdächtigen" Zeile eine Meldung im Log erzeugen und unmittelbar danach, dann aber auch mit dem konkreten Wert. Die logBefehle beherrschen zu diesem Zweck Substitution, d.h. jedes {} Klammerpaar wird durch den nächsten durch Komma separierten Wert ersetzt, also die erste {} wird durch i.name ersetzt (der aktuelle Itemname), die zweite {} wird durch die ermittelte Timestamp ersetzt. der Logger formatiert den Wert automatisch korrekt (oder zumindest sollte das so sein).
Bei der zweiten Rule (bzw. dem Code-Fragment) ist die Sache klar, das Item MyCounter_Poolpumpe enthält keinen gültigen Zahlenwert. Prüfe vorher so:
if(MyCounter_Poolpumpe.state instanceof Number), ob der enthaltene Wert zu den Zahlen gehört (QuantityType ist ebenfalls Teil von Number).
Die dritte Rule (BWM schalten) ist komplett unverdächtig und müsste auf jeden Fall funktionieren. Eventuell ist drumherum irgendwas "kaputt". Wie hast Du das Betriebssystem aufgesetzt? Welche Hardware? Welche Software(-versionen)?
Ganz allgemein kann ich Dir versichern, dass Timer super stabil laufen, so wie alles andere auch. Ich habe hier openHAB als LX Container laufen, das sollte eigentlich ähnlich docker laufen.
Ich habe auch eine openHAB Installation unter docker laufen, aber die nutze ich nur zum testen, da ist es etwas schwierig, zu beurteilen, ob alle Funktionen stabil arbeiten...
openHAB5.0.1 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime) (Proxmox 9.0.6, LXC)
