Jahreszeit Snippet per DOIF abfragen? Bin mal wieder zu doof dazu ^^

[M_I_B]

... vielleicht schreibt irgend wer mal ein nettes Modul für die Jahreszeiten, was beides beinhaltet, fest in FHEM verankert ist und sich der geneigte DAU um nichts mehr kümmern muss, außer um die Abfrage was nun ist

Eigentlich war es gar nicht mein Fehler, habe ihn nur (ungeprüft, das war mein Fehler!) übernommen

Stimmt, aber warum soll es dir anders gehen als mir? Ich bin bei sowas vermutlich noch besser als du, glaub und übernehme ungefragt erst mal alles, was die Forengemeinde so ausbrütet. Und wenn's dann nicht geht? Tja... dann nerve ich euch

[Laffer72]

Jetzt steinigt mich bitte nicht, aber kann man das nicht ganz simpel über eine eigene Holiday-Datei lösen?

Duck und weg....

Code Auswählen Erweitern

define Jahreszeit holiday

und die Datei Jahreszeit.holiday anlegen mit

Code Auswählen Erweitern

4 03-21 06-20 Frühling
4 06-21 09-21 Sommer
4 09-22 12-20 Herbst
4 12-21 03-20 Winter

fertig.

[M_I_B]

... klar, könnte man auch, ist aber statisch und zu einfach

[Laffer72]

nur ganz kurz noch:

-einfach: ja, keep it simple. Bessere Lesbarkeit und weniger Fehleranfälligkeit

-statisch: ja, genauso statisch, wie das DOIF. Der Zeitraum wird da ja auch mit festen Zahlenwerten (quasi fix im Code) abgefragt...oder anders gefragt wie oft  ändern sich die Daten für die Jahreszeitenwechsel??? 

[Per]

Du hast den Smylie fehlinterpretiert!

Aber mal ernsthaft gefragt, warum eine eigene Datei? Kenne mich, mangels Bedarf mit "holiday" nicht aus. Darf es nicht mit in die "große" Feiertags-Datei, weil sonst immer Feiertag wäre, da ja immer eine der vier Jahreszeiten aktiv ist?

[Laffer72]

kommt darauf an, was Du mit der großen Datei machst. Solltest Du sie im Device global als

Code Auswählen Erweitern

attr global holiday2we xxx.holiday

dann wäre immer Feiertag.

Also besser eine eigene Datei. Ich hab mir auch eine für Sternzeichen und eine für die katholischen Kirchenfeste (nicht alle sind gesetzliche Feiertage) angelegt.
Außerdem ist das ganze nicht nur tagesgültig, sondern man kann den Wert auch für ein beliebiges Datum abrufen.

Viele Grüße

Reinhard

[schucki]

Hallo @Laffer72 ich habe deinen Vorschlag mit de Holiday Datei mal umgesetzt, da ist mir aber aufgefallen, dass die holiday Datei nicht über den Jahreswechsel hinaus mit dem Parameter 4 (Zeitspanne) zurecht kommt. Bei mir funktioniert nur:

Code Auswählen Erweitern

4 12-21 12-31 Winter
4 01-01 03-20 Winter

[Dersch]

Ich grabe das hier mal wieder aus. Ich möchte meine Bachpumpe auch mit einer Jahreszeit Angabe steuern und habe das hier daher kopiert und musste sehen das der Dummy leider auf Winter geschaltet wurde. Das DOIF ging auf ERR.

