Monat: Januar 2026

Smarter Gasleser Home Assistant – mein Langzeittest ohne Cloud

admin Schreib einen Kommentar

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

Ein smarter Gasleser Home Assistant ist für viele Smart-Home-Nutzer der nächste logische Schritt, um den eigenen Gasverbrauch transparent zu erfassen und im Energie-Dashboard auszuwerten.

Ich habe in den letzten Monaten genau so einen smarten Gasleser für Home Assistant im Alltag getestet – als Ersatz für meine bisherige DIY-Lösung mit ESP und improvisierter Befestigung.

In diesem Beitrag teile ich meine Erfahrungen aus dem Langzeittest und zeige, warum ich mich bewusst für eine fertige Lösung entschieden habe. Die komplette Einrichtung und alle Details findet ihr im Video.

Hier bekommst du den Gasleser mit einem extra 10% Rabatt*

Warum ich mein DIY-Projekt ersetzt habe

Wie viele in der Home-Assistant-Community habe auch ich meinen Gaszähler zunächst selbst ausgelesen – mit ESP-Hardware, Sensor und einer provisorischen Halterung.

Das funktionierte grundsätzlich, hatte aber zwei große Nachteile: Die Befestigung war nicht wirklich dauerhaft stabil und kleinere Probleme führten immer wieder zu Nachjustierungen. Mit der Zeit blieb das Projekt liegen, weil andere Smart-Home-Themen wichtiger wurden.

Der smarte Gasleser von Nineti sollte genau dieses Problem lösen: eine kompakte, saubere Lösung ohne Bastelaufwand, aber trotzdem vollständig integrierbar in Home Assistant.

Durchdachtes Montagesystem statt Klebeband

Ein Punkt, der mir direkt positiv aufgefallen ist, ist das Adapter-Konzept. Beim Bestellen wählt man einfach den eigenen Gaszähler-Typ aus und bekommt direkt eine passende Halterung mitgeliefert.

Die Montage ist schnell erledigt, rückbaubar und ohne Bohren oder Kleben möglich. Gerade im Keller oder Hausanschlussraum ist das ein großer Vorteil.

Stromversorgung und WLAN als Voraussetzung

Der Gasleser wird per USB-C mit Strom versorgt und kommuniziert über WLAN. Eine Steckdose in der Nähe sowie eine stabile WLAN-Verbindung sind daher notwendig.

Für den dauerhaften Betrieb ist eine Powerbank aus meiner Sicht keine sinnvolle Alternative.

Schnelle Einrichtung per App

Die Ersteinrichtung erfolgt über die zugehörige App. Nach der Registrierung wird der Gasleser ins WLAN eingebunden, der aktuelle Zählerstand eingetragen und der Impulswert des Gaszählers festgelegt.

Das Ganze ist in wenigen Minuten erledigt und der Verbrauch wird direkt erfasst.

Der smarte Gasleser Home Assistant

Integration in Home Assistant über MQTT

Für Home-Assistant-Nutzer besonders interessant ist die lokale Einbindung per MQTT. Der Gasleser sendet seine Daten direkt an den MQTT-Broker und erscheint automatisch als Gerät in Home Assistant.

Auch die Einbindung in das Energie-Dashboard funktioniert problemlos.

Betrieb komplett ohne Cloud

Ein wichtiges Feature ist die Möglichkeit, die Cloud-Anbindung vollständig zu deaktivieren. Über das lokale Webinterface lässt sich der Gasleser auf reinen Lokalbetrieb umstellen.

Alle Daten bleiben damit im eigenen Netzwerk. Gerade für Nutzer, die Wert auf Datenschutz und Kontrolle legen, ist das ein großer Pluspunkt.

Wie das genau funktioniert, zeige ich ausführlich im Video.

Erfahrungen aus dem Langzeittest

Nach mehreren Monaten im Einsatz zeigt sich der Gasleser als zuverlässig und stabil. Die Erfassung funktioniert konstant, die Montage sitzt sicher und die Integration in Home Assistant läuft ohne Probleme.

Positiv hervorzuheben ist auch der Support des Herstellers. Kleinere Themen wurden schnell aufgegriffen und per Updates verbessert.

Was man beachten sollte

Nicht jeder Keller oder Technikraum bietet perfekte Voraussetzungen. Wichtig sind eine erreichbare Steckdose und ausreichend WLAN-Empfang. Fehlt eines von beidem, ist diese Lösung eher ungeeignet.

DIY oder fertige Lösung

Ich bin grundsätzlich ein Freund von Eigenbauprojekten. In diesem Fall überwiegen für mich aber klar die Vorteile der fertigen Lösung: weniger Wartung, saubere Montage, Support und die Möglichkeit zum reinen Lokalbetrieb.

Auch wenn die Kosten höher sind als bei einer DIY-Variante, erhält man ein rundes Gesamtpaket.

Weitere Infos und Rabattcode

Der Hersteller stellt aktuell auch einen Rabattcode zur Verfügung*.

Hier bekommst du den Gasleser mit einem extra 10% Rabatt*

Das vollständige Video

In meinem Video zeige ich die komplette Montage, die App-Einrichtung, das MQTT-Setup, die Integration ins Energie-Dashboard sowie den Betrieb ohne Cloud.

Home Assistant Automatisierungen debuggen – wenn Traces nicht mehr reichen

admin

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

Home Assistant Automatisierungen debuggen: Wenn Automatisierungen versagen, wird es schnell ungemütlich

Wer Home Assistant intensiv nutzt, kennt diese Situationen nur zu gut: Man geht in den Flur – und das Licht bleibt aus. Oder morgens bleiben die Rollläden unten, obwohl sie seit Monaten zuverlässig funktioniert haben. Solche Fehler sind nicht nur technisch ärgerlich, sie sorgen auch im Alltag schnell für Frust. Gerade dann, wenn andere Personen im Haushalt dem Smart Home ohnehin skeptisch gegenüberstehen.

In diesem Beitrag zeige ich keinen neuen Sensor, keine neue Integration und auch keine klassische „Automatisierung des Monats“. Stattdessen geht es um eine Frage, die mir regelmäßig gestellt wird – und die ich mir selbst oft genug stellen muss:

Warum läuft meine Automatisierung nicht, obwohl eigentlich alles richtig aussieht?

Warum die Home-Assistant-Traces oft nicht ausreichen

Home Assistant bringt mit den Traces bereits ein sehr mächtiges Werkzeug zur Fehlersuche mit. Man sieht, welche Trigger ausgelöst wurden, welche Bedingungen geprüft wurden und an welcher Stelle eine Automatisierung eventuell abgebrochen ist.

In der Praxis stoße ich damit aber immer wieder an Grenzen:

  • Traces werden schnell unübersichtlich

  • Zustände werden nur punktuell angezeigt

  • Zusatzinformationen wie „Wann hat sich dieser Zustand zuletzt geändert?“ fehlen

  • Zusammenhänge zwischen mehreren Entitäten sind schwer zu erkennen

Gerade bei komplexeren Automatisierungen mit Zeitfenstern, Nachtmodi, Helligkeitswerten oder mehreren Bedingungen wird das Debugging schnell zur Fleißarbeit.

An genau dieser Stelle setze ich mit meinem eigenen Ansatz an.

Mein Ansatz: Debug-Snapshots statt Rätselraten

Statt mich ausschließlich auf Traces zu verlassen, arbeite ich mit sogenannten Debug-Snapshots. Die Idee dahinter ist simpel:

Ich speichere mir zu definierten Zeitpunkten innerhalb einer Automatisierung den Zustand relevanter Entitäten – strukturiert, nachvollziehbar und dauerhaft in einer Logdatei.

So sehe ich später ganz in Ruhe:

  • Welche Entitäten welchen Status hatten

  • Wann sich ein Zustand zuletzt geändert hat

  • Ob Bedingungen wirklich erfüllt waren

  • Wie sich Zustände vor und nach einer Aktion unterscheiden

Das Ganze ist kein Ersatz für Traces, sondern eine Ergänzung – vor allem dann, wenn man systematisch verstehen möchte, warum eine Automatisierung nicht so läuft wie gedacht.

Debug-Snapshots in der Praxis

Ich nutze dafür ein eigenes Skript, das ich an beliebigen Stellen in einer Automatisierung aufrufen kann. Typischerweise setze ich es:

  • direkt am Start der Automatisierung

  • vor kritischen Aktionen

  • nach der eigentlichen Aktion

