57_Calendar.pm: Exchange Kalender verursacht 'HTTP Response Code 503'

[Dr. Boris Neubert]

Hallo,

ich dachte, zufällig zwischen 10 bis 30 Sekunden nach der Initialisierung oder Neuladen der Konfiguration macht der Kalender ein update. Ich sehe aber gerade, dass ich diese Funktion entfernt habe.

Bitte setze im Kalendermodul 57_Calendar.pm vor die Zeile 1851 ein # zum Auskommentieren der Fixierung auf 2 Sekunden. Die gesamte Subroutine sieht danach so aus:

Code Auswählen Erweitern

sub Calendar_Notify($$)
{
  my ($hash,$dev) = @_;
  my $name  = $hash->{NAME};
  my $type  = $hash->{TYPE};

  return if($dev->{NAME} ne "global");
  return if(!grep(m/^INITIALIZED|REREADCFG$/, @{$dev->{CHANGED}}));

  return if($attr{$name} && $attr{$name}{disable});

  # update calendar after initialization or change of configuration
  # wait 10 to 29 seconds to avoid congestion due to concurrent activities
  Calendar_DisarmTimer($hash);
  my $delay= 10+int(rand(20));

  # delay removed until further notice
  # $delay= 2;  <---------- HIER!

  Log3 $hash, 5, "Calendar $name: FHEM initialization or rereadcfg triggered update, delay $delay seconds.";
  InternalTimer(time()+$delay, "Calendar_Wakeup", $hash, 0) ;

  return undef;
}
Viele Grüße
Boris

[JudgeDredd]

Hallo Boris,

nach der Auskommentierung läuft es nun auch nach Neustart von FHEM mit allen Kalendern.
Super und vielen Dank, das Du es Dir mal angesehen hast.

Frage:
Checkst Du das ins SVN ein oder soll ich es auf meine ToDo nehmen und es nach einem ModulUpdate händisch machen ?

Gruß,
JudgeDredd

[Dr. Boris Neubert]

Hurra!

Ich habe es eingecheckt. Ab morgen kommt es per Update für alle.

Viele Grüße
Boris

[JudgeDredd]

Hallo Boris,

leider muss ich das Thema doch noch mal aufgreifen.

Ich nutze aktuell 5 Kalender des gleichen Exchange. Grundsätzlich funktioniert auch alles, es kommt aber alle paar Tage vor das mindestens zwei Kalender das gleiche Delay zugewiesen bekommen und wieder auf den 503er laufen.
Ein Vorschlag wäre (falls es Du es auch als sinnvoll erachtest und es nicht zu aufwändig ist), ein Default-Delay als optionalen Parameter im Define mitzugeben.
Dann könnten so komische Leute wie ich , die 5 oder mehr Kalender haben die Verzögerung manuell in gewissen Abständen setzen. Alternativ könnte man auch den Zufallsbereich vergrößern, aber dann sinkt ja nur die Wahrscheinlichkeit.

Gruß,
JudgeDredd

[Dr. Boris Neubert]

Hallo,

bitte teste mal die angehängte Datei. Neues Attribut delay.

Viele Grüße
Boris

[JudgeDredd]

Du bist aber von der ganz fixen Sorte
Datei werde ich testen, vermute aber, das es durch ein Attribut nicht verhindert werden kann.
Nach meinem Verständnis wird beim FHEM Neu-Start erst das DEFINE abgearbeitet und die Attribute greifen erst nach dem ersten Update.

Aber ich werde es auf jeden Fall testen und gebe Feedback ...

[Dr. Boris Neubert]

Die Aktualisierung des Kalenders wird (erst) getriggert, FHEM vollständig initialisiert ist. Dann sind die Attribute geladen. Die Aktualisierung findet nicht zum Zeitpunkt des DEFINE statt.

[JudgeDredd]

Hallo Boris,

