KI-Tools Praxis: Bye bye Alexa & Google

Kurzantwort

Alexa und Google Assistant werfen Werbung und ungewollte KI-Features in dein Wohnzimmer. Hier ist ein praxisnahes Homelab-Setup mit lokaler Sprachsteuerung, eigenem LLM und WAN-Bonding — kein Cloud-Zwang. Kurz gesagt: ki tools praxis ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Warum Alexa und Google Assistant gehen mussten

Im Dezember 2025 spielte Amazon Prime-Nutzern ohne Opt-out die KI-Assistentin Alexa+ auf ihre Echo-Geräte; Amazon hat dafür Werbeformate in Alexa+-Gesprächen angekündigt und KI-generierte Zusammenfassungen eingeführt. Google zog Ende 2025 nach: Die Gemini-Migration des Assistant wurde auf 2026 verschoben, der klassische Assistant soll im März 2026 abgeschaltet werden – mit wechselnder Funktionsverfügbarkeit je nach Region und Gerät. Für mich war das der Punkt, an dem aus Unbehagen eine handfeste Entscheidung wurde: Die Geräte fliegen raus, die Kontrolle kommt zurück ins eigene Netz.

Die Frage war nicht mehr ob, sondern wie. Kann man 2026 ein sprachgesteuertes Smart Home komplett lokal betreiben: mit Sprachbefehlen, einem eigenen KI-Modell für flexible Konversation und einem Netzwerk, das auch dann funktioniert, wenn der DSL-Anschluss ausfällt? Die kurze Antwort: Ja, mit Einschränkungen. Die lange Antwort ist dieser Artikel.

Was mich an der Cloud-Abhängigkeit am meisten störte, war nicht nur die Werbung. Es war die Kombination aus drei Faktoren: Ich bezahle für Hardware, die ich nicht kontrolliere. Ich trainiere mit jedem Sprachbefehl ein Modell, das mir nicht gehört. Und ich habe null Einfluss darauf, welche Funktion morgen verschwindet, weil ein Produktmanager eine Roadmap umwirft.

Das hier beschriebene Setup ist meine Antwort darauf. Es ist kein Baukasten, den man an einem Wochenende zusammensteckt. Es ist eine Architekturentscheidung: Sprache, KI und Netzwerk laufen auf eigener Hardware, mit eigenen Regeln, unter eigener Kontrolle. Drei Komponenten, die ineinandergreifen: ein redundantes WAN-Bonding als Netzwerk-Fundament, eine vollständig lokale Sprachpipeline für die tägliche Interaktion und ein selbst gehostetes LLM für die Fälle, in denen einfache Befehle nicht reichen. Dazu kommt Claude Code als Werkzeug für Wartung und Fehlerdiagnose: ein KI-Agent, der nicht das Smart Home steuert, sondern das Homelab selbst am Laufen hält.

Netzwerk-Fundament: DSL plus 5G als Bonding-Verbund

Bevor irgendein Docker-Container oder KI-Modell läuft, braucht das Homelab ein stabiles Netz. Mein Anschluss ist eine 70-MBit/s-DSL-Leitung: für den Alltag ausreichend, für Parallel-Lasten (Streaming, Remote-Zugriff, größere Downloads) aber spürbar knapp. Ein 5G-Router mit 250 MBit/s im Download lag nahe, aber zwei getrennte Internetzugänge sind nur so nützlich, wie man sie kombiniert.

Die naive Lösung ist Load Balancing: Traffic wird abwechselnd oder nach Regeln über beide Leitungen geschickt. Ein einzelner Download profitiert davon nicht; er läuft immer nur über eine der beiden Verbindungen. Load Balancing erhöht die Gesamtkapazität für viele parallele Verbindungen, nicht die Geschwindigkeit einer einzelnen.

Bonding dagegen bündelt beide WAN-Verbindungen zu einer logischen Leitung: Ein TCP-Stream wird in Pakete zerlegt und über beide Leitungen parallel übertragen. Die effektive Download-Geschwindigkeit liegt dann bei der Summe beider Leitungen minus Protokoll-Overhead. In der Praxis braucht Bonding einen Endpunkt auf der Gegenseite: einen Bonding-Server im Rechenzentrum oder einen VPN-Tunnel, der die Pakete wieder zusammensetzt.

Ich habe mich für eine Bonding-Konfiguration mit zwei WAN-Ports entschieden: DSL via PPPoE auf Port 1, der 5G-Router auf Port 2. Als Router-Plattform kommt RouterOS zum Einsatz, das Bonding über das integrierte Interface-Bonding-Modul unterstützt (802.3ad oder balance-rr, je nach Gegenseite). Die praktische Konsequenz: Ein 5-GB-Download läuft mit rund 300 MBit/s statt 70; vorausgesetzt, der Bonding-Tunnel steht sauber.

Was Bonding nicht löst: Latenz. Die round-trip time bleibt so hoch wie die langsamere der beiden Leitungen. Für Web-Browsing, Videocalls oder interaktive SSH-Sessions bringt Bonding keinen spürbaren Vorteil. Es ist eine Lösung für Durchsatz, nicht für Reaktionszeit.

Der zweite, für den Alltag oft wichtigere Vorteil: Failover. Fällt DSL aus, läuft der Traffic automatisch über 5G weiter, ohne manuellen Eingriff, ohne Verbindungsabbruch. In den letzten Wochen ist das dreimal passiert, jedes Mal unbemerkt von allen Geräten im Netz.

Feststellung nach zwei Monaten: Der Aufbau einer Bonding-fähigen Verbindung ist kein Nachmittagsprojekt. Bonding-Server mieten oder selbst hosten, Tunnel konfigurieren, MTU-Probleme mit 5G-Trägern debuggen: das ist Feinarbeit, kein Plug-and-Play. Der Aufwand lohnt sich dann, wenn man regelmäßig große Datenmengen bewegt oder auf die Kombination aus Bandbreite und Ausfallsicherheit angewiesen ist.

ki tools praxis – Illustration 2

Lokale Sprachsteuerung: Der Wyoming-Pipeline-Stack

Ein smartes Zuhause ohne Sprachsteuerung ist für einen Haushalt mit mehreren Personen kaum vermittelbar. Die mechanische Alternative (App auf, Gerät suchen, Schalter tippen) ist im Vergleich zu „Licht Wohnzimmer an" schlicht langsamer.

Home Assistant stellt seit 2023 (beginnend mit Version 2023.5) eine komplett lokale Sprachpipeline bereit, die sich in den letzten Jahren von experimentell zu alltagstauglich entwickelt hat. Der technische Unterbau heißt Wyoming-Protokoll, ein schlankes Peer-to-Peer-Protokoll aus dem Rhasspy-Projekt. Es verbindet vier Stufen zu einer Pipeline:

Wake Word: openWakeWord erkennt das Aktivierungswort (lokal, keine Cloud)
Speech-to-Text (STT): faster-whisper wandelt Sprache in Text
Intent-Handling / Conversation Agent: Entweder regelbasiert (deterministisch) oder über ein lokales LLM
Text-to-Speech (TTS): Piper oder Kokoro erzeugen die gesprochene Antwort

Alle vier Stufen laufen auf eigener Hardware. Nichts verlässt das LAN. Das ist kein Zukunftsszenario; es funktioniert Stand August 2026 mit Home Assistant Core 2026.7 und einer halbwegs aktuellen Installation.

Das Wyoming-Protokoll ist dabei der entscheidende Baustein. Es standardisiert die Kommunikation zwischen den Pipeline-Stufen, sodass STT, TTS und Wake-Word-Erkennung als austauschbare Dienste laufen. openWakeWord etwa hört dauerhaft auf das Aktivierungswort und triggert die Pipeline nur dann, wenn es tatsächlich erkannt wurde: kein permanenter Audiostream ins Netz. faster-whisper bekommt den Audiostream nur für die Dauer des Befehls. Piper generiert die Sprachausgabe und gibt sie an das Voice-Gerät zurück. Jede Stufe läuft als separater Prozess; fällt eine aus, bleiben die anderen funktionsfähig.

