Autor Thema: Weekdaytimer nach Delay wegen geöffnetem Fenster kein neuer Wert im FHT-Thermost  (Gelesen 9854 mal)

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Hallo,
ich habe jetzt für die startende Heizperiode mal die WeekdayTimer für die Thermostate nutzen wollen. Soweit so gut. Leider bekommt ein Thermostat nach dem Delay wegen einem geöffnetem Fenster keine aktuell gültige Temperatur. Hier die Auszüge aus der Config und dem Log.
defmod HZT_Schlafen WeekdayTimer sz_heizung 7|05:45|20.0 7|20:15|16.0 8|05:45|20.0 8|06:55|16.0 8|16:00|20.0 8|20:15|16.0
attr HZT_Schlafen WDT_Group Heizung_Eco
attr HZT_Schlafen WDT_delayedExecutionDevices sz_fenster
attr HZT_Schlafen commandTemplate set $NAME desired-temp $EVENT
attr HZT_Schlafen group Heizplan
attr HZT_Schlafen room Heizung
attr HZT_Schlafen sortby 4
attr HZT_Schlafen switchInThePast 1

setstate HZT_Schlafen open window
setstate HZT_Schlafen 2019-10-05 09:50:00 currValue 20.0
setstate HZT_Schlafen 2019-10-05 09:50:00 nextUpdate 2019-10-05 20:15:00
setstate HZT_Schlafen 2019-10-05 09:50:00 nextValue 16.0
setstate HZT_Schlafen 2019-10-05 09:49:00 state open window
2019.10.05 09:50:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.05 06:55:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 06:55
2019.10.05 05:45:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 05:45
2019.10.05 05:45:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Der state ist immer noch auf "Window open", obwohl dies geschlossen ist. Dies wurde um 9:55 Uhr ja auch erkannt. Nur steht die Heizung immer noch auf 16°C. Mit einem set HZT_Schlafen WDT_Params single wird die Temperatur dann übertragen. Das switchInThePasthabe ich mal gesetzt, ändert sich aber nichts. Sollte ja bei einem Thermostat auch bereits so sein. sz_heizung ist ein FHT80B Thermostat.
Habe ich etwas überlesen in der commandref?

Wenn noch mehr Infos benötigt werden, bitte melden.

Vielen Dank und Grüße
Dirk
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Online amenomade

  • Hero Member
  • *****
  • Beiträge: 4857
Das ist merkwürdig:2019.10.05 06:55:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 06:55da der 6:55 Uhr Timer eigentlich nur an Wochentage greifen sollte.

Es sei denn, Du nutzt die noWeekEnd Funktionalität: was sagt { IsWe("today") } im Kommandofeld von Fhem?
FHEM 5.9 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, und HM Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Ergebnis von { IsWe("today") } ist 1. Demnach sollte also Wochenende sein. Alle anderen Timer arbeiten auch nach dem Programm für das Wochenende.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Online amenomade

  • Hero Member
  • *****
  • Beiträge: 4857
Hmm vielleicht muss Beta-User mal schauen
Ich würde verbose 5 setzen, und auch eine Log von sz_fenster erstellen. Und Morgen früh gucken...
FHEM 5.9 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, und HM Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hallo zusammen,

ich habe den Verdacht, dass das mit dem hier eng verwandt ist: https://forum.fhem.de/index.php/topic,104167.0.html. Wird etwas dauern, aber es würde mir sehr helfen, wenn du als workaround mal noch einen "gedoppelten" Schaltzeitpunkt einfügen könntest, nämlich 23:59 Uhr - 16.0°C.

Damit könnte ich besser lokalisieren, ob das Thema tatsächlich auf den letzten Schaltzeitpunkt beschränkt ist oder nicht. Danke vorab und sorry für die Unannehmlichkeiten...

Gruß, Beta-User
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Hallo,
ist eingefügt. Und da ich morgen zuhause bin ist morgen laut Plan auch wieder Wochenende. Sollte also morgen wieder so laufen. Melde mich morgen mit den Ergebnissen.
GrüßeDirk
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Guten Morgen,

so das Fenster ist geschlossen. Leider keine Änderungen mit dem zusätzlichen Timer. Hier die zugehörigen Meldungen aus dem FHEM Log.

Zu sehen ist auch, dass er beide Timer um 5:45 Uhr berücksichtigt, den fürs Wochenende und den für Nicht-Wochenende. Müsste ja eigentlich auch nicht sein. Passt hier vielleicht etwas nicht? 6:55 Uhr ist ja auch für Nicht-Wochenende. { IsWe("today") } liefert heute auch wieder 1.


2019.10.07 07:38:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.07 06:55:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 06:55
2019.10.07 05:45:00 3: [HZT_Schlafen] timer at 05:45 skiped by new timer at 05:45
2019.10.07 05:45:00 3: [HZT_Schlafen] timer at 23:59 skiped by new timer at 05:45
2019.10.06 23:59:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
2019.10.06 20:15:00 2: FHT set sz_heizung desired-temp 16.0
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hallo zusammen,

nachdem ich jetzt zugegebenermaßen einige Zeit ratlos auf den Code von WDT (bzw. meine letzten Änderungen daran) geschaut habe: Bist du sicher, dass
a) der Befehl nicht an das Device versendet wurde (und dort evtl. nur nicht ankam), und (wenn das sicher ist)
b) das jemals funktioniert hat?

Ich kann an den Codeänderungen (Vergleich zwischen Versionen 19806 und 19043) nichts erkennen, was diese Art Auswirkung haben dürfte. Da ist zwar v.a. einiges umgestellt wegen IsWe() und ein dummy-Fensterkontakt sollte jetzt auch gehen, aber die grundsätzliche Logik usw. wurde nicht angefaßt.
Wenn du einen abgesicherten Test mit einer Vorversion machen willst, müßte 19043 eigentlich ausreichen, ansonsten wäre mindestens auf 18591 zurückzugehen (die kann aber nur ein holiday2we-Device, und die Änderungen zwischen diesen beiden Versionen sind (programmiertechnisch) nichts gravierendes).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Hallo,
a) Ganz sicher bin ich mir mit dem Timer nicht. Generell funktioniert der Timer, da er ja 20:15 Uhr auf 16°C zurück stellt. Das funktioniert. Auch die anderen Timer funktionieren soweit bei den anderen Thermostaten, nur gibt es hier bisher nicht den Fall mit dem geöffneten Fenster zum Schaltzeitpunkt. Ich habe die Timer erst letzte Woche am Mittwoch eingerichtet. Vorher gab es noch keine Timer.

