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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8544
  • 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: 8544
  • 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}

Online 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: 8544
  • 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}

Online 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

Online 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: 8544
  • 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}

Online 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: 8544
  • 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}

Online 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

 

decade-submarginal