der erste Testtag ist nun fehlerlos überstanden 
Ich habe meine Kalender im 5 Sekunden Abstand konfiguriert. Danach ca. 5 "shutdown restart" und alle ohne Fehler.
Auch die Nacht nach meinen maintanance Skripten verlief geräuschlos.
Ich würde mal sagen ... das sieht gut aus.

Dann nochmals vielen Dank für die prompte und kompetente Unterstützung.

Gruß,
JudgeDredd

[Dr. Boris Neubert]

eingespielt, wird morgen ab ca 8 Uhr per Update verteilt

Danke für Deinen Test!

[JudgeDredd]

Hallo Boris und auch andere Helferlein,

es gab bei diesem Modul ja mal den kleinen Bug mit dem Delay, der auch per 20.05.2020 behoben war.

Leider muss ich aber heute dieses Thema nochmal ansprechen.
Ich habe wieder seit einiger Zeit (ca. ende letzten Jahres) das Delay Problem erneut.

Mangels Zeit, habe ich es bis heute erstmal ignoriert.
Da aber durch die Behebung eines anderen Bugs Events fehlen, so dass meine Notify Logiken nicht mehr funktionieren, muss und ich nun doch mal in die Analyse gehen.

Wenn ich den Kalender auf verbose 5 stelle, sollte doch gem. SourceCode Zeile 1879

Code Auswählen Erweitern

Log3 $hash, 5, "Calendar $name: FHEM initialization or rereadcfg triggered update, delay $delay seconds.";
Die Info über die Anzahl der Verzögerungssekunden im Log auftauchen.

Diese fehlt aber. Was mich zu der Frage führt, wie weit die Modulfunktion

Code Auswählen Erweitern

sub Calendar_Notify($$)
beim INIT ausgeführt wird.

Nach meinen Bescheidenen Kenntnissen, kehrt er nach dieser Zeile aus der Sub wieder zurück:

Code Auswählen Erweitern

return if(!grep(m/^INITIALIZED|REREADCFG$/, @{$dev->{CHANGED}}));

Wäre es möglich dies mal durch einen anderen Nutzer des Moduls zu bestätigen und ggf. durch Boris zu korrigieren ?

Gruß,
JudgeDredd

[Dr. Boris Neubert]

Mangels Zeit, habe ich es bis heute erstmal ignoriert.
Da aber durch die Behebung eines anderen Bugs Events fehlen, so dass meine Notify Logiken nicht mehr funktionieren, muss und ich nun doch mal in die Analyse gehen.

Es fehlen nur Termine jenseits des Horizonts, also diejenigen, die zum Zeitpunkt des letzten Reloads oder Neustarts von FHEM weiter als min(400d; cutoffLaterThan) in der Zukunft liegen. Dem kann mit einem at-getriebenem Reload alle 30d abgeholfen werden.

Wenn ich den Kalender auf verbose 5 stelle, sollte doch gem. SourceCode Zeile 1879

Code Auswählen Erweitern

Log3 $hash, 5, "Calendar $name: FHEM initialization or rereadcfg triggered update, delay $delay seconds.";
Die Info über die Anzahl der Verzögerungssekunden im Log auftauchen.

Habe ich gerade versucht nachzuvollziehen, aber nur die Korrektheit bei mir bestätigt. Mit

Code Auswählen Erweitern

attr Calendar verbose 5 bekomme ich die Meldung im Log:

Code Auswählen Erweitern

2021.03.23 19:06:07 5: Calendar Calendar: FHEM initialization or rereadcfg triggered update, delay 14 seconds.


[JudgeDredd]

Hallo Boris,

Habe ich gerade versucht nachzuvollziehen, aber nur die Korrektheit bei mir bestätigt. Mit

Code Auswählen Erweitern

attr Calendar verbose 5 bekomme ich die Meldung im Log:

Code Auswählen Erweitern

