ExpirationTimer und Gruppen

[oh3twh]

Hi *,

ich habe mehrere Switches über Gruppen-Items hierarchisiert.

LüfterAlle (Group)
Lüfter1OG (Group)
Lüfter1 (Switch)
Lüfter2 (Switch)
LüfterDG (Group)
Lüfter3 (Switch)
Lüfter4 (Switch)

Die Lüfter sollen nur n-Minuten lang laufen, dann sollen die Switches wieder auf "OFF" gehen.
(Der ON/OFF-Event der Switches schaltet eine Rule für ein reales Switch.)

Konfiguriert habe ich das mit den Expiration Metadata zuerst nur auf Switch Ebene, dann aber auch auf Group Ebene nachdem ich sah das es bei AKtivierung über Gruppen-Ebene nicht zur Expiration kam.

Also muss ich annehmen, dass die ExpirationTimer der Gruppen keinen Effekt auf die Switches haben
Ist das eine bekannte Einschränkung? Wenn ja, was wäre ein vernünftiger Workaround?

Irgendwo im Forum stand auch, das die Items Updates bekommen das kann ich aber nicht nachvollziehen - da es virtuele Items sind.

Wäre für Tips sehr dankbar!

grüße,
\thomas

[udo1toni]

Ich verstehe nicht so ganz, worauf Du hinaus willst. Die Expiration Timer sollten ja eigentlich auf den einzelnen Lüfter bezogen sein, oder?

[oh3twh]

Ja ich will das die einzelnen Lüfter "expiren".
Aber ich will die Lüfter auch über Gruppen steuern:

Beispiel:
LüfterDG (Group) -> ON

Dann per Gruppen-Aggregation:
Lüfter 3 -> ON - Expiration 30min -> OFF
Lüfter 4 -> ON - Expiration 30min -> OFF
LüfterDG (Group) -> OFF

Auf der GUI sieht es auch gut aus. Lüfter3 und Lüfter4 gehen auf an. Nur leider zieht der Expiration-Timer "0h30m0s,command=OFF" dann nicht und sie bleiben ungewollt auf Dauer an.

[udo1toni]

Du schreibst ja, dass die Lüfter indirekt mit der Expiration verknüpft sind, das wird vermutlich das Problem dabei sein.
Gibt es einen guten Grund, warum die Expiration nicht direkt im Lüfter Item angegeben ist?

[oh3twh]

Es fällt mir schwer das verständlich zu dokumentieren. Sorry!

Anfangs nahm ich an, dass die Expiration Timer genau so funktioneren wie du sagst:

LüfterDG (Group) (hier kein Expiration Timer)
Lüfter 3 (Expiration Timer 30min -> OFF)
Lüfter 4 (Expiration Timer 30min -> OFF)

Wenn ich in dieser Konfig dann über LüfterDG->ON schalte, hätte ich erwartet das Lüfter3 und Lüfter4 nach 30 Minuten automatisch ausschalten. Tun sie aber nicht.

Also habe ich den Expiration Timer nochmal definert auf Group-Ebene.

LüfterDG (Group) (Expiration Timer 30min -> OFF)
Lüfter 3 (Expiration Timer 30min -> OFF)
Lüfter 4 (Expiration Timer 30min -> OFF)

Auch in dieser Konfig schalte ich nun alle an "LüfterDG->ON". Leider schalten sich die Lüfter nicht wie gedacht nach 30 Minuten wieder auf "OFF".

Die Expiration Timer funktionieren nur auf Item-Ebene und nur wenn ich sie einzeln aktiveren. Das ist für mich aktuell der Effekt. Und ich denke das ist entweder ein Bug oder ein "Works as Designed" weil irgendein Effekt mitspielt, den ich nicht verstehe.

[udo1toni]

Dann hast Du die Expiration Action falsch konfiguriert
Du kannst als Action einstellen, dass der Status geändert wird, oder dass ein Command gesendet wird.
Du musst hier wählen, dass ein Command gesendet wird.
Leider gibt es für Items bisher keine Code Ansicht (was auch daran liegen dürfte, dass sich die verschiedenen Eigenschaften eines Items über verschiedene Dateien verteilen)
Deshalb hier als Beispiel die Textdefinition eines Switch Items mit Expiration Timer:

Code: Alles auswählen

Switch Luefter1 "Lüfter 1" {channel="...",expire="10s,command=OFF"}

Wenn der Status des Items nicht OFF ist, wird 10 Sekunden nach dem letzten Update der Befehl OFF gesendet.
Du kannst an dieser Stelle (z.B. aus einer Rule heraus) durchaus aktiv verhindern, dass die Expiration greift, indem Du nach einem ON Befehl ein OFF Update sendest.
Damit wechselt dann der Status des Items auf OFF, womit die Expiration nicht mehr ausgeführt wird.
Wenn aber alles korrekt konfiguriert ist, wird openHAB immer einen OFF Befehl senden, solange das Item nicht auf OFF steht.