b) Ich teste morgen früh noch eine andere Konstellation. Ich werde das Fenster zwischen 5:45 und 6:55 schließen. Dann werden wir sehen was dann funktioniert.

Danach kann ich ja immer noch eine ältere Version testen.

Eine Frage für mein Verständnis. Ich habe den Delay bisher so verstanden, das der Befehl erst gesendet wird, wenn das Fenster geschlossen wird. Nicht das bei geöffnetem Fenster der Thermostat eine neue Temperatur bekommt und beginnt zu heizen.

Grüße
Dirk
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Dann noch zwei Anmerkungen:

- die beiden Morgendlichen Timer zu trennen nach 7+8 macht wenig Sinn, wenn die für $we und !$we auf demselben Zeitpunkt liegen (das _scheint_ aber nicht das Problem zu sein)
- Das offene Fenster sollte eine Verzögerung bewirken, der Befehl geht also erst raus, wenn das Fenster zu ist. Das allerdings nicht Event-basiert, sondern durch eine Timer-Funktion, die jede Minute prüft, ob das Fenster noch offen ist. Von daher ist eine Ausgabe wie
Zitat
2019.10.07 07:38:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
mMn. eigentlich i.O., da der Zustand korrekt ausgewertet wurde. Leider ist an der Stelle der Code (für meine Begriffe) etwas eigenwillig geschrieben, aber wie gesagt: an sich unverändert, aber man würde erwarten, dass vorher oder kurz danach auch die Meldung kommt, dass das ausgeführt wurde...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Hallo,
vielleicht ist das mit den beiden Timern zur gleichen Zeit für $we und !$we doch ein Problem. Ich habe die beiden Timer jetzt mal zu einem Timer für jeden Tag zusammen gefasst. Mal sehen was nun morgen passiert. Ich kann ja morgen noch einmal mit geöffnetem Fenster testen und übermorgen mit Fenster geschlossen.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Guten Morgen,
mit geändertem Timer sieht es leider immer noch so aus. Kein aktueller Sollwert an das Thermostat. Immer noch der Eintrag um 6:55 Uhr, das der Timer geskiped wurde.

Meine aktuelle Definition
defmod HZT_Schlafen WeekdayTimer sz_heizung 05:30|20.0 7|20:25|16.0 8|06:55|16.0 8|16:00|20.0 8|20:15|16.0
attr HZT_Schlafen WDT_Group Heizung_Eco
attr HZT_Schlafen WDT_delayedExecutionDevices sz_fenster
attr HZT_Schlafen commandTemplate set $NAME desired-temp $EVENT
attr HZT_Schlafen group Heizplan
attr HZT_Schlafen room Heizung
attr HZT_Schlafen sortby 4
attr HZT_Schlafen switchInThePast 1

setstate HZT_Schlafen open window
setstate HZT_Schlafen 2019-10-08 07:58:00 currValue 20.0
setstate HZT_Schlafen 2019-10-08 07:58:00 nextUpdate 2019-10-08 20:25:00
setstate HZT_Schlafen 2019-10-08 07:58:00 nextValue 16.0
setstate HZT_Schlafen 2019-10-08 07:57:00 state open window

Die Einträge im Log
2019.10.0807:58:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.0806:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.0805:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Aktuell ist auf jeden Fall Wochenende, das habe ich geprüft. Und da ich die Woche zuhause bin, ist die gesamte Woche in der zugehörigen holiday Datei eingetragen. Das kommt wohl auch im Timer an, wie man an den Profileinträgen erkennt.
Profil 0: Sonntag    05:30:00 20.0, 20:25:00 16.0
Profil 1: Montag    05:30:00 20.0, 20:25:00 16.0
Profil 2: Dienstag    05:30:00 20.0, 20:25:00 16.0
Profil 3: Mittwoch    05:30:00 20.0, 20:25:00 16.0
Profil 4: Donnerstag    05:30:00 20.0, 20:25:00 16.0
Profil 5: Freitag    05:30:00 20.0, 20:25:00 16.0
Profil 6: Samstag    05:30:00 20.0, 20:25:00 16.0
Profil 7: Wochenende    20:25:00 16.0
Profil 8: Werktags    06:55:00 16.0, 16:00:00 20.0, 20:15:00 16.0

Ich werde morgen früh nun noch einmal testen, wenn ich das Fenster vor 6:55 Uhr schließe. Dann berichte ich morgen wieder.

Grüße
Dirk
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hmm, das scheint eventuell wirklich mit der Wochenendbehandlung zusammenzuhängen. Bin mal auf morgen gespannt, vielleicht komme ich auch dazu, mir den Code dazu nochmal näher anzusehen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Guten Morgen,

so der Test ist gelaufen. Heute ist alles so wie es soll. Fenster zwischen den beiden Zeiten geschlossen. Thermostat geht auf neue Temperatur und bleibt dort auch.

2019.10.09 06:19:00 2: FHT set sz_heizung desired-temp 20.0
2019.10.09 06:19:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.09 05:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Scheint auch aus meiner bescheidenen Sicht auf die Dinge ein Thema mit der Wochenendbehandlung zu sein. Aber nur, wenn das Fenster offen ist und dann ein neuer Timer kommt. Sonst funktioniert ja das Ganze.

Grüße
Dirk
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hast du eigentlich die weekEnd-Datei auch als holiday-Device definiert oder nur in das holiday2we-Attribut eingetragen?

(Wenn nicht definiert, bitte nachdefinieren und dann den Test wiederholen).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Hallo,

ist natürlich beides gemacht. Sowohl ein Device für holiday angelegt als auch das Attribut in global gesetzt.

