[gelöst] Probleme mit WeekdayTimer

Begonnen von JWRu, 01 Oktober 2019, 23:16:25

Vorheriges Thema - Nächstes Thema

JWRu

ZBox; RasPi 3B; RasPi Zero W; Homematic; Z-Wave; EnOcean, Shelly; DuoFern; Oregon-Sensoren; TFA-Sensoren; Steuerung Viessmann-Heizung; Arduinos für Strom-, Wasser-, Gaszähler, Rauchmelder und FI-Schutzschalter

Beta-User

Thx. Auch hier die Info:

Durch den update, den ich eben ins svn geschubst habe, ist das ausdrücklich nicht behoben; der bringt nur etwas mehr Transparenz dahingehend, was das IsWe()-Umfeld so an Ergebnis liefert, verstetigt das intern für den einzelnen Tag und initialisiert die Timer etwas anders als bisher (das waren die Änderungen im Parallelthread) und ergänzt HMCCUDEV als FK-Typ (das war der eigentliche Anlaß).
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

Lelle

Hallo,

zur Info: Bei mir habe ich das gleiche Problem. Die WeekdayTimer Devices initialisieren nach einem Restart korrekt und setzen die Timer. (Den Restart habe ich jeden Nacht geplant.) Die ersten Timer funktionieren auch problemlos. Mir scheint, dass dann der aber der letzte Timer am Tag nicht mehr funktioniert. Keine Einträge im FHEM Log - als ob der Timer gelöscht wurde. Allerdings ist dies auch nicht immer durchgängig so. Ich habe trotz intensiver Beobachtung noch nicht herausgefunden, wann es für welches Device funktioniert und wann nicht. Mehrheitlich geht es aber nicht.


Beta-User

Hmm, irgendwie habe ich weiter keinen richtigen Anpack zu dem ganzen...

