Autor Thema: Der WeekdayTimer-Thread ab 2020  (Gelesen 5765 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Der WeekdayTimer-Thread ab 2020
« am: 10 September 2020, 16:42:29 »
Hallo zusammen,

nachdem WeekdayTimer jetzt schon eine ganze Weile meinereinen als Maintainer hat, Heating_Control ausgephast ist und manche Teile von Twilight irgendwie immer noch in der Codebasis drin sind, ist es jetzt an der Zeit, auch den Thread "Neues Modul - Heating_Control, WeekdayTimer" mal in Rente zu schicken und einen neuen anzufangen...

Dieser Thread soll also zukünftig als erste Anlaufstelle für den WeekdayTimer werden, und anfangen möchte ich zum einen mit einer Testversion, die einen Syntaxcheck bei der DEF beinhaltet (zum aktuellen Anlass siehe https://forum.fhem.de/index.php/topic,114131.0.html). Wäre also nett, wenn jemand das austesten will, sonst checke ich das wie immer "irgendwann" mal ein ;) .

Bei Gelegenheit werde ich dann auch den WeekdayTimer vermutlich in ein package-Format packen, wer also derzeit noch mit Heating_Control unterwegs ist, sollte möglichst zeitnah umstellen, denn wenn das gemacht ist, wird dieses Modul nicht mehr funktionieren.

Grüße,
Beta-User
« Letzte Änderung: 21 September 2020, 19:46:49 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline juemuc

  • Hero Member
  • *****
  • Beiträge: 1000
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #1 am: 12 September 2020, 21:28:48 »
Bisher alles ok.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
Fritzbox 7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM Fensterkontakte und  Amazon Echo Dot, raspberry3B+ mit RPI-RF-MOD und piVCCU, Raspbian Buster Lite

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #2 am: 21 September 2020, 19:47:42 »
Danke für die Rückmeldung, hab's dann mal eingecheckt (es gab jüngst wieder so eine DEF, bei der der Check evtl. geholfen hätte...).
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline cruser1800

  • Full Member
  • ***
  • Beiträge: 237
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #3 am: 25 September 2020, 21:36:28 »
Danke, Fehler gefunden! Syntaxprüfung funktioniert!

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #4 am: 11 Mai 2021, 10:42:40 »
Hallo,

ich nutze schon lange Zeit Weekdaytimer (vorher HeatingControl) zur Steuerung meiner Homematic Thermostate. Dazu habe ich pro Thermostat unterschiedliche Timer angelegt, die abhängig von Parametern wie "Homeoffice", "Büro", "Urlaub zuhause" etc. bezüglich einzelner Bewohner greifen.
Nun ist mir letztens aufgefallen, dass die jeweils letzten Schaltpunkte am Tag manchmal nicht stattfinden. Auf der Suche nach einer Lösung fand ich die Threads:

https://forum.fhem.de/index.php/topic,105571.msg994968.html#msg994968
https://forum.fhem.de/index.php/topic,104167.0/all.html
https://forum.fhem.de/index.php/topic,104272.0/all.html#lastPost

Dort fand ich meine Probleme wieder, jedoch keine Lösung dazu.

Auch in der aktuellen Version
# $Id: 98_WeekdayTimer.pm 24285 2021-04-20 06:02:27Z Beta-User $existiert das Problem noch.

Nun habe ich testweise den Rat befolgt und in der letzten Woche zusätzliche Schaltpunkte 10 Minuten nach der geplanten Zeit angelegt, jedoch nur für Mo-Fr, den Sa und So habe ich bei nur einem Zeitschaltpunkt abends belassen.
 Internals:
   COMMAND   
   CONDITION  (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
   DEF        struct.Heizung.st.Schlafzimmer 12345|14:01:00|day 12345|21:31:00|night 12345|21:41:00|night 60|07:01:00|day 60|21:31:00|night (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
   DEVICE     struct.Heizung.st.Schlafzimmer
   FUUID      60868de4-f33f-c765-0cb9-a9be825d1ffad321
   GlobalDaylistSpec
   LANGUAGE   en
   NAME       hc.st.Schlafzimmer.SH.MB
   NR         1791
   Profil 0: Sunday 07:01:00 day, 21:31:00 night,
   Profil 1: Monday 14:01:00 day, 21:31:00 night, 21:41:00 night,
   Profil 2: Tuesday 14:01:00 day, 21:31:00 night, 21:41:00 night,
   Profil 3: Wednesday 14:01:00 day, 21:31:00 night, 21:41:00 night,
   Profil 4: Thursday 14:01:00 day, 21:31:00 night, 21:41:00 night,
   Profil 5: Friday 14:01:00 day, 21:31:00 night, 21:41:00 night,
   Profil 6: Saturday 07:01:00 day, 21:31:00 night,
   SETTIMERATMIDNIGHT 1
   STATE      night
   STILLDONETIME 0
   TYPE       WeekdayTimer
   setModifier desired-temp
   READINGS:
     2021-05-11 07:09:00   currValue       night
     2021-04-26 11:54:44   disabled        0
     2021-05-11 07:09:00   nextUpdate      2021-05-11 14:01:00
     2021-05-11 07:09:00   nextValue       day
     2021-05-11 07:09:00   state           night
   SWITCHINGTIMES:
     12345|14:01:00|day
     12345|21:31:00|night
     12345|21:41:00|night
     06|07:01:00|day
     06|21:31:00|night
   TIMER:
     hc.st.Schlafzimmer.SH.MB_1:
       HASH       hc.st.Schlafzimmer.SH.MB
       MODIFIER   1
       NAME       hc.st.Schlafzimmer.SH.MB_1
     hc.st.Schlafzimmer.SH.MB_2:
       HASH       hc.st.Schlafzimmer.SH.MB
       MODIFIER   2
       NAME       hc.st.Schlafzimmer.SH.MB_2
     hc.st.Schlafzimmer.SH.MB_3:
       HASH       hc.st.Schlafzimmer.SH.MB
       MODIFIER   3
       NAME       hc.st.Schlafzimmer.SH.MB_3
   helper:
     daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
     daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
     SWITCHINGTIME:
       0:
         07:01:00   day
         21:31:00   night
       1:
         14:01:00   day
         21:31:00   night
         21:41:00   night
       2:
         14:01:00   day
         21:31:00   night
         21:41:00   night
       3:
         14:01:00   day
         21:31:00   night
         21:41:00   night
       4:
         14:01:00   day
         21:31:00   night
         21:41:00   night
       5:
         14:01:00   day
         21:31:00   night
         21:41:00   night
       6:
         07:01:00   day
         21:31:00   night
     WEDAYS:
       4          1
       5          1
   profil:
     1:
       EPOCH      1620734460
       PARA       day
       TIME       14:01:00
       WE_Override 0
       TAGE:
         1
         2
         3
         4
         5
     2:
       EPOCH      1620761460
       PARA       night
       TIME       21:31:00
       WE_Override 0
       TAGE:
         1
         2
         3
         4
         5
     3:
       EPOCH      1620762060
       PARA       night
       TIME       21:41:00
       WE_Override 0
       TAGE:
         1
         2
         3
         4
         5
     4:
       EPOCH      1620709260
       PARA       day
       TIME       07:01:00
       WE_Override 0
       TAGE:
         0
         6
     5:
       EPOCH      1620761460
       PARA       night
       TIME       21:31:00
       WE_Override 0
       TAGE:
         0
         6
   profile_IDX:
     0:
       07:01:00   4
       21:31:00   5
     1:
       14:01:00   1
       21:31:00   2
       21:41:00   3
     2:
       14:01:00   1
       21:31:00   2
       21:41:00   3
     3:
       14:01:00   1
       21:31:00   2
       21:41:00   3
     4:
       14:01:00   1
       21:31:00   2
       21:41:00   3
     5:
       14:01:00   1
       21:31:00   2
       21:41:00   3
     6:
       07:01:00   4
       21:31:00   5
Attributes:
   WDT_Group  former_HC
   WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
   commandTemplate set $NAME controlMode $EVENT
   comment    struct.Heizung.st.Schlafzimmer 12345|14:01:00|day 12345|21:31:00|night 60|07:01:00|day 60|21:31:00|night (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
   disable    0
   room       Heizung
   switchInThePast 1

Das Ergebnis ist gemischt:
Freitag funktionierte der Schaltpunkt erwartungsgemäß um 21:31 (war ja die vorletzte Zeit), am Samstag wurde jedoch auch um 21:31 geschaltet, obwohl dies der letzte Zeitpunkt am Tag war.
Am Sonntag (ebenfalls nur ein Punkt) funktionierte es wieder nicht, am Montag hingegen erwartungsgemäß schon (war ja der vorletzte Zeitpunkt).

Ich bekomme keine Regelmäßigkeit hin.
FHEM wurde letztmalig am 01.05. neu gestartet. Morgens um 03:55 lasse ich ein
set hc..* enableausführen, da gelegentlich eine Statusänderung (Homeoffice/Büro/Urlaub) erst nach 00:00 durchgeführt wird.
Zur Analyse hatte ich den verbose-Level zeitweise auf 5 gesetzt, erhielt aber keine Einträge für die nicht durchgeführten Schaltvorgänge.

Was kann ich zur weiteren Eingrenzung noch versuchen?
« Letzte Änderung: 11 Mai 2021, 10:44:46 von netwalk »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #5 am: 11 Mai 2021, 11:30:06 »
Hmm, war eigentlich davon ausgegangen, dass das Problem gelöst gewesen wäre...

Um es einzukreisen:
- kannst du bitte möglichst die Testversion aus hier benutzen: https://forum.fhem.de/index.php/topic,111401.msg1154753.html#msg1154753
Da ist insbesondere die Timerverwaltung für "delayed" geändert, könnte sein, dass das auch einen Einfluss hatte.

- Bitte zum Testen die "doppelten" Schaltpunkte möglichst draußen lassen, das muss am Ende so gehen.

- Welche Timer angelegt wurden, sollte via "fhemdebug timerList" rauszubekommen sein. Für jeden aktiven WDT und jeden noch in der Zukunft liegenden Schaltpunkt müßte ein Timer vorhanden sein.

- Ist zum Schaltpunkt der Zielzustand schon erreicht (egal, warum), führt der WDT den Befehl nicht aus. Vielleicht war auch das der Fall (müßte mal schauen, ob dann was nei höherem verbose im Log stehen sollte und ggf. was einbauen?)?
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #6 am: 11 Mai 2021, 13:09:35 »
Ok,
ich werde die Version heute einspielen und auch die doppelten Schaltpunkte entfernen.

Zum Schaltpunkt war der Zielzustand definitiv nicht erreicht, das sehe ich im Log der Thermostate.

Das delayedExecutionDevice (Fensterkontakt) ist zum Schaltzeitpunkt nie aktiv, allerdings zum Zeitpunkt des
set hc..* enableum 03:55 immer.

Ich werde berichten...
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

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #7 am: 13 Mai 2021, 10:46:18 »
So, hier einmal die ersten Erkenntnisse:

Die Version habe ich am 11.05. nachmittags eingespielt und der Timer um 21:31 hat funktioniert:
2021-05-11_21:23:19 hm.wt.st.Schlafzimmer measured-temp: 19.3
2021-05-11_21:31:00 hm.wt.st.Schlafzimmer commState: CMDs_pending
2021-05-11_21:31:00 hm.wt.st.Schlafzimmer CMDs_pending
2021-05-11_21:31:00 hm.wt.st.Schlafzimmer commState: CMDs_processing...
2021-05-11_21:31:01 hm.wt.st.Schlafzimmer desired-temp: 17.0
2021-05-11_21:31:01 hm.wt.st.Schlafzimmer commState: CMDs_done
2021-05-11_21:31:01 hm.wt.st.Schlafzimmer CMDs_done

Am 12.05. gegen 18:30 wurde der Status geändert (von "Homeoffice" auf "Urlaub"), so dass ein anderer WeekdayTimer hätte greifen sollen, allerdings fand bis zum fraglichen Zeitpunkt absichtlich kein "set enable" statt. Das Ergebnis war, dass nicht geschaltet wurde, der "Homeoffice"-Timer war aktiv, der "Urlaub"-Timer war inaktiv. Zum Schaltzeitpunkt des "Homeoffice"-Timers trafen die Bedingungen nicht mehr zu, daher war diese Reaktion zu erwarten.
Nun sollten ja um 00:00 durch das Modul die Timer neu gesetzt werden, was im State der WeekdayTimer auch funktionierte. "Homeoffice" ist inaktiv, "Urlaub" ist aktiv. Der fragliche Timer sieht folgenderweise aus:
Internals:
   COMMAND   
   CONDITION  (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status", "state", "") eq "Urlaub" and ReadingsVal("sc.Micha.Status", "state", "") eq "Urlaub")
   DEF        struct.Heizung.st.Schlafzimmer 1234560|07:01:00|day 1234560|21:31:00|night  (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status", "state", "") eq "Urlaub" and ReadingsVal("sc.Micha.Status", "state", "") eq "Urlaub")
   DEVICE     struct.Heizung.st.Schlafzimmer
   FUUID      5de97613-f33f-c765-6749-85e684e94177744a
   GlobalDaylistSpec
   LANGUAGE   en
   NAME       hc.st.Schlafzimmer.SU.MU
   NR         1634
   Profil 0: Sunday 07:01:00 day, 21:31:00 night,
   Profil 1: Monday 07:01:00 day, 21:31:00 night,
   Profil 2: Tuesday 07:01:00 day, 21:31:00 night,
   Profil 3: Wednesday 07:01:00 day, 21:31:00 night,
   Profil 4: Thursday 07:01:00 day, 21:31:00 night,
   Profil 5: Friday 07:01:00 day, 21:31:00 night,
   Profil 6: Saturday 07:01:00 day, 21:31:00 night,
   SETTIMERATMIDNIGHT 1
   STATE      day
   STILLDONETIME 0
   TYPE       WeekdayTimer
   setModifier desired-temp
   READINGS:
     2021-05-13 08:58:00   currValue       day
     2021-01-13 14:42:26   disabled        0
     2021-05-13 08:58:00   nextUpdate      2021-05-13 21:31:00
     2021-05-13 08:58:00   nextValue       night
     2021-05-13 08:58:00   state           day
   SWITCHINGTIMES:
     0123456|07:01:00|day
     0123456|21:31:00|night
   TIMER:
     hc.st.Schlafzimmer.SU.MU_1:
       HASH       hc.st.Schlafzimmer.SU.MU
       MODIFIER   1
       NAME       hc.st.Schlafzimmer.SU.MU_1
     hc.st.Schlafzimmer.SU.MU_delayed:
       HASH       hc.st.Schlafzimmer.SU.MU
       MODIFIER   delayed
       NAME       hc.st.Schlafzimmer.SU.MU_delayed
   helper:
     daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
     daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
     SWITCHINGTIME:
       0:
         07:01:00   day
         21:31:00   night
       1:
         07:01:00   day
         21:31:00   night
       2:
         07:01:00   day
         21:31:00   night
       3:
         07:01:00   day
         21:31:00   night
       4:
         07:01:00   day
         21:31:00   night
       5:
         07:01:00   day
         21:31:00   night
       6:
         07:01:00   day
         21:31:00   night
     WEDAYS:
       2          1
       3          1
   profil:
     1:
       EPOCH      1620882060
       PARA       day
       TIME       07:01:00
       WE_Override 0
       TAGE:
         0
         1
         2
         3
         4
         5
         6
     2:
       EPOCH      1620934260
       PARA       night
       TIME       21:31:00
       WE_Override 0
       TAGE:
         0
         1
         2
         3
         4
         5
         6
   profile_IDX:
     0:
       07:01:00   1
       21:31:00   2
     1:
       07:01:00   1
       21:31:00   2
     2:
       07:01:00   1
       21:31:00   2
     3:
       07:01:00   1
       21:31:00   2
     4:
       07:01:00   1
       21:31:00   2
     5:
       07:01:00   1
       21:31:00   2
     6:
       07:01:00   1
       21:31:00   2
Attributes:
   WDT_Group  former_HC
   WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
   commandTemplate set $NAME controlMode $EVENT
   disable    0
   room       Heizung
   switchInThePast 1

Der Zeitpunkt um 21:31 scheint gesetzt zu sein.
Aber ein "fhemdebug timerList" liefert folgendes Ergebnis:
2021-05-13 21:07:08.00000 RT_Exec
2021-05-13 21:07:08.00000 RT_Exec
2021-05-13 21:07:08.00000 RT_Exec
2021-05-13 21:24:40.00000 DOIF_TimerTrigger
2021-05-13 21:24:40.00000 WeekdayTimer_Update
2021-05-13 21:24:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 DOIF_TimerTrigger
2021-05-13 21:39:40.00000 DOIF_TimerTrigger
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:50:00.00000 DOIF_TimerTrigger
2021-05-13 21:54:39.98000 Twilight_fireEvent

Der Zeitpunkt 21:31 ist nicht geplant (21:24 und 21:39 sind Timer für Rollladen), und das hätte doch jetzt sein müssen, oder?
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #8 am: 13 Mai 2021, 11:00:40 »
Verstehe ich das richtig, dass du davon ausgehst, dass "CONDITION" zu jedem Ausführungszeitpunkt geprüft wird?

Ich meine, das wäre nicht der Fall: CONDITION wird - soweit ich das im Kopf habe - schon immer nur beim "Tageswechsel" geprüft. Trifft sie nicht zu, ist der WDT für diesen Tag "außer Kraft". Müßte mir das auch nochmal intensiver ansehen, und die Doku dazu ist vermutlich auch nicht wirklich glücklich bzw. aussagekräftig genug.

Wenn du das "on th fly" haben willst, müsstest du die Auswertung in Perl notieren und dann am Ende selbst den set-Befehl zusammenbasteln, oder eben den "update"-Command hinter dem Wechsel des Modus herschicken, dass sich alle WDT umstellen.

(OT-Anmerkung: Vermutlich wäre das ganze mit der weekprofile-Variante einfacher zu machen; da wird bei jedem "Topic"-Wechsel dann einfach der (eine) WDT passend neu initialisiert; day + night müsstest du dann ggf. entweder im WDT mappen, oder (neuerdings) in weekprofile.)

EDIT: Aber trotzdem ist das nicht wirklich sinnvoll, einen Schaltzeitpunkt anzuzeigen und dann nichts zu tun bzw. den Timer nicht anzulegen; das muss ich mir wirklich nochmal intensiver zu Gemüte ziehen...
« Letzte Änderung: 13 Mai 2021, 11:06:26 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #9 am: 13 Mai 2021, 14:31:53 »
Das mit der Condition-Überprüfung würde zumindest ins Bild passen:
Der Homeoffice-Timer war für das Modul noch gesetzt, es wurde aber nichts geschaltet.

Eine Version mit set-Befehl und if-Abfrage hatte ich im April getestet, diese funktionierte aber nach zwei Wochen plötzlich nicht mehr zuverlässig (s. Screenshot).

Daraufhin, und weil ich die State-Übersicht wieder aktuell haben wollte, habe ich wieder zurück-geswitcht.

WeekProfile habe ich mir vor einiger Zeit nur flüchtig angeschaut, kann man denn darin auch variable Zeiten, abhängig von Readings eines Wecker-Dummies hinterlegen?
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

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #10 am: 16 Mai 2021, 09:29:33 »
Ich habe das Verhalten der Condition-Überprüfung weiter beobachtet.
Dazu habe ich gestern nachmittag den Status der Bewohner auf "Büro" geändert ("SB" und "MB".
Danach habe ich ein:
set hc..* WDT_Params allabgesetzt.

Der Timer für 21:31 wurde korrekt gesetzt:
2021-05-15 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SB.MB_4
Danach habe ich den Status zurück auf "Homeoffice" bzw. "Büro" ("SH" und "MB") gesetzt, aber kein WDT_Params angestoßen.
Der ursprünglich geplante Timer "SB.MB" blieb in der Liste stehen.

Um 21:31 wurde nichts geschaltet. Für mich ein Indiz, dass die Condition zum Schaltzeitpunkt überprüft wird.

Um 00:00 hätte turnusgemäß der neue Timer durch das Modul gesetzt werden müssen, das passierte jedoch nicht (vollständig):
2021-05-16 21:29:59.00000 DOIF_TimerTrigger 
2021-05-16 21:29:59.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2021-05-16 21:29:59.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause_1
2021-05-16 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-16 21:44:59.00000 DOIF_TimerTrigger 

Der Timer "hc.eg.Kueche.SH.MB" (den hatte ich im WeekdayTimer mal testweise für diese Statuskombination auf 21:30:30 gesetzt) taucht auf, der erwartete "hc.st.Schlafzimmer.SH.MB" jedoch nicht. Der Fensterkontakt als "WDT_delayedExecutionDevice" wurde erst um 00:22 geöffnet.
Um 03:55 wurde ein geplantes "set hc..* enable" abgesetzt.
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #11 am: 18 Mai 2021, 07:39:35 »
Habe eben ein update ins svn geschoben, von dem ich aber nicht ganz sicher bin, ob es dieses Problem auch behebt.
Da war auf alle Fälle in der Testversion noch eine "komische" Zeile betreffend "zurückgehaltene Timer" drin gewesen.

Ansonsten hast du vermutlich recht, die CONDITION wirkt sich hier anders aus als im RandomTimer.

Meine Bitte wäre daher, die InternalTimer nach dem update auch die kommenden Tage immer mal wieder  gegenzuchecken, ob  alle erwarteten auch gesetzt sind.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #12 am: 18 Mai 2021, 09:49:45 »
Werde ich heute abend einspielen und berichten.

Kleiner Nachtrag von gestern/heute:

Am 17.05. waren beide Timer 21:30:30 und 21:31:00 gesetzt und wurden ausgeführt, ohne eine Änderung fehlt in der heutigen TimerList allerdings der Schaltpunkt für das Schlafzimmer:
2021-05-18 21:14:30.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-18 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-18 21:33:26.00000 DOIF_TimerTrigger 
2021-05-18 21:33:26.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #13 am: 18 Mai 2021, 09:58:52 »
Wie geschrieben: In der Testversion aus dem anderen Thread war noch was drin, das v.a. bei verzögerten Timern nicht passen konnte, und das Problem scheint nur aufgetreten zu sein, wenn man den WDT "in Ruhe" über Mitternacht hinaus laufen läßt (und es ein "switch in the past"-Gerät ist, wenn ich das richtig deute).

Bei meinem letzten Test hatte das funktioniert, allerdings ist meine Umgebung vermutlich deutlich einfacher, so dass eventuelle wechselseitigen Abhängigkeiten hier nicht so sehr reinspielen können. Bin dann mal auf deine Berichte ab morgen (mit der svn-Version) gespannt.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #14 am: 19 Mai 2021, 11:33:00 »
Hier die vorläufigen Erkenntnisse:

gestern Nachmittag habe ich die aktuelle Version eingespielt:
98_WeekdayTimer.pm        24466 2021-05-18 05:26:03Z
Nach einem Neustart wurden die Timer auch ordnungsgemäß angelegt:
2021-05-18 21:14:30.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-18 21:17:45.00000 netatmo_refreshTokenTimer netatmo
2021-05-18 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-18 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-18 21:33:26.00000 DOIF_TimerTrigger 
2021-05-18 21:33:26.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause

und problemlos ausgeführt.

Das sieht leider heute anders aus, es wurde keinerlei Änderung bzgl. der Parameter vorgenommen, aber es fehlt wieder der Timer für das Schlafzimmer:
2021-05-19 21:15:56.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2021-05-19 21:15:56.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-19 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-19 21:35:08.00000 DOIF_TimerTrigger 
2021-05-19 21:35:08.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2021-05-19 21:35:08.00000 WeekdayTimer_Update
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #15 am: 19 Mai 2021, 14:55:41 »
Hab' noch einen Ansatzpunkt gefunden, werde aber erst mal über Nacht einen Test in meinem Hauptsystem laufen lassen, bevor ich das auf jemanden anderen loslasse...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #16 am: 20 Mai 2021, 07:25:24 »
OK, sah' soweit gut aus (wie vorher auch schon...), von daher würde ich dich nochmal um einen "overnight"-Test mit der Version aus dem heutigen update (ab 8:00 Uhr) bitten.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #17 am: 21 Mai 2021, 08:14:25 »
Schade, sah erst gut aus:


20.05. 17:50 nach Update und Reboot:

2021-05-20 21:17:20.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-20 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-20 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-20 21:36:49.00000 DOIF_TimerTrigger 


21.05. 00:00 nach automatischem Timer-Setzen:

2021-05-21 21:18:42.97000 Twilight_fireEvent_MyTwilight_ss
2021-05-21 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-21 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-21 21:36:49.00000 DOIF_TimerTrigger 


Aber dann:

21.05. 06:08 (nach set hc..* enable um 03:55):

2021-05-21 21:18:43.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-21 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-21 21:38:29.00000 DOIF_TimerTrigger 

Der Fensterkontakt im Schlafzimmer wurde um 23:47 geöffnet, damit scheint das "set hc..* enable" ein Problem zu haben...
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #18 am: 21 Mai 2021, 08:33:10 »
Aha, also liegt das Problem nicht (mehr nur) in der "Initialisierung" um Mitternacht (da hatte ich es bisher verortet, und es kann auch sein, dass es da auch war), sondern "beschränkt" sich auf den Fall, dass es zu einer _vollständigen_ ("rückwärtsgewandten") Neuinitialisierung kommt, während "delay" angesagt ist.
So habe ich wenigstens Testbedingungen, mit denen ich das untersuchen kann und auch eine Idee, wieso das passiert. Muss nur überlegen, wie das am besten einzufangen ist...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #19 am: 21 Mai 2021, 14:42:18 »
Jetzt habe ich das soweit eingegrenzt, dass die ursprüngliche Annahme wieder stimmen würde, dass (CONDITION) dazu führt, dass der WDT den ganzen Tag über deaktiv ist, wenn die als falsch ausgewertet wird (und bei einer Aktualisierung dann auch alle Timer wieder abgeräumt werden sollten).
"Eigentlich" glaube ich, dass das das historische Verhalten war und von daher auch so wiederhergestellt werden sollte. Falls es massive Gegenstimmen gibt, würde ich mir das nochmal überlegen, aber das würde ggf. bedeuten, dass eigentlich ein intensiverer Umbau an ein paar Stellen erfolgen müßte (=> eher ungern).

Bitte um alsbaldige Meinungsäußerungen!

(Code füge ich keinen bei, denn das ist in Richtung "lib" umgebaut und daher nicht so einfach außerhalb der FHEM-update-Routinen zu machen wie sonst üblich).
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline helmut

  • Developer
  • Full Member
  • ****
  • Beiträge: 306
  • You can have easy, cheap or secure. Pick two.
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #20 am: 21 Mai 2021, 20:28:28 »
Bitte um alsbaldige Meinungsäußerungen!

Ich habe keine Einwaende.

Gruss Helmut
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)
Informativ Informativ x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #21 am: 22 Mai 2021, 06:19:57 »

Ich habe keine Einwaende.

Gruss Helmut
Fasse das mal als Rückmeldung eines sehr erfahrenen WeekdayTimer/Heating_Control-Nutzers  und Bestätigung der These auf, dass das Verhalten "historisch" so war, dass CONDITION bei Tagesbeginn gecheckt werden sollte und sich auf diesen Tag auswirkt (und bei späteren Änderungen der Rahmenbedingungen der User für ein neuerliches "Anschubsen" des WDT zuständig sein soll) => ab ins svn...

Wäre nett, wenn ihr die korrekte Funktionsweise nach einem update nachher nochmal checken könntet. Ist jetzt nämlich direkt auch die "lib"-Version...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Zustimmung Zustimmung x 1 Liste anzeigen

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #22 am: 23 Mai 2021, 08:59:48 »
Hat leider nicht funktioniert:

22.05. 18:20 nach Update und Reboot:

2021-05-22 21:20:05.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-22 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-22 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_4
2021-05-22 21:40:07.00000 DOIF_TimerTrigger 


23.05. 00:00 nach automatischem Timer-Setzen:

2021-05-23 21:20:05.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-23 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-23 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_4
2021-05-23 21:40:07.00000 DOIF_TimerTrigger 


Dann habe ich den Status auf "SU" und "MU" gesetzt, bei denen nur das Schlafzimmer um 21:31 schalten soll (Küche entfällt):

23.05. 08:49 (nach set hc..* enable um 03:55):

2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-23 21:41:44.00000 DOIF_TimerTrigger 
2021-05-23 21:41:44.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1


Der Fensterkontakt im Schlafzimmer wurde um 02:06 geöffnet.
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #23 am: 23 Mai 2021, 09:14:35 »
Der Fensterkontakt im Schlafzimmer wurde um 02:06 geöffnet.
Kann es sein, dass der Kontakt  noch offen ist?

Wenn ja: Schau bitte nochmal, nachdem er geschlossen wurde.

Nachtrag: Falls er geschlossen wurde, müßte eine "skipped"-Meldung (verbose 3) im Log stehen. Wäre nett, wenn du das kurz verifizieren könntest. (Dann wäre das vermutlich kein wirklich neues Thema, sondern eher "schon immer" so (fehlerhaft) gewesen.)
« Letzte Änderung: 23 Mai 2021, 09:45:29 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #24 am: 23 Mai 2021, 09:59:24 »
Hmhh, der Fensterkontakt wurde auch um 08:49 geschlossen:

2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links contact: closed (to hm.wt.st.Schlafzimmer)
2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links closed
2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links SwitchTime: 08.49
2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links onoff: 0
2021-05-23_08:49:13 hm.fk.st.Schlafzimmer.links contact: closed (to hm.hr.st.Schlafzimmer)
2021-05-23_08:49:13 hm.fk.st.Schlafzimmer.links contact: closed (to VCCU)

Ob er zum Zeitpunkt des "fhemdebug timerList" (auch 08:49) noch geöffnet war, kann ich nicht genau sagen.


Jetzt ist er jedenfalls geschlossen, es hat sich aber nichts geändert:

2021-05-23 21:21:25.00000 RT_Exec rnd.li.eg.Garderobe
2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-23 21:41:44.00000 DOIF_TimerTrigger 
2021-05-23 21:41:44.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1

Im Log finde ich folgenden Eintrag (um 07:01 war der Kontakt offen):

2021.05.23 07:00:50 3: CUL_HM set hm.wt.st.Arbeitszimmer_Climate controlMode day
2021.05.23 07:01:00 3: [hc.st.Schlafzimmer.SU.MU] timer at 21:31:00 skipped by new timer at 07:01:00 while window contact returned open state
2021.05.23 07:02:30 3: CUL_HM set stat.eg.Arbeitszimmer_Dis displayEP A\_930\_977,noicon:W\_872,noicon:S\_1455\_07.02,noicon off 3 0 off
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #25 am: 23 Mai 2021, 10:09:50 »
Thx, jetzt ist wenigstens klar, wann der Timer verloren geht: mit dem "skipped".

Wird etwas dauern, bis ich das fixen kann, als workaround kannst du den nach dem ersten Schaltzeitpunkt nochmal initialisieren.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #26 am: 23 Mai 2021, 10:22:49 »
Ok, dann werde ich die Intialisierung vorerst mehrmals am Tag durchführen lassen.
Vielen Dank.
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #27 am: 24 Mai 2021, 08:27:36 »
Seit vorhin ist eine Version im svn, von der ich hoffe, dass das "skipped"-Problem damit dann auch gelöst ist...
War aber etwas zu spät für den regulären update-Lauf, ggf. dann eben aus dem svn direkt holen, falls du direkt testen willst...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Cybers

  • Full Member
  • ***
  • Beiträge: 440
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #28 am: 24 Mai 2021, 16:44:42 »
Hallo,
ich nutze UZSU in Smartvisu um mehrere Weekdaytimer zu setzen. Wenn ich Sunset oder Sunrise  nutze und eine  Zeit bei spätesten UND frühestens einsetze, klappt es problemlos.
Wenn ich allerdings nur eine Uhrzeit bei spätestens einsetzte, wird diese Zeit nicht berücksichtigt und es wird zur Sunset-Zeit geschaltet.
define wdt_uzsu_EnO_00000017_0 WeekdayTimer EnO_00000017 en MO,TU,WE,TH,FR,SA,SU|{sunset_abs("REAL",5400,,"22:00")}|100Anscheinend kommt der Weekdaytimer nicht mit einer leeren Stelle in der Funktion klar.
Gruß, Sascha
FHEM 6.0 auf Raspberry PI 3 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #29 am: 25 Mai 2021, 08:07:50 »
Das Update habe ich am 24.05. um 10:40 eingespielt:

98_WeekdayTimer.pm 24498 2021-05-24 06:12:31Z Beta-User
Zu diesem Zeitpunkt war der Status "SU/MU".
Der Schlafzimmer-Timer wurde, wie nach dem Reboot gewohnt, korrekt auf 21:31 gesetzt (Küche soll in diesem Status nicht um 21:30 schalten und war auch nicht gelistet).

Um 00:00 war auch noch alles ok.

Dann habe ich um 00:30 den Status auf "SH/MB" gesetzt, bei dem die Küche und das Schlafzimmer um 21:30/21:31 schalten sollen.

Um 03:55 wurde ein "set hc..* enable" ausgeführt. Das Schlafzimmerfenster war zu diesem Zeitpunkt geöffnet.

Das Ergebnis heute um 06:30:

2021-05-25 21:24:02.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-25 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-25 21:44:53.00000 DOIF_TimerTrigger

Küchen-Timer wurde korrekt hinzugefügt, Schlafzimmer-Timer wurde leider nicht gesetzt.

Im Log taucht kein "skipped"-Ereignis auf.



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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #30 am: 25 Mai 2021, 11:01:54 »
Anscheinend kommt der Weekdaytimer nicht mit einer leeren Stelle in der Funktion klar.
Das ist m.E. kein originäres WDT-Thema: gib das ({sunset_abs("REAL",5400,,"22:00")}) einfach mal in die Kommandozeile ein, da kommt dann auch eine spätere Zeit raus...

Der WDT-Code erkennt nur, _dass_ es Perl ist (also nicht, welche Funktion und welche Parameter ggf. erforderlich sind), "läßt" dann auswerten, und checkt im Ergebnis nochmal, ob es eine Uhrzeit ist, was zurückkommt. Das ist der Fall => aus WDT-Sicht ist alles bestens...

Das Ergebnis heute um 06:30:
[...]
Küchen-Timer wurde korrekt hinzugefügt, Schlafzimmer-Timer wurde leider nicht gesetzt.

Im Log taucht kein "skipped"-Ereignis auf.
Kein "skipped" paßt zur Info, dass der späteste Timer _noch_ nicht angelegt war. Der betreffende Timer (zu erkennen an der internen Nummer) sollte zu der fraglichen Zeit (noch) als "delayed" (vom Vortag, Schaltung auszuführen bei "Fenster-zu"-Erkennung) vorhanden gewesen sein und taucht dann in der timerList erst auf, wenn er entweder "skipped" wird oder das Fenster zugemacht wurde (und die nächste diesbezügliche Prüfung drübergelaufen ist).

Kannst du das mal gegenchecken?
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #31 am: 25 Mai 2021, 11:36:27 »
Im Log sind als letzte "delayed"-Einträge bzgl. des Schlafzimmers folgende vorhanden:

2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] set hc.st.Schlafzimmer.SB.MB enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] set hc.st.Schlafzimmer.SH.MB enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] set hc.st.Schlafzimmer.SU.MB enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] set hc.st.Schlafzimmer.SU.MU enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'

Das Fenster im Schlafzimmer wurde um 08:04 geschlossen.

Die letzten "delay-stopped"-Einträge:

2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SB.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SH.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.25 08:05:00 3: CUL_HM set hm.hr.st.Schlafzimmer_Clima controlMode night
2021.05.25 08:05:00 3: CUL_HM set hm.wt.st.Schlafzimmer_Climate controlMode night
2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SU.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SU.MU] delay of switching struct.Heizung.st.Schlafzimmer stopped.
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #32 am: 25 Mai 2021, 11:56:38 »
Kannst du nochmal in die timerList schauen, ob er jetzt da ist?
Du hattest um den Dreh' des Schließens rum den Post heute morgen erstellt, und wenn der "alte Timer" aus der "Fenster ist jetzt geschlossen"-Funktion raus erneuert wird, taucht das (schon immer) nur ab verbose 4 im Log auf.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #33 am: 25 Mai 2021, 11:59:36 »
Nein, ist leider nicht angelegt worden:

2021-05-25 21:24:02.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-25 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-25 21:44:53.00000 DOIF_TimerTrigger 
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #34 am: 25 Mai 2021, 14:30:06 »
Danke für's nachschauen.

Ich glaube, jetzt auch die diesbezügliche Stelle vollends gefunden zu haben. Da war aber auch noch eine eventuelle "Baustelle" (eigentlich eher: eine (logische) Optimierung) in der Register.pm, von daher würde ich das gerne erst wieder einem "Übernacht"-Test im eigenen System unterziehen, bevor es ggf. dann morgen per update kommt...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #35 am: 26 Mai 2021, 14:08:52 »
Über Nacht keine Probleme => ist im svn mit der Bitte, das Ergebnis nochmals zu testen ::) ...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #36 am: 27 Mai 2021, 08:49:06 »
So, hier die Ergebnisse des ersten Tests:

26.05. 18:30 Update und Reboot
$Id: 98_WeekdayTimer.pm 24513 2021-05-26 03:53:53Z Beta-User
Status: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)