Dirk
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Thx. Ich denke, das Problem gefunden zu haben. Leider habe ich noch keine Idee, wie man es behebt:

Für einen Tag, der per weekEnd zum Wochenende erklärt ist, tauchen die Schaltzeitpunkte zwar nicht in den helper-SWITCHINGTIME-Infos auf, aber in den profile_IDX-Angaben (im list). Das scheint übrigens für alle holiday-Devices zu gelten, hat also mit weekEnd/IsWe() eigentlich gar nicht direkt was zu tun.

Na jedenfalls werden bei WeekdayTimer_searchAktNext() dann diese profile_IDX-Angaben ausgewerten. Ergo muß verhindert werden, dass die da überhaupt reinkommen (denke ich jedenfalls)... Ganz schön kompliziert, das ganze.



Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Immerhin hast du eine Idee, woran es liegen könnte. Wenn ich was testen soll, sag einfach Bescheid.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Also, anbei mal eine Testversion, die das Problem zu beseitigen scheint. Für einen beschleunigten Start bitte den fraglichen Timer auch gleich mit "enable" dazu bewegen, die heutigen Zeiten nochmal zu ermitteln...
« Letzte Änderung: 14 November 2019, 16:13:50 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Version ist eingespielt und FHEM neu gestartet. Erste zugehörige Meldung beim FHEM Start im Log ist:

2019.10.09 18:59:28 3: [HZT_Schlafen] Reading/Attribute 'Window' of sz_fenster not found, sz_fenster ignored - inform maintainer
sz_fenster hat aber eigentlich ein solches Reading. Hier mal die komplette Definition.

defmod sz_fenster CUL_FHTTK 58f177
attr sz_fenster userattr HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes
attr sz_fenster HomeContactType window
attr sz_fenster HomeModeAlarmActive armaway
attr sz_fenster HomeValues Open
attr sz_fenster IODev CUL_1
attr sz_fenster alias Schlafen Fenster
attr sz_fenster model FHT80TF
attr sz_fenster room CUL_FHTTK,Schlafen

setstate sz_fenster Closed
setstate sz_fenster 2019-10-09 06:18:34 Previous Open
setstate sz_fenster 2019-10-09 19:01:54 Reliability ok
setstate sz_fenster 2019-10-09 19:01:54 Window Closed
setstate sz_fenster 2019-10-09 19:01:54 batteryState ok
setstate sz_fenster 2019-10-09 19:01:54 state Closed
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
? Bin etwas ratlos, wo das jetzt herkommen soll...

Kannst du bitte zum einen mal nachsehen, ob das früher schon mal kam und zum anderen testen, ob es trotzdem funktioniert (könnte etwas mit der Reihenfolge in der cfg bzw. dem späteren Laden der Werte aus der statefile zu tun haben). An der Reihenfolge bzw. der Initialisierung des Moduls wollte ich eh' nochmal was drehen - per default sollte bei nicht deaktiviertem Device immer gleich ein "enable" ausgeführt werden, dann stimmen auch alle Timerwerte zeitnah zum FHEM-Start...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Okay sorry. Beim letzten Neustart am 5. Oktober gab es die Meldung auch schon. Habe ich damals in den zahlreichen Meldungen beim Neustart übersehen / nicht darauf geachtet. Scheint ja trotzdem zu funktionieren.

Ich nutze die configdb, da kann ich die Reihenfolge nicht mehr beeinflussen (denke ich).

Also warten wir morgen früh ab. Ich schließe das Fenster wieder erst nach 6:55 Uhr.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Puh, "wenigstens das"... (Man kann durch löschen/Neuanlegen auch @configDB was an der Reihenfolge drehen, aber das ist ja nicht Sinn der Übung, außerdem dürfte das bei Readings alleine nichts helfen, die statefile wird trotzdem erst nach allen defines gelesen  ;D ).

Im Anhang der Versuch, manche der Initialisierungsroutinen etwas verzögert auszuführen. Könnte sein, dass das das die Einträge bereits eliminiert, kann aber auch Nebenwirkungen haben...
« Letzte Änderung: 14 November 2019, 16:13:37 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Okay eingespielt und neu gestartet. Jetzt kommen folgende Meldungen bzgl. WeekdayTimer.
2019.10.09 21:09:20 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:20 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:20 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:16 3: [HZT_Schlafen] Reading/Attribute 'Window' of sz_fenster not found, sz_fenster ignored - inform maintainer

Da die neue Meldung sieben Mal kommt und ich sieben Timer für die Heizung haben, könnte das damit zusammen hängen. Dafür brauchte ich kein enable mehr setzen, die Timer hatten alle ihre aktuellen Werte.

Noch was anderes. Mir ist beim anlegen aufgefallen, das das Attribute commandTemplate für die FHT Thermostate und das HM Wandthermostat schon richtig eingestellt waren auf
commandTemplate set $NAME desired-temp $EVENTBei den HM Heizungthermostaten fehlte das "disired-temp". Kann das damit zusammenhängen, das für diese Thermostate der Channel Clima und nicht Climate verwendet werden muss.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Anbei eine wg. der Startgeschichte nochmals angepaßte Fassung; damit sollten die "7-fach"-Meldungen und auch das mit dem Fensterkontakt Geschichte sein (allerdings bin ich nicht ganz sicher, ob die Meldung später dann noch im Log landet, wenn man wirklich eine falsche Type hat...). (Was in dem Zuge immer noch nicht erledigt ist, ist ein Hinweis, wenn das Zieldevice noch nicht definiert ist, also in der config hinter dem WDT steht...).