Ganz wichtig: Ein Item hat einen Status, der verrät im Idealfall, welchen Zustand eine bestimmte Eigenschaft (eines Geräts) hat, also z.B. ob eine Steckdose gerade eingeschaltet ist oder nicht. Der Status eines Items kann jederzeit frei gesetzt werden - aus einer Rule heraus per .postUpdate().
Ein Item kann außerdem (bis auf eine Ausnahme - Contact) auch Befehle empfangen. Dieser Befehl wird dann an die verbundenen Channel weitergeleitet und darüber auch an die betroffenen Geräte geschickt.
Grundsätzlich wird nur ein Befehl weitergeleitet, keine Statusänderung. (Grundsätzlich -> es gibt Ausnahmen zu dieser Regel).
Der Channel sendet also nur den Befehl an das Gerät, welches dann auch auf den Befehl reagiert und seinerseits den Befehl ausführt, sowie (wenn korrekt eingerichtet) den neuen Zustand an openHAB sendet (mindestens, wenn sich der Zustand durch den Befehl geändert hat).
Da es diverse Systeme gibt, die entweder sehr lange brauchen, um den neuen Zustand zu melden, oder dies gar nur unzuverlässig tun, ist in openHAB aber noch ein automatisches Update des Status eingebaut.
Abhängig vom gesendeten Befehl wird also auch der Status des Items geändert, also z.B. ich sende ON an ein Switch Item, dann wechselt auch der Status des Items auf ON. Dies kann man verhindern, indem man über die Metadaten des Items autoupdate=false konfiguriert (eigentlich sollte man diese Betriebsart bevorzugen, sie ist aber leider nicht das default Verhalten)

Die beiden Funktionen Befehl und Status sind grundverschieden, auch wenn sie sehr häufig ein sehr ähnliches Ergebnis haben, aber als Beispiel:
Ich habe knx Dimmer, bei denen ich eine Grundhelligkeit definieren kann. Wenn der Dimmer den Befehl ON empfängt (nicht 100!) dann dimmt er auf diese Helligkeitsstufe, nicht zwingend auf 100. Es ist also ein Unterschied, ob ich den Dimmer über einen Slider einschalte (bei dem ich nur absolute Helligkeitswerte senden kann) oder ein Switch Widget verwende, bei dem ich den "echten" ON Befehl senden kann.
Und an dieser Stelle kommt ganz erheblich die Sache mit dem autoupdate zum Tragen.
autoupdate=true -> Ich sende ON -> openHAB sendet ON in Richtung Dimmer und setzt den Status auf 100. Der Dimmer dimmt aber nur auf 80, und zwar innerhalb 5 Sekunden (weil so konfiguriert). Am Ende des Dimmvorgangs sendet der Dimmer seine aktuelle Helligkeit, also 80, was von openHAB auch als neuer, aktueller Status gespeichert wird. In der UI (oder auch im Log) sehe ich also Befehl ON -> Status 100 -> Status 80, die 100 ist komplett falsch
autoupdate=false -> ich sende ON -> openHAB sendet ON. Nach Abschluss des Dimmvorhgangs empfängt openHAB die 80 vom Dimmer und setzt den Status auf 80, also Befehl ON -> Status 80, so wie es sein soll.
Dass die Meldung der 80 erst nach 5 Sekunden erfolgt ist ebenfalls korrekt, denn vorher dimmt der Dimmer ja noch

[oh3twh]

Hi *,

ich habe nun endlich umgesetzt bekommen was ich benötigt habe.
Vielen Dank Udo für deine Hinweise, letztlich habe ich dich aber anscheinend auf eine falsche Fährte gebracht.

Summary:
Mir ist aufgefallen das die sog. "Expiration Timer" zwar eine gute Idee sind, aber auf meinem OH3.4.2 nicht zuverlässig funktionieren. Weder auf einzelnen Items noch auf aggregierte Gruppen-Items.

Die Lösung war, dass ich dedizierte Scripts verwende und darin Timer für die Statuswechsel an den Items anlege und dann ein OFF-Comand an die Items schicken.

Ein Beispiel sieht dann so aus. Ich habe das mit Blockly erst zusammengeklickt, dann getestet und dann in Ecmascript Scripts extrahiert.
Timer die so angelegt werden, werden bei meine OH3.4 auch zuverlässig ausgelößt.

Code: Alles auswählen

if (typeof this.timers === 'undefined') {
  this.timers = [];
}

var scriptExecution = Java.type('org.openhab.core.model.script.actions.ScriptExecution');

var zdt = Java.type('java.time.ZonedDateTime');

var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);

logger.info('Gäste Lufreinigung Timer started');

if (!(typeof this.timers['GaesteExpireTimer'] !== 'undefined' && this.timers['GaesteExpireTimer'].isActive())) {
  if (typeof this.timers['GaesteExpireTimer'] === 'undefined' || this.timers['GaesteExpireTimer'].hasTerminated()) {
    this.timers['GaesteExpireTimer'] = scriptExecution.createTimer(zdt.now().plusMinutes(15), function () {
      events.sendCommand('LuftReinigungGaeste', 'OFF');
      logger.info('Gäste Lufreinigung Timer expired');
      })
  }
}