Jeder Aufruf erzeugt einen Snapshot, der folgende Informationen enthalten kann:

  • Name der Automatisierung

  • aktuelle Phase (z. B. Start, Before Action, After Action)

  • Zeitstempel

  • Zustände definierter Entitäten

  • „Last Changed“-Informationen

So entsteht Schritt für Schritt ein klares Bild davon, was in der Automatisierung tatsächlich passiert.

Home Assistant Automatisierungen debuggen

Welche Entitäten sind wirklich relevant?

Ein großer Vorteil dieses Ansatzes ist, dass ich selbst entscheide, was geloggt wird. Typische Kandidaten sind bei mir:

  • Bewegungsmelder (inkl. last_changed)

  • Lichtzustände

  • Helligkeitssensoren

  • Zeit- oder Datumsbedingungen

  • Nachtmodus (z. B. über input_boolean)

Gerade der Nachtmodus ist in der Praxis eine häufige Fehlerquelle. Ich hatte schon mehrfach Situationen, in denen eine Automatisierung „nicht funktionierte“, weil schlicht noch der Nachtmodus aktiv war. Im Debug-Log sehe ich das sofort – ohne langes Suchen.

File-Integration: Logdateien direkt in Home Assistant

Damit die Debug-Snapshots nicht irgendwo verschwinden, nutze ich die File-Integration von Home Assistant. Darüber lässt sich ein Notify-Dienst anlegen, der Text direkt in eine Datei schreibt.

Der große Vorteil:

  • keine externe Infrastruktur

  • keine zusätzlichen Tools

  • alles bleibt innerhalb von Home Assistant

Die Logdatei liegt im „www" -Verzeichnis und kann bequem über den File Editor oder per Browser eingesehen werden.

Home Assistant Automatisierungen debuggen

Debug-Log lesen und richtig interpretieren

Ein einzelner Logeintrag besteht aus mehreren Blöcken:

  • Metainformationen (Zeitpunkt, Phase, Name)

  • Zustände der Entitäten

  • Zusatzinformationen wie last_changed

Besonders hilfreich ist der direkte Vergleich zwischen Before Action und After Action. So sehe ich zum Beispiel:

  • Wurde das Licht wirklich eingeschaltet?

  • Hat sich der Status geändert?

  • Wurde eine Bedingung vielleicht doch nicht erfüllt?

Mit diesen Informationen kann ich Automatisierungen gezielt anpassen, statt nur „auf Verdacht“ Werte zu ändern.

Typische Fehlerquellen, die schnell sichtbar werden

Mit Debug-Snapshots lassen sich viele Klassiker schnell entlarven:

  • Nachtmodus noch aktiv

  • Helligkeitswert knapp über oder unter dem Grenzwert

  • Zeitfenster falsch gewählt

  • Entität war länger unverändert als erwartet

Gerade bei Helligkeitssensoren nutze ich die Logs auch, um über mehrere Tage Daten zu sammeln und Grenzwerte realistisch festzulegen.

Für wen ist dieser Ansatz sinnvoll?

Ganz klar: Das ist kein Einsteiger-Thema.

Wenn du gerade erst mit Home Assistant anfängst, brauchst du dieses Werkzeug vermutlich noch nicht. Aber es ist gut zu wissen, dass es diese Möglichkeit gibt.

Für fortgeschrittene Nutzer, die:

  • viele Automatisierungen betreiben

  • komplexe Bedingungen nutzen

  • nachvollziehbar debuggen möchten

ist dieser Ansatz extrem hilfreich.

Fazit: Debuggen mit System statt Trial-and-Error

Automatisierungen, die nicht funktionieren, gehören leider zum Smart-Home-Alltag dazu. Entscheidend ist, wie man damit umgeht.

Mit Debug-Snapshots habe ich für mich einen Weg gefunden, Probleme systematisch zu analysieren, statt im Nebel zu stochern. In Kombination mit den Home-Assistant-Traces ergibt sich ein sehr mächtiges Werkzeug zur Fehlersuche.

Den kompletten Code für das Debug-Snapshot-Skript stelle ich wie immer in meinem Blog bereit.