Was das mit den Homematics angeht: Kannst du mal schauen, ob du bei dem WT nicht den Climate-Kanal direkt angegeben hast? Entsprechend wäre bei den RT's dann der Clima-Kanal auszuwählen.
« Letzte Änderung: 14 November 2019, 16:13:13 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Also neue Version jetzt heute früh eingespielt, leider erst nach dem Test mit dem Fenster. Folgendes ergaben die Tests:

  • der Timer wird mit der Version von gestern immer noch um 6:55 Uhr geskiped
  • mit der Version von gestern Abend hat heute früh nur der Timer, der getestet wird wegen dem Fenster, geschaltet. Alle anderen 6 haben nicht zur angegebenen Zeit geschaltet und brauchten einen manuellen Anstoß. Kann vielleicht an dem enable liegen. Habe ich nur für den einen Timer gemacht.
  • Version von heute früh lief beim Start ohne Meldungen. Dafür hat der im Test befindliche Timer wieder zurück auf 16°C geschaltet. Stand vorher auf 20°C durch manuellen Anstoß von mir. Das Zurückschalten auf 16°C erfolgte beim Start von FHEM. Der Timer ließ sich aber wieder manuell zu den 20°C bewegen. Dies lässt sich mit jedem Neustart nachstellen.

Zu den Homematics habe ich noch einmal meinen Anlagevorgang geprüft. Ich hatte für die Heizkörperthermostate den Channel Climate angegeben. Und erst im Nachhinein den Fehler bemerkt und im Timer das Device auf Clima geändert. Daher wahrscheinlich das fehlende desired-temp im Attribut.
« Letzte Änderung: 10 Oktober 2019, 12:20:06 von dlehmann69 »
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Geskipped hat die Version von 20:56 Uhr, nehme ich an?

Bisher scheint die Version von 17:34 ganz ok zu sein, wenn man von der Initialisierung absieht, oder bezog sich der Test auf diese Fassung? Wenn möglich, dann bitte erst mal die verwenden.

Wegen der gesamten Initialisierung bastle ich grade noch etwas rum, aber dabei passieren teils "lustige" Sachen :( ...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Okay die Version von 17:34 Uhr ist wieder eingespielt, das FHEM neu gestartet und alle Timer einmal auf enable gesetzt. Nun schauen wir einmal morgen früh.
Das mit dem Fenstersensor ist aber schon komisch. Er meckert nur bei dem einen Sensor. Ich habe ja drei FHT und drei HM Thermostate mit einem Fenstersensor. Aber nur das Reading ist noch nicht da.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
ebend. Es ist ein Reading, der Rest dürften Attribute sein. (Attribut: vorheriges define reicht; Reading: statefile muß gelesen werden...)

Wie dem auch sei: Auf Basis der 17:34-Version anbei nochmal ein update, dieses Mal mit einer funktionierenden Initialisierung erst nach $init_done (hoffe ich wenigstens) :) .

Bis auf etwas cleanup bin ich jetzt optimistisch, dass das so passen müßte ;D .

Danke für die Geduld bis dahin!
« Letzte Änderung: 14 November 2019, 16:13:03 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Aktuelle Version vom letzten Post ist eingespielt, FHEM neu gestartet und alle Timer einmal auf enable gesetzt. Jetzt kam folgende Meldung, aber wieder nur für den einen Timer:

2019.10.10 16:46:46 3: [HZT_Schlafen] no switches to send, due to possible errors.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hmm,

kannst du dann testweise noch am Ende der "Start"-Routine (bei L249) eine Zeile einfügen, so dass das dort so ausschaut:
$attr{$name}{commandTemplate} =
     'set $NAME '. WeekdayTimer_isHeizung($hash) .' $EVENT' if (!defined $attr{$name}{commandTemplate});

  WeekdayTimer_SetTimerOfDay({ HASH => $hash});
  WeekdayTimer_SetTimer($hash);
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Okay habe die Zeile an besagter Stelle so eingefügt. Leider kommt noch immer die gleiche Meldung
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Leider  mit letzter Version von gestern Nachmittag keine Verbesserungen. Die Meldungen kommen immer noch so und der Timer wird bei geöffnetem Fenster um 6:55 Uhr für den Wochentag geskiped. Aber es ist laut Aufruf auch heute noch Wochenende.
2019.10.1107:44:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.1106:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.1105:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Was auch auffällt ist, dass der State des Timers selbst nach schließen des Fensters immer noch auf Window open stehen bleibt. Erst nach dem manuellem Anstoßen des Timers geht er wieder in den normalen Modus laut Zeitplan.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
 :o Hmm, die spannende Frage Frage ist doch, warum die 05:30 Uhr-Angabe überhaupt "angefahren" wird, wenn $we ist, eigentlich sollte dann nur 06:55 Uhr ein Rolle spielen...

Kannst du mal ein aktuelles list davon einstellen?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Also 5:30 Uhr soll er schon anfahren, der Schaltpunkt gilt für jeden Tag. Werktags soll er dann eine Heizpause von 6:55 Uhr bis 16:00 Uhr einlegen und am Wochenende halt nicht. Warum fährt er 6:55 am Wochenende an, aber nur wenn das Fenster offen ist. Mit geschlossenem Fenster hat alles funktioniert.
Hier das aktuelle List.
Internals:
   COMMAND   
   CONDITION 
   DEF        sz_heizung 05:30|20.0 7|20:25|16.0 8|06:55|16.0 8|16:00|20.0 8|20:15|16.0
   DEVICE     sz_heizung
   FUUID      5d949033-f33f-73c2-f688-cd4b36882bbe6364
   GlobalDaylistSpec
   LANGUAGE   de
   NAME       HZT_Schlafen
   NR         321
   Profil 0: Sonntag 05:30:00 20.0, 20:25:00 16.0
   Profil 1: Montag 05:30:00 20.0, 20:25:00 16.0
   Profil 2: Dienstag 05:30:00 20.0, 20:25:00 16.0
   Profil 3: Mittwoch 05:30:00 20.0, 20:25:00 16.0
   Profil 4: Donnerstag 05:30:00 20.0, 20:25:00 16.0
   Profil 5: Freitag 05:30:00 20.0, 20:25:00 16.0
   Profil 6: Samstag 05:30:00 20.0, 20:25:00 16.0
   Profil 7: Wochenende 20:25:00 16.0
   Profil 8: Werktags 06:55:00 16.0, 16:00:00 20.0, 20:15:00 16.0
   STATE      20.0
   STILLDONETIME 0
   TYPE       WeekdayTimer
   Helper:
     DBLOG:
       currValue:
         DBLogging:
           TIME       1570776802.03367
           VALUE      20.0
       nextUpdate:
         DBLogging:
           TIME       1570776802.03367
           VALUE      2019-10-11 20:25:00
       nextValue:
         DBLogging:
           TIME       1570776802.03367
           VALUE      16.0
       state:
         DBLogging:
           TIME       1570776802.03367
           VALUE      20.0
   READINGS:
     2019-10-11 08:53:22   currValue       20.0
     2019-10-11 08:53:22   nextUpdate      2019-10-11 20:25:00
     2019-10-11 08:53:22   nextValue       16.0
     2019-10-11 08:53:22   state           20.0
   SWITCHINGTIMES:
     05:30|20.0
     7|20:25|16.0
     8|06:55|16.0
     8|16:00|20.0
     8|20:15|16.0
   TIMER:
     HZT_Schlafen_1:
       HASH       HZT_Schlafen
       MODIFIER   1
       NAME       HZT_Schlafen_1
       immerSchalten 1
     HZT_Schlafen_2:
       HASH       HZT_Schlafen
       MODIFIER   2
       NAME       HZT_Schlafen_2
     HZT_Schlafen_4:
       HASH       HZT_Schlafen
       MODIFIER   4
       NAME       HZT_Schlafen_4
     HZT_Schlafen_5:
       HASH       HZT_Schlafen
       MODIFIER   5
       NAME       HZT_Schlafen_5
     HZT_Schlafen_SetTimerOfDay:
       HASH       HZT_Schlafen
       MODIFIER   SetTimerOfDay
       NAME       HZT_Schlafen_SetTimerOfDay
       SETTIMERATMIDNIGHT 1
     HZT_Schlafen_delayed:
       HASH       HZT_Schlafen
       MODIFIER   delayed
       NAME       HZT_Schlafen_delayed
   dayNumber:
     !$we       8
     $we        7
     di         2
     do         4
     fr         5
     mi         3
     mo         1
     sa         6
     so         0
   helper:
     daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
     daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
     SWITCHINGTIME:
       0:
         05:30:00   20.0
         20:25:00   16.0
       1:
         05:30:00   20.0
         20:25:00   16.0
       2:
         05:30:00   20.0
         20:25:00   16.0
       3:
         05:30:00   20.0
         20:25:00   16.0
       4:
         05:30:00   20.0
         20:25:00   16.0
       5:
         05:30:00   20.0
         20:25:00   16.0
       6:
         05:30:00   20.0
         20:25:00   16.0
       7:
         20:25:00   16.0
       8:
         06:55:00   16.0
         16:00:00   20.0
         20:15:00   16.0
   longDays:
     de:
       Sonntag
       Montag
       Dienstag
       Mittwoch
       Donnerstag
       Freitag
       Samstag
       Wochenende
       Werktags
     en:
       Sunday
       Monday
       Tuesday
       Wednesday
       Thursday
       Friday
       Saturday
       weekend
       weekdays
     fr:
       Dimanche
       Lundi
       Mardi
       Mercredi
       Jeudi
       Vendredi
       Samedi
       weekend
       jours de la semaine
   profil:
     1:
       EPOCH      1570764600
       PARA       20.0
       TIME       05:30
       TAGE:
         0
         1
         2
         3
         4
         5
         6
     2:
       EPOCH      1570818300
       PARA       16.0
       TIME       20:25
       TAGE:
         7
     3:
       EPOCH      1570769700
       PARA       16.0
       TIME       06:55
       TAGE:
         8
     4:
       EPOCH      1570802400
       PARA       20.0
       TIME       16:00
       TAGE:
         8
     5:
       EPOCH      1570817700
       PARA       16.0
       TIME       20:15
       TAGE:
         8
   profile_IDX:
     0:
       05:30:00   1
       20:25:00   2
     1:
       05:30:00   1
       20:25:00   2
     2:
       05:30:00   1
       20:25:00   2
     3:
       05:30:00   1
       20:25:00   2
     4:
       05:30:00   1
       20:25:00   2
     5:
       05:30:00   1
       20:25:00   2
     6:
       05:30:00   1
       20:25:00   2
     7:
       20:25:00   2
     8:
       06:55:00   3
       16:00:00   4
       20:15:00   5
   shortDays:
     de:
       so
       mo
       di
       mi
       do
       fr
       sa
       $we
       !$we
     en:
       su
       mo
       tu
       we
       th
       fr
       sa
       $we
       !$we
     fr:
       di
       lu
       ma
       me
       je
       ve
       sa
       $we
       !$we
Attributes:
   WDT_Group  Heizung_Eco
   WDT_delayedExecutionDevices sz_fenster
   commandTemplate set $NAME desired-temp $EVENT
   group      Steuerung Heizpläne
   room       Heizung
   sortby     4
   switchInThePast 1
« Letzte Änderung: 11 Oktober 2019, 13:03:20 von dlehmann69 »
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
 :) :'( :-\ :)
Das Verhalten scheint der Beschreibung nach also aus WeekdayTimer_delayedTimerInPast() zu kommen. Damit bin ich zwar einen kleinen Schritt weiter, habe aber mal wieder erst mal keine Idee, wie die Lösung dazu sein könnte :( . Ist einfach recht abstrakt, was Dietmar da gecoded hatte...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Naja du hast wenigstens mehr Ahnung vom Programmieren als ich.

So eine Idee von einem absoluten Laien, der einen Blick auf den Code geworfen hat. Kann es vielleicht auch um die Zeile 955 mit der Prüfung zu tun haben, ob der nächste Timer überhaupt relevant ist?
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Na ja, bin da auch nur mehr oder weniger zufällig rangeraten, und ob ich da wirklich viel weiter bin als du, mag ich nicht beurteilen ;D ::) .

Das Problem scheint mir zu sein, dass diese Funktion ständig aufgerufen wird, hier aber gar nicht hätte aufgerufen werden dürfen (bzw. mit einem anderen Parameter, nämlich dem Schaltzeitpunkt für $we, nicht dem für !$we). Der Code ist leider (?) sehr verschachtelt, so dass ich auch eher am Raten bin, was jetzt wie zusammengehört und wo eine Auswirkung hat. (Daher mußten auf jeden Fall erst mal die überflüssigen Schaltzeitpunkte aus profile_IDX raus).
Jetzt ist die spannende Frage (mMn.), wieso der Code dann bei der "Rückwärtssuche" plötzlich doch wieder auf die "basics" zurückkommt und dann die 7 bzw. 8 wieder ohne Berücksichtigung von den aktuellen tatsächlichen Gegebenheiten (IsWe()) "drüberschiebt". Vermute, das hat damit zu tun, dass das ohne Initialisierung auf den heutigen Tag (das, was jetzt "set ... enable" ist, und zuvor nur durch einen Tageswechsel veranlaßt wurde) sonst gar nicht anders möglich war.

Anders gesagt: Vermutlich muß in WeekdayTimer_delayedTimerInPast() geprüft werden, ob SETTIMERATMIDNIGHT (?) vorhanden ist. Wenn nein, wäre es die alte Routine, wenn ja, müßte erst rückwärts geschaut werden, was für timer für heute so anstehen. Ist da "noch nicht Zeit" (also noch kein Schaltzeitpunkt erreicht), entsprechend für den Vortag usw., wobei dann (korrekterweise eigentlich) für "gestern" und andere vergangene tage auch noch eine IsWe()-Prüfung dazukäme (die wird in den Profilen für die Zukunft gemacht)...
Das ganze ist aber ein feature, das in WDT dann eigentlich "schon immer" da gewesen sein müßte (bei Feiertagen). Komisch, dass das all die Jahre niemandem aufgefallen ist ??? .

Wie dem auch sei, ich werde wohl mal versuchen, das mit der simplen Unterstellung da reinzucoden, der Wert sei wahr (was neuerdings ja stimmen dürfte), dann können wir ja sehen, ob die grundsätzliche Überlegung richtig ist...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Anbei ein Versuch...

Kann im Moment nur sagen, dass das lädt, habe aber keine Ahnung, ob das wirklich was hilft ;D .
« Letzte Änderung: 12 Oktober 2019, 08:30:43 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Funktioniert leider überhaubt nicht. FHEM stürzt nach dieser Meldung im Log komplett ab, ist nicht mehr erreichbar. Nach einem Neustart gleiche Situation.

Can't use string ("7") as an ARRAY ref while "strict refs" in use at ./FHEM/98_WeekdayTimer.pm line 1109.
Gehe zurück auf die vorherige Version
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
UPS, da fehlen je ein paar eckige Klammern...Uptade folgt, dauert aber min. bis morgen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Alles klar und kein Problem. Bis jetzt ist da Fenster ja nur bei diesem einen Timer um die Schaltzeit offen.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
nur kurz angetestet, aber mit eckigen Klammern...
Führt jedenfalls bei delayed-FK's scheinbar nicht zum Absturz.
« Letzte Änderung: 14 November 2019, 16:12:11 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Okay startet schon einmal problemlos. Test läuft dann später zu den Schaltzeiten morgen früh wieder. Oder ich lege zum testen mal heute einen zusätzlichen Timer an. Da heute ja Wochenende ist, wird das mit der Simulation eines Werktags aber schwierig.

