Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trigger-Parameter "check" liest ics-Datei neu ein statt nur auszuwerten #597

Open
ammawel opened this issue Oct 14, 2023 · 19 comments
Open

Comments

@ammawel
Copy link

ammawel commented Oct 14, 2023

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.

ical check.log

@Alex71w
Copy link

Alex71w commented May 11, 2024

Same here :-(, still existing in V1.14.3

@klein0r
Copy link
Contributor

klein0r commented May 11, 2024

Der Trigger wird mit der nächsten Version komplett entfernt: #662

@Alex71w
Copy link

Alex71w commented May 12, 2024 via email

@Apollon77
Copy link
Member

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 Apollon77 reopened this May 12, 2024
@klein0r
Copy link
Contributor

klein0r commented May 13, 2024

@Apollon77 check hat noch nie funktioniert (zumindest laut Readme und dem, was ich im Code gefunden hatte). Das habe ich zuletzt entfernt:

ioBroker.ical/README.md

Lines 24 to 26 in 1a2182f

<!--
## Todo
* `data.trigger` doesn't support `check` option

@Apollon77
Copy link
Member

Das dachte ich mir fast. ;-). Also wäre das hier eher ein Feature Request ;-)

@klein0r
Copy link
Contributor

klein0r commented May 13, 2024

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.

@Alex71w
Copy link

Alex71w commented May 13, 2024

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?

@Apollon77
Copy link
Member

@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

@Apollon77
Copy link
Member

@Alex71w Was genau ist denn dein Usecase? Geht es darum nicht immer zu laden oder worum gehts?

@ammawel
Copy link
Author

ammawel commented May 13, 2024

@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!

@Alex71w
Copy link

Alex71w commented May 13, 2024 via email

@klein0r
Copy link
Contributor

klein0r commented May 13, 2024

Da steigt der ein oder andere Server aus.

Das bisschen Logik verkraftet jedes System ohne Probleme. Last ist hier kein Argument.

@klein0r
Copy link
Contributor

klein0r commented May 13, 2024

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.

@ammawel
Copy link
Author

ammawel commented May 13, 2024

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.

@klein0r
Copy link
Contributor

klein0r commented May 13, 2024

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

@Apollon77
Copy link
Member

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,

@Alex71w
Copy link

Alex71w commented May 14, 2024 via email

@Apollon77
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants