Aktion nur einmal pro 15 Minuten ausführen - einfache Frage

[Frood42]

Das scheint eine einfache Frage, aber trotz Brain 2.0 kann ich nach 2-3 Tagen nicht sagen, dass ich die optimale Lösungen gefunden habe.

Da ist ein Ventilator im Schrank und ein Temperatur Sensor.
Wenn die Temperatur > 28 ist, soll der Ventilator angehen, sonst aus.
Das macht der auch andauernd, für mich zu oft, so ca 10 mal die Stunde an und aus. Das muss ja nicht sein.
So sieht das aktuell aus:

Code Auswählen Erweitern


define di_lamp DOIF ([temp_schrank:temperature] > 28) (set venti on) DOELSE (set venti off)
attire di_lamp do always

Jetzt würde es reichen, den Ventilator nur alle 15 Minuten an oder auszuschalten. Es kann auch passieren, dass der Ventilator zwo mal hintereinander, also um 10:15 und 10:30 angeschaltet wird, das ist auch ok.
D.h. die Bedingung sollte nur alle 15 Minuten überprüft werden.
Oder soll die Aktion an/ausschalten nur nach 15 Minuten durchgeführt werden und nicht mehrmals innerhalb 15 Minuten?

Ein do always scheint ungeeignet - alleine.
So hatte ich auch

Code Auswählen Erweitern


([+600] and [temp_schrank:temperature] > 28)

ausprobiert und Sachen mit

Code Auswählen Erweitern

attr di_push wait 600
attr di_push do resetwait

oder auch

Code Auswählen Erweitern

attr di_push  repeatsame 3

Aber irgendwie bin ich mir nicht sicher.

Was ist denn die empfohlene Vorgehensweise?

[Byte09]

In erster Linie würde ich hier mit schwellwerten arbeiten , da es vermutlich darum geht zu 'kühlen'. Also an bei >28 und aus bei <27 z.b. . Damit solltest du das gröbste 'flattern' schonmal in den griff bekommen.



Gruss Byte09



Gesendet von meinem SM-G900F mit Tapatalk

[Otto123]

Hi,

Vorschlag für das was Du sagst - ungetestet:

Code Auswählen Erweitern

define di_lamp DOIF ([+:15] and [?temp_schrank:temperature] > 28) (set venti on) DOELSE (set venti off)
attr di_lamp do always

Allerdings würde ich eigentlich für so etwas THRESHOLD nehmen, dass ist dafür gemacht. Und dann wie byte08 (09) (der spielt heute Jekyll & Hide) schon sagt: regelt die Hysterese das Meiste

Gruß Otto

[Frood42]

ok, also das mit <27.5 und > 28.5 ist schon ganz gut glaube ich.

Was bedeutet denn das Fragezeichen vor dem ?temp_schrank ? Das kommt mir öfters unter, aber habe nicht gefunden was es ist.
Heisst das, dass 28 exkludiert ist?

THRESHOLDS muss ich mal ankucken. Hat denn THRESHOLDS diese 15 Minuten delay drinne?

[Damian]

THRESHOLD kennt keine delay-Zeit, sondern eine Hysterese.

Code Auswählen Erweitern

define di_lamp DOIF ([temp_schrank:temperature] > 28.5) (set venti on)  DOELSEIF  ([temp_schrank:temperature] < 27.5) (set venti off)

do always nicht setzen, die Hysterese bei diesem DOIF-Beispiel beträgt übrigens 1 Grad

[Otto123]

Was bedeutet denn das Fragezeichen vor dem ?temp_schrank ? Das kommt mir öfters unter, aber habe nicht gefunden was es ist.

Dann Doku gucken, ctrl+f im Browser nutzen einfach nach [? suchen, der zweite Treffer erklärt:
https://commandref.fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger

[Frood42]

do always nicht setzen, die Hysterese bei diesem DOIF-Beispiel beträgt übrigens 1 Grad

Früher hatte ich schlechtere Schaltsteckdosen, da hatte ich lieber immer geschaltet, besser als gar nicht... just in case...
Jetzt läuft es so:

Code Auswählen Erweitern

defmod di_venti_an DOIF ([temp_server:temperature] < 28]) (set HM_6A9B61_fan_server off) DOELSEIF ([temp_server:temperature] > 29)) (set HM_6A9B61_fan_server on) 
attr di_venti_an do always
attr di_venti_an waitsame 60