Zur Info, diese Meldung ist noch da.
[HZT_Schlafen] no switches to send, due to possible errors.
Diese Meldung kam beim Start richtigerweise, da das Fenster noch offen ist.
[HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
So hier nun die Ergebnisse der letzten 24 Stunden. Aufgrund des schönen Wetters war das Fenster die gesamte Zeit offen. Trotzdem sieht man im Log, wie er trotz Wochenende jeden Schaltpunkt mitnimmt und immer wieder den Timer skiped.
2019.10.13 16:00:00 3: [HZT_Schlafen] timer at 06:55 skiped by new timer at 16:00
2019.10.13 06:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.13 05:30:00 3: [HZT_Schlafen] timer at 20:25 skiped by new timer at 05:30
2019.10.12 20:25:00 3: [HZT_Schlafen] timer at 20:15 skiped by new timer at 20:25
2019.10.12 20:15:00 3: [HZT_Schlafen] timer at 16:00 skiped by new timer at 20:15
2019.10.12 16:00:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Auch bleibt weiterhin der State im Timer nach dem Schließen des Fensters auf "Window open" stehen. So gesehen auch bei einem weiteren Timer mit Homematic Geräten.

Das war es leider nicht.  :(
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Wenn du kein weekEnd-holiday-Device hast: Kannst du mal testen, ob das Problem mit der Version 19567 auch schon bestanden hat?

Ich versuche grade, den Code wieder in diese Richtung zu ändern, dabei aber die deutlich komplexere Auswertung, ob bzw. wann denn jetzt $we ist, (die mit 19806 kam, und auch andere unerwünschte Nebenwirkungen zu haben scheint) auf eine andere, zentrale Stelle zu verlagern (die dann auch nur einmal am Tag/auf Anforderung erneuert wird).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Also ein Holiday Device habe ich, welches sich auf meine holiday Datei bezieht. In dieser steht dann halt drin, ob gerade ein Tag ist, welcher wie ein Wochenende behandelt werden soll. Ich könnte es ja testweise löschen und danach wieder anlegen. Die nächsten Tage brauche ich Datei gerade nicht.

Soll ich das testweise einmal tun und auf die genannte Version zurück gehen? Wo bekomme ich die eigentlich her? Aus einem Backup und/oder von SVN?
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Über svn ist in der Regel einfacher (finde ich).

Anbei aber eine neue Version, die etwas näher an dem ursprünglichen h2we-Code dran ist. Jetzt werden die $we-Angaben (hoffentlich) nur einmal am Tag bzw. auf Anforderung ermittelt und können dann als statische Abfrage direkt aus einem Hash gelesen werden.

Test wäre willkommen, evtl. schaffe ich es auch, das Problem mal nachzustellen...
« Letzte Änderung: 14 November 2019, 16:11:56 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
So neue Version eingespielt, bisher nichts auffälliges. Bisherige Meldungen sind noch da.

Die Meldungen wegen möglicher Fehler.
[HZT_Schlafen] no switches to send, due to possible errors.
Kommt nur bei diesem Timer, wahrscheinlich weil nur hier das Fenster offen ist.[HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
Das holiday Device haben ich zunächst noch so belassen. Aktuell ist kein Wochenende. Trotzdem hatte die alte Version bei geöffnetem Fenster einen Timer fürs Wochenende berücksichtigt. Hätte ja eigentlich schon 20:15 Uhr geschaltet werden sollen.
2019.10.14 20:25:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
Mal sehen was morgen so läuft.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Hier das bisherige Ergebnis.

Der unter Beobachtung stehende Timer hate heute Abend zu den Schaltzeiten ein geöffnetes Fenster. Laut Log hat der Timer um 20:25 Uhr reagiert. Das ist ja aber die Zeit fürs Wochenende. Dies ist laut Profile des Timers auch so.

Heute früh war zur Schaltzeit um 5:30 Uhr das Fenster offen und dieses wurde um 5:38 Uhr geschlossen. Der Timer hat immer richtig reagiert und die Heizung auch um 6:55 Uhr wieder runter gefahren.

Mal sehen wie es morgen früh mit geöffnetem Fenster läuft.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Der unter Beobachtung stehende Timer hate heute Abend zu den Schaltzeiten ein geöffnetes Fenster. Laut Log hat der Timer um 20:25 Uhr reagiert. Das ist ja aber die Zeit fürs Wochenende. Dies ist laut Profile des Timers auch so.
Wenn es im Profil so vorgesehen ist, sollte es passen. Ist denn das Profil nicht richtig, oder wie ist das obige zu deuten?
(Dann sollte ich aber die Infos haben, was in global als h2we-Attribut eingetragen ist, und ggf. ob in den holiday-Devices irgendwelche Urlaubs-/Feiertage usw. eingetragen sind.)

Ansonsten klingt das nach: Paßt soweit?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Sorry war wohl gestern Abend schon etwas spät  ::)

Laut Profil, was auch richtig ist, sollte er um 20:15 Uhr für Werktag schalten. Der Timer hat aber um 20:25 Uhr auf die Zeit fürs Wochenende reagiert und diese geskiped. Laut Abfrage ist auch kein Wochenende. Wegen dem geöffnetem Fenster aber erst mal kein Problem.


Heute früh hat er bei geöffnetem Fenster beide Zeiten für den Werktag geskiped, passt also erst einmal.

Am Freitag ist laut holiday Datei wieder Wochenende. Steht so auch schon im Profil des Timers. Da werden wir sehen, ob der Timer richtig reagiert.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Geskiped klingt trotdem erst mal nicht optimal, aber das war vermutlich vorher schon so.

Es scheint aber zumindest dahingehend eine Verbesserung zu sein, dass jetzt immer korrekt auf ein Schließen des Fensters reagiert wird, oder?

(Dann werde ich im anderen Thread nämlich auch mal um einen Test dieser Version bitten.)

Ist zwar irgendwie noch unfertig, denn eigentlich sollte der WEDAY-Hash komplett via IsWe() gefüllt werden und die Initialisierung noch etwas weiter verzögert (damit die holiday-Devices schon richtige Werte enthalten), aber wichtig wäre ja erst mal, dass auch bei Sonderkonstellationen die richtige Reaktion veranlaßt wird...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Ja geskiped war vorher auch schon.

Das Schließen des Fenster war aus meiner Sicht nicht das Problem. Das Problem war, dass bei geöffnetem Fenster statt dem Timer fürs Wochenende der Timer für Werktag berücksichtigt wurde und dann beim Schließen des Fensters die Heizung wegen Werktag nicht geheizt hat. Gestern Abend war der Fall eher andersrum. Er hat beim skipen den Timer für das Wochenende berücksichtigt statt dem für den Werktag.

Ich würde gern den Freitag morgen abwarten. Da ist wieder laut Datei Wochenende und das Fenster steht offen. Mal sehen, ob er dann beim Schließen des Fensters den richtigen Timer berücksichtigt.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
So der Test heute früh mit der bekannten Konstellation ist gelaufen. Leider bringt das geöffnete Fenster die Abfrage, ob Wochenende ist, immer noch durcheinander. Hier die dazugehörigen Auszüge aus dem Log. Selbst gestern Abend wurde der Timer für Werktag um 20:15 richtig geschaltet für Werktag. Dann wurde das Fenster geöffnet und der Timer fürs Wochenende um 20:25 wurde geskiped. Und heute früh wurden bei geöffnetem Fenster alle Timer geskiped. Leider halt auch der für Werktag um 6:55 Uhr, obwohl heute wieder Wochenende ist.

2019.10.18 08:45:49 2: FHT set sz_heizung desired-temp 20.0
2019.10.18 08:45:44 3: [HZT_Schlafen] set HZT_Schlafen enable
2019.10.18 07:54:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.18 06:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.18 05:30:00 3: [HZT_Schlafen] timer at 20:25 skiped by new timer at 05:30
2019.10.17 20:25:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
2019.10.17 20:15:00 2: FHT set sz_heizung desired-temp 16.0

Das Verhalten ist aus meiner Sicht auch unabhängig von einem Holiday Device. Den morgen früh ist ja normal immer Wochenende auch ohne einen Eintrag in der Datei für holiday. Wird aber auch wieder das gleiche Verhalten wie heute geben. Können wir noch abwarten.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hmmm, dann muß ich da wohl weiter knobeln.

Was das $we-Thema angeht: Es ist nicht mehr zwangsläufig $we, nur weil grade Samstag oder Sonntag ist, man kann das mit einem Eintrag "weekEnd" bei holiday2we in global unterbinden bzw. dann mit entsprechenden Einträgen da entsprechend steuern. Gerade aus dem Grund scheint auch das Gefüge durcheinandergekommen zu sein (vermute ich jedenfalls).
Eventuell wäre es einen Versuch wert zu sehen, ob auch die Vorversion (19568 oder so) dieses Verhalten (schon) aufweist; das sollte immer dann komplikationslos gehen, wenn man keinen weekEnd- (und noWeekEnd-) Eintag hat bzw. braucht.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Ich bin dann mal auf Vorversion 19567 zurück gegangen. Mal sehen, was damit morgen früh läuft.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Der Test mit der Vorversion ist durch und ich muss leider sagen, gleiches Verhalten. Das geöffnete Fenster bringt die Timer durcheinander. Gestern Abend mit geschlossenem Fenster korrekt für Wochenende geschaltet. Heute früh bei geöffnetem Fenster dann wieder für Wochentag geschaltet und damit die Heizung ausgeschaltet. Für das aktivieren heute Früh funktionierte das enable nicht, nur ein single set hat den Timer wieder richtig gesetzt.
2019.10.19 09:43:29 2: FHT set sz_heizung desired-temp 20.0
2019.10.19 09:42:39 3: [HZT_Schlafen] set HZT_Schlafen enable
2019.10.19 09:21:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.19 06:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.19 05:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
2019.10.18 20:25:00 2: FHT set sz_heizung desired-temp 16.0
2019.10.18 16:40:40 3: [HZT_Schlafen] Reading/Attribute 'Window' of sz_fenster not found, sz_fenster ignored - inform maintainer
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Zwischeninfo: Das Thema ist noch auf der Liste, und durch den update, den ich eben ins svn geschubst habe, ist das auch nicht behoben; der bringt nur etwas mehr Transparenz dahingehend, was das IsWe()-Umfeld so an Ergebnis liefert und ergänzt HMCCUDEV als FK-Typ (das war der eigentliche Anlaß).
Irgendwie "beruhigt" es mich einerseits, dass der auf 19567 folgende commit zumindest für das Problem hier nicht als "Schuldiger" festgemacht werden kann, andererseits bedeutet das, dass ich wohl den Code gedanklich nochmal komplett auseinandernehmen muß und auch die Teile verstehen, die älteren Ursprungs sind. Das wird nochmal etwas dauern...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Alles klar.  Ich stehe weiterhin gern für Tests zur Verfügung.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Kannst du evtl. auch mal mit dem myUtils-Code aus https://forum.fhem.de/index.php/topic,104167.msg992793.html#msg992793 (mit dem "f"-Aufruf statt "t") nachsehen, welche Timer ggf. zu den unterschiedlichen Zeiten tatsächlich vorhanden sind?

Ich vermute, dass da die Rückmeldungen des Moduls und die tatsächlich gesetzten Timer uU. nicht ganz deckungsgleich sind...

(Wenn du nicht grade eine funktionierende Vorversion im Einsatz hast, bitte die derzeit über update verfügbare Version verwenden).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hmm, ich glaube das (oder zumindest ein) Problem gefunden zu haben, bitte die eben gepostete Version aus dem anderen Thread testen.
Scheinbar wurden (je nach DEF teilweise viel) zu viele Timer angelegt.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
So neue Version eingespielt und FHEM neu gestartet. Bis jetzt keine neuen Probleme, nur die bekannt Fehlermeldung beim Start und immer noch nur für diesen einen Timer.

[HZT_Schlafen] no switches to send, due to possible errors.
Den myUtils-Code habe ich eingebaut und es sieht so von den relevanten Timern gut aus. Die aktuellen Schaltzeiten für den betrachteten Timer passen alle für heute. Wann sollte ich da am besten die Schaltzeiten kontrollieren?

716    15.11.2019 16:00:00    HZT_Schlafen_4 WeekdayTimer_Update
717    15.11.2019 20:15:00    HZT_Schlafen_5 WeekdayTimer_Update
719    16.11.2019 00:00:05    HZT_Schlafen_SetTimerOfDay WeekdayTimer_SetTimerOfDay

Morgen früh ist ja wieder Wochenende und da testen wir gleich mal wieder.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Hm, wann kontrollieren ist eine gute Frage. Würde sagen: Nach 16:00 Uhr und dann checken, ob der letzte Timer auch geschaltet hat.

Was hier vor allem interessant ist, ist ja was passiert, wenn ein Fenster offen ist => da müßte dann nach dem update-Timer ein delayed kommen.

Die Fehlermeldung schaue ich mir nochmal an, kannst du mal nach dem Internal "NR" von beiden sehen? Vermute der WDT hat die kleinere, werde aber nach der Meldung auch nochmals sehen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Also hier die beiden Internal "NR"

WDT Schlafzimmer 321
zugehöriger Fenstersensor 10

Der WDT hat also die Größere.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
So kurzes Feedback nach zwei Tagen Wochenende.

Der Timer hat in der neuen Testversion ohne Probleme zu den richtigen Zeiten geschaltet. Auch das geöffnete Fenster hat ihne nicht durcheinander gebracht. Also in der aktuellen Testversion aus meiner Sicht alles okay.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
Zur Info:
Das ist jetzt (mit entfernten Kommentaren usw.) im svn, kommt morgen per update.

Was das hier angeht, scheint es nichts dramatisches zu sein:
[HZT_Schlafen] no switches to send, due to possible errors.
Kann es sein, dass an dem Tag keine Timer anstanden?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Also die Meldung kommt bei jedem Neustart auch wenn noch ein Timer ansteht. Den Fall andersrum ohne anstehenden Timer hatte ich noch nicht. Da müsste ich FHEM einmal abends neu starten.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8495
  • eigentlich eher user wie "developer"
So eine richtige Idee zu der Fehlermeldung habe ich nicht, evtl. ist das eine veraltete Schreibweise. Fragt sich nur, warum das dann nur einmal angemeckert wird...

Vielleicht kannst du testweise Zeile 643 mal so ändern:
if (@switches == 0) {
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 159
Ich habe noch einmal den betreffenden Timer mit anderen Timern verglichen. Einziger Unterschied war das Attribut switchInThePast. Das hatte ich für den problematischen Timer testweise auf 1 gesetzt.

Ich habe das Attribut jetzt wieder gelöscht und die Fehlermeldung ist beim Neustart nicht wieder erschienen.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO