Da ist von vornherein ein Denkfehler drin. Der Timer sorgt nur dafür, dass Code verzögert ausgeführt wird.
So wird eher ein Schuh draus:
Code: Alles auswählen
var Timer timer_online = null // Globale Variablen zu Beginn der Datei anlegen
rule "Anwesend oder Anwesend"
when
Member of gPhones changed //Group gPhones anlegen und dort alle Items für den Online-Status zusammenfassen
then
if(gPhones.members.filter[i|i.state == ON].size > 0) {
timer_online?.cancel
if(Z_ZENTRAL_Ein.state != ON)
Z_ZENTRAL_Ein.sendCommand(ON)
} else {
timer_online = createTimer(now.plusMinutes(30), [ |
if(Z_ZENTRAL_Ein.state != OFF)
Z_ZENTRAL_Ein.sendCommand(OFF)
])
}
end
Punkt 1: Der Timer muss global definiert werden (hast Du vielleicht auch gemacht... aber vergessen, dazu zu schreiben)
Punkt 2: Warum überhaupt zwei Rules? das ist viel sinnvoller in einer Rule abzufeiern:
Punkt 3: selbst bei nur zwei Geräten ist es schon sinnvoll, eine Gruppe zu verwenden.
Punkt 3.1: geht schon beim Trigger los...
Punkt 3.2: Und wird mächtig bei der Auswertung, ob eines der Geräte Online ist. Der Trick ist hier, die Anzahl der Geräte auszuwerten, deren Status ON ist. Das geht, wie man sehen kann, super bequem.
Punkt 4: Der Timer kann bequem gecancelt werden, wenn mindestens eines der Geräte Online ist (der true-Teil)
Punkt 5: es ist sinnvoller, auf !=ON zu testen, da ein Item mindestens beim Systemstart zunächst den Zustand UNDEV oder NULL hat.
Punkt 6: Es ist besser, die Methode Item.sendCommand(Befehl) zu verwenden, statt die Action sendCommand(Itemname,Befehlstext)
openHAB5.0.3 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime - LXC, 4 Kerne, 3 GByte RAM)
Hostsystem Proxmox 9.1.2 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte