remind als Kalender / Zeitsteuerung

xenos1984 · 24 November 2019, 19:27:37

Für meinen Kalender nutze ich ein Programm namens remind:

http://dianne.skoll.ca/projects/remind/
http://manpages.ubuntu.com/manpages/bionic/man1/remind.1.html

Der Vorteil von remind gegenüber anderen mir bekannten Systemen besteht in seiner Flexibilität was die Definition von Terminen bzw. Ereignissen angeht - diese werden nach bestimmten Regeln aus einem Skript "berechnet". Dazu kommt, dass man remind wahlweise als Hintergrundprozess laufen lassen kann, der zum programmierten Zeitpunkt (sowie zu ebenfalls programmierbaren "Vorwarnzeiten") ein Programm aufruft, oder auch die von remind berechneten Zeitpunkte als Tabellenformat exportieren. Damit sollte sich doch auch zusammen mit FHEM etwas anfangen lassen.

Idee: Zu den von remind berechneten Zeitpunkten Ereignisse in FHEM auslösen. Vielleicht den Kalender oder bevorstehende Termine in einem FHEM UI anzeigen.

Bevor ich mich nun ans Werk mache, möchte ich zunächst ein paar Ideen / Gedanken / Meinungen zum Thema sammeln, da ich noch recht unerfahren mit FHEM bin. Insbesondere wäre ich an Gedanken zu folgenden Punkten interessiert:

Wäre es sinnvoll, ein Perl-Modul zu schreiben, das mit remind interagiert? Oder lässt sich das Gewünschte auch mit anderen Mitteln halbwegs einfach erreichen?
Welche Variante wäre sinnvoller: Sollte remind als Hintergrundprozess laufen und FHEM aufrufen, um Ereignisse auszulösen? (Das wäre sicher einfach - z.B. per Telnet Befehle übergeben sollte ja einfach sein.) Oder sollte FHEM die Zeitpunkte als Tabelle aus remind auslesen und dann z.B an ein anderes Kalendermodul weitergeben? Letzteres würde die Möglichkeit geben, die Termine auch innerhalb von FHEM als Kalender anzusehen.

Beta-User · 26 November 2019, 16:34:14

Hallo,

es ist vermutlich nicht so einfach, sich sowas wie eine abschließende Meinung zu diesem tendenziell eher komplexen Thema zu bilden. Da auf der Webseite angegeben war, dass remind "seine Ereignisse" auch als ical zur Verfügung stellen kann, wäre mein erster Ansatz, die ical lokal von der remind-Seite her ablegen/erneuern zu lassen und dann ein "calendar"-Device zu nutzen, um die Datei regelmäßig zu lesen und für FHEM Aktionen daraus abzuleiten. Damit sollte bereits mit Bordmitteln eine standardisierte Schnittstelle zur Verfügung stehen, mit der man "im Prinzip" alles machen kann, und man ist nicht zwingend darauf angewiesen, dass zu jedem Zeilpunkt beide Services laufen.

Bausteine dafür sind m.E. hier zu finden: https://forum.fhem.de/index.php/topic,87895.0.html,

Kommt aber insgesamt darauf an, wie du dir eine Schnittstelle zwischen remind und FHEM vorstellst bzw. was das Tool an Datensätzen bereitstellen kann/soll.

Steuerung via Telnet geht sicher auch, und hat vermutlich Vorteile, wenn es darum geht, eher kurzfristig auf irgendwas zu reagieren. Grundsätzlich würde ich aber dazu neigen, die Ereignisauswertung in FHEM zu machen (die liebe Gewohnheit...), und vor allen: Die Logik eher nicht auf zu viele Stellen verteilen, die miteinander interagieren. Das wird mAn. sonst eventuell schnell sehr unübersichtlich.

Gruß, Beta-User

xenos1984 · 26 November 2019, 20:00:03

Danke für die Infos!

Ja, an ical als gemeinsame Schnittstelle hatte ich auch schon gedacht. So weit ich das sehe, kann calendar dann ja als Zeitsteuerung dienen. Für das Einlesen müsste man sich vielleicht überlegen, ob calendar statt einer Datei oder URL einen Prozess anstoßen kann, um dann dessen Ausgabe einzulesen. Dann könnte man in regelmäßigen Abständen remind aufrufen und so die aktuellen Daten einlesen. Ansonsten müsste man wohl z.B. remind über cron regelmäßig seine Daten in eine ical Datei schreiben lassen.

Telnet scheint von der Umsetzung her besonders einfach zu sein. Derzeit nutze ich für meinen Kalender remind und habe Termine in dessen Datei mittels REM und MSG definiert. Wenn remind dann als Hintergrundprozess läuft, kann man ihm als Argument mitgeben, was er tun soll, wenn so ein Termin eintritt. In meinem Fall liest er den Inhalt des MSG-Teils des Termins mittels espeak vor und zeigt mir ein Erinnerungsfenster. Für eine FHEM-Anbindung könnte man nun letzteres so ersetzen, dass der Inhalt des MSG-Teils stattdessen über Telnet an FHEM geschickt wird, und dann natürlich statt Sachen wie "Onkel Otto vom Bahnhof abholen" eher "set heating temp 22" als MSG übergeben. Damit würde man aber in der Tat viel Logik in remind auslagern, und man könnte keine Terminliste in FHEM sehen. (Wobei mir diese Variante für den Anfang genügen würde - ausbauen und einen Kalender basteln kann man es ja danach immer noch.)

