Home Assistant - „Die Schattenseite“ oder „Wenns mal abschmiert, kuckst du in die Röhre“

Henry · 2026-05-20T02:21:06+00:00

Guten Abend liebe Community, Ich bin ja bekanntermaßen ein glühender Verfechter von Home Assistant. Aber heute hab ich die Schattenseite einer Open Source L...

Surfer1264(2nd)

Zen_4711 Dachte wenigstens die HA DB ist ein Selbstläufer

Selbstläufer ist leider (fast) gar nichts……. 😎😁🥶
HA ist eine Datenkraake, die man ein wenig einhegen sollte…..

5 GB DB ist perse nicht schlimm, aber dazu gehören dann auch ein paar Bedingungen …..
Und am Ende ..wenn ich mir bestimmte Datenpunkte ( Sensoren) nie ansehe …dann sollte ich sie auch nicht speichern……führt unweigerlich irgendwann zum GAU

Die Arbeit macht man einmal ….ich habe da schon relativ lange Ruhe.

Zen_4711

Surfer1264(2nd) Der erste Schritt wäre getan. Die v2 DB hängt am File sitze, jetzt hab ich das schon mal im Blick.
Bin wohl zu doof für 's Web Forum, der Post Reply "meckert" und die Suche macht auch ganz komische Sachen. Schaue mir auch noch an☺️

ZenUser62871M3

Home Assistant räumt die Datenbank eigentlich schon von Haus aus recht vernünftig auf. Schaut mal, welcher Sensor bei euch aus der Reihe tanzt, und gebt das wenn ihr es einer Integration zuordnen könnt als Feedback an den jeweiligen Maintainer weiter. Das lässt sich von dort beheben oder sinnvoller steuern als das es die Datenbank unnütz füllt. Alles, was alle paar Sekunden neue Werte liefert, würde ich nach Möglichkeit von den Statistiken fernhalten wenn es die Information nicht unbedingt braucht. Wenn das aus euren selbst erstellten Sensoren kommt, macht ihr das einfach über die state_class.
Bei mir läuft die Konfiguration weitgehend im Standard. Ich habe lediglich die Short-Term-Retention global auf 30 Tage erhöht. Mit aktuell 321 von 1.257 Entitäten, die Statistiken schreiben, liegt die Datenbank bei rund 4,2 GB und läuft völlig unauffällig seit mehreren Jahren.

Surfer1264(2nd)

Zen_4711

Surfer1264(2nd) Perfekt, vielen Dank Jörg. 👍️ So schaut das bei mir aus:
"Scheinleistung" kann schon mal direkt weg, nur die echten KWhs zählen. 😉
Meine "Monat" und "Jahr" Helfer braucht es wahrscheinlich auch gar nicht in der Statistik.
Meine wo gelesen zu haben, dass man die Statistik "Rate" nicht für einzelne Entitäten unterschiedlich einstellen kann.
Muss mich jetzt nur noch mehr einlesen. Das lange Wochenende ist gesichert. 😄
Hast Du 3800 Entitiäten? Respekt.
Blicke ja bei meinen wenigen schon ab und an mal nicht mehr durch und dann sind ja Flow Variablen auch noch da.

Henry

Update:
Ich bin inzwischen mit HA auf einen Dell Wyse mit Proxmox umgezogen. Ich hatte ja gehofft, dass es an der externen SSD am HA Green liegt, das Problem ist aber leider mit auf den Wyse gewandert. Die SQL Datenbank habe ich mir bzgl platzfressender Statistiken angeschaut und alles was ich nicht unbedingt brauche vom Recorder ausgeschlossen. DB ist aktuell schlanke 900MB groß.
Dabei habe ich einen eskalierenden Sensor gefunden. Ich lese meinen Gaszähler mit einem Reedkontakt aus, dummerweise ist der Magnet vom Zähler genau über dem Reedkontakt stehen geblieben. Daher hat der Sensor 2-3x pro Sekunde geschrieben.
Hatte mich schon gefreut, weil ich dachte das könnte der Fehler sein. Aber Pustekuchen.
Das System wird trotzdem von Tag zu Tag träger, bis es garnicht mehr reagiert. Dann hilft nur DB zurück setzen. Mit leerer DB läufts dann wieder problemlos, aber auch nur 2-3 Tage, dann muss ich die DB wieder zurücksetzen.
Ich bin inzwischen echt ratlos.

Surfer1264(2nd)

Henry Dann hilft nur DB zurück setzen

Verdammt gibts ja nicht.

Startest du mit ganz frischer DB, vermutlich ja
Und spielst keine Historien ein, vermutlich ja

Wie zen4711 sagt…würde ich auch starten ……nur die unauffälligen Integrationen aktivieren.

Vermutlich läuft schon Proxmox ……?
Dann würde ich nur HA und deine Regelung mit den Sensoren laufen lassen…..und schrittweise weitere Integrationen hinzufügen.

Surfer1264(2nd)

Henry aber auch nur 2-3 Tage, dann muss ich die DB wieder zurücksetzen.
Ich bin inzwischen echt ratlos.

Wie gross ist die DB nach 3 Tagen?

Laufen Deine Effizienzbetrachtungen- Statistiken noch dauerhaft mit?

Und …..nur ne Idee……alles eigenen Scripte mal kurz außen vor lassen ……ZHA Regeln lassen, wenn auch nicht perfekt….

Geht ja nur noch über ausschließen,denke ich.,,,,und damit eingrenzen.

Zen_4711

Henry Nachdem Du ja jetzt 2x Systeme hast, kannst an einem ja mal großzügig Sachen entfernen/abschalten in einen Testsystem. Wie gross ist denn die DB nach 3 Tagen? Meine DB hat derzeit 1,7GB, relativ konstant. Was sagt denn die Prozessorauslastung und Speicherauslastung nach 3 Tagen? Und es ist wirklich nur die DB, die das System langsam macht. Ein reiner Neustart nach 3x Tagen mit alter, bestehender DB bringt keine Verbesserung? Wenn es rein in der DB liegt, muss es ja fast ein aufgezeichneter Wert sein. Und eine andere SSD am Wyse hast Du ja auch verwendet, nehme ich mal an.

Henry

Henry Proxmox läuft. DB ist nach dem Zurücksetzen immer jungfräulich. Ich greife dabei über Samba aufs Dateisystem zu, benenne die aktuelle DB um und starte HA neu. Beim Neustart setzt HA dann eine neue, leere DB auf. Zurückgespielt habe ich nichts.
Auffällig ist noch, dass obwohl das System zunehmend träger wird, Prozessor und RAM lange nicht im Grenzbereich laufen.
Meist fängt es damit an, dass der MQTT Broker immer wieder nicht erreichbar ist. Daher funktioniert meine eigene Regelung über AppDaemon ohnehin recht zeitig nicht mehr, weil AppDaemon dann damit zu tun hat, einen anderen Sensorwert (PV-Leistung Dach Anlage) an MQTT zu übergeben und damit meine Steuerung blockiert. Daher läuft aktuell wieder Z-HA, wobei auch das immer träger regelt.
Naja, ich werde jetzt mal den HA Green als Testsystem nutzen und sukzessive Apps und Integrationen deaktivieren. Das wird ne sisyphus Arbeit, weil ich je Änderung ja immer ein paar tage abwarten muss…😬😅

Zen_4711

Zen_4711 Hast Du womöglich eine Langzeitstatistik als Diagrann auf deiner Startseite? Hatte aus Versehen mal in so einer Statistik eine Entität verstellt, die Statistik wurde dann gar nicht mehr fertig mit Daten einladen, sprich die Grafik kam nie. Konnte das Objekt zum Glück dann komplett löschen. Ich bin halt doch noch im HA Anfängerstatus 😌

Surfer1264(2nd)

@Henry
Das antwortet Claude

Das klingt nach einem sehr hartnäckigen Problem! Die Symptome deuten auf etwas Spezifisches hin:

Was du beschreibst:

• System wird über 2-3 Tage progressiv träger
• CPU/RAM unauffällig → kein klassisches Ressourcenproblem
• MQTT-Broker wird zuerst unerreichbar
• Leere DB = sofortige Besserung
• Problem auf neuer Hardware reproduzierbar

Meine Hypothese: SQLite-Locking / Connection-Stau

Das Muster “DB-Reset hilft sofort” bei gleichzeitig unauffälliger CPU/RAM deutet stark auf SQLite WAL-Korruption oder wachsende WAL-Datei hin, nicht auf die DB-Größe selbst.

Schau mal nach diesen Dateien neben deiner home-assistant_v2.db:

• home-assistant_v2.db-wal
• home-assistant_v2.db-shm

Die WAL-Datei kann massiv anwachsen, wenn der Checkpoint-Prozess nicht sauber durchläuft – und blockiert dann zunehmend alle DB-Schreiber, darunter auch MQTT-Integrationen.

Sofortmaßnahmen zum Diagnostizieren:

WAL-Größe beobachten – schau täglich wie groß home-assistant_v2.db-wal wird. Wenn die auf mehrere GB wächst, ist das der Täter.
In configuration.yaml umstellen:

recorder:
commit_interval: 30 # statt default 1
db_url: sqlite:////config/home-assistant_v2.db?connection_timeout=30

Langfristig: Auf MariaDB/PostgreSQL umsteigen – SQLite ist für dauerhaften HA-Betrieb mit vielen Sensoren eigentlich nicht ideal. MariaDB als LXC auf Proxmox wäre die saubere Lösung.

Warum zuerst MQTT?