alias: debug_snapshot
description: Debug Snapshot (JSONL, dynamisches Ziel)
fields:
  name:
    name: Name
    description: Bezeichnung des Snapshots
    selector:
      text: null
  phase:
    name: Phase
    description: Status oder Phase (z.B. Start, Error, Ende)
    default: info
    selector:
      text: null
  entities:
    name: Entitäten
    description: Liste der zu loggenden Entitäten
    selector:
      entity:
        multiple: true
  zusatzdaten:
    name: Zusatzdaten
    description: Ein Dictionary für extra Infos
    default: {}
    selector:
      object: null
  benachrichtigungsdienst:
    name: Benachrichtigungsdienst
    description: Welcher Dienst soll genutzt werden?
    default: notify.file
    selector:
      text: null
sequence:
  - variables:
      ent_list: >-
        {{ entities if entities is iterable and entities is not string else
        ([entities] if entities else []) }}
      payload: |-
        {% set ns = namespace(snapshot={}) %}
        {% for e in ent_list %}
          {% if states[e] is defined %}
            {% set obj = states[e] %}
            {% set lc = obj.last_changed.astimezone() %}
            {% set ns.snapshot = dict(ns.snapshot, **{e: {
              "state": states(e),
              "last_changed": lc.isoformat(),
              "seconds_since_change": (now() - lc).total_seconds() | int,
              "attributes": obj.attributes
            }}) %}
          {% endif %}
        {% endfor %}
        {{ {
          "ts": now().isoformat(),
          "name": name,
          "phase": (phase | default("info")),
          "extra": (zusatzdaten | default({})),
          "snapshot": ns.snapshot
        } | tojson }}
  - action: notify.send_message
    target:
      entity_id: "{{ benachrichtigungsdienst }}"
    data:
      message: "{{ payload }}"
mode: queued
max: 200

Deine Meinung ist gefragt

Mich interessiert, wie du Automatisierungen debuggt:

  • Arbeitest du nur mit Traces?

  • Nutzt du eigene Logs?

  • Oder ganz andere Ansätze?

Schreib mir das gerne in die Youtube Kommentare.

Und falls du Wünsche für eine kommende Automatisierung des Monats hast – lass es mich wissen.

Hier kommst du übrigens zu meiner letzten Automatisierung des Monats .

Home Assistant Backup richtig umsetzen – Mein vollständiger Rettungsplan für den Worst Case

admin

Home Assistant Backup ist eines der meist unterschätzten Themen im Smart Home. Erst wenn der Server ausfällt, eine VM beschädigt ist oder eine SD-Karte den Geist aufgibt, zeigt sich, ob das eigene Backup-Konzept wirklich funktioniert.

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

Warum ein Home‑Assistant‑Backup erst im Ernstfall seinen Wert zeigt

Was passiert eigentlich, wenn heute Nacht dein Home‑Assistant‑Server ausfällt? Festplatte defekt, VM gelöscht, SD‑Karte korrupt – und plötzlich ist alles weg. Automationen, Dashboards, Tokens, Integrationen. Genau dieses Szenario ist der Grund, warum ich mich intensiv mit Backups beschäftigt habe.

Viele Nutzer haben irgendwo ein Backup laufen. Aber die entscheidende Frage lautet nicht: Habe ich ein Backup? Sondern: Kann ich es im Worst Case wirklich wiederherstellen?

In diesem Beitrag zeige ich dir mein vollständiges Backup‑Konzept für Home Assistant – inklusive echter Wiederherstellung auf neue Hardware. Kein Theorie‑Artikel, sondern ein praxisnaher Leitfaden, der sich an genau dem orientiert, was im Ernstfall zählt.

Die 3‑2‑1‑Regel – Fundament jedes seriösen Backup‑Konzepts

Bevor wir über Home Assistant sprechen, müssen wir über das Grundprinzip reden. Die 3‑2‑1‑Backup‑Regel ist kein Buzzword, sondern ein bewährter Standard:

  • 3 Kopien deiner Daten

  • 2 unterschiedliche Medien

  • 1 Kopie außerhalb deines Systems

Für Home Assistant bedeutet das konkret:

  • ein lokales Backup für schnelle Rollbacks

  • ein Netzwerkspeicher (NAS/SMB) als zweites Medium

  • ein externes Ziel, z. B. Cloud oder Offsite‑Storage

Home Assistant Backup Speicherorte

Alles andere ist kein Backup‑Konzept, sondern Hoffnung.

Ich habe in diesem Beitrag bewusst auf die Nabu Casa Cloud als externes Backup Ziel verzichtet. Für die Cloud ist eine Subscription nötig und mein Ziel war es Möglichkeiten ohne zusätzliche Kosten aufzuzeigen. Dennoch kann ich die Nabu Casa Cloud empfehlen. Man unterstützt damit auch die Weiterentwicklung von Home Assistant.

