Es muss
immer explizit der Status verwendet werden. Ein Item ist ein Item.
Ausgehend von Deiner Rule (ich habe mal die Code-Tags ergänzt...):
Code: Alles auswählen
// Globale Variablen werden zu Beginn der Datei definiert, vor der ersten Rule
var Timer tLuefter = null // Objektvariable für Timer
rule "Lüfter Timer"
when
Item HMIPSchalter_11_Switch changed from OFF to ON
then
var Integer iTime = 5 // Default Wert, falls irgendwas schief gegangen ist und kein gültiger Wert geliefert wird
if(Min_set_time01.state instanceof Number) // Falls Itemstatus eine gültige Zahl ist
iTime = (Min_set_time01.state as Number).intValue // setze die Variable auf den Wert
tLuefter?.cancel // Stoppe einen eventuell laufenden Timer
tLuefter = createTimer(now.plusMinutes(iTime), [| // Erzeuge den Timer
HMIPSchalter_11_Switch.sendCommand(OFF)
])
end
Der Code oben kann getrost als Minimum angesehen werden, auch wenn Dein Code grundsätzlich funktioniert.
Aber.
Was passiert, wenn der schalter mehrfach hintereinander ein- und wieder ausgeschaltet wird und erst dann auf ON stehen bleibt? Antwort: es wird für jeden Einschaltvorgang ein Eintrag im Scheduler erzeugt. Der Scheduler speichert beliebig viele Einträge und führt diese alle zum genannten Zeitpunkt aus, es werden dann also mehrfach OFF-Befehle gesendet.
Das kann man zuverlässig verhindern, indem man den Timer an ein Objekt bindet, mit dem man den Timer dann abbrechen kann. Die Schreibweise
ist gleichbedeutend mit dem Code
Was bedeutet: Falls das Objekt tLuefter nicht auf null zeigt (!==), lösche den passenden Eintrag aus dem Scheduler.
Wenn tLuefter noch nicht initialisiert wurde (tLuefter = createTimer...), so wird das .cancel auch nicht ausgeführt. Dafür sorgt das ?.
Ein Item kann immer einen ungültigen Wert enthalten, zu jedem Zeitpunkt. Deshalb ist es wirklich wichtig, immer zu prüfen, ob der Itemstatus zum erwarteten Wert passt, also in diesem Fall, ob der Status eine Zahl ist.
Falls das nicht der Fall ist, sollte sich die Rule in diesem Fall vermutlich nicht einfach still verabschieden, sondern einen Fallback auf einen Default Wert machen.
erwartet einen Long-Wert. Integer dürfte allerdings vollkommen ausreichen, openHAB macht dann aus dem Integer automatisch ein Long.
Schreibweise
vs.
oder
Ersteres ist die Methode, welche im Kontext des Items existiert. Deshalb weiß sie genau, welche Befehle zur Verfügung stehen, in jeder Form.
Letzteres ist die Action, welche zwingend zwei Strings als Parameter verlangt. Da ein Item ein Objekt ist, wird openHAB stillschweigend aus dem Item den String Item.name ableiten. Genauso wird es aus dem OnOffType Objekt stillschweigend per .toString den String "OFF" erzeugen. Das geht aber nur solange gut, wie beide Parameter Objekte sind. Nutzt man hier Primitives, knallt es. Allgemein wird die Verwendung der Methode empfohlen, wenn man nicht zwingend auf die Action angewiesen ist.
Meine Schreibweise von createTimer weicht ebenfalls ab. Beide Schreibweisen sind erlaubt, jedoch wird durch das Hineinziehen des Lambda in die Parameterliste deutlich, das der Code Teil des Timers ist.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
Dazu bietet der erweiterte Editor eine entsprechende Funktion an 
