Vermeidung von einer Vielzahl von Logeinträgen bei fhem-restart erwünscht

[Homalix99]

Hallo,

zur Rollosteuerung habe ich das WeekdayTimer (WDT) Modul eingesetzt. Ursprüngliche Def. ohne Auffälligkeiten.

Code Auswählen Erweitern


define AutoJalousie_AZ WeekdayTimer Rollo_1.OG_Ost_l {sunset_abs(-1500,"16:20","22:00")}|down !$we|{sunrise_abs(+1400,"06:25","08:30")}|up $we|08:00|up { \
fhem("set Rollo_AZ_l %");;\
fhem("set Rollo_AZ_r %");;\
}



Modifikation: Lichtabhängige Steuerung unter Beibehaltung der WDT

Code Auswählen Erweitern


define AutoJalousie_AZ WeekdayTimer Rollo_1.OG_Ost_l {Rollo_down()}|down !$we|{Rollo_up_WT()}|up $we|{Rollo_up_WE()}|up { \
fhem("set Rollo_AZ_l $EVENT");;\
fhem("set Rollo_AZ_r $EVENT");;\
}


Beim Fhem-init werden ja
1. zunächst die benötigten Fhem-Module geladen, dann
2. die 99:Utils, in der sich die Routinen für die lichtabhänginge Steuerung, sowie die Subs (a), welche die berechteten Öffnungs/Schließzeiten aus Dummies lesen und als return Werte den WDT zur Verfügung stellen, befinden.
3. Dann wird die fhem.cfg geladen, in der sich die Dummies für die Öffnungs/Schließzeiten, sowie ein notify (b), welches getriggert wird, sobald sich der Wert von den Dummies Öffungs.-bzw. Schießzeiten ändern (abh. von Lichtstärke an den Sensoren).
4. Zum Schluß werden erst die abgespeicherten Werte aus der fhem.save geladen.

Problem:
Sobald die Konfig. (unter Punkt 3) geladen wird, versucht der WDT, die switch-Zeitpunkte zu laden, die ja zu diesem Zeitpunkt noch nicht zur Verfügung stehen.
Sieht dann ellenlang im log so aus:

Code Auswählen Erweitern


2018.10.20 20:01:03.084 1: [AutoJalousie_AZ] invalid time <???> HH:MM[:SS]
2018.10.20 20:01:03.085 3: Rollo_down(): WDT-Aktualisierung, Schliesszeit: ???
2018.10.20 20:01:03.086 1: [AutoJalousie_AZ] invalid time <???> HH:MM[:SS]
2018.10.20 20:01:03.087 3: Rollo_down(): WDT-Aktualisierung, Schliesszeit: ???
2018.10.20 20:01:03.088 1: [AutoJalousie_AZ] invalid time <???> HH:MM[:SS]
2018.10.20 20:01:03.089 3: Rollo_down(): WDT-Aktualisierung, Schliesszeit: ???
2018.10.20 20:01:03.090 1: [AutoJalousie_AZ] invalid time <???> HH:MM[:SS]
2018.10.20 20:01:03.091 3: Rollo_down(): WDT-Aktualisierung, Schliesszeit: ???
2018.10.20 20:01:03.092 1: [AutoJalousie_AZ] invalid time <???> HH:MM[:SS]
2018.10.20 20:01:03.093 3: Rollo_down(): WDT-Aktualisierung, Schliesszeit: ???
2018.10.20 20:01:03.094 1: [AutoJalousie_AZ] invalid time <???> HH:MM[:SS]
2018.10.20 20:01:03.095 3: Rollo_down(): WDT-Aktualisierung, Schliesszeit: ???
2018.10.20 20:01:03.096 1: [AutoJalousie_AZ] invalid time <???> HH:MM[:SS]
....


Wie kann ich das vermeiden, hat da Jemand eine Idee?
Wenn ich fhem kontrolliert reseten würde, könnte ich auf global:SHUTDOWN reagieren und zuvor die WDT disablen, aber das kommt selten vor, Hochlauf eher nach einem Absturz von fhem.