2021-05-26 21:25:18.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-26 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-26 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-26 21:40:37.71822 GetUpdate

26.05. 23:30
Statusänderung auf: SU/MU (erwartet: Schlafzimmer 21:31)
Fenster Schlafzimmer: geschlossen

27.05. 00:00
2021-05-27 21:26:31.00000 Twilight_fireEvent_MyTwilight_ss
2021-05-27 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SU.MU_2
2021-05-27 21:46:25.00000 DOIF_TimerTrigger

27.05. 00:07
Fenster Schlafzimmer: offen

27.05. 00:20
Statusänderung auf: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)

27.05. 03:55
set hc..* enable
27.05. 06:06
2021-05-27 21:26:32.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:47:55.00000 DOIF_TimerTrigger 
(doppelter Eintrag Küche, Schlafzimmer fehlt)

27.05. 07:51
Fenster Schlafzimmer: geschlossen
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SB.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SH.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:53:00 3: CUL_HM set hm.hr.st.Schlafzimmer_Clima controlMode night
2021.05.27 07:53:00 3: CUL_HM set hm.wt.st.Schlafzimmer_Climate controlMode night
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SU.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SU.MU] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:54:29 3: CUL_HM set li.eg.Flur.Handlauf_Dim_V_01 pct 15 60 0

