Der WeekdayTimer-Thread ab 2020

Begonnen von Beta-User, 10 September 2020, 16:42:29

Vorheriges Thema - Nächstes Thema

ToKa

Ich mache das über einen Feiertagskalender, der mit dem Holiday device kombiniert ist. Feiertag wurde auch angezeigt und es hat sehr lange gut funktioniert.

Heute dann ganz exotisch, kein Feiertag mehr, aber Heizungen werden wie am Feiertag geschaltet  :o

VG
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

netwalk

Hallo Beta-User,

am langen WE habe ich folgende Beobachtungen gemacht:

Der Status wurde geändert (auf Urlaub):
01.05. 00:10 SU.MU eingestellt
Die allnächtliche Reanimierung der Timer:
01.05. 03:50 set wdt.* enable
Die resultierenden Timer:
01.05. 16:39 fhemdebug timerList

2023-05-01 20:47:25.97000 Twilight_fireEvent MyTwilight_ss
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.links
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.rechts
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Badezimmer
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Flur
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Garderobe
2023-05-01 20:47:26.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2023-05-01 20:47:26.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2023-05-01 21:01:46.00000 DOIF_TimerTrigger 
2023-05-01 21:01:46.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2023-05-01 21:01:46.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause_1
2023-05-01 21:16:46.00000 DOIF_TimerTrigger 
2023-05-01 21:16:46.00000 DOIF_TimerTrigger 
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Arbeitszimmer.Arbeit_1
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Arbeitszimmer.Urlaub.zuhause_1
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Schlafzimmer.Arbeit_1
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Schlafzimmer.Urlaub.zuhause_1
2023-05-01 21:29:54.00000 DOIF_TimerTrigger 
2023-05-01 21:29:54.00000 DOIF_TimerTrigger 
2023-05-01 21:29:54.00000 DOIF_TimerTrigger 
2023-05-01 21:30:30.00000 WDT_Update hc.eg.Kueche.SH.MB_6
2023-05-01 21:30:30.00000 WDT_Update hc.eg.Kueche.SH.MH_6
2023-05-01 21:31:00.00000 DOIF_TimerTrigger 
2023-05-01 21:31:45.98000 Twilight_fireEvent MyTwilight_ss_civil
2023-05-01 21:31:46.00000 DOIF_TimerTrigger 
2023-05-01 21:31:46.00000 DOIF_TimerTrigger 
2023-05-01 21:31:46.00000 DOIF_TimerTrigger 
2023-05-01 21:31:46.00000 DOIF_TimerTrigger 
2023-05-01 21:31:46.00000 DOIF_TimerTrigger 
2023-05-01 21:31:46.00000 WDT_Update wdt.duo.eg.Wohnzimmer.Seite.Arbeit_1
2023-05-01 21:31:46.00000 WDT_Update wdt.duo.eg.Wohnzimmer.Seite.Urlaub.zuhause_1
2023-05-01 21:50:00.00000 DOIF_TimerTrigger 

um 21:01:00 hätte der Timer hc.st.Schlafzimmer.SU.MU schalten sollen, wird aber gar nicht gelistet.

Um den Fehler abzufangen, lasse ich jeden Abend um 21:31 erneut ein
set wdt.* enableausführen.
Dies funktioniert:
2023-05-01_20:49:37 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_20:59:27 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:01:34 hm.hr.st.Schlafzimmer actuator: 27
2023-05-01_21:01:34 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_21:09:42 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:11:56 hm.hr.st.Schlafzimmer actuator: 27
2023-05-01_21:11:56 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_21:20:22 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:24:48 hm.hr.st.Schlafzimmer actuator: 27
2023-05-01_21:24:48 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_21:30:24 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:31:10 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-05-01_21:32:50 hm.hr.st.Schlafzimmer actuator: 0
2023-05-01_21:35:02 hm.hr.st.Schlafzimmer measured-temp: 19.3
2023-05-01_21:38:03 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:43:23 hm.hr.st.Schlafzimmer actuator: 0
2023-05-01_21:43:23 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-05-01_21:50:38 hm.hr.st.Schlafzimmer measured-temp: 19.2

