So stoppst du heimliche datenübermittlungen im homeassistant und stellst automatisierungen datensparend wieder her

Heimliche Datenübermittlungen in Home Assistant sind für mich eines der unangenehmsten Probleme: Du glaubst, dein Smart‑Home läuft lokal, und plötzlich wandern Telemetriedaten, API‑Calls oder Meta‑Informationen ins Netz. In diesem Beitrag zeige ich dir, wie ich solche Lecks aufspüre, eliminiere und Automatisierungen so wiederherstelle, dass sie datensparsam und lokal funktionieren.

Warum du prüfen solltest, ob Daten heimlich übertragen werden

Als Technikjournalistin habe ich oft Systeme gesehen, die mehr Daten nach außen schicken als nötig. Bei Home Assistant sind die üblichen Ursachen: Cloud‑Integrationen (z. B. Home Assistant Cloud / Nabu Casa), Gerätetreiber mit Cloud‑Fallback (Smart‑Plugs, Kameras), Drittanbieter‑Integrationen oder Telemetrie‑Module. Auch Add‑ons wie Voice‑Assistants, externe APIs oder Drittanbieter‑Cloud‑Dienste in Automatisierungen können heimlich Daten weiterreichen. Ein bewusster Umgang schützt deine Privatsphäre und reduziert Abhängigkeiten von externen Diensten.

Schritt 1 — Sichtbarer Check: Integrationen, Add‑ons und Cloud‑Konten

Als erstes schaue ich in die Offene Integrationen-Liste von Home Assistant:

Öffne Einstellungen → Geräte & Dienste → Integrationen und scanne die Einträge nach Cloud‑Anbindungen (z. B. Philips Hue Bridge bindet lokal, manche Xiaomi‑Integrationen nutzen aber Cloud‑APIs).

Kontrolliere unter Einstellungen → System → Add‑ons, Backups & Supervisor, welche Add‑ons laufen. Viele Add‑ons haben eigene Update‑ oder Telemetrie‑Optionen.

Wenn du Nabu Casa benutzt: das ist bequem, aber sendet Daten an die Nabu‑Casa‑Server. Deaktiviere es, wenn du komplett lokal bleiben willst.

Schritt 2 — Netzwerkanalyse: Welche Verbindungen werden aufgebaut?

Ich empfehle, kurz dein Heimnetz zu überwachen. Tools, die ich nutze:

Pi‑Hole (als DNS‑Sinkhole) zum Erkennen ungewöhnlicher DNS‑Anfragen.

tcpdump / Wireshark für detaillierte Paketanalysen — nützlich, wenn du gezielt eine Integration verdächtigst.

Router‑Logs oder ein Managed Switch mit Flussüberwachung.

Praktischer Tipp: Erstelle temporäre Firewall‑Regeln, die Home Assistant an das Internet blockieren, um zu sehen, welche Automationen oder Integrationen unterbrechen. Das verrät schnell, wer auf Remote‑Dienste angewiesen ist.

Schritt 3 — Home Assistant interne Logs und die Recorder‑Daten

Home Assistant protokolliert viele Aktivitäten. Schau in:

Einstellungen → System → Protokolle (oder die logfile im config‑Verzeichnis).

Die add‑on‑Logs, z. B. von Node‑RED, Zigbee2MQTT oder ESPHome.

Die Recorder‑Komponente speichert Ereignisse in der DB. Ich prüfe, welche Entitäten besonders viele Einträge erzeugen — das kann auf Chatty Devices oder fehlerhafte Integrationen hinweisen.

Schritt 4 — Telemetrie abschalten und Konfiguration härten

Viele Integrationen haben Optionen zur Telemetrie. Allgemeine Maßnahmen, die bei mir immer gelten:

Telemetrie/Analytics in den jeweiligen Integrations‑Einstellungen deaktivieren.

Externe API‑Keys entfernen, die nicht nötig sind (z. B. Google Maps, externe Wetter‑APIs). Lokale Alternativen nutzen: MeteoSwiss, Open‑Meteo (mit lokalem Caching), lokale Wetterstationen.

Falls eine Integration keine lokale Alternative bietet, ersetze sie durch lokale Bridges (z. B. Zigbee‑Coordinator, Z‑Wave‑Stick, MQTT‑Bridges).

Beispiel: Viele Kameras senden Metadaten in die Cloud. Ich nutze lokale RTSP‑Streams und setze Frigate oder motionEye ein, statt Hersteller‑Clouds.

Schritt 5 — Netzwerkzugriff beschränken und Remote‑Zugriff sicher gestalten

Vernünftige Netzwerkgrenzen reduzieren Lecks drastisch:

Blockiere nicht benötigte ausgehende Verbindungen vom Home Assistant‑Host (Outbound Firewall).

Für Remote‑Zugriff nutze ich ein VPN (z. B. WireGuard) oder Home Assistant Cloud, wenn du Nabu Casa vertraust. Ein Reverse‑Proxy mit Zwei‑Faktor schützt zusätzliche Ebenen, aber prüfe, dass er keine Logs an Dritte sendet.

Deaktiviere UPnP auf dem Router — das erlaubt Geräten automatisch Portweiterleitungen einzurichten.

Schritt 6 — Datensparsame Automatisierungen neu bauen

Wenn du Automatisierungen rekonstruierst, überlege: Welche minimale Information muss übertragen werden? Meine Prinzipien:

Lokale Trigger und Services bevorzugen (z. B. sensor, binary_sensor, light.turn_on).

State‑Only statt full payloads: Verwende Entity‑States und Templates statt Rohdaten an externe APIs zu senden.

Verwende input_boolean, input_number, input_datetime als lokale Zustände, um Cloud‑Rundrufe zu vermeiden.

Ein typisches Beispiel: Statt eine Cloud‑Wetter‑API in einer Automation aufzurufen, nutze den lokalen Wetter‑Sensor oder aktualisiere Wetterdaten per Cronjob nur stündlich und speichere sie in einem lokalen sensor.

Praktische Beispiele: Automationen datensparend umsetzen

Hier zwei konkrete Szenarien, wie ich Automatisierungen sicherer mache:

Beispiel Anwesenheit: Statt auf Google‑Location zu setzen, nutze ich:

Lokales Wi‑Fi‑Presence‑Monitoring (Rogue DHCP leases oder spezielle Presence‑Tracker), kombiniert mit Bluetooth‑Beacons.

Automatisierung: trigger: device_tracker.home → action: homeassistant.turn_on/notify lokal über MQTT oder ein Backup‑Push über Signal‑Gateway (selbst gehostet).

Beispiel Sprachsteuerung: Statt cloudbasierter Services (Alexa/Google) benutze ich Rhasspy oder Mycroft lokal. Diese Systeme verarbeiten Sprache lokal und senden nur, wenn du das explizit erlaubst.

Wiederherstellung von Automatisierungen: Backup, YAML vs. UI

Ich habe zwei Strategien kombiniert:

Regelmäßige Backups (Snapshots) mit vollständiger Konfigurationsdatei. Falls du Automatisierungen entfernst, kannst du sie aus dem Snapshot wiederherstellen.

Migration ins YAML‑Format für kritische Automatisierungen: YAML ist transparent und versionierbar (Git). So sehe ich sofort, welche Dienste auf externe APIs zugreifen und kann unerwünschte Aufrufe entfernen.

Wenn du Automatisierungen aus der UI exportierst, prüfe die Felder action/service_call und condition, ob URLs, API‑Keys oder Templates mit externen Hosts vorkommen. Ersetze diese durch lokale Services oder input‑Entities.

Best Practices und eine kleine Tabelle zur Übersicht

Problem	Maßnahme
Cloud‑Integration	Deaktivieren / lokal ersetzen (Bridge, MQTT)
Telemetrie	Telemetrie in Integration ausschalten
Unklare Außenverbindungen	DNS/Firewall‑Logging, Pi‑Hole, tcpdump
Remote‑Zugriff	VPN / WireGuard, kein UPnP
Chatty Devices	Recorder Filter / DB‑Retention reduzieren

Aufräumen der Historie und Datenschutz in der DB

Manchmal brauchst du nicht nur stopfen, sondern auch löschen. Der Recorder speichert viele Details:

Konfiguriere recorder: purge_keep_days auf einen niedrigen Wert (z. B. 7 Tage) oder stelle regelmäßige purges ein.

Schließe Entitäten aus der DB via recorder.exclude: sensoren, die personenbezogene Daten senden, müssen nicht historisiert werden.

Für größere Setups empfehle ich eine externe DB (MariaDB) — einfacher zu verwalten und zu säubern als die interne SQLite.

Wenn du magst, kann ich dir anhand deiner configuration.yaml oder einer Automatisierungs‑Beispieldatei konkret zeigen, welche Teile du datensparsam umschreiben solltest. Schreib mir einfach deine aktuelle Config oder nenn ein konkretes Device — dann gehe ich punktgenau darauf ein.