Home Assistant Backup in der Nabu Casa Cloud

Home Assistant Backups richtig konfigurieren

In Home Assistant selbst stehen dir mittlerweile sehr gute Bordmittel zur Verfügung. Wichtig ist, dass du sie bewusst konfigurierst und nicht einfach auf den Standardwerten stehen lässt.

Automatische Backups

Ich setze auf tägliche automatische Backups, zeitlich so gelegt, dass sie nicht mit anderen Wartungsaufgaben kollidieren. Zusätzlich begrenze ich die Anzahl der Backups pro Ziel, damit Speicher nicht unkontrolliert vollläuft.

Automatische Home Assistant Backups

Was gehört ins Backup?

Für ein echtes Worst‑Case‑Backup sichere ich:

  • Konfiguration

  • Add-ons

  • Datenbanken

  • Share‑Ordner

Home Assistant Backup Einstellungen

Ja, das Backup wird größer – aber genau das ist der Punkt. Im Ernstfall möchte ich nichts manuell rekonstruieren müssen.

Verschlüsselung: Dein Notfall‑Set ist entscheidend

Sobald Backups außerhalb deines Systems liegen, ist Verschlüsselung Pflicht. In einem Home‑Assistant‑Backup befinden sich unter anderem:

  • API‑Tokens

  • Zugangsdaten

  • Integrations‑Secrets

  • Informationen über dein Smart Home

Ohne Verschlüsselung liegen diese Daten im Klartext vor.

Das Notfall‑Set

Home Assistant generiert bei der Einrichtung ein Notfall‑Set mit dem Verschlüsselungs‑Key. Dieser Punkt ist kritisch:

Ohne diesen Schlüssel ist ein Restore unmöglich.

Ich speichere das Notfall‑Set:

  • offline

  • redundant

  • getrennt vom System

Home Assistant Backup Verschlüsselungscode

Das ist keine Paranoia, sondern Vorsorge.

Ich nutze dafür eine lokal gehostete Vaultwarden Lösung und speichere dort alle meine Kennwörter und Daten redundant. Der Verschlüsselungscode ist elementar. Ohne sind eure Backups wertlos und ihr könnt diese nicht wiederherstellen.

Backup‑Ziel 1: Lokale Backups

Lokale Backups sind perfekt für:

  • schnelle Rollbacks

  • Fehlkonfigurationen

  • Updates, die schiefgehen

Sie sind kein Schutz vor Hardware‑Ausfall, aber ein wichtiger Baustein. Ich betrachte sie als Komfort‑Backup – nicht als Lebensversicherung.

Backup‑Ziel 2: NAS / SMB‑Freigabe

Als zweites Medium nutze ich eine SMB‑Freigabe auf einem NAS. Das kann ein klassisches NAS sein oder ein Server im Netzwerk.

Wichtig dabei:

  • eigener Benutzer nur für Backups

  • klare Freigaberechte

  • stabiler Netzwerkspeicher

Dieses Ziel deckt bereits viele Ausfallszenarien ab – aber noch nicht alle. In meinem Setup habe ich eine SMB-Freigabe auf einem virtuellen Unraid System im Einsatz. Jede beliebige andere Freigabe , sei es auf einem Synology, QNAP, Terramaster , UGreen – NAS erfüllen aber den gleichen Zweck.

Backup‑Ziel 3: Cloud / WebDAV mit Nextcloud

Für das externe Backup‑Ziel setze ich auf WebDAV, z. B. über Nextcloud. Der große Vorteil: Plattformunabhängig, bewährt und gut integriert.

Zwei‑Faktor‑Authentifizierung richtig lösen

Viele scheitern hier an 2FA. Die Lösung ist kein Abschalten der Sicherheit, sondern:

  • Nutzung eines App‑Passworts

  • 2FA bleibt aktiv

  • Zugriff ist sauber begrenzt

So funktioniert Cloud‑Backup ohne Sicherheitskompromisse. Die Nextcloud ist in einem Rechenzentrum gehostet und wird von mir selber verwaltet. Es können aber genauso auch andere Lösungen angewendet werden. Interessant finde ich z.B. auch SFTP Storage, da man sich so schnell einen eigenen günstigen virtuellen Server für kleines Geld bei IONOS, Hetzner etc.. mieten kann und ohne große Infrastruktur und Verwaltungsaufwand nur mit einem SSH Server eine externe Speicherfreigabe hat.

