Projekt JARVIS: Vom Sprachsatelliten zum eigenen Command Center

Chris // 6 Sep, 2026

Im letzten Beitrag ging es um den ersten Linux Satelliten.

Damit konnte JARVIS zum ersten Mal außerhalb des Servers tatsächlich zuhören und antworten.

Seitdem ist allerdings ziemlich viel passiert.

Aus dem kleinen Sprachprojekt sind inzwischen mehrere Dienste, verschiedene Satelliten, ein eigenes Command Center und immer mehr Integrationen entstanden.

Zeit also für einen neuen Zwischenstand.

Der Linux Satellit war erst der Anfang

Der Linux Satellit mit dem ReSpeaker Core v2 war vor allem der Beweis, dass die Architektur funktioniert.

Ein kleines Gerät nimmt Audio auf, schickt es zum Core und spielt anschließend die Antwort wieder ab.

Die eigentliche Logik bleibt zentral.

Genau dieses Prinzip habe ich anschließend auf eine komplett andere Plattform übertragen.

Den ESP32.

Ein ESP32 als Sprachsatellit

Als nächste Hardware kam ein Waveshare ESP32 S3 mit Display zum Einsatz.

Im Vergleich zum ReSpeaker ist das natürlich eine völlig andere Plattform.

Kein normales Linux.

Deutlich weniger Arbeitsspeicher.

Andere Audiotreiber.

Andere Entwicklungsumgebung.

Und selbstverständlich auch neue Probleme.

Das Board besitzt allerdings fast alles, was ich für einen kleinen Satelliten brauche:

ESP32 S3
Display
Mikrofon
Lautsprecher
WLAN
PSRAM
Touch Bedienung

Damit konnte ich ausprobieren, wie klein ein JARVIS Satellit eigentlich werden kann.

Audio auf dem ESP32 war etwas schwieriger

Die ersten Tests waren erwartungsgemäß nicht besonders spektakulär.

Das WLAN funktionierte.

Der Core war erreichbar.

Das Voice Protokoll wurde erkannt.

Nur ausgerechnet das Mikrofon lieferte zunächst keine brauchbaren Daten.

Die Ursache lag unter anderem bei der Initialisierung des ES7210 Audio Codecs.

Nachdem das gelöst war, funktionierte schließlich die komplette Kette:

Mikrofon
Sprache
Core
STT
JARVIS
Antwort
TTS
ESP32
Lautsprecher

Damit konnte auch der kleine ESP32 erstmals eine Frage aufnehmen und die gesprochene Antwort wiedergeben.

Der Satellit bekommt ein eigenes Display

Wenn schon ein Display vorhanden ist, sollte es natürlich auch genutzt werden.

Die Oberfläche zeigt inzwischen unter anderem:

Uhrzeit
Mikrofonstatus
Netzwerkstatus
Lautstärke
Mute
Core Status

Auch die Netzwerkverbindung wird direkt visualisiert.

Wenn alles funktioniert, zeigt der Satellit den entsprechenden Status an.

Ist keine Verbindung vorhanden, wird das ebenfalls sichtbar.

Dazu kommen Touch Buttons für Mikrofon, Lautstärke und weitere Funktionen.

Der Satellit soll langfristig möglichst komplett ohne zusätzliche Bediengeräte funktionieren.

Musik verändert die Oberfläche

Eine weitere Änderung kam durch die Medienwiedergabe.

Sobald Musik läuft, braucht der Satellit nicht dieselbe Oberfläche wie während einer normalen Sprachinteraktion.

Deshalb gibt es inzwischen eine eigene Medienansicht.

Dort stehen die wichtigsten Bedienelemente im Mittelpunkt:

Play
Pause
Lauter
Leiser
Mikrofon

Der normale Assistent bleibt trotzdem weiterhin erreichbar.

Damit wird der Satellit langsam mehr als nur ein Mikrofon mit WLAN.

Plex wird eingebunden

Parallel dazu habe ich angefangen, die Medienfunktionen des Core auszubauen.

Als erster Provider wurde Plex angebunden.

Das Ziel ist dabei wieder eine möglichst allgemeine Architektur.

JARVIS soll nicht fest mit Plex verbunden sein.

Plex ist lediglich der erste Medienprovider.

Die Suche funktioniert beispielsweise bereits über die CLI:

jarvis media search "Metallica"

Der Core findet daraufhin passende Künstler, Alben oder Titel.

