AT- Ab 7:00Uhr bis 22:Uhr alle 3 Stunden schalten - Wie?

[Rocky]

Hallo,

ich möchte zwischen 7:00Uhr und 22:00Uhr alle 2 Stunden etwas schalten.
Wie müsste denn der AT dazu sein?

Dieses Beispiel schaltet lediglich einmal am Tag "define test at *17:00:00 ..."
und dieses alle 10 Minuten: "define test at +*00:10:00 ..."

Wie kann ich aber jetzt die Zeit einschränken und beide kombinieren?

Gruß
Markus

[jhohn]

Versuche mal:

Code Auswählen Erweitern


define at_test at +*02:00:00 { if($hour > 16 && $hour < 23) { fhem "set schalter on" } }
attr at_test alignTime 00:00


[Rocky]

Ich danke Dir jhohn.
Funktioniert so prima.

[ak323]

Danke !
Hat mir auch sehr geholfen ... sooo leicht kann es sein ...

ak323

[Damian]

Der Nachteil dieser Lösung ist, dass auch außerhalb des Zeitintervalls getriggert wird.

siehe alternativ: https://fhem.de/commandref_DE.html#DOIF_Intervall-Timer

oder etwas kürzer, hier z. B.

Code Auswählen Erweitern

define zwei_stunden DOIF {[16:00-23:00,+[2]:00];fhem_set"schalter on"}

Hier wird nur zwischen 16:00 und 23:00 Uhr alle zwei Stunden getriggert.

[roedert]

andere alternative wäre aus das Attribut disabledForIntervals beim at

[Damian]

andere alternative wäre aus das Attribut disabledForIntervals beim at

gab´s wohl 2013 noch nicht

[ak323]

gab´s wohl 2013 noch nicht

... dafür funktioniert die Lösung aber auf Anhieb (im Gegensatz zur "modernen" DOIF-Lösung)

Wo ist das Problem mit der Alten ? Was ist schlimm am "triggern" ?

VG ak323

[Damian]

... dafür funktioniert die Lösung aber auf Anhieb (im Gegensatz zur "modernen" DOIF-Lösung)

Wo ist das Problem mit der Alten ? Was ist schlimm am "triggern" ?

VG ak323

hier nicht viel, bis auf die Tatsache, dass man sich bei jeder Definition Gedanken über unnötige Events machen sollte

[ak323]

hier nicht viel, bis auf die Tatsache, dass man sich bei jeder Definition Gedanken über unnötige Events machen sollte

Ok, danke für die Erhellung.
Ich versuche mich irgendwann nochmal an der DOIF Variante.

[Beta-User]

hier nicht viel, bis auf die Tatsache, dass man sich bei jeder Definition Gedanken über unnötige Events machen sollte

Na ja, der "Event" ist in diesem Fall jeweils höchstens ein abgelaufener Timer, der dann eine (sehr) kurze - auf das at selbst beschränkte - Prüfung anwirft. Mit disabledForIntervals umgeht man das übrigens auch weitgehend:

Code Auswählen Erweitern

defmod a_disabletest at +*01:00 set xyz on
attr a_disabletest disabledForIntervals 09:48-10:00

setstate a_disabletest Next: 10:01:00
setstate a_disabletest 2020-08-04 09:47:10 state Next: 10:01:00

Aber selbst wenn man das mit der Prüfung im Ausführungsteil macht, ist der unmittelbare Aufwand begrenzt, v.a., wenn man ansonsten seine Eventhandler-Trigger sauber definiert. Viel "schlimmer" sind da z.B. die weit verbreiteten fehlenden Trigger bei userReadings...

[Damian]

Hier sind das nur paar Millisekunden alle zwei Stunden, das kann man vernachlässigen. Dennoch definieren Leute immer wieder Timer, die rund um die Uhr alle paar Sekunden triggern - da sollte man genauer schauen, was man definiert. Noch viel schlimmer sind unnötige Events, es gibt Module die regelmäßig irgendetwas per Event mitteilen wollen.

Im Laufe der Zeit ist der Eventmonitor vor lauter Events nur noch am scrollen. Das war mir in meinem System vor kurzem aufgefallen, da ich inzwischen einige Module benutze.

Ich konnte die Reaktionszeit meines Systems erheblich erhöhen, indem ich mit attr .* event-on-change-reading .* gefühlte 90 % der Events eliminiert hatte. Bei wichtigen Sensoren habe ich dann noch event-min-interval gesetzt z. B. attr ESPEasy_ESP_Temp_Zirkulation event-min-interval Temperature:300, damit auf jeden Fall nach einer bestimmten Zeit ein Event durchkommt.

Damit konnte ich die Schwuppdizität meines Systems ohne großen Aufwand merklich verbessern - und schon fühlt sich ein raspi wie ein performantes i5-System an

[Beta-User]

  ja, besonders lustig wird es, wenn irgendwelche (statischen) Internetquellen im Minutentakt angezapft werden, die dann Dutzende von (triggernden) Readings erzeugen usw..

Einen längeren und kritischen Blick auf den Event-Monitor kann ich daher auch nur empfehlen, v.a., wenn man neues Zeug (und insbesondere bisher unbekannte Module) in Betrieb nimmt.

"eocr .*" sehe ich allerdings sehr kritisch, da zu pauschal, (v.a. auch im Nachgang zu längeren Diskussionen dazu mit Rudi), man sollte das (ggf. in Verbindung mit min-interval und timestamp-on-change-reading) bewußt einsetzen.
Was mich in dem Zusammenhang immer wieder wundert: Tasmota und Shelly sind (zumindest mit MQTT-JSON) unglaubliche "update-without-change-Schleudern", die ja doch eine ich größere Verbreitung haben; ich bekomme aber kaum Rückmeldungen, wie man das dem Shelly austreiben kann (derzeit noch eine offene Frage) und auch bei Tasmota hat sich da lange überhaupt keiner beschwert (da habe ich das aber @MQTT2_DEVICE-attrTemplate irgendwann einigermaßen in den Griff bekommen; ob das für alle Varianten gilt, kann ich aber nicht sagen, da ich auch nur zwei Testdevices habe...).

Staun