Vorab zusammenfassend darf ich anmerken,
dass es kein super Rezept für diese Anforderung gibt, sondern [+:15] soweit das ausgefeilteste war. Ansonsten muss man nur das DOIF anpassen, dass sich im Kontext des Temperaturverlaufs weniger oft eine Schaltung ergibt.

Danke und Grüße,
Frood

Ansonsten verwendet man den THRESHOLD.

[Otto123]

Früher hatte ich schlechtere Schaltsteckdosen, da hatte ich lieber immer geschaltet, besser als gar nicht... just in case...

Das löst man doch nicht mit do always!?

[Frood42]

Wenn die Steckdose das Signal nicht immer empfängt oder verarbeitet, ist es doch besser, wenn es mehrfach gesendet wird, also bei jedem reading.
Mit do always: "Befehle werden wiederholt im bestehenden Status ausgeführt."
Bei HM passiert glaub gar nichts an der Steckdose wenn sie an ist und nochmal an geschaltet wird. Ausser dem Stromverbrauch schadet es da erst mal wenig.

[Otto123]

Mit do always: "Befehle werden wiederholt im bestehenden Status ausgeführt."

Wunschlesemodus und Dünnbrettbohrer aktiv 
Das das DOIF wiederholt auf Events reagiert, obwohl sich der Status der Bedingung nicht ändert, hat doch nichts damit zu tun, dass im Ausführungsteil die Kommandos beim Empfänger nicht ankommen.
Lieber zuviel machen weil ich das Ziel verfehlen könnte ist für mich keine Lösungsstrategie. Aber leider ist das der Grundansatz der meisten Menschen, nicht nur in der Hausautomatisierung. 

Ich entschuldige mich für Off Topic
Otto

[Frood42]

Vielen Dank für den Hinweis.
Dennoch ist diese Art von destruktiver Kritik zu persönlich und unbegründet. Und unterstützt in keiner Weise eine intelligente oder sinnvolle Lösungsstrategie.
Falls das nicht ankommt, muss ich es noch mal wiederholen  Das wäre dann so wie bei den miserablen PCA301 Funksteckdosen, die da mal in Betrieb waren, aber nun in Rente geschickt wurden. 

[Otto123]

Du, persönlich habe ich das nicht gemeint - destruktiv sollte das auch nicht sein. 
Du hast Recht, ist bei Dir so angekommen - Entschuldigung dafür.

Aber, es war auch viel allgemeiner gemeint:

• Wenn die Steckdosen miserabel sind kann ich entweder damit leben oder diese aussortieren. Sperrfeuer löst doch das Problem nicht.
  
• Und do always klingt zwar so, aber wiederholt doch nicht von sich aus. Nur wenn ein zweiter Event kommt, wird auch nochmal die Ausführung wiederholt. do always erzeugt also nicht das scheinbar gewünschte Sperrfeuer. Ich müsste (wenn gewollt) Sperrfeuer im Ausführungsteil erzeugen 
  

[Damian]

Das Attribut waitsame macht hier aber wenig Sinn. Wenn du schon mit do always wiederholen willst, dann würde ich dir das Attribut cmdpause empfehlen. Bei schlechtem Empfang wiederhole ich bewusst, indem ich den set-Befehl dopple, das reicht meistens schon aus, statt alle paar Minuten etwas wiederholt zu schalten (erhöhte Kollisionswahrscheinlichkeit bzw. 1%-Regel).

[Frood42]

Ok, also interessanterweise ist das jetzt stark reduziert und bis auf waitsame ohne besondere Attribute.

Code Auswählen Erweitern

defmod di_venti_an DOIF ([temp_server:temperature] < 28) (set HM_6A9B69_fan_server off) DOELSEIF ([temp_server:temperature] > 29) (set HM_6A9B69_fan_server on)
attr di_venti_an waitsame 60

Den waitsame braucht man wahrscheinlich auch nicht mehr.
Eigentlich hatte ich den Thread aufgemacht um die Attribute besser zu verstehen. Stattdessen sind sie beseitigt. So muss ich sie nicht mehr verstehen. Mh 

Leider kann ich den Verlauf heute nicht so gut kontrollieren, da Ausreisser dabei sind - da weiß ich leider auch noch nicht wie man die filtert.

[Damian]

Es ist immer gut die Bedeutung der Attribute zu verstehen, denn gerade beim DOIF können sie eine Steuerung komplett auf den Kopf stellen.

Ausreißer kannst du mit Median elegant ausmerzen: https://fhem.de/commandref_DE.html#DOIF_Reading_Funktionen