Die Wiedergabe kann anschließend auf einem registrierten Ausgabegerät gestartet werden.

Zum Beispiel auf dem ESP32 Satelliten.

Der Core kennt jetzt Ausgabegeräte

Damit Musik nicht einfach irgendwo abgespielt wird, musste JARVIS lernen, verschiedene Ausgabegeräte zu unterscheiden.

Ein Satellit meldet deshalb unter anderem:

Device ID
Name
Status
Lautstärke
unterstützte Audioformate
verfügbare Steuerfunktionen

Ein Gerät kann beispielsweise melden, dass es folgende Aktionen unterstützt:

play
pause
resume
stop
volume

Damit wird die Medienwiedergabe nicht direkt an eine bestimmte Hardware gekoppelt.

Später könnten beispielsweise Linux Satelliten, ESP32 Geräte oder andere Netzwerkplayer dieselbe Schnittstelle verwenden.

Wakeup und Begrüßungen

Auch beim Sprachablauf hat sich einiges verändert.

Ein Satellit kann den Core inzwischen bereits informieren, sobald eine Interaktion beginnt.

Dadurch kann das Sprachmodell im Hintergrund vorbereitet werden.

Die Idee dahinter ist einfach:

Wenn das Modell bereits geladen wird, während der Benutzer mit dem Sprechen beginnt, kann später etwas Zeit eingespart werden.

Zusätzlich gibt es inzwischen dynamische Begrüßungen.

Ein Satellit kann nach dem Aktivieren beispielsweise eine passende Begrüßung erhalten:

Guten Morgen.

Guten Abend.

Hallo Chris.

Was kann ich für dich tun?

Die Antwort kann sowohl als Text als auch direkt als TTS Audio geliefert werden.

Das Mikrofon bleibt offen

Eine weitere Änderung betrifft die eigentliche Unterhaltung.

Ursprünglich war eine Sprachinteraktion ziemlich klar abgeschlossen:

Aufnahme
Frage
Antwort
Ende

Für eine richtige Unterhaltung ist das allerdings unpraktisch.

Deshalb kann der Mikrofonkanal inzwischen offen bleiben.

Nach einer gesprochenen Antwort wird automatisch wieder auf Eingabe geschaltet.

Wenn anschließend nichts mehr gesagt wird, erkennt die Stilleerkennung das Ende der Unterhaltung.

Damit wird aus einzelnen Sprachbefehlen langsam ein richtiger Dialog.

Das Command Center wird komplett neu aufgebaut

Während die Satelliten immer mehr Funktionen bekamen, wurde auch die Weboberfläche zunehmend wichtiger.

Aus der ursprünglichen einfachen Oberfläche entwickelt sich inzwischen ein richtiges Command Center.

Dort sollen langfristig alle wichtigen Bereiche zusammenlaufen.

Aktuell gehören dazu beispielsweise:

System
Satelliten
Tasks
Task History
Services
Settings
Updates
Medien
Provider

Dabei geht es nicht nur darum, Informationen anzuzeigen.

Viele Einstellungen können inzwischen direkt über die Oberfläche geändert werden.

Einstellungen ohne SSH

Das war eines meiner ursprünglichen Ziele.

Für normale Änderungen möchte ich nicht ständig eine Konfigurationsdatei auf dem Server bearbeiten müssen.

Deshalb bekommt das Command Center nach und nach eigene Einstellungsdialoge.

Unter anderem für:

Ollama
Kalender
Zuhause
Arbeit
Telegram
Wetterwarnungen
Satelliten
Provider

Beim Ollama Dialog kann beispielsweise der Server geändert werden.

Anschließend werden die verfügbaren Modelle geladen und eines davon kann als aktives Modell ausgewählt werden.

Auch mehrere Kalender werden berücksichtigt.

Ein einheitliches Interface

Die neue Oberfläche soll nicht aus vielen unterschiedlich aussehenden Seiten bestehen.

Deshalb wurden Navigation, Modale und Bedienelemente zunehmend vereinheitlicht.

Auch auf kleineren Displays soll das Command Center funktionieren.

Auf dem Smartphone wird die normale Navigation deshalb durch ein Hamburger Menü ersetzt.

Das klingt nach einer kleinen Änderung.

Wenn die Weboberfläche später aber tatsächlich täglich benutzt werden soll, ist genau das wichtig.

Aufgaben bekommen einen eigenen Worker