Ein wichtiger Unterschied zur Cloud: openWakeWord erkennt nur das antrainierte Aktivierungswort (typischerweise „Ok Nabu" oder ein eigenes). Es versteht keine Kontextwechsel, keine Kettenbefehle, keine Sprecheridentifikation. Wer „Alexa, Licht an und spiel Jazz" gewohnt ist, muss sich umgewöhnen: Ein Befehl, eine Aktion.

Für die Hardware gibt es zwei Wege: Entweder man nutzt das offizielle Home Assistant Voice Preview Edition (Voice PE), ein ESP32-S3-basiertes Gerät mit XMOS-Audio-Prozessor für rund 59 USD, das per ESPHome und Wyoming direkt an den HA-Server angebunden wird. Oder man baut mit einem ESP32-S3-BOX-3 oder Raspberry Pi Zero 2 W eigene Satelliten; der Wyoming-Discovery-Mechanismus findet den HA-Server automatisch.

Ich verwende das Voice PE in der Küche und einen selbst geflashten ESP32-S3-BOX im Wohnzimmer. Die Einrichtung beider Geräte dauert mit ESPHome-Firmware und Wyoming-Integration etwa 20 Minuten pro Stück. Die Spracherkennung mit faster-whisper (small-Modell) liegt auf einem Intel N100 bei 800-1200 ms Verarbeitungszeit pro Befehl. Das ist langsamer als Amazons cloud-gestützte Erkennung, aber nah genug an „gefühlter Echtzeit", dass es im Alltag nicht stört.

Der entscheidende Punkt bei der lokalen Pipeline: Sie ist deterministisch, nicht konversationell. „Licht Küche an" funktioniert zuverlässig. „Mach es hier drin ein bisschen heller" ohne Benennung des Raums scheitert; das braucht ein LLM als Conversation Agent.

Wenn die KI einziehen soll: Lokales LLM mit Ollama

Wer mehr will als starre Sprachbefehle, braucht ein Sprachmodell, das Absicht erkennt statt Keywords zu matchen. Home Assistant kann seit Version 2025.9 ein Ollama-Modell als Conversation Agent einbinden. Das läuft dann so: Ein Sprachbefehl wird als Text an das LLM geschickt, das Modell interpretiert die Absicht und ruft die entsprechenden Home-Assistant-Services auf: Licht schalten, Thermostat setzen, Szenen aktivieren.

Die Ollama-Integration in Home Assistant ist inzwischen gut integriert; die Gerätesteuerung über die Assist-API führt Home Assistant offiziell noch als experimentell. Sie läuft als Add-on oder als externer Docker-Container, registriert sich als Conversation Agent und nutzt die Assist-API von Home Assistant, um auf Geräte und Entitäten zuzugreifen. Welche Entitäten das Modell ansteuern darf, steuert man in der HA-Konfiguration: Nur freigegebene Bereiche und Geräte sind für das LLM erreichbar. Das ist keine optionale Sicherheitsmaßnahme; ein unkontrolliertes LLM mit Zugriff auf alle Entitäten könnte Szenarien auslösen, die man nicht intendiert hat (Garagentor bei Abwesenheit öffnen, Heizung im Sommer auf Maximum setzen).

Die Qualität der Antworten hängt stark vom System-Prompt ab. Das Modell muss wissen, welche Räume existieren, welche Geräte in welchem Raum sind und welche Aktionen erlaubt sind. Ohne strukturierte Vorgabe neigen selbst 8B-Modelle zu Halluzinationen; sie erfinden Räume oder schlagen Aktionen vor, die mit der tatsächlichen HA-Konfiguration nichts zu tun haben. Mein Prompt spezifiziert explizit: Räume, Gerätetypen, keine Aktionen ohne Bestätigung bei sicherheitsrelevanten Geräten (Türschlösser, Garagentor), keine erfundenen Entitäten.

Welches Modell? Mit Stand Juli 2026 sind Qwen 3 (8B) und Llama 3.1 (8B) die praktikabelsten Optionen für ein Homelab. Beide Modelle beherrschen Function Calling und laufen auf Consumer-Hardware. Ein aktueller Mini-PC mit 32 GB RAM und einer NVIDIA RTX 4060 (8 GB VRAM) verarbeitet Anfragen in 2-4 Sekunden. Ohne GPU, also nur mit CPU-Inferenz, werden es eher 8-15 Sekunden, abhängig von Modellgröße und Prompt-Länge. Für die reine Gerätesteuerung reicht auch ein kleineres Modell (3B-Parameter-Klasse) auf einem Raspberry Pi 5 mit 8 GB RAM, sofern man mit höherer Latenz leben kann.

Der qualitative Sprung gegenüber der deterministischen Pipeline: „Mir ist kalt" schaltet nicht stumpf die Heizung ein, sondern fragt nach, in welchem Raum, auf welche Temperatur, für wie lange; oder es schlägt vor, stattdessen das Fenster zu schließen, weil der Fenstersensor „offen" meldet. Das fühlt sich nach Hausverstand statt nach Endlos-if-then-Kette an.

Der Betriebszustand 2026 ist aber: Noch ist es kein Alexa-Ersatz. Musik abspielen per Spracheingabe? Nur mit Bastelarbeit. Timersetzung über Räume hinweg? Funktioniert, aber unzuverlässig bei komplexer Formulierung. Wetterabfrage oder Kalenderzugriff? Geht mit Integration, scheitert aber gelegentlich an fehlenden Entitäten oder API-Lücken. Wer Alltagsfragen à la „Wie spät ist es in Tokio?" erwartet, wird enttäuscht; dafür ist ein lokales LLM ohne Internetzugriff nicht gemacht.

Claude Code im Homelab: Ein KI-Agent für die Infrastruktur

Die interessanteste Entwicklung der letzten Monate war nicht die Sprachsteuerung, sondern der Einzug von Coding-Agenten ins Homelab-Management. Claude Code, Anthropics terminalbasiertes Agenten-Tool, versteht Bash, Docker, Konfigurationsdateien und git. Es kann keine Geräte schalten, aber es kann Docker-Compose-Dateien analysieren, Backup-Skripte debuggen, Nginx-Konfigurationen prüfen und Monitoring-Dashboards vorschlagen.

Ich habe Claude Code inzwischen fest in meinen Workflow integriert. Konkret: Jede Änderung an einer Docker-Compose-Konfiguration läuft vor dem Deployment durch einen Review-Schritt. Backup-Skripte werden auf race conditions geprüft, bevor sie im Cron landen. Netzwerkprobleme wie Paketverluste beim Bonding-Tunnel oder DNS-Fehler nach Failover diagnostiziert Claude Code anhand von Logs und schlägt Korrekturen vor, die ich dann manuell anwende oder verwerfe.

Das ist kein Autopilot. Claude Code trifft keine eigenständigen Infrastrukturentscheidungen und führt keine unbeaufsichtigten Änderungen am laufenden System durch. Aber es reduziert die Zeit für Fehlersuche und Konfigurationsarbeit erheblich, besonders bei Themen, die nicht täglich anfallen (SSL-Zertifikate erneuern, Docker-Volume-Bereinigung, Log-Rotation). Der Agent arbeitet innerhalb des Terminals, liest und editiert Dateien und kann Befehle ausführen; ich lasse das nur mit explizitem Approval und in einem dedizierten Homelab-User-Kontext zu.

Ein konkretes Beispiel: Vor zwei Wochen fiel nach einem Stromausfall der gesamte Docker-Stack aus; die Container starteten in falscher Reihenfolge, Abhängigkeiten brachen auf, Home Assistant kam nicht hoch. Statt 40 Minuten Log-Dateien zu durchforsten, habe ich Claude Code die docker-compose.yml und die Boot-Logs gegeben. Die Diagnose (falsche depends_on-Ketten und fehlende healthchecks) kam in unter einer Minute, der Patch-Vorschlag inklusive. Ich habe die Änderungen geprüft und übernommen, der Stack lief wieder.

Die Grenzen zeigen sich bei physischer Hardware: Ein defekter Switch-Port, ein lockeres SFP-Modul, ein überhitzter 5G-Router; das findet Claude Code nicht, weil die Symptome in den Logs nicht von einem Software-Fehler unterscheidbar sind. Die Verbindung zum physischen Layer fehlt. Bei rein softwarebasierten Problemen (Konfiguration, Abhängigkeiten, Syntax, Protokoll-Debugging) ist das Werkzeug dagegen präzise und schnell.

Für die Praxis bedeutet das: Statt eine Stunde in Stack-Overflow-Threads und Manpages zu versinken, formuliere ich das Problem, Claude Code schlägt eine Lösung vor und zeigt den Diff. Ich prüfe und bestätige. Das spart Zeit bei Wartungsarbeiten und senkt die Wahrscheinlichkeit für Konfigurationsfehler durch Copy-Paste.

Was das Setup kostet

Ein vollständig lokales Homelab mit Sprachsteuerung, LLM und redundanter Netzwerkanbindung kostet mehr als drei Echo Dots. Hier die groben Hardware-Posten, wie sie bei mir stehen:

Router + Switch: MikroTik RB5009 (~200 €) für Bonding/VLAN/Routing; ein gemanagter 8-Port-Switch (~80 €)
5G-Router: ZTE MU5001 oder baugleich (~260 €, gebraucht ab 150 €)
Homelab-Server: Intel N100 Mini-PC mit 32 GB RAM (~350 €) für Home Assistant, Ollama, Docker-Stack
GPU für LLM-Inferenz: NVIDIA RTX 4060 (~320 €), optional, ohne GPU läuft es, aber langsamer
Voice-Hardware: 1x Voice PE (~59 €), 1x ESP32-S3-BOX-3 (~45 €)
Speicher: 2x 1 TB NVMe SSD (~120 €) für VMs, Container-Volumes, Backups

Summe: rund 1.420 Euro mit GPU, etwa 1.100 ohne. Dazu kommen monatlich der 5G-Tarif (10-20 €) und der Bonding-Server (~5 € bei günstigen VPS-Anbietern). Stromverbrauch des gesamten Stacks liegt im Idle bei etwa 45 Watt, unter Last (LLM-Inferenz) bei 80-95 Watt, je nach GPU-Auslastung.

Das ist kein Schnäppchen. Aber es ist eine einmalige Investition gegen ein laufendes Abo-Modell, bei dem ein Konzern entscheidet, wann Werbung eingespielt wird und wann nicht.

Was funktioniert, und was (noch) nicht

Nach zwei Monaten Dauerbetrieb die ehrliche Bilanz:

Funktioniert gut:

Determinierte Sprachbefehle (Licht, Szenen, Thermostate, Rollläden): zuverlässig und schnell
WAN-Bonding für große Downloads und Failover: seit Einrichtung kein ungeplanter Ausfall
Lokales LLM für kontextbewusste Gerätesteuerung bei klaren, einfachen Befehlen
Claude Code als Diagnose- und Review-Werkzeug für Docker, Backups und Konfigurationen

Funktioniert mit Einschränkungen:

Sprachbefehle bei Hintergrundgeräuschen oder aus größerer Entfernung als 3 Meter; die Mikrofone der Voice PE sind ordentlich, aber nicht mit Echo-Studio-Hardware vergleichbar
Interaktionen, die externe APIs brauchen (Wetter, Verkehr, Spracherkennung für Eigennamen); das LLM hat ohne Internet nur das Wissen aus dem Training
Musik-Sprachsteuerung; Music Assistant als HA-Integration existiert, aber die Befehlserkennung für Playlists, Alben oder Interpreten ist brüchig

Funktioniert nicht oder nur mit Tagesprojekt:

Mehrpersonen-Haushalt mit Sprechererkennung; ein ausgereiftes lokales Äquivalent zu Amazons Voice-ID fehlt noch (erste Community-Projekte existieren)
Sprachbefehle, die zeitgleich über mehrere Räume laufen sollen („Im ganzen Haus Licht aus")
Natürlichsprachliche Konversation, die Smalltalk, Faktenfragen und Gerätesteuerung in einem Modell vereint; die Latenzen werden zu hoch oder das Modell zu groß für bezahlbare Hardware

Die ehrliche Empfehlung: Wer ein reines „Licht an, Licht aus"-Setup hat, braucht kein LLM und keinen Bonding-Tunnel. Home Assistant mit deterministischer Pipeline und einem einzigen WAN-Anschluss tut es für unter 300 Euro Hardware. Der Mehrwert des kompletten Stacks entsteht erst bei Haushalten, die entweder alle Cloud-Abhängigkeiten konsequent kappen wollen oder deren Netz- und Steuerungsanforderungen über einfache Regeln hinausgehen.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Quellen

ki tools praxis – Illustration 3

Weiterführende Artikel

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du ki tools praxis nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.