Beta-User · 27 November 2019, 07:58:32

So wie du das schilderst, scheint mir telnet passend zu sein, evtl. wäre auch websocket (?) was, was passen könnte (telnet muß man erst aktivieren), aber da kann ich mangels eigener Kenntnisse nicht wirklich mitreden.

Was ical angeht, erschließt sich mir dein Gedankengang im letzten Post nicht wirklich.
Du hast einen Dienst, der angeblich völlig flexibel alles mögliche tun kann, auch zeitgesteuert. Warum willst du den dann über einen _anderen_ Dienst (cron) anweisen, regelmäßig eine bestimmte (ical) Datei zu aktualisieren? (evtl. stellt sogar einer der ical-Dienste, die in remind verwendet werden können eine http-Schnittstelle bereit, die man auf localhost jederzeit aktuell abrufen kann?)
Welchen Sinn hat es, ein neues Interface zu schaffen, wenn es schon eines gibt, in dem die beiden Dienste (jedenfalls unidirektional remind => calendar@FHEM) schon "miteinander Reden" können?

xenos1984 · 27 November 2019, 15:08:13

So weit ich das FHEM Calendar Modul verstehe, kann es in bestimmten Zeitabständen einen ical Kalender einlesen, und zwar entweder von einer URL (also letztlich über HTTP) oder aus einer Datei. Also müsste man ihm entweder einen Webserver bereitstellen, damit Calendar eine URL aufrufen kann, die ihm dann aus remind dynamisch eine ical Datei übergibt, oder man müsste eine ical Datei haben, die von Calendar eingelesen wird. Allerdings sehe ich gerade nicht, wie man dynamisch so eine ical Datei aus remind erzeugen kann, wenn Calendar diese einlesen will. D.h. man müsste diese Datei irgendwie extern aus remind erzeugen und regelmäßig aktuell halten, damit Calendar immer etwas aktuelles hat, das es einlesen kann. Natürlich kann man auch remind oder FHEM selbst benutzen, um diese Datei zeitgesteuert zu aktualisieren - mir ist nur deshalb cron eher im Sinn gewesen, weil es hier keine komplexe Zeitsteuerung braucht, sondern ein einfaches "erstelle jede Stunde eine ical Datei aus remind" ausreicht, das man auch per cron realisieren kann.

Besser wäre natürlich, wenn das Calendar Modul neben file und url noch eine dritte Option hätte, mit der man als Argument einen Perl-Befehl oder ein Shell-Kommando übergeben könnte, das regelmäßig aufgerufen wird, und dessen Ausgabe dann als ical interpretiert wird. Dann könnte man direkt aus Calendar heraus regelmäßig remind aufrufen und die Terminliste im Calendar aktualisieren. Oder löst die Aktualisierung des Calendar ein Event aus, das man mit notify abfangen und dann aus dem notify heraus remind aufrufen könnte? Oder einfach remind mittels at aus FHEM aufrufen und die Ausgabe in Calendar einspeisen?

Beta-User · 27 November 2019, 15:33:00

Sorry, aber so tief bin ich in der Materie nicht drin, ich würde das wie beschrieben so lösen, dass ich in remind ein (scheinbar dort verfügbares) plugin nutze, das ical (file) schreiben kann und dann in remind - ggf. timer- oder event-basiert überwachen, dass das regelmäßig/wenn notwendig geschieht.
Du kannst dann auch das file von FHEM überwachen lassen (inotify?, kann es sein, dass du das gesucht/gemeint hast?) und bei Aktualisierung/zeitbasiert calendar das Teil auswerten lassen. Fertig die Laube...

Dr. Boris Neubert · 27 November 2019, 20:39:49

Zitat von: Beta-User am 27 November 2019, 15:33:00
Fertig die Laube...

Jo. So würde ich das auch machen.

xenos1984 · 28 November 2019, 07:44:26

Zitat von: Beta-User am 27 November 2019, 15:33:00Sorry, aber so tief bin ich in der Materie nicht drin, ich würde das wie beschrieben so lösen, dass ich in remind ein (scheinbar dort verfügbares) plugin nutze, das ical (file) schreiben kann und dann in remind - ggf. timer- oder event-basiert überwachen, dass das regelmäßig/wenn notwendig geschieht.

Ja, genau das war auch mein Gedankengang. Dafür müsste man eben regelmäßig den remind → ical Konverter laufen lassen. Ob man den nun über cron oder FHEM mittels "at" regelmäßig laufen lässt, sollte keinen großen Unterschied machen.

ZitatDu kannst dann auch das file von FHEM überwachen lassen (inotify?, kann es sein, dass du das gesucht/gemeint hast?) und bei Aktualisierung/zeitbasiert calendar das Teil auswerten lassen. Fertig die Laube...

