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