Der entscheidende Test: Restore im Worst Case

Ein Backup ist erst dann ein Backup, wenn es erfolgreich wiederhergestellt wurde.

Ich habe deshalb bewusst den Worst Case simuliert:

  • bestehende VM außer Betrieb

  • neues System aufgesetzt

  • Restore auf komplett andere Architektur (x86 → ARM)

Home Assistant macht das erstaunlich sauber – wenn das Backup korrekt erstellt wurde. Ich habe mich bewusst auch für eine andere Architektur entschieden, um euch im Video direkt zu zeigen, dass ihr selbst vor einem Wechsel , sei es x86 zu ARM oder ARM zu x86 keine Sorge haben müsst, so lange ihr das Home Assistant OS verwendet.

Typische Probleme nach dem Restore – und wie man sie löst

IP‑Adressen

Nach einem Restore ändern sich oft IP‑Adressen. Das betrifft:

  • MQTT

  • Integrationen

  • externe Dienste

Meine Empfehlung: feste IPs oder DHCP‑Reservierungen.

Grundsätzlich würde ich eine DHCP Reservierung im Router per MAC Adresse bevorzugen, da sie hinterher einfacher zu veralten ist. Das unterstützt mittlerweile jeder halbwegs vernünftige Router. Ihr spart euch so später manuelles „Gefrickel“ nach dem Restore.

USB‑Geräte & Device‑by‑ID

USB‑Sticks (Zigbee, Z‑Wave) sollten immer per Device‑by‑ID eingebunden werden. Dann spielt es keine Rolle, an welchem Port sie stecken – auch nach einem Hardware‑Wechsel. Ich habe mich in meinem Beitrag deshalb bewusst entschieden eine USB-ZigBee Verbindung zu verwenden, um euch dieses Szenario ebenfalls direkt zeigen zu können und die Sorge vor einem Wechsel oder einer Wiederherstellung zu nehmen.

Warum dieses Backup‑Konzept bewusst ausführlich ist

Dieses Setup ist kein Minimal‑Guide. Es ist ein Referenz‑Konzept. Ziel ist nicht, möglichst schnell fertig zu sein, sondern:

  • vorbereitet zu sein

  • reproduzierbar zu bleiben

  • im Ernstfall ruhig reagieren zu können

Ein echtes Backup‑Konzept zeigt seinen Wert nicht im Alltag – sondern dann, wenn alles schiefgeht.

Fazit: Backup ist keine Funktion, sondern ein Prozess

Wenn du aus diesem Beitrag nur eines mitnimmst, dann das:

Ein Backup, das du nie getestet hast, ist kein Backup.

Mit der 3‑2‑1‑Regel, Verschlüsselung, mehreren Zielen und einem getesteten Restore bist du auf der sicheren Seite – auch dann, wenn dein Home‑Assistant‑Server plötzlich nicht mehr startet.

Kurzfassung für Eilige (Backup‑Checkliste)

Wenn du Home Assistant ernsthaft betreibst, solltest du mindestens diese Punkte erfüllen:

  • ✔️ Automatische Backups aktiviert

  • ✔️ Backups verschlüsselt

  • ✔️ 3‑2‑1‑Regel umgesetzt (lokal, NAS, extern)

  • ✔️ Externes Ziel unabhängig vom Home‑Assistant‑System

  • ✔️ Notfall‑Set sicher und offline abgelegt

  • ✔️ Restore mindestens einmal getestet (idealerweise auf anderer Hardware)

Wenn einer dieser Punkte fehlt, ist dein Backup‑Konzept unvollständig.

Typische Fehler bei Home‑Assistant‑Backups

Aus Erfahrung scheitern Backups selten an der Technik, sondern an Kleinigkeiten:

  • Backups werden nie getestet

  • Verschlüsselungs‑Key geht verloren

  • Backups liegen nur lokal

  • Cloud‑Backups ohne Verschlüsselung

  • USB‑Geräte nicht per Device‑by‑ID eingebunden

Diese Fehler fallen meist erst auf, wenn es zu spät ist.

Interne Empfehlungen