Hier habe ich das season_get DOIF:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        ([00:00] and 10 * $month + $mday >= 1121) (set season Winter)
DOELSEIF ([00:00] and 10 * $month + $mday >= 822) (set season Herbst)
DOELSEIF ([00:00] and 10 * $month + $mday >= 521) (set season Sommer)
DOELSEIF ([00:00] and 10 * $month + $mday >= 220) (set season Frühling)
   NAME       season_get
   NR         41468
   NTFY_ORDER 50-season_get
   STATE      initialized
   TYPE       DOIF
   Readings:
     2017-07-09 00:05:23   cmd             0
     2017-07-09 00:05:23   state           initialized
     2017-07-09 00:05:23   timer_01_c01    10.07.2017 00:00:00
     2017-07-09 00:05:23   timer_02_c02    10.07.2017 00:00:00
     2017-07-09 00:05:23   timer_03_c03    10.07.2017 00:00:00
     2017-07-09 00:05:23   timer_04_c04    10.07.2017 00:00:00
   Condition:
     0          DOIF_time_once($hash,0,$wday) and 10 * $month + $mday >= 1121
     1          DOIF_time_once($hash,1,$wday) and 10 * $month + $mday >= 822
     2          DOIF_time_once($hash,2,$wday) and 10 * $month + $mday >= 521
     3          DOIF_time_once($hash,3,$wday) and 10 * $month + $mday >= 220
   Days:
   Devices:
   Do:
     0:
       0          set season Winter
     1:
       0          set season Herbst
     2:
       0          set season Sommer
     3:
       0          set season Frühling
     4:
   Helper:
     globalinit 1
     last_timer 4
     sleeptimer -1
   Itimer:
   Localtime:
     0          1499637600
     1          1499637600
     2          1499637600
     3          1499637600
   Realtime:
     0          00:00:00
     1          00:00:00
     2          00:00:00
     3          00:00:00
   Regexp:
     All:
   State:
     State:
   Time:
     0          00:00:00
     1          00:00:00
     2          00:00:00
     3          00:00:00
   Timecond:
     0          0
     1          1
     2          2
     3          3
   Timer:
     0          0
     1          0
     2          0
     3          0
   Timers:
     0           0
     1           1
     2           2
     3           3
   Triggertime:
     1499637600:
       localtime  1499637600
       Hash:
Attributes:
   cmdState   F|S|H|W|ERR

Das DOELSE (set season Winter) am Ende habe ich danach erstmal rausgenommen. Ich vermute das war der Grund. Aber warum nimmt er nicht die Variablen davor?

Grüße
Dirk

[Ellert]

Aber warum nimmt er nicht die Variablen davor?

Was meinst Du mit Variablen nehmen?

Ob einer der 4 Bedingungszweige wahr werden kann, siehst Du, wenn Du

Code Auswählen Erweitern

{10 * $month + $mday} in die Befehlszeile ein gibst und die Eingabetaste drückst.

[Damian]

Was meinst Du mit Variablen nehmen?

Ob einer der 4 Bedingungszweige wahr werden kann, siehst Du, wenn Du

Code Auswählen Erweitern

{10 * $month + $mday} in die Befehlszeile ein gibst und die Eingabetaste drückst.

Für sowas gibt es eine Variable $md im Format MM-DD, die man abfragen kann, z. B.

Code Auswählen Erweitern

$md ge "11-21"

[Per]

Code Auswählen Erweitern

10 * $month

Wie wäre es mit

Code Auswählen Erweitern

100 * $month
?

[nils_]

Ich grabe das hier mal wieder aus. Ich möchte meine Bachpumpe auch mit einer Jahreszeit Angabe steuern und habe das hier daher kopiert und musste sehen das der Dummy leider auf Winter geschaltet wurde. Das DOIF ging auf ERR.

Hier habe ich das season_get DOIF:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        ([00:00] and 10 * $month + $mday >= 1121) (set season Winter)
DOELSEIF ([00:00] and 10 * $month + $mday >= 822) (set season Herbst)
DOELSEIF ([00:00] and 10 * $month + $mday >= 521) (set season Sommer)
DOELSEIF ([00:00] and 10 * $month + $mday >= 220) (set season Frühling)
   NAME       season_get
   NR         41468
   NTFY_ORDER 50-season_get
   STATE      initialized
   TYPE       DOIF


deine berechnung stimmt so ja nicht (siehe antwort von per)
und dazu kommt noch die frage was soll er zb bei einem ergebnis von 671 machen? du willst vermutlich Sommer setzen (weil 671 > 521) , aber auch Frühling ist möglich (weil 671 > 220) ist.
prüf auf beide grenzen....

[Per]

und dazu kommt noch die frage was soll er zb bei einem ergebnis von 671 machen? du willst vermutlich Sommer setzen (weil 671 > 521) , aber auch Frühling ist möglich (weil 671 > 220) ist.

Nee, weil das DOIF von oben nach unten abgearbeitet wird. Die Abfrage nach >220 ist gleichzeitig (weil vorher geprüft) ein <=521.

[nils_]

Nee, weil das DOIF von oben nach unten abgearbeitet wird. Die Abfrage nach >220 ist gleichzeitig (weil vorher geprüft) ein <=521.

wenn das so ist, dann ok.
und hoffentlich bleibt das "gewünschte" verhalten auch immer so.



ich würde auf nummer sicher gehen, deswegen wollte ich es nur erwähnen

[Damian]

und hoffentlich bleibt das "gewünschte" verhalten auch immer so.

ja, ist so gewollt und bewusst so programmiert worden.