Projekt JARVIS, Tag 2: Der Assistent bekommt einen Kalender

Chris // 18 Aug, 2026

Am ersten Tag ging es vor allem darum, überhaupt eine funktionierende Grundlage zu schaffen.

JARVIS lief im Terminal, Ollama war angebunden und mit den Wetterdaten gab es die erste Funktion, die tatsächlich Informationen aus einem externen Dienst abrufen konnte.

Das war nett.

Aber ein persönlicher Assistent, der mir nur sagen kann, ob es draußen regnet, ist noch nicht besonders persönlich.

Also ging es an Tag 2 an das nächste Thema:

JARVIS bekommt Zugriff auf meinen Kalender.

Was soll am Ende möglich sein?

Für den Anfang wollte ich es bewusst einfach halten.

JARVIS sollte zunächst nur Termine lesen können.

Zum Beispiel:

Jarvis: Was steht heute in meinem Kalender?

Später soll daraus aber deutlich mehr werden.

Zum Beispiel:

Jarvis: Was steht morgen an?

Oder:

Jarvis: Wann ist mein nächster Termin?

Und irgendwann natürlich auch:

Jarvis: Trage morgen um 15 Uhr einen Testtermin ein.

Das Interessante daran ist weniger der einzelne Kalendereintrag.

Spannend wird es dann, wenn JARVIS die Kalenderdaten mit anderen Funktionen kombinieren kann.

Zum Beispiel:

Jarvis: Wann muss ich morgen losfahren?

Dafür müsste der Assistent den ersten Termin kennen, den Ort des Termins bestimmen, eine Route berechnen und eventuell sogar Verkehr oder Wetter berücksichtigen.

Aber dafür braucht er erst einmal einen Kalender.

Warum CalDAV?

Ich wollte den Kalender nicht fest mit einem bestimmten Anbieter verbinden.

Meine Kalender liegen aktuell in Nextcloud.

Nextcloud unterstützt CalDAV und damit gibt es eine standardisierte Schnittstelle für Kalender.

Das bedeutet auch, dass JARVIS später nicht zwangsläufig nur mit Nextcloud funktionieren muss.

Grundsätzlich können beispielsweise auch andere CalDAV Server angebunden werden.

Die Konfiguration habe ich deshalb bewusst so aufgebaut, dass später mehrere Accounts möglich sind.

Aktuell verwende ich Nextcloud.

Eine Synology oder ein generischer CalDAV Server sollen ebenfalls möglich sein.

Die ersten Kalender entdecken

Bevor JARVIS Termine lesen kann, muss zunächst geklärt werden, welche Kalender überhaupt existieren.

Dafür gibt es inzwischen einen eigenen Befehl:

jarvis calendar discover

Darüber fragt JARVIS den konfigurierten CalDAV Server ab und zeigt die gefundenen Kalender an.

Bei mir kamen dabei unter anderem Kalender wie diese zurück:

Aufgaben
Geburtstage
Privat
Familie

Nicht jeder davon muss später automatisch für jede Anfrage verwendet werden.

Gerade bei mehreren Kalendern möchte ich kontrollieren können, welche davon aktiv eingebunden werden.

Damit steht aber schon einmal fest:

Die Verbindung zu Nextcloud funktioniert.

Die ersten Termine im Terminal

Der nächste Schritt war naheliegend.

Termine für heute abrufen:

jarvis calendar today

Und anschließend Termine für morgen:

jarvis calendar tomorrow

Damit war die erste Kalenderfunktion vorhanden.

Noch nicht besonders intelligent, aber funktional.

Aus einer CalDAV Verbindung wurde eine Funktion, die JARVIS tatsächlich verwenden kann.

Natürlich musste es auch Probleme geben

Ganz ohne Fehlermeldungen wäre es schließlich langweilig.

Beim Zugriff auf meine Nextcloud tauchten unter anderem Warnungen wegen der TLS Zertifikatsprüfung auf.

Die Verbindung funktionierte zwar, Python meldete aber:

InsecureRequestWarning:
Unverified HTTPS request is being made

Für einen kurzen Test kann man so etwas ignorieren.

Für einen Assistenten, der später dauerhaft auf persönliche Daten zugreifen soll, möchte ich solche Dinge aber nicht einfach unter den Teppich kehren.

Also wanderte auch die TLS Prüfung in die Konfiguration.

JARVIS soll wissen, ob ein Serverzertifikat überprüft werden soll.

Und die Diagnosefunktion soll entsprechend melden, ob die Einstellung korrekt ist.

Zum Beispiel:

Calendar 1 TLS        OK
Calendar 1 calendars  OK

Das klingt nach einer Kleinigkeit.

Genau solche Kleinigkeiten entscheiden später aber darüber, ob ein Projekt nur auf dem eigenen Testsystem funktioniert oder halbwegs sauber aufgebaut ist.

Zugangsdaten gehören nicht in die Konfiguration

Ein weiterer Punkt war mir wichtig.

Passwörter möchte ich nicht direkt in YAML Dateien speichern.

Deshalb liegen sensible Werte wie das CalDAV Passwort in Umgebungsvariablen.

Die Kalenderkonfiguration enthält lediglich den Namen der entsprechenden Variable.

Sinngemäß sieht das so aus:

accounts:
  nextcloud:
    provider: nextcloud
    password_env: JARVIS_NEXTCLOUD_PASSWORD

Das eigentliche Passwort liegt getrennt davon.

Die Diagnosefunktion kann anschließend überprüfen, ob die Variable vorhanden ist.

Fehlt sie, sieht das beispielsweise so aus:

Calendar 1 password  ERROR
environment variable JARVIS_NEXTCLOUD_PASSWORD is not set or empty

Damit bekommt man zumindest sofort einen Hinweis darauf, warum die Verbindung nicht funktioniert.

Der Kalender wird zum Werkzeug

Bis zu diesem Zeitpunkt konnte ich die Kalenderfunktionen direkt über Befehle aufrufen.

Der wesentlich interessantere Schritt war jedoch, sie dem eigentlichen Assistenten zur Verfügung zu stellen.

Denn ich möchte langfristig nicht ständig wissen müssen, welcher CLI Befehl hinter einer Funktion steckt.

Ich möchte einfach schreiben:

Jarvis: Was ist mein nächster Termin?

JARVIS muss daraus selbst erkennen:

1. Es geht um einen Kalender.
2. Der passende Kalender muss abgefragt werden.
3. Die relevanten Termine müssen gefunden werden.
4. Das Ergebnis muss verständlich ausgegeben werden.

Genau hier wird das lokale Sprachmodell langsam sinnvoll.

Das Modell muss nicht selbst wissen, was in meinem Kalender steht.

Es muss lediglich erkennen, welches Werkzeug für die Anfrage benötigt wird.

Die eigentlichen Daten kommen weiterhin aus meinem eigenen System.

Der erste richtige Erfolg

Nachdem die Kalenderabfrage als Tool eingebunden war, konnte JARVIS tatsächlich meinen nächsten Termin bestimmen.

Eine beispielhafte Ausgabe sah so aus:

Nächster Termin:

Feuerwehr
20. August 2026
19:30 bis 22:30 Uhr
Geisenheim

Damit wurde aus einer einfachen CLI Funktion langsam etwas, das ich tatsächlich als Assistent bezeichnen würde.

Ich stelle eine Frage in natürlicher Sprache.

Das Sprachmodell erkennt die Absicht.

JARVIS ruft das passende Werkzeug auf.

Und anschließend bekomme ich eine Antwort.

Kann JARVIS auch Termine erstellen?

Nachdem das Lesen funktioniert hatte, war natürlich die nächste Frage:

Warum nur lesen?

Also folgte der erste Schreibtest.

Jarvis: Trage einen Testtermin für morgen 15 Uhr ein.

JARVIS musste dabei mehrere Informationen aus einem normalen Satz herausziehen:

Titel: Testtermin
Datum: morgen
Uhrzeit: 15:00 Uhr

Anschließend wurde daraus ein neuer CalDAV Eintrag erstellt.

