Trigger-Parameter "check" liest ics-Datei neu ein statt nur auszuwerten #597
Comments
|
Same here :-(, still existing in V1.14.3 |
|
Der Trigger wird mit der nächsten Version komplett entfernt: #662 |
|
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
<#662>
—
Reply to this email directly, view it on GitHub
<#597 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH3OF2JGRK735ZZRBGMXOTDZBZXQTAVCNFSM6AAAAAA6AHCKG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGAYDCNBSGI>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
|
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 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 |
|
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? |
Hallo, da ich das Ganze oben losgetreten habe, antworte ich auch mal. |
|
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
<#597 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH3OF2K7JGH56GD6LEH6LUDZCD3ARAVCNFSM6AAAAAA6AHCKG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYGM4DANJUGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Das bisschen Logik verkraftet jedes System ohne Probleme. Last ist hier kein Argument. |
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.
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. |
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. PS: |
Ich kenne die Rate-Limits der Outlook-Server nicht.
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. Und ja Mülldaten ändern sich in der regel nicht so oft ... also denke hier kann man mit Cache lifetimes von 24h problemlos arbeiten, |
|
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
<#597 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH3OF2JUBNKQVEVR5TLSMJTZCEKXPAVCNFSM6AAAAAA6AHCKG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYGY4DANBVGA>
.
You are receiving this because you were mentioned.
Message ID: <iobroker-community-adapters/ioBroker.
***@***.***>
|
|
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
The text was updated successfully, but these errors were encountered: