Autor Thema: Ankündigung+Testversion: Überarbeitung WeekdayTimer  (Gelesen 14385 mal)

Offline ToKa

  • Sr. Member
  • ****
  • Beiträge: 679
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #15 am: 22 Dezember 2020, 11:45:46 »
Hallo Beta-User,

danke für die weiteren Erläuterungen und Beispiele. Damit sollte ich zurechtkommen und werde die Version mal in meinem Testsystem ausprobieren.

Mit "eco" und "comfort" im weekprofile wäre natürlich dann perfekt, aber da wende ich mich mal an Risiko...

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
GreenWave: PowerNode 1 port
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Zipato Bulb 2

Offline ToKa

  • Sr. Member
  • ****
  • Beiträge: 679
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #16 am: 22 Dezember 2020, 18:07:33 »
Hallo Beta-User,

WDT_eventMap funktioniert wie beschrieben und der Z-Wave Thermostat lässt sich damit steuern. Viel mehr habe ich noch nicht getestet, aber es sind mir auch keine negativen Dinge (keine Fehler im log) aufgefallen.

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
GreenWave: PowerNode 1 port
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Zipato Bulb 2
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #17 am: 22 Dezember 2020, 18:15:51 »
Danke für die Rückmeldung. Ich habe das ohne größere Nutzung des Mappings im Echtsystem laufen und vorgestern mit der Vorversion auch schon mal nach Mitternacht einen FHEM-Neustart via systemd verursacht ::) ... (Der Neustart war jetzt letzte Nacht weg, und ich meine auch die Ursache gefunden/behoben zu haben, aber sowas _kann_ auch von Wechselwirkungen mit was anderem kommen...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline juemuc

  • Hero Member
  • *****
  • Beiträge: 1000
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #18 am: 22 Dezember 2020, 20:30:40 »
Auch bei mir nach dem ersten Test alles ok :-)

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

Offline Wardancer

  • Jr. Member
  • **
  • Beiträge: 97
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #19 am: 01 Januar 2021, 10:39:12 »
So,

kurzes Feedback von mir... ich hab die Testversion vor zwei Tagen eingespielt und nutze das mit WDT_sendDelay im Zusammenhang mit meinen Z-Wave-Thermostaten. Funktioniert genauso wie erwartet, keine Probleme oder Abstürze von FHEM....
läuft also!

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #20 am: 02 Januar 2021, 05:26:07 »
Vielen Dank für eure Rückmeldungen!

Im ersten Post gibt's nochmal eine aktualisierte Fassung. Bringt keine neuen features, aber unnötig gewordene Teile sind aus dem Code raus etc. pp..

Die Basis sollte da sein, um ggf. irgendwann die restlichen perlcritic-3-Punkte anzugehen.

Zwischenzeitlich bin ich am überlegen, ob ich dem WDT noch eine echte NotifyFn spendieren soll, mit der er direkt auf Verzögerungsbedingungen (Fensterkontakte) reagieren kann. Die Syntax dürfte nicht so einfach werden (device:reading:delay-regex:Reaktions-Wert), aber möglich wäre es. Besteht an sowas Interesse?

Grüße, Beta-User
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Wardancer

  • Jr. Member
  • **
  • Beiträge: 97
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #21 am: 02 Januar 2021, 09:30:32 »
Hi,

Du meinst, man würde dann wenn Fensterkontakt offen wäre, die Schaltung verzögern? Also ich brauch sowas nicht, da bei den ZWave-Thermostaten von mir die Temperatureinstellung das Ausschalten des Thermostats nicht aufhebt.
Oder verstehe ich das falsch?
Ich glaube übrigens noch eine Besonderheit gefunden zu haben:
Ich hab meine Thermostate alle aug Absenk um 23:59 gestellt. Wenn ich mit den Delays nicht über die Datumsgrenze komme scheint alles schön abgearbeitet zu werden, wenn ich aber mit den Delays über die 0-Uhr Grenze Rutsche scheinen die übrigen dann fast zeitgleich gesendet zu werden. Ich denke das liegt an dem Standard-Verhalten, das um 0:00 die Timer neu gesetzt werden, oder? Ich hab mir jetzt mal beholfen und einfach absenk auf 23:56 gesetzt. Ich schaue mal, wie es heute Abend ist.

Offline ToKa

  • Sr. Member
  • ****
  • Beiträge: 679
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #22 am: 02 Januar 2021, 09:45:08 »
Hallo Beta-User,

Ich nutze keine Fensterkontakte, zumal die Spirits das is angeblich selbst merken.

Viele Grüße
Torsten
RaspberryPi3 mit RaZberry2
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
GreenWave: PowerNode 1 port
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Zipato Bulb 2

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #23 am: 02 Januar 2021, 09:53:18 »
Es ist heute schon so, dass WENN ein Fensterkontakt angegeben ist (oder eine delay-Condition), dass dann die nächste Schaltung verzögert wird. Man muss allerdings das Ausschalten extern triggern und auch die Rückkehr zum "Normalmode" extern erledigen (zwischen den Schaltzeiten).
Die Frage wäre, ob man diese externen Regelungen nach intern verlagern sollte/könnte.

Und bitte bei allem berücksichtigen, dass es nicht nur ZWave auf der Welt gibt; ich meine, CUL_HM "tickt" da anders ;) , und wie ggf. die neueren ZigBee-Vertreter unterwegs sind, ist wieder eine "neue Welt". Die haben teils auch eine Fenster-Offen-Erkennung, aber es ist nicht gesagt, dass die bei "neuen Anweisungen" diese alle ebenfalls ignorieren, bis das Fenster wieder als geschlossen erkannt wird.
Aber dass  tmOff auch das Setzen einer andere desired-temp überdauert ist auf alle Fälle eine Info, die ich ggf. an anderer Stelle noch verwerten muss, dann ist vermutlich mein userReadings von hier überarbeitungsbedürftig (und tmOff (und ggf. noch mehr) muss auch noch irgenwie da rein)...

Und ja, man sollte bei den Verzögerungen darauf achten, dass man mit den Schaltzeiten etwas wegbleibt vom Tageswechsel. Falls da jemand Vorschläge für die Doku hat...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Wardancer

  • Jr. Member
  • **
  • Beiträge: 97
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #24 am: 08 Januar 2021, 08:28:48 »
Hi,

eine Sache ist mir auch noch aufgefallen:
Kann es sein, dass die Verzögerungen (warum auch immer) einen Neustart von FHEM nach der Kalkulation der Zeiten um Mitternacht herum nicht überleben?
Ich habe nämlich im moment das Phänomen, dass die Verzögerungen morgens beim Hochfahren der Heizung korrekt gezogen werden, abends aber bei der Absenkungen alle Befehle auf einmal geschickt werden. Ich kann mir das eigentlich nur damit erklären, dass ich ja fast täglich einen Update-Lauf mit anschließendem Neustart von FHEM mache...den mache ich meistens irgendwann am Vormittag, also nach dem Schalten der Körper auf warm..... beobachte das gerade noch ein wenig und mache heute mal keinen Neustart...

VG

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #25 am: 08 Januar 2021, 09:57:03 »
Müßte das nochmal im Code nachvollziehen, aber soweit ich das noch im Kopf habe, wird einfach bei jedem "eigentlichen" Schaltzeitpunkt die Verzögerung addiert und nicht zwischen erstem, x-tem und letztem Schaltzeitpunkt unterschieden, und die Ermittlung der Schaltzeitpunkte läuft auch im Grunde gleich ab, egal ob um Mitternacht oder untertägig (wegen Neustart, Topic-Änderung, ...).

Prüfen kannst du das, indem du
fheminfo timerList aufrufst. Da sollten die Timer dann lesbar aufgelistet sein. Bitte nochmal melden, falls es da Auffälligkeiten gibt.


@all:
Da das relativ stressfrei zu laufen scheint, werde ich das voraussichtlich am WE einchecken.

Bitte daher dringend alle mitlesenden "noch-Heating_Control"-Nutzer jetzt dann umsteigen, sonst wird das knirschen!
« Letzte Änderung: 08 Januar 2021, 09:58:51 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Wardancer

  • Jr. Member
  • **
  • Beiträge: 97
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #26 am: 08 Januar 2021, 11:49:10 »
Hi,