Danke für den Hinweis auf inotify! Das kannte ich noch nicht. Damit könnte man vermutlich dem Calendar ein "set update" oder "set reload" mitgeben, sobald sich die ical Datei ändert.

Beta-User · 28 November 2019, 09:34:44

Zitat von: xenos1984 am 28 November 2019, 07:44:26
Ob man den nun über cron oder FHEM mittels "at" regelmäßig laufen lässt, sollte keinen großen Unterschied machen.

Das verstehe ich nicht. Warum willst du unbedingt die wechselseitigen Abhängigkeiten erhöhen? Das kommt mir wie ein Konstruktionsfehler vor... (Aber ich bin auch kein SW-Architekt, sondern einfacher user).
Nutzt du zur Überwachung eventueller update-Erfordernisse nur "remind", läuft das autonom, auch wenn z.B. FHEM grade hakt, abgeschaltet ist, usw.. (Selbst der Rückgriff auf cron erscheint mir für ein System überflüssig, das selbst Timer-basiert arbeitet; ist das alles in einer Konfiguration, ist es viel einfacher, ggf. mal auf ein anderes System umzuziehen).

Andersrum gibt es kein Risiko, das FHEM hängt, weil remind grade nicht verfügbar ist. Im schlimmsten Fall wird mit "alten", nicht aktualisierten Daten gearbeitet, aber das war es auch schon...

xenos1984 · 28 November 2019, 15:12:16

Zitat von: Beta-User am 28 November 2019, 09:34:44Das verstehe ich nicht. Warum willst du unbedingt die wechselseitigen Abhängigkeiten erhöhen? Das kommt mir wie ein Konstruktionsfehler vor... (Aber ich bin auch kein SW-Architekt, sondern einfacher user).

Ich sage ja gar nicht, dass ich das will, sondern nur, dass das mögliche Zeitgeber sind, um den ical-Konverter zu starten.

ZitatNutzt du zur Überwachung eventueller update-Erfordernisse nur "remind", läuft das autonom, auch wenn z.B. FHEM grade hakt, abgeschaltet ist, usw.. (Selbst der Rückgriff auf cron erscheint mir für ein System überflüssig, das selbst Timer-basiert arbeitet; ist das alles in einer Konfiguration, ist es viel einfacher, ggf. mal auf ein anderes System umzuziehen).

Ja, natürlich kann man den ical-Konverter auch mit remind als Zeitgeber starten. Dann müsste man eben remind sowohl als Hintergrundprozess / Zeitgeber und dann von diesem aus den Konverter aufrufen. Mir erschien cron oder FHEM als Zeitgeber sinnvoller, wenn diese ohnehin laufen - dann braucht man nicht zusätzlich auch noch remind als Zeitgeber laufen lassen, sondern nur den ical-Konverter. Der einzige Zeitgeber wäre dann FHEM, und FHEM bekommt die Zeitinformationen per ical geliefert.

ZitatAndersrum gibt es kein Risiko, das FHEM hängt, weil remind grade nicht verfügbar ist. Im schlimmsten Fall wird mit "alten", nicht aktualisierten Daten gearbeitet, aber das war es auch schon...

Wenn remind "nicht verfügbar" ist, müsste schon jemand das Programm gelöscht haben oder es müsste durch ein Update nicht mehr lauffähig sein. Ansonsten sehe ich keinen Grund, warum FHEM nicht in der Lage sein sollte, es per Shell-Befehl aufzurufen.

Beta-User · 28 November 2019, 15:25:19

Na ja, scheint so, als hätte ich das wohl falsch verstanden, dass remind immer im Hintergrund läuft. Wenn man es explizit aufrufen muß, kann man auch FHEM als Zeitgeber nutzen, dann "weiß" FHEM ja auch, wann mit aktualisierten Daten zu rechnen ist und muß keine separate Überwachung bauen. Dabei sollte dann aber darauf geachtet werden, dass das non-blocking läuft/aufgerufen wird.

xenos1984 · 28 November 2019, 20:30:02

Richtig, das sind zwei verschiedene Dinge:

remind -z startet einen Hintergrund-Prozess, der zu den festgelegten (aus einem remind-Skript berechneten) Zeiten Programme startet und / oder Meldungen ausgibt bzw. an ein bestimmtes Programm (z.B. über telnet an FHEM) weitergibt. In diesem Fall dient remind als Zeitgeber.
remind -s gibt eine Liste der berechneten Zeitpunkte und deren Beschreibungen aus, die dann mit einem externen Programm z.B. in ical konvertiert werden und an FHEM übergeben werden kann. Damit dies regelmäßig geschieht, muss man remind regelmäßig aufrufen. Die übergebenen Zeiten kann man dann in FHEM nutzen und damit Ereignisse auslösen - hier dient also FHEM als Zeitgeber.

Wenn man nun die zweite Variante wählen will und remind nur als Datenquelle für FHEM dient, während FHEM als Zeitgeber dient, macht es natürlich eher Sinn, auch remind selbst aus FHEM heraus periodisch aufzurufen, statt als zweiten Zeitgeber auch noch remind hinzuzunehmen. Auf die Weise braucht es nur einen Hintergrundprozess und nur einen Zeitgeber.