Der WeekdayTimer-Thread ab 2020

[Beta-User]

Kannst du vollständige RAW-lists liefern, damit ich das nachvollziehen kann?

Wenn du einen "6-er Schaltzeitpunkt" definierst, wird der (fast, s.u.) immer ausgeführt, ganz egal, ob $we wahr ist oder nicht. Und nur "by-holiday" machen aus Samstagen noch keine !$we-Tage, dazu müßtest du auf ein Device namens "weekEnd" definiert haben (oder per noWeekEnd die Samstage rausnehmen).

Noch "lustiger" ist, dass WDT auch eine Option für "an diesem numerischen Tag, aber nicht, wenn $we ist" kennt .

[juemuc]

Hi Beta-User,
anbei mein Testszenario:
1. Bettlicht-WT ohne Samstag/Sonntag:

Code Auswählen Erweitern

defmod Bettlicht_WT WeekdayTimer Bettlicht_WT_Dummy de 8|21:45|on 8|23:00|off
Es werden nur die Wochentage Mo-Fr berücksichtigt (wie erwartet). Wenn ich in der globalen Variable "holiday2we" zusätzlich "weekEnd" eintrage, dann wird auch Samstag/Sonntag berücksichtigt (wie erwartet).

2. Bettlicht-WT mit "!we" und "6" für Samstag. In der globalen Variable "holiday2we" ist nur by eingetragen.

Code Auswählen Erweitern

defmod Bettlicht_WT WeekdayTimer Bettlicht_WT_Dummy de 68|21:45|on 8|23:00|off
Hier wird der Samstag berücksichtigt. Das hätte ich so nicht erwartet.
Ich hoffe, es ist so klar geworden.
Viele Grüße
Jürgen

[juemuc]

Kannst du vollständige RAW-lists liefern, damit ich das nachvollziehen kann?

Wenn du einen "6-er Schaltzeitpunkt" definierst, wird der (fast, s.u.) immer ausgeführt, ganz egal, ob $we wahr ist oder nicht. Und nur "by-holiday" machen aus Samstagen noch keine !$we-Tage, dazu müßtest du auf ein Device namens "weekEnd" definiert haben (oder per noWeekEnd die Samstage rausnehmen).

Noch "lustiger" ist, dass WDT auch eine Option für "an diesem numerischen Tag, aber nicht, wenn $we ist" kennt .

Das bedeutet, dass WDT hier eine eigene Logik verwendet, oder  (auch wenn Du sie nur übernommen hast  )

Noch "lustiger" ist, dass WDT auch eine Option für "an diesem numerischen Tag, aber nicht, wenn $we ist" kennt

Du meinst hier |w ?  Jetzt verstehe ich auch den Sinn 

Wenn dem so ist, dann arbeitet natürlich WDT "as designed" 

Viele Grüße
Jürgen

[Beta-User]

Das bedeutet, dass WDT hier eine eigene Logik verwendet, oder  (auch wenn Du sie nur übernommen hast  )

Jein...

Du meinst hier |w ?  Jetzt verstehe ich auch den Sinn 

Korrekt... Das "w" stammt (soweit ich mich entsinne) von mir, denn ich fand es auch nicht "logisch zwingend", dass die "6" trotzdem berücksichtigt wird, obwohl (typischerweise) $we ist.

Wenn dem so ist, dann arbeitet natürlich WDT "as designed" 

Qed.

Habe jetzt deine RAW nicht getestet, aber nach dem, was du schreibst besteht hinsichtlich der Funktionalität mAn. im Moment kein handlungsbedarf. Man kann "alles" umsetzen...

Vielleicht ist jetzt aber klarer, warum ich mich mit dem "wording" etwas schwer tue? Ich selbst denke da nur in den Kategorieren $we oder eben "nicht $we" (und habe dabei die vielfältigen Optionen zur "Erzeugung und Deutung" der Variable im Hinterkopf) . Ist natürlich nicht so einfach, das in ein Widget zu packen....

[Beta-User]

Ok. Ich werde es so umsetzen:
Bei $we( 7 ) und bei !$we( 8 ) lese ich die Profile aus, ansonsten das DEF.
Dadurch kann ich die Darstellung der Button der aktiven Tage unterscheiden. Einmal mit Rahmen und einmal voll ausgefüllt.

LG mr_petz

Bitte beachten: die in den Internals sichtbaren Profile sind Momentaufnahmen, die jeden Tag neu gebaut werden! Es können sich also Änderungen ergeben, wenn die zugrundeliegenden Infos zu IsWe() sich ändern...
(Es klang so, als wäre das ggf. noch klärungsbedürftig).

Ansonsten bin ich weiter für Änderungen des wordings offen (falls das nicht klar genug rüberkam). Es muss halt so sein, dass grade auch zu den Usern keine Brüche entstehen, die noch FUIP/FTUI2 im Einsatz haben.

[juemuc]

Danke für den Hinweis.
Werden durch die Änderung der Profile (welcher Grund auch immer) Ereignisse erzeugt?
Viele Grüße
Jürgen

[mr_petz]

Danke für den Hinweis.
Es werden, sobald sich was ändert, die Daten neu geholt. Ich Trigger da drauf.
Ich konnte nur nicht richtig Folgen was nun wie gesetzt oder nicht gesetzt wird...

LG

[mr_petz]

@Beta-User
Hi,
nochmal eine Frage zwecks Event´s.
Ich muss extra noch auf disabled im FTUI3-Modul gehen(im case) um ein "refresh"/eine Aktualisierung zubekommen wenn in fhem disabled wird.
Jetzt die Frage.
Könntest du wenn disabled wird (in Fhem) noch ein Event auf´s wdt setzen wie beim enablen?
Standardmäßig gehe ich auf currValue um das FTUI3-Modul zu aktualisieren.
Im FTUI2-widget ist das selbe Szenario. Erst nach neu laden wird disabled angezeigt.
Ich hoffe du verstehst mein Anliegen und könntest da was pimpen .

LG mr_petz

Edit: der state bleibt bei disabled 1 auch auf aktiv?! Das sollte man auch ändern?

Edit2: Hat sich erledigt Danke. Es geht wenn ich nur auf das Device gehe.... LG mr_petz

[juemuc]

Hi mr_petz,

aus meiner Sicht werden schon Ereignisse generiert. Hier mein Testergebnis:

Code Auswählen Erweitern

2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT disabled: 0
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT inactive
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT active
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT active
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT nextUpdate: 2023-02-02 21:45:00
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT nextValue: on
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT currValue: off
2023-02-02 15:43:25 Global global ATTR Bettlicht_WT disable 0
2023-02-02 15:43:30 dummy Bettlicht_WT_Dummy off
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT nextUpdate: 2023-02-02 21:45:00
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT nextValue: on
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT currValue: off
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT off

Viele Grüße
Jürgen

[mr_petz]

Setze mal bitte auf disabled 1

LG

[juemuc]

Bitteschön:

Code Auswählen Erweitern

2023-02-02 15:56:23 WeekdayTimer Bettlicht_WT disabled: 1
2023-02-02 15:56:23 Global global ATTR Bettlicht_WT disable 1

Viele Grüße
Jürgen

[mr_petz]

Das habe ich ja geschrieben. Es geht nur ein Event auf disabled. ich bräuchte das auf currentValue oder auf ein anderes reading .
Ich muss doch auf irgendwas triggern. Wenn ich nur auf disabled gehe, dann passiert bei einer Änderung der Timer nichts...
beim setzen disabled 0 oder enablen werden alle Events ausgelöst...

LG

[juemuc]

Kannst Du nicht global triggern? Immer wenn ein Event des WDT-Devices erscheint, wird neu gelesen.
Ich will aber Beta-User nicht vorgreifen.

Viele Grüße
Jürgen

[Beta-User]

Ähm, ihr habt mich etwas verloren...

Also prinzipiell möchte ich ja "unnötige" Trigger eher vermeiden, aber wenn das hilft, kann man schon was einbauen. Da ist neben "disable" übrigens noch ein anderer Punkt: Die Profile werden jeden Tag kurz nach Mitternacht neu generiert, jeweils für eine Woche im Voraus. Wenn das erfolgt, triggert da vermutlich gar nichts, aber es kann durchaus sein, dass einzelne Tage komplett anders aussehen, weil sich eben irgendwas im $we-Umfeld geändert hat oder überhaupt erst auslesbar wird (für den aktuellen und die kommenden Tage)...

Wäre sowas wie "trigger WDT profiles updated" (bzw "deactivated") hilfreich?

(Und wie war das jetzt mit der Benennung von "Werktage"?)

[mr_petz]

Das mit dem Event hat sich erledigt. Wenn ich nur auf das Device ohne Reading gehe bekomme ich alle Events von wdt, aber wie du sagst vermutlich nicht die Profile.

Werktage wollten wir in Arbeitstage umbnennen.

Jetzt noch zu $we. Hier wird bei mir auch der Fr definiert wenn Freitag ein Feirtag ist.
Ist das so richtig?

LG