Und tatsächlich:

Der Termin erschien in Nextcloud.

Das war für mich einer der ersten Momente, an denen das Projekt deutlich interessanter wurde.

Denn jetzt fragt JARVIS nicht mehr nur Informationen ab.

Er kann erstmals eine Aktion in einem angebundenen System ausführen.

Lesen ist einfach, Schreiben braucht Regeln

Damit taucht allerdings direkt das nächste Problem auf.

Bei einer Wetterabfrage kann relativ wenig passieren.

Bei einem schreibenden Zugriff sieht das anders aus.

Wenn ein Sprachmodell eine Anfrage falsch interpretiert, möchte ich nicht plötzlich zehn falsche Termine in meinem Kalender haben.

Das wird später noch wichtiger.

Denn wenn JARVIS irgendwann Licht schalten, Nachrichten verschicken oder andere Systeme verändern darf, braucht es klare Regeln.

Welche Aktionen dürfen automatisch ausgeführt werden?

Wann muss vorher nachgefragt werden?

Welche Aktionen müssen protokolliert werden?

Das möchte ich lieber von Anfang an berücksichtigen, anstatt es später irgendwie nachzurüsten.

Langsam entsteht eine Architektur

Nach zwei Tagen besteht JARVIS inzwischen aus mehreren klar getrennten Teilen.

Zum einen gibt es die eigentliche Assistant Engine.

Dazu kommen verschiedene Werkzeuge.

Aktuell beispielsweise:

Assistant
    |
    + Calendar
    |
    + Weather
    |
    + Memory
    |
    + Ollama

Das soll auch weiterhin das Grundprinzip bleiben.

JARVIS selbst ist der Orchestrator.

Die einzelnen Funktionen sitzen in getrennten Modulen.

Das Sprachmodell entscheidet nicht, wie eine CalDAV Anfrage technisch funktioniert.

Es entscheidet nur, dass für eine Frage der Kalender benötigt wird.

Genau diese Trennung wird später hoffentlich dafür sorgen, dass neue Funktionen relativ einfach ergänzt werden können.

Stand nach Tag 2

Nach dem zweiten Tag kann JARVIS inzwischen deutlich mehr als beim ersten Start.

Aktuell funktioniert:

• Verbindung zu einem Nextcloud CalDAV Server
• automatische Erkennung vorhandener Kalender
• Auswahl der verwendeten Kalender
• Termine für heute abrufen
• Termine für morgen abrufen
• nächsten Termin bestimmen
• Kalenderdaten über natürliche Sprache abfragen
• neue Termine über natürliche Sprache erstellen
• Zugangsdaten über Umgebungsvariablen verwalten
• TLS Einstellungen konfigurieren
• Kalenderverbindung über die Diagnosefunktion prüfen

Zusammen mit der Wetterfunktion gibt es damit inzwischen zwei echte Datenquellen.

Noch arbeiten sie weitgehend unabhängig voneinander.

Aber genau das soll sich als Nächstes ändern.

Der nächste Schritt

Kalender und Wetter sind nützlich.

Aber für einen persönlichen Assistenten fehlt noch ein wichtiger Faktor:

Wo bin ich eigentlich und wo muss ich hin?

JARVIS kennt einen Termin.

Vielleicht kennt er sogar dessen Adresse.

Aber momentan weiß er noch nicht, wie weit der Weg dorthin ist.

Der nächste logische Schritt ist deshalb die Integration von Orten und Routen.

Dann könnte aus:

Jarvis: Was ist mein nächster Termin?

irgendwann eine deutlich interessantere Antwort werden:

Dein erster Termin beginnt morgen um 8:00 Uhr.

Die Fahrt dauert ungefähr 45 Minuten.

Da morgen Regen erwartet wird, solltest du etwas mehr Zeit einplanen.

Und spätestens dann werden Kalender, Wetter und weitere Datenquellen nicht mehr nur einzelne Funktionen sein.

Dann beginnt JARVIS, Informationen miteinander zu verknüpfen.

Fortsetzung folgt mit Tag 3.