27.05. 08:10
2021-05-27 21:26:32.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-27 21:47:55.00000 DOIF_TimerTrigger

Das sieht doch schon sehr vielversprechend aus.  :)
Stört nur noch der doppelte Eintrag für die Küche...
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #37 am: 27 Mai 2021, 12:28:06 »
Stört nur noch [...]
"Nur noch" ist relativ, man muss da immer aufpassen, dass man mit dem Hinterteil nicht einreißt, was man mit den Händen (usw...).

Ich glaube, die zwei diesbezüglichen Stellen gefunden zu haben, ohne massive Probleme an anderer Stelle  zu verursachen, wäre aber für einen Test dankbar.
Da die Funktionsnamen jetzt teils gekürzt sind, bitte FHEM nach dem Einspielen dieser Fassung neu starten!
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #38 am: 28 Mai 2021, 09:42:19 »
Hier die aktuellen Test-Ergebnisse:

27.05. 17:34 Update und Reboot
$Id: 98_WeekdayTimer.pm 24513 2021-05-26 03:53:53Z Beta-User(Datei aus dem Thread, Dateigröße 69517 B)

Status: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)
Fenster Schlafzimmer: geschlossen

2021-05-27 21:26:32.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-27 21:40:37.71822 GetUpdate


27.05. 23:15
Statusänderung auf: SU/MU (erwartet: Schlafzimmer 21:31)

28.05. 00:00
2021-05-28 21:27:44.97000 Twilight_fireEvent_MyTwilight_ss
2021-05-28 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SU.MU_2
2021-05-28 21:47:55.00000 DOIF_TimerTrigger

28.05. 01:08
Statusänderung auf: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)

28.05. 01:19
Fenster Schlafzimmer: offen

28.05. 03:55
set hc..* enable2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] set hc.st.Schlafzimmer.SB.MB enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] set hc.st.Schlafzimmer.SH.MB enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] set hc.st.Schlafzimmer.SU.MB enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] set hc.st.Schlafzimmer.SU.MU enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'

28.05. 06:06
2021-05-28 21:27:45.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-28 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-28 21:49:23.00000 DOIF_TimerTrigger
(Schlafzimmer fehlt wg. offenem Fenster)

28.05. 07:11
Fenster Schlafzimmer: geschlossen
2021.05.28 07:12:00 3: CUL_HM set li.eg.Flur.Handlauf_Dim_V_01 pct 15 60 0
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SB.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SH.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.28 07:13:00 3: CUL_HM set hm.hr.st.Schlafzimmer_Clima controlMode night
2021.05.28 07:13:00 3: CUL_HM set hm.wt.st.Schlafzimmer_Climate controlMode night
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SU.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SU.MU] delay of switching struct.Heizung.st.Schlafzimmer stopped.


28.05. 07:20
2021-05-28 21:27:45.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-28 21:30:30.00000 WDT_Update hc.eg.Kueche.SH.MB_6
2021-05-28 21:31:00.00000 WDT_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-28 21:49:23.00000 DOIF_TimerTrigger

Ich sag mal: works as intended! :)

Ich werde jetzt die anderen Profile überarbeiten und weiterhin testen.
Vielen Dank für Dein Engagement!
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
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #39 am: 04 Juni 2021, 09:56:46 »
Hatte diesen Stand auch eingecheckt. Da bisher keine kritischen Rückmeldungen mehr erfolgt sind, gehe ich mal davon aus, dass jetzt alles soweit passt...?
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #40 am: 15 Juni 2021, 11:17:36 »
Die bestehende Programme scheinen zu funktionieren, sind aber aufgrund der warmen Temperaturen z.Zt. außer Betrieb.

Ich teste noch neue Timer für meine Rollladensteuerung.
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