2021.03.23 19:06:07 5: Calendar Calendar: FHEM initialization or rereadcfg triggered update, delay 14 seconds.


Ich fürchte, da muss ich wohl rurückrudern. 
Du hast Recht, den Logeintrag habe ich auch, er hat sich nur etwas zwischen anderen Zeilen als einzelner versteckt.

Das ändert allerdings nichts daran, das mehrere Kalender trotz unterschiedlicher delays versuchen zur gleichen Zeit zu aktualisieren.
Ich werde aber hier erstmal noch selbst nachforschen, bevor ich hier resourcen von anderen binde, die bestimmt besseres zu tun haben.

Das andere Kalenderphänomen das erst seit kurzem auftritt ist, das ich keine "modeUpcoming"-Events mehr bekomme.
Wenn ich bspw.:

13:45 -	neuen Termin im Exchange anlegen mit Beginn um 14 Uhr
13:50 -	FHEM Kalenderupdate
14:00 -	2021-03-24 14:00:00 Calendar cal_KALENDER changed: 040000008200E00074C5 ... CAED498F17D323FA7E21D0 start 2021-03-24 14:00:00 Calendar cal_KALENDER start: 040000008200E00074C5 ... CAED498F17D323FA7E21D0

Dann war es bisher so, das zwischen Kalenderupdate und Start des Termins ein "modeUpcoming"-Event erzeugt wurde.
Das scheint nun nicht mehr so zu sein.

Sagt Dir das spontan etwas, oder ist das auch eher ein Problem das nur auf meiner kleinen Insel existiert ?

[JudgeDredd]

UPDATE:

Das andere Kalenderphänomen das erst seit kurzem auftritt ist, das ich keine "modeUpcoming"-Events mehr bekomme.

Nach etwas forschen und erneutes lesen der Modul-Dokumentation, habe ich das:

Code Auswählen Erweitern

hasModeReadings
Set to 1 to use the obsolete mode readings.
entdeckt.

Das scheint recht neu zu sein und ist an mir wohl vorübergegangen.
Nach setzen auf "1", sind die mode...-Events wieder da.

Wie ist denn das "obsolete" zu verstehen ? Wird es evtl. in künftigen Modulupdates keine Möglichkeit mehr geben, mode...-Events zu erzeugen ?
Das wäre sehr schade, denn ich nutze diese Events zur Erzeugung von ATs zur Erinnerung 5 Minuten vor Beginn.

[Dr. Boris Neubert]

Hallo,

bereits vor zwei Jahren wurden die mode-Readings für tot erklärt. Jetzt habe ich die Ankündigung wahr gemacht, sie zu entfernen, und war so generös, das Attribut zu spendieren, sie wiederzuerwecken. 

Deine Aufgabe lässt sich leichter über ein Notify auf ein alarm-Event lösen und dieses kann, sofern nicht im Kalender, über ein onCreate-Plugin zugefügt werden. Dieser Standardanwendungsfall ist in der Commandref beschrieben.

Viele Grüße
Boris

[JudgeDredd]

Hallo Boris,

bereits vor zwei Jahren wurden die mode-Readings für tot erklärt. Jetzt habe ich die Ankündigung wahr gemacht, sie zu entfernen

Du bist aber auch echt Konsequent 

... und war so generös, das Attribut zu spendieren, sie wiederzuerwecken. 

Dank sei dem generösen Spender.

Deine Aufgabe lässt sich leichter über ein Notify auf ein alarm-Event lösen

Alarme im Kalender hasse  ich wie die Pest. Wenn alle Devices anfangen zu bimmeln 

und dieses kann, sofern nicht im Kalender, über ein onCreate-Plugin zugefügt werden.

Das habe ich gerade mal überflogen und schau mal, das ich das zeitnah umsetze und meine Notifys anpasse.
Ich hoffe Dein Drang zur endgültigen Entfernung ist noch etwas aushaltbar.

Gruß,
JudgeDredd