Trigger-Parameter "check" liest ics-Datei neu ein statt nur auszuwerten
ammawel opened this issue · comments
Wird in den Datenpunkt ical.x.trigger der String "check" geschrieben, wird entgegen der Anleitung die ics-Datei erneut eingelesen.
Ein Trennen der Internetverbindung führt entsprechend im log zu einer Fehlermeldung (warn), erst danach wird auf die Daten aus dem Cache zugegriffen.
Bei aktivierter Internetverbindung sind Events, die zwischen den regulären Einlesezeitpunkten im Online-Kalender eingegeben wurden, vorhanden. Die ics wird also tatsächlich bei jedem "check" neu gelesen und nicht nur ein vermeintlicher Einlesevorgang im log vermerkt.
Beabsichtigtes Verhalten:
Die ics-Datei wird zweimal am Tag eingelesen, da es wenig Änderungen gibt, die Termine sollen aber jede Minute ausgewertet werden, da die Datenpunkte von ical nur bei aktivem Adapter gesetzt werden.
Same here :-(, still existing in V1.14.3
Der Trigger wird mit der nächsten Version komplett entfernt: #662
Das wäre ein neuer Feature request. Ich bin auch ehrlich das ich gerade nicht verstehe was da in der Doku steht mit diesen zwei Variablen ... Auch der Name der Variable ist was ganz anderes ans der ".trigger" state ...
@klein0r Dneke da muss die Doku mit aufgeräumt werden. vllt macht es ja wirklich sinn eine. solchen "check" state dann "sauber" einzuführen der immer das gecachte file nutzt und nicht neu requested... (ausser cache file ist nicht da)
@Apollon77 check hat noch nie funktioniert (zumindest laut Readme und dem, was ich im Code gefunden hatte). Das habe ich zuletzt entfernt:
Lines 24 to 26 in 1a2182f
Das dachte ich mir fast. ;-). Also wäre das hier eher ein Feature Request ;-)
Ja, wobei die Frage ist wie der umzusetzen wäre, wenn das subscribe-Feature in der io-package mit js-controller 6.x nicht mehr exisitiert.
Soll ich das als Feature Request eröffnen? Wie das implementiert wird, ist mir egal, könnte ja auch als Konfiguration im Adapter eingestellt werden: der Adapter läuft immer, zu Zeitpunkt (oder Intervall) x, y, z wird der (oder mehrere) Kalender neu eingelesen, zu Zeitpunkten (bzw. Intervall) a, b, c, d werden die Events bzgl. Start/Ende-Zeit ausgewertet und die DPs aktualisiert.
Wie sieht denn derzeit die Good Practice aus, um zeitnah auf Events zu reagieren?
@klein0r Ahhhh ...hm ... ja da hast Du recht. wir sind immer noch scheduled ... Damit ... wäre ich höchstens dabei zu sagenman fügt noch eine "cache zeit" hinzu für den remote content und es wird darüber gesteuert wann neu geladen wird. Nicht das gleiche aber vllt "gut genug".
Oder ein state den man setzt und der beim start ausgewertet wird "check=true" und nach einem run immer zurückgesetzt wird. Damit wäre es ein schreibe check in den state und setzte dann alive azf true um es einmal so zu verarbeiten
@Alex71w Was genau ist denn dein Usecase? Geht es darum nicht immer zu laden oder worum gehts?
@Alex71w Was genau ist denn dein Usecase? Geht es darum nicht immer zu laden oder worum gehts?
Hallo, da ich das Ganze oben losgetreten habe, antworte ich auch mal.
Mir geht es darum, bei hinreichender Zeit-Genauigkeit der Datenpunkte nicht immer die ics-Datei neu laden zu müssen.
Bei einer Genauigkeit von 5 Minuten müsste z.Zt. die Datei 288 mal pro Tag geladen werden, bei minütlicher Genauigkeit 1440 mal - auch wenn sie sich nicht geändert hat. Da steigt der ein oder andere Server aus.
Mir würde es reichen, die Datei in einem angebbaren Zeitintervall - alle x Stunden - oder zu bestimmten Zeiten zu laden, ein- bis zweimal pro Tag würden mir wegen wenig aktueller Änderungen reichen. Die Aktualisierung der Ereignis-Datenpunkte sollte allerdings möglichst genau sein, z.B. auf die Minute passen.
Vielen Dank für eure Mühen!
Da steigt der ein oder andere Server aus.
Das bisschen Logik verkraftet jedes System ohne Probleme. Last ist hier kein Argument.
Ich frage mich, wie die anderen User des Adapters vorgehen? (Nicht rhetorisch sondern ernsthaft gemeint)
Das hier ist ein sog. schedule-Adapter, welcher nicht dauerhaft läuft, sondern nach einem Zeitplan immer wieder gestartet wird. Diesen Zeitplan kann man auf der Instanz hinterlegen (kennst Du ja sicher). Möchte man es genauer haben, betreibt man daemon-Adapter, welche eben dauerhaft laufen und jederzeit auf Ereignisse reagieren können.
Mir kommt unser UseCase nicht sonderlich exotisch vor :-)
Naja solche Logiken minutengenau über einen Kalender bei Google laufen zu lassen, ist schon exotisch finde ich. Dort habe ich nur Termine liegen, welche länger laufen. Für zeitkritische Themen gibt es ja viel bessere Lösungen, welche auch lokal laufen (wie den JavaScript-Adapter oder den Fullcalendar-Adapter).
Der iCal-Adapter war dafür (afaik) nie konzipiert jede Minute etwas auszuwerten.
Da steigt der ein oder andere Server aus.
Das bisschen Logik verkraftet jedes System ohne Probleme. Last ist hier kein Argument.
Na gut, dann hat es eben andere Gründe, dass bei Verwendung eines Outlook-Kalenders und zu häufigem Abrufs ständig eine "Connection is closed"-Fehlermeldung kommt. Erst bei Reduzierung auf 30 Minuten läuft die Sache stabil.
Gruß Achim
PS:
Der Charme des Adapters liegt in der Anbindung von Outlook oder Google, der Auswertung von Stichworten in den Ereignissen etc.
Schade, dass die ursprünglich oin der Anleitung beschriebene Trennung von Einlesen und Auswertung offensichtlich nicht möglich ist.
Na gut, dann hat es eben andere Gründe, dass bei Verwendung eines Outlook-Kalenders und zu häufigem Abrufs ständig eine "Connection is closed"-Fehlermeldung kommt.
Ich kenne die Rate-Limits der Outlook-Server nicht.
Schade, dass die ursprünglich oin der Anleitung beschriebene Trennung von Einlesen und Auswertung offensichtlich nicht möglich ist.
Gerade geschaut - das steht seit 5+ Jahren falsch in der Dokumentation und hat nie funktioniert / war nie implementiert, ... 😞
Dann schlage ich vor wir machen hier zu. Aber ich denke es macht (extra Frature request) dennoch sinn die Abfragelast zu reduzieren und für den Cache einen Gültigkeitszeitraum je Kalender in die Konfig zu machen.
bei anderen Adaptern (ok das geht es teils um höhere Abholfrequenzen) versuchen wir auch es bestmöglich zu redizieren.
Und ja Mülldaten ändern sich in der regel nicht so oft ... also denke hier kann man mit Cache lifetimes von 24h problemlos arbeiten,
Und warum geht das nicht damit den Adapter einfach einmal die Stunde oder 30minuten laufen zu lassen das er es lädt und danach Entscheidungen trifft?