Alex71w
commented
2 months ago Same here :-(, still existing in V1.14.3
Open ammawel opened 9 months ago
Alex71w
commented
2 months ago Same here :-(, still existing in V1.14.3
klein0r
commented
2 months ago Der Trigger wird mit der nächsten Version komplett entfernt: https://github.com/iobroker-community-adapters/ioBroker.ical/issues/662
Alex71w
commented
2 months ago Okay. Aber wie kann ich dann die reine Verarbeitung der Events veranlassen, ohne den Kalender neu einzulesen? Mir geht es um das Setzen der Now-DPs und im Konfig eingetragener eigener IDs bei Event-Start und -Ende, um Scripte zu triggern.
Matthias Kleine @.***> schrieb am Sa., 11. Mai 2024, 21:37:
Der Trigger wird mit der nächsten Version komplett entfernt: #662 https://github.com/iobroker-community-adapters/ioBroker.ical/issues/662
— Reply to this email directly, view it on GitHub https://github.com/iobroker-community-adapters/ioBroker.ical/issues/597#issuecomment-2106001422, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3OF2JGRK735ZZRBGMXOTDZBZXQTAVCNFSM6AAAAAA6AHCKG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGAYDCNBSGI . You are receiving this because you commented.Message ID: @.*** com>
Apollon77
commented
2 months ago 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)
klein0r
commented
2 months ago @Apollon77 check hat noch nie funktioniert (zumindest laut Readme und dem, was ich im Code gefunden hatte). Das habe ich zuletzt entfernt:
Apollon77
commented
2 months ago Das dachte ich mir fast. ;-). Also wäre das hier eher ein Feature Request ;-)
klein0r
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago @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
commented
2 months ago @Alex71w Was genau ist denn dein Usecase? Geht es darum nicht immer zu laden oder worum gehts?
ammawel
commented
2 months ago @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
commented
2 months ago Stimme ammawel 100% zu. Genau darum geht es, das war es auch, was ich mir von diesem Adapter erwartet/ erhofft hatte.
Auch bei mir ändert sich der Kalender nicht stündlich, daher muss ich auch nicht Google mit minütlicher Abfrage belasten. Aber ich benötige eine möglichst zeitgenaue Aktualisierung der DPs und damit Triggerung meiner Skripte. Ich steuere damit zB Heizungsthermostate und Lichter.
Ich frage mich, wie die anderen User des Adapters vorgehen? (Nicht rhetorisch sondern ernsthaft gemeint) Mir kommt unser UseCase nicht sonderlich exotisch vor :-)
Beste Grüße, Alexandra
Generell möchte ich mich bei der Gelegenheit ganz herzlich für Eure Arbeit an dem Adapter & für die iobroker-Community bedanken, das ist grossartig! Highly appreciated :-)
ammawel @.***> schrieb am Mo., 13. Mai 2024, 19:38:
@Alex71w https://github.com/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 angebaren 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!
— Reply to this email directly, view it on GitHub https://github.com/iobroker-community-adapters/ioBroker.ical/issues/597#issuecomment-2108380545, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3OF2K7JGH56GD6LEH6LUDZCD3ARAVCNFSM6AAAAAA6AHCKG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYGM4DANJUGU . You are receiving this because you were mentioned.Message ID: @.*** com>
klein0r
commented
2 months ago Da steigt der ein oder andere Server aus.
Das bisschen Logik verkraftet jedes System ohne Probleme. Last ist hier kein Argument.
klein0r
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago Hoffe, mein Input kommt noch an trotz Close des Themas...
Es geht nicht um Last oder Performance sondern Häufigkeit des Pollings, wie geschrieben.
Ich stelle jetzt zum besseren Verständnis doch mal meinen Use Case genauer dar:
Ich arbeite teils zuhause, teils im Büro. Dies aber nicht an festen Tagen. Ich stelle mir in meinem Büro-Outlook-Kalender Termine ein, an denen ich ins Büro fahre, und lade meinen privaten Google Kalender dazu ein. So ist auch ein Update (Verschiebung, Löschung...) eines solchen Termines sichergestellt. Diese Termine irgendwo zusätzlich lokal zu pflegen kommt daher für mich nicht in Frage. Die Termine ändern sich meist nicht von jetzt auf gleich, maximal von heute auf morgen.
Abhängig davon, ob ich zuhause arbeite oder nicht wird die Heizung in meinem Home Office gesteuert (Heizprofile gesetzt) und ich überlege auch etwas in Richtung Lichtsteuerung zu implementieren.
Daher ist es durchaus relevant, dass der Eventtrigger recht zeitnah erfolgt, um die Heizung nicht unnötig lange laufen zu haben bzw ich nicht frieren muss.
PS Nur weil man sich selbst vielleicht nicht vorstellen kann, wie ein UseCase aussehen könnte, sollte man doch anerkennen, dass andere Personen einen validen UC haben. Wenn es für meinen UC eine bessere Lösung gibt - immer her damit!
Ingo Fischer @.***> schrieb am Mo., 13. Mai 2024, 21:52:
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,
— Reply to this email directly, view it on GitHub https://github.com/iobroker-community-adapters/ioBroker.ical/issues/597#issuecomment-2108680450, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3OF2JUBNKQVEVR5TLSMJTZCEKXPAVCNFSM6AAAAAA6AHCKG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYGY4DANBVGA . You are receiving this because you were mentioned. Message ID: <iobroker-community-adapters/ioBroker. @.***>
Apollon77
commented
2 months ago 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?
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