Algroveon-Dashboard – Heimserver-Display für Familie und Haushalt

Die Idee hinter dem Display

Wo früher im Flur oft die Pinnwand für die Familie hing, steht heute zur besseren Organisation des Alltags ein digitales Display als Familien-Hub: Regenjacke oder nicht? Welche U-Bahn? Wann ist der nächste Arztbesuch? Es ist als zentraler Familienbildschirm gedacht und zeigt Kalender, ÖPNV-Abfahrtszeiten, Wetter, Familienfotos, Spotify und weitere Informationen, die im Alltag schnell relevant sind. Technisch basiert das System auf einem Raspberry Pi 5 mit 10,1-Zoll-DSI-Touchscreen, eingebaut in ein selbst konstruiertes, 3D-gedrucktes Gehäuse, das bewusst eher wie ein schlichter Bilderrahmen wirkt als wie ein klassischer Bildschirm.

Warum kein fertiges System

HomeAssistant kann Dashboards. Es gibt fertige Panel-Lösungen, kommerzielle Smart-Display-Produkte und Tablet-Mounts mit verschiedenen Apps. Keines davon hat für mich wirklich gepasst – nicht, weil diese Lösungen schlecht wären, sondern weil mir bei den entscheidenden Punkten die Kontrolle gefehlt hätte.

Der wichtigste Punkt war die Sprachverarbeitung. Mir ging es hier um eine Lösung, die lokal funktioniert und trotzdem möglichst flott reagiert. Gerade weil das Gerät im Flur hängt, also an einem Ort, an dem im Alltag zwangsläufig auch private Gespräche stattfinden, war der Rückgriff auf ein klassisches Cloud-System für mich keine sinnvolle Option. Der Algroveon-Agent auf dem Heimserver war dafür die deutlich passendere Grundlage.

Der zweite Punkt war das Design. Kachelbasierte HomeAssistant-Dashboards sind funktional, aber vieles ist dort zu starr vordefiniert oder führt in eine Abhängigkeit von externen Entwicklern, die solche Projekte nicht selten nur in ihrer Freizeit pflegen. Gerade im Umfeld kleinerer Erweiterungen und Community-Projekte, etwa rund um HACS, sieht man über die Zeit immer wieder, dass Lösungen eingestellt werden oder schlicht versanden. Mir fehlte eine konsistente visuelle Sprache, die aus einer Ansammlung von Funktionen tatsächlich ein eigenes Gerät macht.

Der dritte Punkt war die Erweiterbarkeit. Sprechererkennung, personalisierter Kontext pro Familienmitglied oder ein Bewegungssensor zum Aufwecken des Displays sind keine Dinge, die man bei fertigen Lösungen einfach sauber dazusteckt. Dazu kam, dass ich bewusst kein Tablet als Basis verwenden wollte – unter anderem wegen der Akku-Degradation, die bei einem Gerät im Dauerbetrieb absehbar zum Thema wird.

Die Entscheidung fiel deshalb auf Eigenentwicklung: Raspberry Pi 5 als Frontend-Hardware, PyQt6/QML für das UI und der lokale KI-Heimserver für die Sprachverarbeitung.

Der Heimserver als Rückgrat

Die wichtigste Architekturentscheidung war die Aufgabentrennung. Der Pi übernimmt das UI und die Audio-Ein- und Ausgabe. Den Rest macht der Heimserver im Hintergrund.

Die Voice-Pipeline läuft vollständig lokal über HTTP/REST im Heimnetz:

Wake-Word – Die Wake-Word-Erkennung läuft lokal, ohne dass dafür ein externer Netzwerkaufruf nötig ist.
STT – Das Audio geht an Faster-Whisper auf dem Heimserver.
LLM – Die Transkription geht an Ollama mit Gemma 4 auf dem Heimserver.
TTS – Die Antwort geht an Piper TTS auf dem Heimserver. Für die deutsche Stimme kommt Thorsten zum Einsatz, die Audiodatei kommt zurück.

Die rechenintensiven Schritte passieren bewusst auf dem Heimserver. Ein wichtiger Baustein ist dabei auch das ReSpeaker XVF3800 USB Mic Array. Gerade bei Sprachsteuerung im Flur macht die Qualität der Audioaufnahme einen spürbaren Unterschied. Sie hilft dabei, dass Erkennung und Reaktion im Alltag zuverlässig genug funktionieren. Genau das macht die Lösung insgesamt schnell genug, dass ein natürlicher Gesprächsfluss entsteht, statt jeder Antwort hinterherzuwarten.

Das hat einen sehr praktischen Vorteil: Der Pi bleibt günstig, kompakt und stromsparend. Er braucht keine GPU und keinen großen Arbeitsspeicher. Gleichzeitig ist jede ernsthafte KI-Lösung direkt auf dem Pi in diesem Szenario noch immer zu langsam, um mit dem privaten Heimserver mitzuhalten – vor allem dann, wenn Spracheingabe, Sprachausgabe und LLM-Antworten flüssig zusammenspielen sollen. Wenn der Heimserver einmal nicht erreichbar ist, läuft das Dashboard trotzdem weiter – dann eben als reines Informations-Panel ohne Sprachassistenten.

Gleichzeitig gilt: Kein Sprachinhalt verlässt das Heimnetz. Faster-Whisper, Gemma 4 und Piper laufen vollständig auf eigener Hardware. Das bedeutet aber nicht automatisch, dass damit Datensicherheit garantiert wäre. Wer so eine Lösung selbst betreibt, ist auch selbst dafür verantwortlich, den Heimserver und das eigene Netzwerk sicher zu konfigurieren – denn natürlich kann auch ein privates Heimnetz kompromittiert werden.

Das UI: QML als Entscheidung

Die Wahl der UI-Technologie war offen. Tkinter wäre einfacher gewesen. Ein browserbasiertes Interface mit Flask und HTMX hätte näher an meinen anderen Projekten gelegen.

Die Entscheidung fiel trotzdem auf PyQt6/QML – nicht nur wegen der guten Performance auf ARM, sondern auch, weil ich damit bereits sehr gute Erfahrungen gemacht habe und inzwischen die meisten meiner Projekte auf dieser Basis umsetze. Auf dem Raspberry Pi läuft das Interface mit EGLFS ohne klassischen Desktop-Stack wie X11. Das sorgt in dieser Konfiguration für eine direkte und flüssige Darstellung. Animationen, Theme-Wechsel und Touch-Reaktionen wirken dadurch deutlich unmittelbarer als bei manch schwergewichtigerer Alternative.

QML hat allerdings eine steile Lernkurve, vor allem in der Verbindung zum Python-Backend über Signals und Slots. Das Qt Meta-Object-System ist mächtig, aber ungewohnt, wenn man nicht aus dieser Welt kommt. Das Grundprinzip ist am Ende aber klar: Python emittiert Signale mit Daten, QML reagiert darauf und aktualisiert die Darstellung. QML ruft Slots auf, Python führt die Logik aus. Wenn man das einmal sauber getrennt hat, bleibt das System gut beherrschbar. Gerade bei dieser Art von Struktur hat sich für mich auch gezeigt, dass Claude Code damit erstaunlich gut umgehen kann.

Die zentrale DashboardBridge-Klasse ist dabei der einzige Verbindungspunkt. QML hat keinen direkten Datenbankzugriff, macht keine eigenen HTTP-Anfragen und enthält keine Business-Logik. Das hält den Frontend-Code klein, klar und testbar.

Design als System

Das visuelle Konzept orientiert sich an Material Design 3, aber in einer eigenen Ausprägung: klare Karten, starke Kontraste, wenig visuelle Ablenkung. Zwei Themes wechseln um 06:00 und 20:00 Uhr automatisch.

Alle Design-Entscheidungen sind in Theme.qml als Design-Tokens zentralisiert: Farben, Abstände, Radien, Animationsdauern. Kein Widget hat hart codierte Farbnamen. Das bedeutet: Ein Theme-Wechsel passiert an einer Stelle, und alle Komponenten folgen.

Dazu kommen konfigurierbare Profile:

motionMode (normal / reduced / off) – für unterschiedliche Performance-Situationen
densityMode (compact / normal / comfortable) – für verschiedene Informationsdichten

Neue Widgets müssen einem klaren Regelwerk folgen: auf WidgetCard basieren, keine eigenen Farben außerhalb von Theme, und sie müssen auch ohne aktive Bridge absturzfrei rendern. Das verhindert, dass jedes neue Feature das visuelle System Stück für Stück wieder aufweicht.

