DOIF - Bedingung an Timer knüpfen/Überprüfung

Begonnen von Tedious, 29 März 2016, 10:17:40

Vorheriges Thema - Nächstes Thema

Tedious

Morgen zusammen,

ich habe eine kurze Frage. Folgende Ausgangslage

([Familie:state] eq "gone") (set Alles_An_Aus off, set HZ_Marie desiredTemperature comfort)

Familienstatus kommt via iTag Blueetoth LE. Manchmal kommen jedoch Situationen in denen beim "Lauschen" grade kein Signal ankommt - Person also "nicht da", Check alle 60 Sekunden. Ist jetzt nur eine Person anwesend, und das Signal wird grade nciht empfangen ist die Famile "gone" und die Aktionen werden ausgeführt. Das kann mitunter den WAF stark senken... ;)

Ich würde gerne eine Verzögerung einbauen, jedoch mit einer 2. Überprüfung. Sprich - Familie "gone" bitte warte 5 Minuten, denn checke nochmals. Ist Familie immer noch "gone", löse die Aktionen aus. Lässt sich das in einem DOIF direkt realisieren, und müsste ich mit Notifiys und Trigger ausdenken um das zu realisieren? Bin für jeden Tip dankbar!

EDIT:

Habe grade nochmal drüber nachgedacht. iTAG presence triggert ein Notify, das wiederum triggert den Homestatus - hier könnte man auch eingreifen.

iTag_Gast {
  if (Value("iTag_Gast") eq "present") {
    fhem ("set rr_Gast state home")
  } elsif (Value("iTag_Gast") eq "absent") {
    fhem ("set rr_Gast state gone")
  }
}


In BASIC würde ich per FOR .... TO... NEXT eingreifen ... bekomme ich was ähnliches hier auch eingebaut?

Grüße Tedious
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

errazzor

Ich habe bei mir etwas ähnliches mit einem einfachen "wait 300" gelöst (mit einem DOIF).

Vereinfacht gesagt - DOIF triggert auf ein bestimmtes Ereignis (z.b. Dummy geht auf "off") und führt dann eine Aktion aus (z.b. Heizung aus).

Mit dem Attribut "wait 300" tut es das aber erst nach 300 Sekunden - wenn sich innerhalb dieser Zeit der Status des Dummy wieder ändert ("on"), passiert nichts - das DOIF führt keine Aktionen aus.

Tedious

Und das funktioniert? Den Gedanken hatte ich auch schon, aber nach meinem Verständnis sollte ja folgendes passieren -> Doif läst auch (Bedingung) --> wartet --> führt Aktion aus --> lauscht wieder. Das wäre bi mir blöd - unter anderem schaltet er eine Steckdose an der das ganze HIFI und TV-Gelumpe hängt. Sprich, er würde das Signal bekommen, warten, TV ausschalten und direkt wieder anschalten (weil jemand da)?! Oder habe ich da nen Denkfehler? Weil die Aktion an sich ja schon ausgelöst wurde, oder?

EDIT. oder triggerst Du das in zwei Stufen? Sprich, ein DOIF wartet und löst denn ein anderes aus?
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

errazzor

#3
Nö, keine zwei Stufen. Bei mir funktioniert es genau so. Genauere Erklärungen zum Verhalten kann ich Dir leider nicht geben, da ich selbst noch immer Verständnisschwierigkeiten mit DOIF habe.

Nach meinem Verständnis verhält es sich so, anhand von einem einfachen Beispiel:

define Test DOIF ([Person1.Anwesenheit] eq "off") (set Heizung1 off)
attr Test wait 300

Der dummy Person1.Anwesenheit geht auf "off" und triggert damit das DOIF - das DOIF hat aber das Attribut "wait 300" und führt die Aktion erst danach aus und auch nur, wenn die Bedingung dann noch wahr ist.

So funktioniert es bei mir.

Tipp: Leg Dir zum Testen doch einfach ein paar Dummys an mit denen Du spielen kannst. Musst es ja nicht direkt mit Aktoren testen.

Tedious

Ah, ok - wait nicht innerhalb des Befehls/der Befehlskette, sondern "ausserhalb" per attr zugewiesen. denn hab ichs verstanden, teste das mal so - danke!
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...