Lelle:
Irgendein Anhaltspunkt wäre hilfreich (ich nehme auch wilde Spekulationen entgegen...).
Leider scheint es auch nicht mit Zeilenumbrüchen in der DEF zu tun zu haben (siehe https://forum.fhem.de/index.php/topic,105272.msg992401.html#msg992401). Dafür kommt vermutlich demnächst auch wieder ein update (das euer Problem hier aber leider wieder nicht lösen wird).

Grundsätzlich aber die Frage: Muß ein Restart jede Nacht sein? Mein Server läuft in der Regel durch, wenn ich nicht grade irgendwas teste, und das mit dem Memory leak (da gab es einen Mega-Thread zu) scheint auch einigermaßen gelöst zu sein...
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

JWRu

Mein Server läuft durch. Ich habe den Eindruck, dass wenn man einen Timer definiert oder die Definition ändert (z.B. die Zeiten) dieser an diesem Tag einwandfrei funktioniert. Erst an den darauffolgenden Tagen wird die letzte Schaltung nicht mehr ausgeführt.
ZBox; RasPi 3B; RasPi Zero W; Homematic; Z-Wave; EnOcean, Shelly; DuoFern; Oregon-Sensoren; TFA-Sensoren; Steuerung Viessmann-Heizung; Arduinos für Strom-, Wasser-, Gaszähler, Rauchmelder und FI-Schutzschalter

Beta-User

Das ist echt irritierend, denn eigentlich sehe ich keinen wirklichen Unterschied, auf welchem Weg man die Timer generiert (ob durch die Mitternachtsroutine oder durch das Laden oder durch "set enable". Aber ich schau's mir nochmal an, irgendwo muß das ja herkommen.

Völlig doof ist, dass u.a. Lelle sporadische Ausfälle von einzelnen Timern zu haben scheint. Da ist es noch schwerer, das zu lokalisieren (jedenfalls für mich, aber evtl. hat ja jemand anders eine Idee?).
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

Lelle

Es ist etwa 19:30 Uhr und ich habe mir einen der WeekdayTimer angeschaut. Dieser hätte eigentlich um 17:00 Uhr den Thermostat auf 12 Grad runtersetzen sollen. Aktueller Status des Devices ist Folgender. Bitte die Readings in rot beachten:

defmod Heizung.AZ.Profil.Arbeiten WeekdayTimer AZ.Thermostat 12345|06:45|21 12345|17:00|12
attr Heizung.AZ.Profil.Arbeiten WDT_Group former_HC
attr Heizung.AZ.Profil.Arbeiten WDT_delayedExecutionDevices 1
attr Heizung.AZ.Profil.Arbeiten commandTemplate set $NAME thermostatSetpointSet $EVENT
attr Heizung.AZ.Profil.Arbeiten devStateIcon aktiv:10px-kreis-gruen undef:10px-kreis-gelb inaktiv:10px-kreis-grau
attr Heizung.AZ.Profil.Arbeiten disable 0
attr Heizung.AZ.Profil.Arbeiten group Heizung
attr Heizung.AZ.Profil.Arbeiten icon sani_heating_timer
attr Heizung.AZ.Profil.Arbeiten room Arbeitszimmer,Heizung,ZWave
attr Heizung.AZ.Profil.Arbeiten stateFormat { my $curVal = ReadingsVal("Heizung.AZ.Profil.Arbeiten", "disabled", "undef");;;;;;;; $curVal =~ s/.*0.*/aktiv/;;;;;;;; $curVal =~ s/.*1.*/inaktiv/;;;;;;;; return $curVal }
attr Heizung.AZ.Profil.Arbeiten verbose 1

setstate Heizung.AZ.Profil.Arbeiten aktiv
setstate Heizung.AZ.Profil.Arbeiten 2019-11-13 06:45:00 currValue 21
setstate Heizung.AZ.Profil.Arbeiten 2019-11-13 00:01:30 disabled 0
setstate Heizung.AZ.Profil.Arbeiten 2019-11-13 06:45:00 nextUpdate 2019-11-13 17:00:00
setstate Heizung.AZ.Profil.Arbeiten 2019-11-13 06:45:00 nextValue 12

setstate Heizung.AZ.Profil.Arbeiten 2019-11-13 06:45:00 state 21


Für mich sieht das genau danach aus, was auch passiert ist - nämlich nichts. Der Timer hat schlicht seinen Einsatz um 17:00 verpennt. Auch im Log ist für den Zeitpunkt nichts zu sehen (wobei aktuell keinen debug mode fahre).

Beta-User

#37
Hmm, hast du auch noch ein list? (Da stehen auch die Profile usw. drin).

FHEM-uptime ist > 20h? (Also "Mitternachts-Aktualisierung" ist durch?)

Hast du noch (je) einen Timer, der entweder
- noch eine Schaltung hat oder
- einen ausdrücklichen Schaltbefehl hinten angefügt hat?

Ich habe die Murmel "leider" heute morgen neu gestartet, das könnte das Ergebnis verfälschen. Jetzt habe ich mir mal alle Timer anzeigen lassen und zu meiner Überraschung festgestellt, dass nur einer der WDT einen laufenden "midnight-update-timer" hat (es sollten nach meinem Verständnis eigentlich alle sein, mindestens aber die, deren letzte Schaltzeit durch ist). Könnte darauf deuten, dass es evtl. Wechselwirkungen gibt, die mir bisher verborgen waren. Eventuell könnt ihr aber auch mal versuchen, etwas tiefer mit zu graben:

Befehl für die Kommandozeile - gibt alle laufenden InternalTimer aus, geordnet nach Schaltzeitpunkt:
{listInternalTimer("t")}
{listInternalTimer("f")}
Dazu braucht man eine passende myUtils-Routine aus dem Anhang (am einfachsten den Anhang nehmen und ins Modul-Verzeichnis mit den richtigen Rechten legen, da ist auch eine cref drin, Anzeige ohne commandref-Aktualisierung mit help.).
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

Lelle

Muss ich auf morgen verschieben. Sorry.

Beta-User

#39
Zitat von: Lelle am 13 November 2019, 20:22:00
Muss ich auf morgen verschieben. Sorry.
Kein Ding...

Habe übrigens festgestellt, dass der "listInternalTimer"-Code schuld war, dass nicht alles zu sehen war  >:( : Mit dem "t"-Argument wird nur der letzte Timer gelistet, der zu einem bestimmten Zeitpunkt ausgeführt werden soll... Besser "f" verwenden (oder gar nichts), da (mit "f" kommen dann auch alle zu einem Gerät gehörenden Timer nacheinander).
(Sorry, habe den Code auch nur woanders geklaut, Quelle ist angegeben...)

(Damit bin ich jetzt leider wieder kein Schrittchen weiter).

Frage: Kann es sein, dass die nicht funktionierenden WDT alle solche sind, die in der Vergangenheit schalten sollten (also entweder als Heizung erkannt werden oder das entsprechende Attribut aktiviert? (Dann müßte der Fehler tendenziell in Zeilen 702ff entstehen?)
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

#40
So, anbei eine aktualisierte Version mit der Bitte um Test...

Kann aber sein, dass da gewaltig was schiefgeht und/oder das nur das Problem der "doppelten timer" aus dem anderen Thread löst, bitte zur Sicherheit Kopie der aktuellen update-Version bereithalten.

Gruß, Beta-User
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

Lelle

Erstmal anbei nochmals - aktuell - die Device Definition und das List. Ist die selbe Situation wie gestern: Die Schaltung wurde nicht vollzogen. Bei diesem Profile ist das fast immer der Fall ...

Zweitens habe ich das 99_myAdvancedUtils.pm in das FHEM Verzeichis kopiert und die Permissions/Owner entsprechend gesetzt. Leider bekomme ich die Routine listInternalTimer nicht zum Laufen. Fehler: Undefined subroutine &main::listInternalTimer called at (eval 10590) line 1.
Vermutlich habe ich etwas nicht beachtet ...  :-[ Bin leider nicht so tief drin ...

Drittens habe ich das neue WeekdayTimer Modul mal noch nicht eingespielt, weil ich erstmal die listInternalTimer Routine laufen lassen wollte.

Und zuletzt versuche ich noch ein Teil deiner Fragen zu beantworten :-) Meine WeekdayTimer Devices sind alle auf Thermostate bezogen. Sie sind alle wie Heizung.AZ.Profil.Arbeiten zusammengebaut, also [Wochentage]|[Uhrzeit]|[Temperatur] und ggf. weitere solche Einträge. Es gibt Profile, die mehrfach am Tag schalten. Z.B. Heizung.Kueche.Profil.Schule (siehe Anhang). Aber auch für dieses Profil gilt, dass der letzte Eintrag ***oft*** nicht schaltet. (Aktuell ist dieses Profil disabled, kann ich aber wieder einschalten.)

Weiß nicht, ob das nun weiterhilft ....

Beta-User

Dass das mit dem InternaltTimer-list-Code nicht wollte, hat vermutlich damit zu tun, dass FHEM die erst laden muss. Dazu am einfachsten entweder via FHEMWEB editieren (oder FHEM neu starten was wir aber grade nicht wollten...).

Habe grade die Testversion auch im Produktivsystem eingespielt, das sieht erst mal plausibel aus, was man da an timern sieht (nach "... WDT_parms all"). Offen ist aber noch, ob das auch am WE paßt. Wenn ja, kommt bald ein update :) .

Kann es sein, dass die die schalten alle "einfache" WDT sind, die kein WE kennen (oder zumindest an allen Wochentagen (mit !$we usw.)  durchlaufen)?
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

Lelle

anbei erstmal der ListInternalTimer Output

Lelle

So, habe nun das aktualisierte WDT Modul aktiviert und den dazu noch den nächtlichen Restart mal deaktiviert. Nun mal warten und hoffen :-)