Power Management und Bewegungssensor

Ein dauerhaft aktives Display verbraucht nicht nur Energie, sondern ist für ein Display im Flur letztlich auch unnötig. Drei Betriebsmodi lösen das:

Active – volle Benutzeroberfläche, alle Widgets aktiv, Sprachassistent einsatzbereit. Idle – Foto-Slideshow läuft als Hintergrundbild, Uhrzeit und Wetter bleiben sichtbar. Sleep – Display dunkel, System läuft weiter.

Der Wechsel zwischen den Modi passiert per Timeout oder über den Bewegungssensor: Ein ESP32 mit LD2450-Radarsensor erkennt Personen im Flur berührungslos und ohne Kamera. Das Display wacht auf, sobald jemand vorbeigeht.

Sprechererkennung: Wer spricht gerade?

Ein Familien-Dashboard, das jeden gleich behandelt, ist am Ende kein besonders gutes Familien-Dashboard. Wenn ein Kind fragt „Was machen wir heute?“ und ein Erwachsener dieselbe Frage stellt, können sinnvolle Antworten unterschiedlich aussehen. Dafür muss das System zumindest grob einschätzen können, wer gerade spricht.

Die Lösung: resemblyzer läuft vollständig lokal auf dem Pi. Die Bibliothek berechnet aus dem aufgenommenen Audio einen 256-dimensionalen Stimmvektor (d-vector) und vergleicht ihn per Cosine-Similarity mit gespeicherten Profilen. Liegt das beste Match über einem konfigurierbaren Schwellwert, gilt die Person als erkannt.

Die Profile liegen als NumPy-Arrays (.npy-Dateien) auf dem Pi. Es wird kein Audio dauerhaft gespeichert und nichts in eine Cloud hochgeladen. Das Enrollment läuft einmalig über ein Kommandozeilen-Tool: fünf bis zehn Sätze sprechen, Durchschnittsvektor speichern.

Die praktische Erkenntnis dabei: Sprechererkennung funktioniert gut bei klarem, direktem Audio. Bei Hintergrundgeräuschen – laufender Fernseher, Stimmen aus anderen Räumen, Küchensituation – sinkt die Erkennungsrate spürbar.

Das Gedächtnissystem

Damit das System nicht bei jedem Gespräch wieder bei null beginnt, gibt es ein lokales Memory-System. Fakten, Präferenzen und Notizen werden pro Familienmitglied gespeichert – in einer JSON-Datei, manuell editierbar und ohne zusätzlichen Datenbankserver.

Die semantische Suche bei einer Anfrage läuft über sentence-transformers lokal auf dem Pi: Der aktuelle Sprachinput wird eingebettet, danach werden die relevantesten Einträge aus dem Memory per Cosine-Similarity gezogen. Als Fallback gibt es eine BM25-Keyword-Suche. Das Ergebnis ist ein kompakter Kontext-Block, der als Teil des System-Prompts an das LLM geht.

Vier Kategorien strukturieren das Ganze: fact (relativ stabile Fakten), preference (Vorlieben), restriction (Einschränkungen, zum Beispiel für kindgerechte Inhalte) und note (allgemeine Notizen). Der Scope ist entweder personenspezifisch oder geteilt für alle.

Was funktioniert, was noch nicht

Funktioniert zuverlässig:

Touch-UI mit allen Widgets
Auto-Theme (hell/dunkel)
ÖPNV, Wetter, Uhrzeit
Home Assistant Integration
Google Calendar
Spotify-Steuerung
Power Management und Bewegungssensor
Sprachassistent für einfache Kommandos

Noch in Arbeit:

Wake-Word-Zuverlässigkeit: funktioniert bereits recht gut und nicht wesentlich schlechter als bekannte Systeme am Markt
Personalisierung vollständig ausbauen: Memory-System steht, die Integration in alle Antwortpfade läuft noch
Sprachinteraktion: Reaktion und Antworten folgen zwar schnell, aber Sinnhaftigkeit und Verständlichkeit sind noch nicht durchgehend auf dem Niveau, das ich mir für den Alltag wünsche. Vieles wirkt noch zu technisch – ein Punkt, an dem im Übrigen auch etablierte Anbieter nach wie vor erkennbar zu kämpfen haben