MQTT-Integration läuft über den Event-Bus und schreibt bei jedem State-Change in die DB. Wenn SQLite anfängt zu blocken, ist MQTT als einer der schreibfreudigsten Dienste der erste, der hängt.

Kannst du mal schauen, wie groß die WAL-Datei aktuell ist und ob sie wächst?

Surfer1264(2nd)

Als du von ZHa weg bist ( die nur zenSDk benutzen) und umgeschwenkt bist auf das Verarbeiten der MQTT von deinen drei Hubs…..ab da ging’s los , oder ?

Surfer1264(2nd)

WAL = Write-Ahead Log

SQLite schreibt Änderungen nicht sofort direkt in die Hauptdatenbank, sondern erst in diese separate Log-Datei. Das ist eigentlich eine Schutzmaßnahme – wenn das System abstürzt, gehen keine Daten verloren.

Normaler Ablauf:

Schreibvorgang → WAL-Datei → (Checkpoint) → Hauptdatenbank

Der Checkpoint-Prozess überträgt die WAL-Daten periodisch in die eigentliche DB und leert die WAL danach wieder.

Was bei dir vermutlich passiert:

Der Checkpoint läuft nicht sauber durch – zum Beispiel weil immer irgendein Prozess die DB gerade liest. SQLite wartet dann höflich, aber die WAL wächst derweil weiter. Je größer die WAL, desto länger dauert jedes Lesen (weil SQLite immer die Hauptdatenbank plus die gesamte WAL im Kopf behalten muss). Das verlangsamt alles, was die DB benutzt – und das ist in HA fast alles.

Wenn du die DB umbenennst und neu startest, verschwinden auch WAL und SHM – frischer Start, alles flott.

Zum Nachschauen: Im Samba-Ordner neben deiner home-assistant_v2.db solltest du sehen können ob es eine -wal Datei gibt und wie groß sie ist. Wenn die mehrere hundert MB oder sogar GB groß ist, hast du den Übeltäter.

Surfer1264(2nd)

Ich wills jetzt (auch) wissen 🥹

Surfer1264(2nd)

Wenn die WAL-Theorie stimmt, ist der sauberste Weg MariaDB statt SQLite, wie ich ganz oben schon vorschlug. MariaDB hat echtes Connection-Management, keine WAL-Problematik, und läuft auf Proxmox als LXC sehr leichtgewichtig. Die Migration ist in HA gut dokumentiert und du kannst sogar die bestehende History mitnehmen – oder mit leerer DB starten, was nach deinen Erfahrungen eh besser läuft.

Surfer1264(2nd)

So sieht das bei mir aus mit der WAL Datei

Henry

Erstmal vielen lieben Dank @Jörg, dass du dich da so mit reinhängst…☺️
Die *.db-wal hab ich auf beiden Systemen gecheckt, die hat da jeweils 10MB, also offensichtlich eher unproblematisch.
Ob das tatsächlich zeitgleich mit der eigenen Regelung aufgetreten ist, kann ich nicht genau sagen. Das halte ich aber für eher unwahrscheinlich, da ich zum einen schon viel länger dran rum bastel und zum anderen das Problem auch besteht, wenn HEMS regelt (musste ich jetzt für 1 1/2 Wochen so machen, da ich im Urlaub war und durch die Probleme garnicht mehr auf HA zugreifen konnte).

Surfer1264(2nd)

Henry vielleicht lässt du das OriginalSetup nochmal drei Tage laufen und checkst dann die Größen nochmal. …..es eskaliert ja langsam ….irgendwas blockiert die DB ……und wenn keine CPU Last existiert…ist das ein Warten auf irgendwas …das fertig werden soll und nicht fertig wird……auch die utility Meter sind so Kandidaten ( also die Verbrauchssensoren), die ständig was zusammenrechnen …..

ZenUser62871M3

Henry Daher hat der Sensor 2-3x pro Sekunde geschrieben.

Du könntest das recht einfach so umstellen, dass der Sensor nur dann schreibt, wenn der Reed-Kontakt auslöst, und ansonsten keine Werte sendet. Ich habe das bei meinem Gerät in ESPHome genauso umgesetzt über den on_press-Trigger am Pin, kombiniert mit einem Filter fürs Debouncing.

Habt ihr irgendwo Statistik- oder SQL-Sensoren im Einsatz? Wenn die auf immer mehr Daten zugreifen müssen, werden die Abfragen mit der Zeit natürlich langsamer. Normale Utility-Sensoren sind normalerweise unkritisch. Die greifen in der Regel nur auf die Delta- und Summenwerte des letzten Datensatzes zu und werden daher nicht langsamer, wenn die Datenbank wächst.

Ansonsten würde ich empfehlen, mal in der Home Assistant Community direkt nachzufragen. Dort sind viele erfahrene Nutzer unterwegs, die solche Probleme und die Ursachen vermutlich schon kennen.

« Previous Page Next Page »