Algroveon Dashboard – Home Server Display for Family and Household

The Idea Behind the Display

Where a family bulletin board used to hang in the hallway, a digital display now serves as a family hub for better daily organization: Rain jacket or not? Which subway? When is the next doctor's appointment? It is designed as a central family screen, showing calendars, public transport departure times, weather, family photos, Spotify, and other information that is quickly relevant in everyday life. Technically, the system is based on a Raspberry Pi 5 with a 10.1-inch DSI touchscreen, built into a custom 3D-printed enclosure that is intentionally designed to look more like a simple picture frame than a classic monitor.

Why Not a Ready-Made System?

HomeAssistant can do dashboards. There are ready-made panel solutions, commercial smart display products, and tablet mounts with various apps. None of them really fit for me—not because these solutions are bad, but because I would have lacked control over the decisive points.

The most important point was voice processing. I was looking for a solution that works locally and yet reacts as quickly as possible. Precisely because the device hangs in the hallway—a place where private conversations inevitably take place during daily life—relying on a classic cloud system was not a sensible option for me. The Algroveon agent on the home server provided a much more suitable foundation for this.

The second point was design. Tile-based HomeAssistant dashboards are functional, but much of it is too rigidly predefined or leads to a dependency on external developers who often maintain such projects only in their spare time. Especially in the environment of smaller extensions and community projects, such as those around HACS, you see time and again that solutions are discontinued or simply fade away. I lacked a consistent visual language that turns a collection of functions into an actual standalone device.

The third point was extensibility. Speaker recognition, personalized context per family member, or a motion sensor to wake the display are not things you can just cleanly plug into ready-made solutions. Additionally, I deliberately did not want to use a tablet as a base—partly due to battery degradation, which becomes an inevitable issue with a device in continuous operation.

The decision therefore fell on custom development: Raspberry Pi 5 as the frontend hardware, PyQt6/QML for the UI, and the local AI home server for voice processing.

The Home Server as the Backbone

The most important architectural decision was the separation of tasks. The Pi handles the UI and the audio input/output. The home server does the rest in the background.

The voice pipeline runs entirely locally via HTTP/REST on the home network:

Wake-Word – Wake-word detection runs locally without requiring an external network call.
STT – The audio goes to Faster-Whisper on the home server.
LLM – The transcription goes to Ollama with Gemma 4 on the home server.
TTS – The response goes to Piper TTS on the home server. For the German voice, "Thorsten" is used, and the audio file is sent back.

The computationally intensive steps are deliberately performed on the home server. An important component here is also the ReSpeaker XVF3800 USB Mic Array. Especially with voice control in the hallway, the quality of audio recording makes a noticeable difference. It helps ensure that recognition and reaction function reliably enough in everyday life. This is exactly what makes the solution fast enough overall to create a natural conversational flow, rather than waiting after every response.

This has a very practical advantage: The Pi remains inexpensive, compact, and power-efficient. It doesn't need a GPU or large amounts of RAM. At the same time, any serious AI solution running directly on the Pi in this scenario would still be too slow to keep up with a private home server—especially when voice input, voice output, and LLM responses need to work together fluidly. If the home server is unavailable, the dashboard continues to run—just as a pure information panel without a voice assistant.

At the same time: No voice content leaves the home network. Faster-Whisper, Gemma 4, and Piper run entirely on proprietary hardware. However, this does not automatically mean that data security is guaranteed. Anyone operating such a solution themselves is also responsible for securely configuring the home server and their own network—because, of course, a private home network can also be compromised.

The UI: QML as a Decision

The choice of UI technology was open. Tkinter would have been easier. A browser-based interface with Flask and HTMX would have been closer to my other projects.

Nevertheless, the decision fell on PyQt6/QML—not only because of the good performance on ARM, but also because I have already had very good experiences with it and now implement most of my projects on this basis. On the Raspberry Pi, the interface runs with EGLFS without a classic desktop stack like X11. In this configuration, that ensures a direct and fluid display. Animations, theme changes, and touch reactions thus feel significantly more immediate than with many heavier alternatives.

