Weekdaytimer nach Delay wegen geöffnetem Fenster kein neuer Wert im FHT-Thermost

Begonnen von dlehmann69, 05 Oktober 2019, 12:22:49

Vorheriges Thema - Nächstes Thema

Beta-User

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

Beta-User

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

dlehmann69

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 6.0 Development auf Ubuntu 20.04 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

Beta-User

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

dlehmann69

Also hier die beiden Internal "NR"

WDT Schlafzimmer 321
zugehöriger Fenstersensor 10

Der WDT hat also die Größere.
FHEM 6.0 Development auf Ubuntu 20.04 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

dlehmann69

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 6.0 Development auf Ubuntu 20.04 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

Beta-User

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:
Zitat von: dlehmann69 am 15 November 2019, 07:46:46
[HZT_Schlafen] no switches to send, due to possible errors.
Kann es sein, dass an dem Tag keine Timer anstanden?
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

dlehmann69

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 6.0 Development auf Ubuntu 20.04 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

Beta-User

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

dlehmann69

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 6.0 Development auf Ubuntu 20.04 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