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
Versuche mal:
define at_test at +*02:00:00 { if($hour > 16 && $hour < 23) { fhem "set schalter on" } }
attr at_test alignTime 00:00
Ich danke Dir jhohn.
Funktioniert so prima.
Danke !
Hat mir auch sehr geholfen ... sooo leicht kann es sein ...
ak323
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.
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.
andere alternative wäre aus das Attribut disabledForIntervals beim at
Zitat von: roedert am 03 August 2020, 23:03:15
andere alternative wäre aus das Attribut disabledForIntervals beim at
gab´s wohl 2013 noch nicht :)
Zitat von: Damian am 03 August 2020, 23:28:59
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
Zitat von: ak323 am 04 August 2020, 09:12:39
... 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 ;)
Zitat von: Damian am 04 August 2020, 09:27:04
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.
Zitat von: Damian am 04 August 2020, 09:27:04
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:
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...
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 :)
:) 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 :o