Ein weiterer großer Schritt war die Task Engine.

Bisher reagierte JARVIS hauptsächlich auf Anfragen.

Jetzt soll der Assistent auch selbstständig Dinge ausführen können.

Jede Aufgabe wird dabei als eigene Konfiguration gespeichert.

Beispielsweise:

Morgenbriefing
Warnungen prüfen
Flugzeuge beobachten
regelmäßige Abfragen
zukünftige Erinnerungen

Ein eigener Worker liest diese Aufgaben ein und führt sie zum richtigen Zeitpunkt aus.

Dafür läuft inzwischen ein eigener Dienst:

jarvis-task-worker.service

Über die CLI können Tasks angezeigt, aktiviert, deaktiviert und manuell ausgeführt werden.

Telegram wird dadurch deutlich interessanter

Mit den Tasks bekommt auch der Telegram Bot einen neuen Zweck.

Er ist nicht mehr nur ein weiterer Chat Client.

JARVIS kann darüber jetzt auch selbstständig Informationen senden.

Ein Beispiel dafür ist die Flugzeugbeobachtung.

Über Telegram kann die Funktion aktiviert werden:

/task aircraft show on

Danach beobachtet JARVIS Flugzeuge in einem definierten Radius.

Taucht ein neues Flugzeug auf, können beispielsweise folgende Informationen geschickt werden:

Airline
Start
Ziel
Flugzeugtyp

Mit:

/task aircraft show off

wird die Beobachtung wieder beendet.

Flugzeuge über dem eigenen Standort

Die Flugzeugfunktion ist inzwischen selbst ein eigenes Modul geworden.

JARVIS kann beispielsweise beantworten:

Welches Flugzeug fliegt gerade über mir?

Dafür werden mehrere Datenquellen kombiniert.

Ein lokaler FlightRadar24 Feeder liefert Liveinformationen.

Weitere Provider ergänzen beispielsweise:

Flugzeugtyp
Registrierung
Airline
Route
Flughäfen

Auch hier soll die Architektur wieder offen bleiben.

Die einzelnen Provider sind austauschbar.

JARVIS Doctor wird modular

Je mehr Dienste hinzukommen, desto schwieriger wird es herauszufinden, warum etwas nicht funktioniert.

Deshalb wächst auch jarvis doctor weiter.

Allerdings möchte ich vermeiden, dass daraus irgendwann eine einzige riesige Datei wird.

Die Diagnose wird deshalb zunehmend in Provider aufgeteilt.

Beispielsweise:

Voice
Command Center
Home Assistant
Aircraft
Media
Ollama
Atlas
API

Jeder Bereich kann seine eigenen Prüfungen bereitstellen.

Damit lässt sich relativ schnell erkennen, welche Komponente Probleme verursacht.

Home Assistant kommt dazu

Eine weitere große Integration ist Home Assistant.

JARVIS soll dadurch langfristig auch mit dem Smart Home kommunizieren können.

Der erste Schritt besteht darin, die vorhandenen Geräte und Entitäten sichtbar zu machen.

Beispielsweise Lampen:

jarvis ha list lights

Langfristig soll daraus natürlich mehr werden.

Dann könnte ich einfach sagen:

Schalte das Licht im Wohnzimmer ein.

Oder mehrere Funktionen miteinander kombinieren.

Zum Beispiel:

Ich gehe schlafen.

JARVIS könnte daraus irgendwann mehrere Aktionen ableiten.

Licht ausschalten.

Geräte prüfen.

Wecker beziehungsweise Termine berücksichtigen.

Morgenbriefing vorbereiten.

So weit ist es noch nicht.

Die Grundlage dafür entsteht aber gerade.

Mail bekommt eine eigene Vermittlungsschicht

Auch E Mail ist inzwischen ein Thema.

Dabei wollte ich jedoch vermeiden, dass der JARVIS Core direkt sämtliche Zugangsdaten verschiedener Mailserver verwalten muss.

Deshalb entsteht ein eigener Mail Broker.

Der Broker sitzt zwischen JARVIS und den eigentlichen Mailservern.

Das hat einen wichtigen Vorteil.

Ändert sich beispielsweise ein Passwort, muss nicht der komplette Core angepasst werden.

Der Broker kann außerdem kontrollieren, ob ein bestimmtes Konto überhaupt Nachrichten versenden darf.

Ist das nicht erlaubt, wird der Versand abgelehnt.

