Ankündigung+Testversion: Überarbeitung WeekdayTimer

[ToKa]

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

[ToKa]

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

[Beta-User]

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

[juemuc]

Auch bei mir nach dem ersten Test alles ok

Viele Grüße
Jürgen

[Wardancer]

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!

[Beta-User]

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

[Wardancer]

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.

[ToKa]

Hallo Beta-User,

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

Viele Grüße
Torsten

[Beta-User]

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

[Wardancer]

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

[Beta-User]

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

Code Auswählen Erweitern

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!

[Wardancer]

Hi,

Code Auswählen Erweitern

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.

[Beta-User]

sorry, "fhemdebug" müßte es statt "fheminfo" heißen...

[Wardancer]

So,

direkt mal ausgeführt, und folgenden Mischmasch gefunden:

Code Auswählen Erweitern

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

[Beta-User]

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