However, QML has a steep learning curve, especially regarding the connection to the Python backend via signals and slots. The Qt Meta-Object System is powerful but unfamiliar if you don't come from that world. Ultimately, the basic principle is clear: Python emits signals with data, QML reacts to them and updates the display. QML calls slots, Python executes the logic. Once you have separated this cleanly, the system remains well-manageable. Especially with this type of structure, I have found that Claude Code can handle it surprisingly well.

The central DashboardBridge class is the only connection point. QML has no direct database access, makes no HTTP requests of its own, and contains no business logic. This keeps the frontend code small, clear, and testable.

Design as a System

The visual concept is oriented towards Material Design 3, but in its own expression: clear cards, strong contrasts, minimal visual distraction. Two themes switch automatically at 06:00 and 20:00.

All design decisions are centralized in Theme.qml as design tokens: colors, spacing, radii, animation durations. No widget has hard-coded color names. This means: A theme change happens in one place, and all components follow.

In addition, there are configurable profiles:

motionMode (normal / reduced / off) – for different performance situations
densityMode (compact / normal / comfortable) – for different information densities

New widgets must follow a clear set of rules: they must be based on WidgetCard, use no custom colors outside of Theme, and must render without crashing even without an active bridge. This prevents every new feature from gradually eroding the visual system.

Power Management and Motion Sensor

A permanently active display not only consumes energy but is ultimately unnecessary for a display in a hallway. Three operating modes solve this:

Active – full user interface, all widgets active, voice assistant ready. Idle – photo slideshow runs as background, time and weather remain visible. Sleep – display dark, system continues to run.

The switch between modes happens via timeout or via the motion sensor: An ESP32 with an LD2450 radar sensor detects people in the hallway without contact and without a camera. The display wakes up as soon as someone passes by.

Speaker Recognition: Who is speaking right now?

A family dashboard that treats everyone the same is ultimately not a particularly good family dashboard. If a child asks "What are we doing today?" and an adult asks the same question, meaningful answers can look different. To achieve this, the system must be able to at least roughly estimate who is currently speaking.

The solution: resemblyzer runs entirely locally on the Pi. The library calculates a 256-dimensional voice vector (d-vector) from the recorded audio and compares it via cosine similarity with stored profiles. If the best match is above a configurable threshold, the person is considered recognized.

The profiles are stored as NumPy arrays (.npy files) on the Pi. No audio is stored permanently, and nothing is uploaded to a cloud. Enrollment is a one-time process via a command-line tool: speak five to ten sentences, save the average vector.

The practical insight here: Speaker recognition works well with clear, direct audio. With background noise—a running TV, voices from other rooms, kitchen situations—the recognition rate drops noticeably.

The Memory System

To prevent the system from starting from scratch with every conversation, there is a local memory system. Facts, preferences, and notes are stored per family member—in a JSON file, manually editable and without an additional database server.

Semantic search for a query runs via sentence-transformers locally on the Pi: The current voice input is embedded, after which the most relevant entries from the memory are retrieved via cosine similarity. As a fallback, there is a BM25 keyword search. The result is a compact context block that is sent to the LLM as part of the system prompt.

Four categories structure the whole thing: fact (relatively stable facts), preference (preferences), restriction (restrictions, for example for child-friendly content), and note (general notes). The scope is either person-specific or shared for everyone.

What Works, What Doesn't Yet

Works reliably:

Touch UI with all widgets
Auto-theme (light/dark)
Public transport, weather, time
Home Assistant integration
Google Calendar
Spotify control
Power management and motion sensor
Voice assistant for simple commands

Still in progress:

Wake-word reliability: already works quite well and is not significantly worse than well-known systems on the market
Fully expanding personalization: the memory system is in place, integration into all response paths is still ongoing
Voice interaction: although reactions and answers are fast, the meaningfulness and comprehensibility are not yet consistently at the level I desire for everyday use. Much of it still feels too technical—a point where, incidentally, established providers also still clearly struggle