Damit entsteht erneut eine klare Trennung zwischen Assistent und externem Dienst.

Das System wird zunehmend modular

Wenn ich mir den aktuellen Aufbau ansehe, erkennt man langsam ein Muster.

Immer mehr Funktionen werden als eigenständige Bausteine behandelt.

Vereinfacht sieht das inzwischen ungefähr so aus:

                    Benutzer
                       |
        +--------------+--------------+
        |              |              |
     Web UI         Telegram       Satelliten
        |              |              |
        +--------------+--------------+
                       |
                  JARVIS Core
                       |
      +----------------+----------------+
      |                |                |
    Tools           Tasks          Voice
      |                |                |
      +----------------+----------------+
                       |
                  Provider
                       |
     +---------+-------+-------+---------+
     |         |       |       |         |
 Wetter   Kalender   HA     Plex    Aircraft

Das ist deutlich größer als ursprünglich geplant.

Aber genau diese Trennung macht die weitere Entwicklung inzwischen einfacher.

Und es gibt noch mehr Ideen

Natürlich ist die Liste der geplanten Funktionen inzwischen ebenfalls gewachsen.

Unter anderem stehen noch auf der Roadmap:

dynamisches Dashboard
Browser Integration
Astronomie
Mondphasen
Sonnenaufgang und Sonnenuntergang
Milchstraßensichtbarkeit
Raumstationsüberflüge
Raketenstarts
eigene Knowledgebase

Besonders interessant finde ich dabei die Knowledgebase.

Die Idee ist, JARVIS gezielt Informationen dauerhaft zur Verfügung zu stellen.

Zum Beispiel über eine Webseite:

Merke dir die wichtigen Informationen auf dieser Seite.

Diese Inhalte könnten anschließend lokal in einer eigenen Wissensbasis gespeichert werden.

Damit müsste das Sprachmodell solche Informationen nicht selbst kennen.

Wo steht JARVIS aktuell?

Aus dem ursprünglichen Experiment ist inzwischen ein ziemlich umfangreiches System geworden.

Aktuell gibt es unter anderem:

• einen zentralen Core
• Ollama als lokales Sprachmodell
• Wetter und Warnungen
• Kalender
• Routing
• Memory
• Tasks
• Telegram
• Home Assistant
• Aircraft Tracking
• Plex
• Medienwiedergabe
• einen Linux Satelliten
• einen ESP32 Satelliten
• STT
• TTS
• Wakeup
• dynamische Begrüßungen
• Stilleerkennung
• kontinuierliche Sprachinteraktion
• eine HTTP API
• WebSockets
• API Tokens und Scopes
• ein neues Command Center
• zentrale Einstellungen
• einen modularen Doctor
• einen externen Mail Broker

Einige dieser Bereiche sind bereits ziemlich weit.

Andere befinden sich noch mitten in der Entwicklung.

Aber genau deshalb dokumentiere ich das Projekt.

Nicht als fertiges Produkt.

Sondern als Weg dorthin.

Vom Experiment zur Plattform

Am Anfang wollte ich eigentlich nur wissen, wie realistisch diese ganzen selbst gebauten JARVIS Systeme aus den sozialen Medien wirklich sind.

Inzwischen habe ich meine Antwort darauf.

Ein persönlicher KI Assistent ist durchaus machbar.

Die eigentliche KI ist dabei überraschenderweise nicht einmal der komplizierteste Teil.

Viel mehr Arbeit steckt in all den Dingen drumherum.

Audio.

Authentifizierung.

APIs.

Fehlerbehandlung.

Hardware.

Dienste.

Berechtigungen.

Konfigurationen.

Netzwerkprobleme.

Und natürlich darin, alle Komponenten so miteinander zu verbinden, dass sie am Ende tatsächlich zuverlässig zusammenarbeiten.

Genau an diesem Punkt befindet sich JARVIS momentan.

Der Assistent bekommt immer mehr Fähigkeiten.

Die einzelnen Funktionen werden immer stärker miteinander verbunden.

Und das ursprüngliche Terminal Experiment entwickelt sich zunehmend zu einer eigenen Plattform.

Der Name JARVIS ist dabei übrigens weiterhin nur der aktuelle Arbeitsname.

Eine Umbenennung wird irgendwann kommen.

Welcher Name es am Ende wird, weiß ich allerdings selbst noch nicht.

Bis dahin bleibt es einfach:

Projekt JARVIS.