Wenn fhem oben ist, funktioniert alles normal.

Für Anregungen wäre ich sehr dankbar.



Anhang zur Erläuterung der involvierten Routinen:
(a) Routinen, welche der WDT aufruft, um sich die neuen Öffnungs/Schließzeiten zu laden, sobald der WDT durch das notify (b) dazu angestoßen wird.

Code Auswählen Erweitern


sub Rollo_up_WE(){   # wird von den WDT fuer die Auto-Rollosteuerung aufgerufen
  my $opentime_WE = Value("Oeffnungszeit_WE");
  Log3 undef, 4,"Rollo_up_WE(): WDT-Aktualisierung, Oeffnungszeit_WE: $opentime_WE";
  return($opentime_WE);
}

sub Rollo_up_WT(){ # wird von den WDT fuer die Auto-Rollosteuerung aufgerufen
  my $opentime_WT = Value("Oeffnungszeit_WT");
  Log3 undef, 4,"Rollo_up_WT(): WDT-Aktualisierung, Oeffnungszeit_WT: $opentime_WT";
  return($opentime_WT);
}

sub Rollo_down(){ # wird von den WDT fuer die Auto-Rollosteuerung aufgerufen
  my $closetime = Value("Schliesszeit");
Log3 undef, 4,"Rollo_down(): WDT-Aktualisierung, Schliesszeit: $closetime";
return($closetime);
}


(b) Notify zum Aktualisieren der Öffnungs/Schießzeiten in den WDT:

Code Auswählen Erweitern


define ntf_WDT_update_OT notify Oeffnungszeit_.*:state:.* {\
WeekdayTimer_SetParm("AutoJalousie_AZ");;\

fhem("attr AutoJalousie_AZ switchInThePast 0");; # durch setzen von switchInThePast = 0, werden die WDT mit der gültigen Zeit geladen.\

}\


[CoolTux]

Beim Fhem-init werden ja
1. zunächst die benötigten Fhem-Module geladen, dann
2. die 99:Utils, in der sich die Routinen für die lichtabhänginge Steuerung, sowie die Subs (a), welche die berechteten Öffnungs/Schließzeiten aus Dummies lesen und als return Werte den WDT zur Verfügung stellen, befinden.
3. Dann wird die fhem.cfg geladen, in der sich die Dummies für die Öffnungs/Schließzeiten, sowie ein notify (b), welches getriggert wird, sobald sich der Wert von den Dummies Öffungs.-bzw. Schießzeiten ändern (abh. von Lichtstärke an den Sensoren).
4. Zum Schluß werden erst die abgespeicherten Werte aus der fhem.save geladen.

Das ist falsch!!!

[Homalix99]

ok, wie dann?

[CoolTux]

die 99er werden immer als erstes geladen. Dann wird die fhem.cfg eingelesen und die dort enthaltenen Definitions abhängigen Module werden geladen (im Zuge des define). Danach wird das state File und noch bisschen mehr eingelesen.
Bei configDB Benutzung ist es ähnlich nur bezogen auf die Datenbanktabellen.

[rudolfkoenig]

Falls Routinen die Daten aus fhem.save benoetigen, dann sollten sie per notify/DOIF nach dem global:INITIALIZED Event gestartet werden.
Man kann auch die globale Variable $init_done abfragen, diese wird nach dem Einlesen von fhem.save auf 1 gesetzt.

[betateilchen]

oh, ein Popcorn Thread...

[Damian]

Falls Routinen die Daten aus fhem.save benoetigen, dann sollten sie per notify/DOIF nach dem global:INITIALIZED Event gestartet werden.
Man kann auch die globale Variable $init_done abfragen, diese wird nach dem Einlesen von fhem.save auf 1 gesetzt.

Beim DOIF-Modul braucht sich der User nicht um diese Dinge zu kümmern, denn DOIF nimmt erst dann die Arbeit auf, nachdem $init_done gesetzt wird. Abgesehen davon sind selbst definierte Perl-Funktionen im eigenen DOIF-Package gekapselt.