Der WeekdayTimer-Thread ab 2020

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

Vorheriges Thema - Nächstes Thema

juemuc

@Beta-User: Aus meiner Sicht ok.

Ich habe jetzt bei meinen Tests noch eine Konstellation erstellt, die ich zumindest merkwürdig finde.

defmod Bettlicht_WT WeekdayTimer Bettlicht_WT_Dummy de
attr Bettlicht_WT alias Bettlicht (An/Aus)
attr Bettlicht_WT commandTemplate set $NAME  $EVENT
attr Bettlicht_WT devStateStyle style="text-align:right"
attr Bettlicht_WT disable 0
attr Bettlicht_WT stateFormat {my $val;;\
if (ReadingsVal($name, "disabled","") eq "1") {$val = "AUS"}\
else {$val = ReadingsVal($name, "currValue","")};;\
$val}
attr Bettlicht_WT switchInThePast 1

setstate Bettlicht_WT on
setstate Bettlicht_WT 2023-02-03 16:16:22 currValue on
setstate Bettlicht_WT 2023-02-03 16:16:11 disabled 0
setstate Bettlicht_WT 2023-02-03 16:16:22 nextUpdate 2023-02-05 00:00:00
setstate Bettlicht_WT 2023-02-03 16:16:22 nextValue on
setstate Bettlicht_WT 2023-02-03 16:16:22 state on


Ich habe hier alle Wochentage mit den Zeitangaben entfernt. Trotzdem ist das Reading "nextUpdate" noch mit einem Wert gefüllt. Findet da jetzt eine Aktion? Wenn ja, wäre das aus meiner Sicht falsch.
Ich weiß, dass ist konstruiert, aber möglich.

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

Hmmm, vermutlich läuft da im Hintergrund kein Timer, das dürfte ein reines Anzeige-Thema sein, und rauszufischen, ob da jetzt ein optionales Argument übergeben wurde, um den Syntaxfehler zu kaschieren ist zwar möglich, mir aber zumindest für den Moment zu aufwändig....
Server: HP-elitedesk@Debian 12, 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

ok, kann ich verstehen. Das Problem ist ja auch eher theoretischer Natur. Vielleicht kann ich es bei meinen Tests weiter verifizieren.

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).

juemuc

Hi Beta-User,

ich befürchte, ich habe einen weiteren Fehler gefunden.

Bei der Definition "08" wird der Sonntag ignoriert. Bei "068" ist der Sonntag dabei. Siehe Anhänge. Warum fehlt bei der ersten Definition der Sonntag?

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

Hmmm, sieht in der Tat komisch aus. Ich hoffe, in der nächsten Woche mal dazu zu kommen, das mal intensiv anzusehen. Sonst bitte in 3 Wochen nochmal nachhaken!
Server: HP-elitedesk@Debian 12, 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

sinus61

Zitat von: Beta-User am 01 Februar 2023, 09:41:08
Die "9" ist übrigens bei DOIF schon irgendwie vorbelegt, und wenn, dann sollte man zuerst schauen, ob diese Vorbelegung ggf. auch für den WDT sinnvoll übernommen werden könnte.

9 ist da der Tag vor Wochenende/Feiertag, würde ich im WDT auch nützlich finden.

netwalk

Hallo,

ich muss mich hier auch noch einmal einklinken.

Der Timer funktioniert leider reproduzierbar am WE nicht korrekt.
Ich habe einige WeekdayTimer in Abhängigkeit vom Status der Bewohner zur Heizungssteuerung angelegt. Die einzelnen WeekdayTimer werden auch zuverlässig aktiviert und schalten unter der Woche einwandfrei.

Hier das Listing:

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 "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
   DEF        struct.Heizung.st.Schlafzimmer 1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 60|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high 21:01:00|dm.Heizung.st.Schlafzimmer.temp.low (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status","state", "") eq "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
   DEVICE     struct.Heizung.st.Schlafzimmer
   FUUID      5de97613-f33f-c765-a44b-4703036352c33dc6
   GlobalDaylistSpec
   LANGUAGE   en
   NAME       hc.st.Schlafzimmer.SB.MB
   NR         1655
   Profil 0: Sunday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 1: Monday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 2: Tuesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 3: Wednesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 4: Thursday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 5: Friday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 6: Saturday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   STATE      open window
   STILLDONETIME 0
   TYPE       WeekdayTimer
   eventCount 886
   setModifier desired-temp
   READINGS:
     2023-02-14 08:03:00   currValue       dm.Heizung.st.Schlafzimmer.temp.low
     2021-01-13 14:42:26   disabled        0
     2023-02-14 08:03:00   nextUpdate      2023-02-14 15:31:00
     2023-02-14 08:03:00   nextValue       dm.Heizung.st.Schlafzimmer.temp.high
     2023-02-14 08:01:00   state           open window
   SWITCHINGTIMES:
     1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
     5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
     06|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high
     21:01:00|dm.Heizung.st.Schlafzimmer.temp.low
   TIMER:
     hc.st.Schlafzimmer.SB.MB_1:
       HASH       hc.st.Schlafzimmer.SB.MB
       MODIFIER   1
       NAME       hc.st.Schlafzimmer.SB.MB_1
     hc.st.Schlafzimmer.SB.MB_midnight:
       HASH       hc.st.Schlafzimmer.SB.MB
       MODIFIER   midnight
       NAME       hc.st.Schlafzimmer.SB.MB_midnight
       SETTIMERATMIDNIGHT 1
   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   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       1:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       2:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       3:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       4:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       5:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       6:
         07:01:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
     WEDAYS:
       4          1
       5          1
   profil:
     1:
       EPOCH      1676385060
       PARA       dm.Heizung.st.Schlafzimmer.temp.high
       TIME       15:31:00
       WE_Override 0
       DAYS:
         1
         2
         3
         4
     2:
       EPOCH      1676385060
       PARA       dm.Heizung.st.Schlafzimmer.temp.high
       TIME       15:31:00
       WE_Override 0
       DAYS:
         5
     3:
       EPOCH      1676354460
       PARA       dm.Heizung.st.Schlafzimmer.temp.high
       TIME       07:01:00
       WE_Override 0
       DAYS:
         0
         6
     4:
       EPOCH      1676404860
       PARA       dm.Heizung.st.Schlafzimmer.temp.low
       TIME       21:01:00
       WE_Override 0
       DAYS:
         0
         1
         2
         3
         4
         5
         6
   profile_IDX:
     0:
       07:01:00   3
       21:01:00   4
     1:
       15:31:00   1
       21:01:00   4
     2:
       15:31:00   1
       21:01:00   4
     3:
       15:31:00   1
       21:01:00   4
     4:
       15:31:00   1
       21:01:00   4
     5:
       15:31:00   2
       21:01:00   4
     6:
       07:01:00   3
       21:01:00   4
Attributes:
   WDT_Group  former_HC
   WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
   commandTemplate set $NAME desired-temp [$EVENT:state]
   disable    0
   room       Heizung
   switchInThePast 1


Man sieht im Log des Heizungsreglers, dass unter der Woche alles funktioniert, am SA und SO jedoch nicht, der kritische Schaltzeitpunkt ist 21:01 Uhr:


[...]
Donnerstag:
2023-02-09_15:30:37 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-09_15:31:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-09_20:52:50 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-09_20:52:50 hm.hr.st.Schlafzimmer measured-temp: 18.5
2023-02-09_21:01:01 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-09_21:02:59 hm.hr.st.Schlafzimmer actuator: 0
2023-02-09_21:02:59 hm.hr.st.Schlafzimmer measured-temp: 18.5
2023-02-09_21:13:32 hm.hr.st.Schlafzimmer actuator: 0
2023-02-09_21:13:32 hm.hr.st.Schlafzimmer desired-temp: 17.0
[...]
Freitag:
2023-02-10_15:22:04 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-10_15:22:04 hm.hr.st.Schlafzimmer measured-temp: 17.5
2023-02-10_15:26:43 hm.hr.st.Schlafzimmer actuator: 2
2023-02-10_15:26:43 hm.hr.st.Schlafzimmer measured-temp: 17.6
2023-02-10_15:31:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-10_20:55:19 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-10_21:01:01 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-10_21:02:50 hm.hr.st.Schlafzimmer actuator: 0
2023-02-10_21:02:50 hm.hr.st.Schlafzimmer measured-temp: 18.8
2023-02-10_21:12:21 hm.hr.st.Schlafzimmer desired-temp: 17.0
[...]
Samstag:
2023-02-11_09:42:05 hm.hr.st.Schlafzimmer desired-temp: 5.5
2023-02-11_09:44:26 hm.hr.st.Schlafzimmer battery: ok
2023-02-11_09:44:26 hm.hr.st.Schlafzimmer batteryLevel: 2.5
2023-02-11_09:44:26 hm.hr.st.Schlafzimmer motorErr: ok
2023-02-11_09:46:32 hm.hr.st.Schlafzimmer measured-temp: 16.9
2023-02-11_09:49:03 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-11_20:50:32 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-11_20:52:51 hm.hr.st.Schlafzimmer measured-temp: 18.9
2023-02-11_21:02:55 hm.hr.st.Schlafzimmer actuator: 26
2023-02-11_21:02:55 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-11_21:02:55 hm.hr.st.Schlafzimmer measured-temp: 18.9
2023-02-11_21:13:23 hm.hr.st.Schlafzimmer actuator: 26
2023-02-11_21:13:23 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
Sonntag:
2023-02-12_10:10:45 hm.hr.st.Schlafzimmer desired-temp: 5.5
2023-02-12_10:10:45 hm.hr.st.Schlafzimmer measured-temp: 17.1
2023-02-12_10:14:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-12_20:58:21 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-12_21:03:59 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer actuator: 14
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer battery: ok
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer batteryLevel: 2.5
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
Montag:
2023-02-13_15:22:28 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-13_15:29:51 hm.hr.st.Schlafzimmer measured-temp: 17.8
2023-02-13_15:31:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-13_20:49:16 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-13_20:54:34 hm.hr.st.Schlafzimmer measured-temp: 18.9
2023-02-13_20:56:51 hm.hr.st.Schlafzimmer measured-temp: 19.0
2023-02-13_21:01:01 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-13_21:01:46 hm.hr.st.Schlafzimmer actuator: 27
2023-02-13_21:04:24 hm.hr.st.Schlafzimmer actuator: 0
2023-02-13_21:08:57 hm.hr.st.Schlafzimmer measured-temp: 19.0
2023-02-13_21:11:56 hm.hr.st.Schlafzimmer desired-temp: 17.0


Der erste Schaltzeitpunkt am WE auf 19° C wird korrekt geschaltet, ggf. erst nachdem das Fenster morgens geschlossen wurde. Der zweite Schaltpunkt abends auf 17°C wird jedoch nicht ausgelöst, lediglich unter der Woche.
Was läuft (oder mache ich) hier falsch?



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

Damian

Zitat von: sinus61 am 04 Februar 2023, 18:37:22
9 ist da der Tag vor Wochenende/Feiertag, würde ich im WDT auch nützlich finden.
Und wenn die Ziffern ausgehen, dann muss man mit Buchstaben weiter machen, besser aber mit aussagefähigen Begriffen.

siehe: https://forum.fhem.de/index.php/topic,132143.msg1263376.html#msg1263376
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

juemuc

Zitat von: Beta-User am 03 Februar 2023, 21:23:59
Hmmm, sieht in der Tat komisch aus. Ich hoffe, in der nächsten Woche mal dazu zu kommen, das mal intensiv anzusehen. Sonst bitte in 3 Wochen nochmal nachhaken!

Hallo Beta-User,
ich vermute, Du hattest noch keine Zeit. Kein Problem, ich habe dafür noch eine Ungereimtheit gefunden:

Das Reading "nextUpdate" wird nicht korrigiert, wenn Nachts sich die Zeiten in den Profilen ändern (s. Anhang). Der Wert wird erst beim Schaltvorgang wieder angepasst und hat dann den "alten Wert".

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).

netwalk

Auch an diesem Wochenende schaltet der Timer leider nicht korrekt.

Im Listing sieht man, dass der Zeitschaltpunkt angeblich korrekt geplant ist, er wird jedoch nicht ausgelöst:

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 "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
   DEF        struct.Heizung.st.Schlafzimmer 1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 60|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high 1234560|21:01:00|dm.Heizung.st.Schlafzimmer.temp.low (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status","state", "") eq "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
   DEVICE     struct.Heizung.st.Schlafzimmer
   FUUID      5de97613-f33f-c765-a44b-4703036352c33dc6
   GlobalDaylistSpec
   LANGUAGE   en
   NAME       hc.st.Schlafzimmer.SB.MB
   NR         1655
   Profil 0: Sunday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 1: Monday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 2: Tuesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 3: Wednesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 4: Thursday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 5: Friday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   Profil 6: Saturday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
   STATE      dm.Heizung.st.Schlafzimmer.temp.high
   STILLDONETIME 0
   TYPE       WeekdayTimer
   eventCount 3170
   setModifier desired-temp
   READINGS:
     2023-02-26 10:53:00   currValue       dm.Heizung.st.Schlafzimmer.temp.high
     2021-01-13 14:42:26   disabled        0
     2023-02-26 10:53:00   nextUpdate      2023-02-26 21:01:00
     2023-02-26 10:53:00   nextValue       dm.Heizung.st.Schlafzimmer.temp.low
     2023-02-26 10:53:00   state           dm.Heizung.st.Schlafzimmer.temp.high
   SWITCHINGTIMES:
     1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
     5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
     06|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high
     0123456|21:01:00|dm.Heizung.st.Schlafzimmer.temp.low
   TIMER:
     hc.st.Schlafzimmer.SB.MB_midnight:
       HASH       hc.st.Schlafzimmer.SB.MB
       MODIFIER   midnight
       NAME       hc.st.Schlafzimmer.SB.MB_midnight
       SETTIMERATMIDNIGHT 1
   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   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       1:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       2:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       3:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       4:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       5:
         15:31:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
       6:
         07:01:00   dm.Heizung.st.Schlafzimmer.temp.high
         21:01:00   dm.Heizung.st.Schlafzimmer.temp.low
     WEDAYS:
       0          1
       6          1
   profil:
     1:
       EPOCH      1677421860
       PARA       dm.Heizung.st.Schlafzimmer.temp.high
       TIME       15:31:00
       WE_Override 0
       DAYS:
         1
         2
         3
         4
     2:
       EPOCH      1677421860
       PARA       dm.Heizung.st.Schlafzimmer.temp.high
       TIME       15:31:00
       WE_Override 0
       DAYS:
         5
     3:
       EPOCH      1677391260
       PARA       dm.Heizung.st.Schlafzimmer.temp.high
       TIME       07:01:00
       WE_Override 0
       DAYS:
         0
         6
     4:
       EPOCH      1677441660
       PARA       dm.Heizung.st.Schlafzimmer.temp.low
       TIME       21:01:00
       WE_Override 0
       DAYS:
         0
         1
         2
         3
         4
         5
         6
   profile_IDX:
     0:
       07:01:00   3
       21:01:00   4
     1:
       15:31:00   1
       21:01:00   4
     2:
       15:31:00   1
       21:01:00   4
     3:
       15:31:00   1
       21:01:00   4
     4:
       15:31:00   1
       21:01:00   4
     5:
       15:31:00   2
       21:01:00   4
     6:
       07:01:00   3
       21:01:00   4
Attributes:
   WDT_Group  former_HC
   WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
   commandTemplate set $NAME desired-temp [$EVENT:state]
   disable    0
   room       Heizung
   switchInThePast 1


Ein manuell ausgelöstes
set hc.st.Schlafzimmer.SB.MB WDT_Params single
schaltet ohne weitere Verzögerung korrekt auf die Nachtabsenkung.

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

Funsailor

Hallo Beta-User,
du hast dich ja schon mal an der Diskussion UZSU und CommandTemplate beteiligt.
Inzwischen hat Wolfram das Problem mit der Datenübernahme aus der UZSU gelöst, die Daten kommen an und werden in der Variable  "conditionOrCommand" eingetragen.
Allerdings wird das Attribut "commandTemplate" nicht gesetzt. Ich habe das hier (und eine "Lösung" für meine Testumgebung) beschrieben:

Zitathttps://forum.fhem.de/index.php/topic,127432.msg1264026.html#msg1264026

Was wäre dein Vorschlag?

Es gibt da ein paar eindeutige Readings:

R-change_over_delay
R-reference_run_counter
R-reference_running_time_bottom_top
R-reference_running_time_top_bottom


Damit könnte man ja die HMW-Devices eindeutig identifizieren. So wird das ja auch in der Abfrage "checkIfDeviceIsHeatingType" gemacht.

Oder doch immer dann wenn im "conditionOrCommand" etwas drin steht?


LG
Michael
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

Beta-User

Hmm, irgendwie bin ich im Moment immer an ein paar anderen Dingen dran, WDT kommt dann schon auch bald mal an die Reihe.

in commandTemplate was anderes zu legen als gedacht, kommt mir zumindest auf die Schnelle gar nicht passend vor (v.a., weil es auch "condition" sein könnte); dass da überhaupt im laufenden Betrieb immer wieder was gesetzt wird, ist eigentlich schon nicht mehr ein Vorgehen, dass ich heute so vercoden würde (das war aber immer schon so).

Eigentlich müßte auch ein einmal gesetztes Attribut erhalten bleiben. Löst das nicht schon dein Problem, das zu setzen? (Oder löscht der Code das Device, um es from scratch neu anzulegen? Dann ggf. umstellen auf defmod?)

Das mit den "eindeutigen Readings" verstehe ich nicht. isHeating fragt setter ab, wenn ich das richtig im Kopf habe.
Server: HP-elitedesk@Debian 12, 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

Funsailor

#102
Hi,
jeep, in der Funktion "UZSU_execute" (siehe 99_fronthemUtils) wird zuerst der komplette WDT Eintrag, z.B.: "wdt_uzsu_EG_EsseckeRechtsBlind_0" gelöscht und neu generiert. Das zusammenbasteln der wdt_uzsu_' wird mit defmod gemacht.
Ich kann in meinem Testsystem die Zeile "fhem('delete wdt_uzsu_'.$device.'.*');" entfernen und sehen was dann passiert... 8) Ich denke aber nicht, das es so einfach ist :-\


Da ich mehrere Schaltzeiten nutze, ist es ziemlich öde jedesmal das "set level" in der UZSU einzutragen :-\ . Insofern wäre es wirklich besser, dieses Attribut zu sichern und im neuem wdt_... einzusetzen. 8)

In der Funktion "checkIfDeviceIsHeatingType" werden doch die Readings des aktuellen Devices auf "desired-temp etc. geprüft? Oder habe ich die Zeilen falsch verstanden?


my @tempSet = qw(desired-temp desiredTemperature desired thermostatSetpointSet);
  my $allSets = getAllSets($dName);

  for my $ts (@tempSet) {
  if ($allSets =~ m{$ts}xms) {
      Log3( $hash, 4, "[$name] device type heating recognized, setModifier:$ts" );
      $hash->{setModifier} = $ts;
      return $ts
    }


Ich freunde mich erst langsam mit Perl an und bin da nicht sehr sicher.

- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

Beta-User

Nix mit readings:
getAllSets($dName)

Gefragt werden alle setter, und es gibt TYPEs, die nicht zwangsläufig auch so ein Reading kennen (ZWave, z.B.).

Ich kapiere nicht, warum man löschen sollte. defmod ist genau dazu da, dass man sich darüber nicht den Kopf zerbrechen muss? Das gibt es allerdings uU. noch nicht so lange wie den UZSU-Code...
Server: HP-elitedesk@Debian 12, 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

Funsailor

Hi,
ich muss mich korrigieren.

Wenn ich (mit der aktuellen 99_fronthem aus dem develop Zweig) in der UZSU Zeiten hinzufüge, muss ich in der "Expert" Ansicht set level übergeben (siehe Bild)

Der wdt_uzsu_WohnZimmerTestBlind_0 sieht dann so aus:


Internals:
   CFGFN     
   COMMAND    set $NAME level $EVENT
   CONDITION 
   DEF        WohnZimmerTestBlind en TH|20:30|17 set $NAME level $EVENT
   DEVICE     WohnZimmerTestBlind
   FUUID      640a33f7-f33f-8046-01f8-8efcc3401bb2826a
   GlobalDaylistSpec
   LANGUAGE   en
   NAME       wdt_uzsu_WohnZimmerTestBlind_0
   NR         242
   Profil 4: Thursday 20:30:00 17,
   STATE      active
   STILLDONETIME 0
   TYPE       WeekdayTimer
   eventCount 8
   setModifier
   READINGS:
     2023-03-09 20:31:03   currValue       17
     2023-03-09 20:31:03   disabled        0
     2023-03-09 20:31:03   nextUpdate      2023-03-16 20:30:00
     2023-03-09 20:31:03   nextValue       17
     2023-03-09 20:31:03   state           active
     2023-03-09 20:31:03   weekdays        TH|20:30|17
   SWITCHINGTIMES:
     4|20:30|17
   TIMER:
     wdt_uzsu_WohnZimmerTestBlind_0_midnight:
       HASH       wdt_uzsu_WohnZimmerTestBlind_0
       MODIFIER   midnight
       NAME       wdt_uzsu_WohnZimmerTestBlind_0_midnight
       SETTIMERATMIDNIGHT 1
   helper:
     daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
     daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
     SWITCHINGTIME:
       0:
       1:
       2:
       3:
       4:
         20:30:00   17
       5:
       6:
     WEDAYS:
       2          1
       3          1
   profil:
     1:
       EPOCH      1678390200
       PARA       17
       TIME       20:30
       WE_Override 0
       DAYS:
         4
   profile_IDX:
     4:
       20:30:00   1
Attributes:
   commandTemplate set $NAME  $EVENT
   disable    0
   group      WohnZimmerTestBlind
   room       UZSU


Das commando wird richtig erzeugt ->
   COMMAND    set $NAME level $EVENT

Damit wird das Attribut
ZitatcommandTemplate set $NAME  $EVENT
scheinbar hinfällig.

Da ich mit der "alten" 99_fronthem immer das "commandTemplate" ändern musste, habe ich dafür unnötigerweise eine Lösung gesucht.
Verwirrend war für mich auch, das bei den HM-xyz Devices immer ein CommandTemplate angelegt wird. Command bleibt dann leer.

Wenn ich nun Zeiten oder Werte in der UZSU ändere, bleibt das COMMAND set $NAME level $EVENT erhalten.
Der einzige Wermuttropfen ist, das man bei neuen Schaltzeiten in der UZSU in die Expert Einstellungen rein muss.... Damit kann ich leben.
LG Michael

- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -