Ich überlege Zeittrigger um Datumsangaben zu erweitern:
Syntax:
[<erster Tag> to <letzter Tag> at <Zeittrigger wie bisher>]
<letzter Tag> optional
Beispiele
[24.12 at 23:00]
[04.09 to 12.10 at 08:00]
[[tag:erster] to [tag:letzter] at 08:00]
[01.12 to 31.01 at [mydevice:time]]
[01.03 to 20.04 at {timefunc()}]
[01.10 to 30.12 at 08:00-22:00,+:30]
ggf. auch mit US-Darstellung MM/TT
Außerhalb der Zeitspanne sollten keine Zeittrigger stattfinden.
Weitere Ideen?
Ich bräuchte "von Datum+Uhrzeit bis Datum+Uhrzeit, +:30". Hab aber noch nicht geguckt, ob das schon möglich ist
Zitat von: amenomade am 08 Dezember 2020, 22:09:13
Ich bräuchte "von Datum+Uhrzeit bis Datum+Uhrzeit, +:30". Hab aber noch nicht geguckt, ob das schon möglich ist
Das letzte Beispiel reicht dir nicht?
Also so etwas:
[01.10 at 08:00 to 12.12 at 22:00,+:30]
Nö, ich will z.B von Freitag Abend mit Montag-früh
Oder vom ersten Tag des Urlaubs um 16:00 Uhr bis vorletztem Tag des Urlaubs 12:00 Uhr.
Wenn ich dein letztes Beispiel richtig verstanden habe, heisst es "jeden Tag von 1.10 bis 30.12, in der Zeitspanne 08:00-22:30"
Zitat von: amenomade am 08 Dezember 2020, 22:15:59
Nö, ich will z.B von Freitag Abend mit Montag-früh
Oder vom ersten Tag des Urlaubs um 16:00 Uhr bis vorletztem Tag des Urlaubs 12:00 Uhr.
Wenn ich dein letztes Beispiel richtig verstanden habe, heisst es "jeden Tag von 1.10 bis 30.12, in der Zeitspanne 08:00-22:30"
also auch so etwas:
[20:00|Fr-08:00|Mo]
Ja z.B., oder auch [20:00|24.12-08:00|05.01,+:00]
Zitat von: amenomade am 08 Dezember 2020, 22:37:41
Ja z.B., oder auch [20:00|24.12-08:00|05.01,+:00]
ja, das Problem ist die Abwärtskompatibilität, 05.01 würde als Freitag, Sonntag bzw. Montag interpretiert werden, daher eher so etwas:
[01.10 at 08:00 to 12.12 at 22:00,+:30]
Ja, kein Pb mit einer neuen Syntax. Das war nur um meine use-cases zu beschreiben
Die Funktionalität des Calendar-Moduls in DOIF nachbauen um quasi-Kalendereinträge in das DOIF zu kippen?
Warum?
Weil ich keine Affinität mit CALENDAR-Triggerung habe, und das ggf zu kompliziert wäre, um nur ein paar Triggers zu haben, einen Kalender irgendwo zu pflegen (und die gesamte Logik dahinten)
Bin ein fauler Mensch ;)
Die Logik hinter Calendar ist erheblich einfacher. Und vor allem gibt es eine Logik. Und zwar eine, die man auch versteht, weil sie standardisiert ist.
Generell eine gute Idee. Nur so ein Gedanke von mir - ich würde mich vermutlich an einem etwas internationalerem Datumsformat orientieren, und statt Leerzeichen und "at" mit @ arbeiten, an die Syntax vun Remind (http://dianne.skoll.ca/projects/remind/) angelehnt. Z.B. sowas:
[YYYY-MM-DD@hh:mm]
[MM-DD@hh:mm]
Wenn man das noch weiter spinnt, könnte man auch Wildcards o.ä. erlauben, analog zu Cron...
Das Problem ist, wie immer, die Abwärtskompatibilität:
Bisher ist das Minuszeichen ein Trennzeichen für Zeitintervalle:
[von-bis]
[12-01-12-30] ist schon schlecht zu erkennen
[[von]-[bis]] hier weiß der Parser erst mal nicht, ob es um Uhrzeit oder Tage geht.
Grundsätzlich wäre mir eine standardisierte Syntax auch lieber.
Edit:
evtl. so etwas:
[12-01 to 12-30] Tagesintervall ohne Trigger, wahr im Zeitraum mit and sinnvoll verknüpfbar
[12-01@08:00 to 12-30@20:00] Tagesintervall mit Anfangs- und Endzeit mit Trigger am Anfang und Ende, wahr im Zeitraum, sonst falsch
[12-01 to 12-30 at 08:00] Tagesintervall mit Trigger, wahr nur zum Triggerzeitpunkt
[12-01 to 12-30 at 08:00-20:00] Tagesintervall mit Zeitintervall mit Trigger am Anfang und Ende, wahr in Kombination der beiden Intervalle
[12-01 to 12-30 at 08:00-20:00, +01:00] Tagesintervall mit Trigger im jeweiligen Zeitintervall, wahr nur zum Triggerzeitpunkt
Alle Angaben wären mit indirekten Angaben möglich
z. B. für das letzte Beispiel:
[[anfangstag] to [endtag] at [anfangszeit]-[endzeit], [Triggerwiederholung]]
Zitat von: Damian am 09 Dezember 2020, 07:52:08
Bisher ist das Minuszeichen ein Trennzeichen für Zeitintervalle:
Stimmt, das hatte ich nicht bedacht... Vielleicht dann doch ein Schrägstrich YYYY/MM/DD oder der Punkt nach deutschem Format DD.MM.YYYY (wobei der Jahr in beiden Fällen optional wäre).
Die Beispiele sehen durchaus logisch aus. Für solche regelmäßigen Triggerungen scheint mir DOIF logischer zu sein als CALENDAR - letzteres würde ja die Pflege eines externen Kalenders benötigen, um dann in FHEM auf dessen Ereignisse zu reagieren. Das finde ich etwas zu umfangreich, wenn ich nur ein paar feste Zeiten / Tage haben möchte statt gleich einen Kalender zu pflegen und einzubinden.
Zitat von: xenos1984 am 09 Dezember 2020, 09:54:33
Stimmt, das hatte ich nicht bedacht... Vielleicht dann doch ein Schrägstrich YYYY/MM/DD oder der Punkt nach deutschem Format DD.MM.YYYY (wobei der Jahr in beiden Fällen optional wäre).
Die Beispiele sehen durchaus logisch aus. Für solche regelmäßigen Triggerungen scheint mir DOIF logischer zu sein als CALENDAR - letzteres würde ja die Pflege eines externen Kalenders benötigen, um dann in FHEM auf dessen Ereignisse zu reagieren. Das finde ich etwas zu umfangreich, wenn ich nur ein paar feste Zeiten / Tage haben möchte statt gleich einen Kalender zu pflegen und einzubinden.
wenn ich die "bis" Angabe für Tagesintervalle als "to", wie vorgeschlagen (siehe meine letzten Bespiele), definiere, dann sollte man mit Minuszeichen in den Datumsangaben klar kommen
Zitat von: Damian am 09 Dezember 2020, 10:53:42
wenn ich die "bis" Angabe für Tagesintervalle als "to", wie vorgeschlagen (siehe meine letzten Bespiele), definiere, dann sollte man mit Minuszeichen in den Datumsangaben klar kommen
Ah, jetzt verstehe ich - also "to" für Datumsintervalle, Minus für Zeitintervalle und als Trenner für das Datum. Klingt ein wenig kontraintuitiv, dass einerseits das Minus dann zwei verschiedene Bedeutungen hat, und andererseits zwei ähnliche Aufgaben (Intervalle) mit ganz verschiedenen Trennzeichen behandelt werden.
ich denke ich werde mich, wie beim at, an die ISO 8601 halten:
also yyyy-mm-ddThh:mm
Wobei eine Jahreszahl für mich eher ausscheidet, weil einmalige Trigger im DOIF nicht wirklich sinnvoll sind.
z. B. [12-24T17:00]
Dennoch finde ich eine "to at" Syntax für Tagesintervalle sinnvoll. An der kann man sich besser orientieren, auf welcher Ebene man sich befindet.
[10-09 to 10-10 at 20:00-22:00,+01:00]
dürfte lesbarer sein, als z. B.
[10-09 - 10-10,20:00-22:00,+01:00]
auch das Parsen dürfte wesentlich einfacher ausfallen, zu mal die bisherigen Definitionen alle noch funktionieren sollten.
Hallo zusammen, Hallo Damian,
irgendwie finde ich kein Beispiel für mein Problem :
es soll immer am 1. des Monats um 00:01 und am letzten des Monats um 23:59 ein Wert in einen dummy geschrieben werden.
Es werden in den Beispielen immer volle Datumsangaben angeführt.
mein aktueller Versuch :
([00:01] and (strftime ("%d",localtime time) == 01)) (set mv1_ht [E_ht])
DOELSEIF ([23:59] and (strftime ("%d",localtime time+86400) == 01)) (set mv_ht {([mv1_ht:state]-[E_ht])})
FUUID
Freue mich über einen Tipp.
Gruß Peter
Sieht ok aus. Wo ist das Problem?