Hallo,
ich hab folgenden Trigger für das senden eines neuen Weekprofiles an Weekdaytimer zum Umstellen der Heizperiode:
([23:30] and $md eq "08-31")
Ist es möglich, nur Tag und Monat als Trigger zu nutzen? Ich habs nicht hinbekommen.
matze
Den Monat findest du in $month und den Tag in $mday.
Siehe z.B. https://forum.fhem.de/index.php?topic=44380.0
Hallo,
ginge das als Trigger, hatte bei mir nicht funktioniert:
([$mday = 1 and $month = 9])
matze
Dein Syntax ist sehr frei erfunden :) so wäre es besser:
($mday == 1 and $month == 9)Wobei da nichts triggert, also so könnte es gehen:
([23:30] and $mday == 1 and $month == 9)Ich habe es aber nicht getestet und bin nicht sicher an welcher Stelle in FHEM, in welchem Modul $mday und $month wirklich verfügbar sind :-[
Aber laut Doku sollte es überall sein:
ZitatUm die Verwendung von Datum und Zeitangaben zu vereinfachen, wurden die Variablen $sec, $min, $hour, $mday, $month, $year, $wday, $yday, $isdst und $hms für die Verwendung in PERL-"oneliners" eingeführt (s. unter perldoc -f localtime). Ausnahmen: $month hat einen Wertebereich von 1 bis 12 und $year ist korrigiert von 1900. Weiterhin enthält $hms die Zeit in dem HH:MM:SS Format und $today das aktuellen Datum in YYYY-MM-DD Format.
Die Variabe $we hat den Wert 1 wenn der abgefragte Tag auf ein Wochenende fällt (Z.B. $wday == 0 [Sonntag] oder $wday == 6 [Samstag]), und 0 für die anderen Wochentage. Wenn man das global holiday2we Attribut setzt, dann ist $we ebenfalls 1 bei Urlaubstagen.
Zitat von: Otto123 am 30 August 2021, 12:03:43
Aber laut Doku sollte es überall sein:
"Überall", wenn das betreffende "Coding-Umfeld" entweder die Funktion AnalyzePerlCommand() aus fhem.pl korrekt aufruft, oder was vergleichbares intern abbildet (z.B. bei der Auswertung von Attributen usw.). DOIF enthält afaik eine unabhängige gekapselte (aber zumindest in den Grundzügen kompatible) Implementierung.
Anders gesagt: diese Variablen gibt es "fast nirgends" (z.B. in myUtils-Code muss man sie ausdrücklich generieren).
Für solche längere Zeiträume als Tage umfassende Timer enthält afaik nur "at" entsprechende Implementierungen (in der commandref mal nach "at_ultimo()" schauen bzw. in fhem.pl, was es zurückgibt); mit "Perl-at-timespec" sollten sich ggf. auch beliebige Zeitpunkte in der Zukunft (halbjährlich, am 01.01., ...) abbilden lassen. Allerdings stellt sich die Frage, ob es im konkreten Fall den Aufwand wert ist...
Hallo,
Danke, dann ist das wohl doch die kürzeste Variante:
([23:30] and $md eq "08-31")
matze
Naja wenn ich richtig liege willst Du zwei trigger pro Jahr?
ich würde ja ein at nehmen https://fhem.de/commandref_modular.html#at dort gibt es auch: trigger an jeden letzten Tag im Monat - Abfrage des Monats - fertig. ;)
Symbolisch {if (märz) {sommer};if (august) {winter}}
Zitat von: matze1999 am 30 August 2021, 12:36:20
Danke, dann ist das wohl doch die kürzeste Variante:
([23:30] and $md eq "08-31")
:) Vermutlich.
Ich sehe nur ein "Problem": Falls du irgendwann außerhalb der Schalttage irgendwas änderst oder umstellst, findet die Umstellung evtl. gar nicht statt.
Entsprechendes gilt für at/at_ultimo().
Wenn es um Präferenzen für solche "Jahreskalender" geht, würde ich - zumindest mal in der Theorie und ins Unreine gesprochen - zu "holiday" greifen und dann ggf. einen (nicht für holiday2we genutztes) holiday erstellen, ggf. die topics (für weekprofile) als Wert darstellen und dann ein notify auf den holiday ansetzen, der "today" mit "yesterday" (oder dem aktuellen Stand) vergleicht und umstellt, wenn nicht ein "spezieller Modus" (Urlaub) das ganze überlagert oä....
Ist zwar mehr (Rechen-) Aufwand, aber falls es mal irgendwo "hakt", sollte spätestens kurz nach Tagesbeginn immer alles wieder "im Butter" sein.
Aber: TMTOWTDI.