Der Status wurde erneut geändert, diesmal vor 00:00 Uhr:
01.05. 23:23 SH.MB eingestellt
Die allnächtliche Reanimierung der Timer:
02.05. 03:50 set wdt.* enable
Die resultierenden Timer:
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.links
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.rechts
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Badezimmer
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Flur
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Garderobe
2023-05-02 20:49:03.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2023-05-02 20:49:03.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2023-05-02 21:01:00.00000 WDT_Update hc.st.Schlafzimmer.SH.MB_4
2023-05-02 21:03:37.00000 DOIF_TimerTrigger 
2023-05-02 21:03:37.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2023-05-02 21:03:37.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause_1
2023-05-02 21:11:35.62674 HttpUtils_TimeoutErr 

Daraus folgere ich, dass ein
set wdt.* enable nicht ausreicht, um die Timer neu berechnen zu lassen, wenn Bedingungen nach 0:00 Uhr geändert wurden, unabhängig vom Problem der WE-Schaltung.

live long and prosper
netwalk
_______________________________________________
INTEL NUC7CJYH, Homematic mit 3x HMLGW, JEELINK mit 18x TX29-DTH-IT, DUOFERNSTICK, FB7590 mit FBDECT, NETATMO, Philips HUE, RFXtrx433, Ubiquiti G3 PRO/FLEX/DOME/MICRO

Beta-User

Puh, schaut so aus, als müßte ich mich da nochmal grundlegend drüber beugen.

Hoffe, ich komme die Tage mal dazu, neige aber im Moment dazu, erst mal wieder die Version mit dem "relativ kleinen" Bug (also rev. 27118 ) einzuchecken und ggf. dann erst mal wieder Testversionen anzubiegen. Meinungen dazu?
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

juemuc

Kann ich mit leben. Helfe gerne beim Testen.

Hatte bisher keine Probleme. Kann aber meine Testszenarien gerne erweitern.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Beta-User

Hallo zusammen,
bin leider noch nicht dazu gekommen, das ausgiebig auszutesten, aber weil es in https://forum.fhem.de/index.php?topic=133492.0 noch die (m.E. sehr sinnvolle) Anregung gab, im "state" anzuzeigen, dass der WDT im disable-Fall nicht aktiv ist, habe ich eben noch ein update eingecheckt, das sehr vielleicht auch das $we-Problem löst.
Wer auf Nummer sicher gehen will, kann den WDT ja vom update ausnehmen bzw. die (fast) funktionierende Version (also rev. 27118) aus dem svn holen...

(Möglichst positive...) Rückmeldungen wie immer gerne, ich bin jetzt aber ein paar Tage unterwegs, also bitte nicht wundern, wenn es wieder etwas dauert, bis ich mich melde.
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

juemuc

Hi Beta-User,

die aktiven WT haben im Reading "state" weiterhin den Wert des Readings "currValue". Ich hätte erwartet, dass hier nur noch active und inactive angezeigt wird.

Für mich ist es aber auch so ok. Ansonsten keine Auffälligkeiten.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

fireball

Hi,

mir ist jetzt gerade aufgefallen, dass WeekdayTimer bei den Optionen "enable/disable" immer zu einer Änderung der Konfig führt und das rote Fragezeichen bei "save" damit provoziert wird.
Ich habe gerade erfahren, dass ein set Befehl diese Änderung eigentlich nicht hervorrufen soll.
Ist dann ein Bug im Modul oder?

Hintergrund, ich steuere über einen Dummy ein Notify, welches dann 4 WeekdayTimer aktiviert oder deaktiviert.
Jedesmal habe ich, wenn ich den Dummy klicke, dass rote Fragezeichen für unsaved changes.
Ich habe jetzt auch mal den kurzen Weg genommen und direkt set XXXXX enable/disable gemacht und siehe da, auch das rote Fragezeichen...

Last unsaved structural changes:
  attr GB_Kreis_2_Timer disable 1

Viell. kann da jemand nochmal in Code schauen?!

VG+Danke
René

Nobbynews

#142
Ob Bug oder nicht,

die commandref sagt dazu:

https://fhem.de/commandref_DE.html#attr

ZitatMit der silent Option wird der Befehl nicht in die "save -?" Liste eingetragen.

also

attr GB_Kreis_2_Timer -silent disable 1
und der Drops ist gelutscht.

Beta-User

Zitat von: fireball am 25 Juli 2023, 13:02:04Ist dann ein Bug im Modul oder?
"Bug" ist ein großes Wort....

Das Verhalten ist historisch so gewachsen, und im Moment finde ich das auch nicht besonders störend, dass das a) (im Ergebnis) via Attribut gelöst ist und b) dann der deutliche Hinweis erfolgt, dass die Änderung auch abgespeichert wird.

Falls es gute Gründe und ausreichend Interessenten gibt, können wir das gerne nochmal diskutieren, ob es tatsächlich als "bug" anzusehen ist... (dann sind auch patches willkommen!).
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Nobbynews

Zitat von: Beta-User am 25 Juli 2023, 16:15:04
Zitat von: fireball am 25 Juli 2023, 13:02:04Ist dann ein Bug im Modul oder?
"Bug" ist ein großes Wort....
Das war auch mehr ironisch gemeint....

fireball

Moinsen,
ich kann mit dem Workaround leben, ich bin nur endlich froh, dass ich herausgefunden habe, woher ich immer die Meldung bekommen habe, dass sich was geändert hat und ich es speichern soll.
Das mit dem "Bug" war ne Frage und keine Aufforderung.

ich kann mit dem Workaround sicherlich leben, ich geh aber mal davon aus, dass die silent Option zwar das "Fragezeichen" verhindert, aber das Problem, bei einem Restart trotzdem der letzte Stand nicht gespeichert ist?!

BTW: habs grad getestet... in meinem Notify ist diese Zeile jetzt eingetragen:
Gartenbewaesserung attr -silent (GB_Kreis_._Timer) $EVENT

Wenn Gartenbewaesserung enable/disable gesetzt wird, wird dieses EVENT im Notify genutzt und jetzt is das Attribut disable leer, weder 0 noch 1 drin.

Das funzt also doch nicht...

VG
René

Nobbynews

Zitat von: fireball am 26 Juli 2023, 16:10:58Gartenbewaesserung attr -silent (GB_Kreis_._Timer) $EVENT

Wenn Gartenbewaesserung enable/disable gesetzt wird, wird dieses EVENT im Notify genutzt und jetzt is das Attribut disable leer, weder 0 noch 1 drin.

Das funzt also doch nicht...

Wenn in $EVENT enable/diable steht, dann geht das so nicht.
Es muss immer ".... disable 0" oder ".... disable 1" im notify für den attr-Befehl stehen.


fireball

Sowas hab ich mir schon gedacht,als ich in die Doku geschaut habe. Dann muss ich mal schauen, ob mein Dummy-Schalter die 0 oder 1 als EVENT mit übertragen kann.
Danke für den Hinweis.

VG René

Nobbynews

Zitat von: fireball am 26 Juli 2023, 16:51:38ob mein Dummy-Schalter die 0 oder 1 als EVENT mit übertragen kann.
Das kannst Du doch im notify erledigen, z.B.:
Heizperiode:on|Heizperiode:off {
....
my $Wert2 =0;
....
if ($EVENT eq "off") {
 .....
 $Wert2 = 1;
 .....
 }
fhem("attr -silent wdT_.* disable $Wert2");
....
}

fireball

Ja klar 💪 danke für die Erleuchtung. Sowas hab ich auch schon an anderer Stelle... Manchmal denke ich einfach zu kompliziert.
VG René