fheminfo timerList
nimmt er bei mir nicht.
Zu den Timern zum runterfahren der Thermostate hat er es vorgestern z.B. mit den entsprechenden Delays gemacht, daher vermute ich halt irgendwas, was ich hier unbewusst auslöse ...
Wenn ich die Timer checken kann wäre das grandios, ansonsten warte ich einfach auf heute Abend.


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #27 am: 08 Januar 2021, 11:53:55 »
sorry, "fhemdebug" müßte es statt "fheminfo" heißen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Wardancer

  • Jr. Member
  • **
  • Beiträge: 97
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #28 am: 08 Januar 2021, 12:37:38 »
So,

direkt mal ausgeführt, und folgenden Mischmasch gefunden:

2021-01-08 18:00:00.00000 WeekdayTimer_Update
2021-01-08 18:04:31.99000 Twilight_fireEvent
2021-01-08 18:44:16.00000 Twilight_fireEvent
2021-01-08 19:30:31.00000 WeekdayTimer_Update
2021-01-08 20:00:02.00000 SunSetShuttersAfterTimerFn
2021-01-08 20:00:02.00000 SunSetShuttersAfterTimerFn
2021-01-08 20:03:31.00000 WeekdayTimer_Update
2021-01-08 22:00:00.00000 DOIF_TimerTrigger
2021-01-08 22:00:00.00000 WeekdayTimer_Update
2021-01-08 22:00:00.00000 WeekdayTimer_Update
2021-01-08 22:00:00.00000 WeekdayTimer_Update
2021-01-08 22:01:28.00000 WeekdayTimer_Update
2021-01-08 22:45:00.00000 WeekdayTimer_Update
2021-01-08 23:00:00.00000 DOIF_TimerTrigger
2021-01-08 23:00:00.00000 DOIF_TimerTrigger
2021-01-08 23:00:00.00000 DOIF_TimerTrigger
2021-01-08 23:00:00.00000 WeekdayTimer_Update
2021-01-08 23:00:00.00000 WeekdayTimer_Update
2021-01-08 23:00:00.00000 WeekdayTimer_Update
2021-01-08 23:00:00.00000 WeekdayTimer_Update
2021-01-08 23:00:00.00000 WeekdayTimer_Update
2021-01-08 23:00:00.00000 WeekdayTimer_Update
2021-01-08 23:00:00.00000 DOIF_TimerTrigger
2021-01-08 23:04:00.00000 WeekdayTimer_Update
2021-01-08 23:57:07.00000 WeekdayTimer_Update
2021-01-08 23:57:17.00000 WeekdayTimer_Update
2021-01-08 23:58:09.00000 WeekdayTimer_Update
2021-01-08 23:59:00.00000 DOIF_TimerTrigger
2021-01-08 23:59:00.00000 DOIF_TimerTrigger
2021-01-08 23:59:00.00000 WeekdayTimer_Update
2021-01-08 23:59:00.00000 DOIF_TimerTrigger
2021-01-08 23:59:11.00000 WeekdayTimer_Update
2021-01-08 23:59:50.00000 WeekdayTimer_Update

eigentlich sollte der Timer um 18:00 um 53 Sekunden verzögert laufen ... Witzigerweise ist aber z.b. der Timer um 23:57:07 vollkommen korrekt, genauso, wie der um 23:57:17 .... dazwischen gibt es dann wieder die um 23:00:00 die ich gar nicht zuordnen kann, weil Freitags eigentlich die Thermostate in der Mehrzahl um 23:57 + Delay runtergefahren werden ... kann ich noch was zur Fehleranalyse tun? Soll ich die Attribute mal neu setzen?

VG

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Ankündigung+Testversion: Überarbeitung WeekdayTimer
« Antwort #29 am: 08 Januar 2021, 12:58:46 »
Hmm, ist von hier aus schwierig. Es macht auf alle Fälle Sinn, mal zu checken, ob die Attribute wirklich bei allen gesetzt sind.

Ansonsten müßte man etwas tiefer einsteigen und nachsehen, welcher Timer denn im Detail zu welchem WDT gehört. Irgendwo hatte ich mal Code gepostet, mit dem man da etwas mehr rausbekommt, die Funktion heißt "listInternalTimer()" und steckt in einer myutils...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

 

decade-submarginal