Ich habe (wie oben geschrieben) die Positionen wieder in die configuration.yml aufgenommen (vorher hatte ich diese zum Testen mit # ausgeblendet. Danach lief es wieder bei mir.
Hi zuammen, aber verstehe ich es richtig das dies nur die “Lösung” ist für eine InfluxDB als HA App. Aber in diesem Zusammenhang auch eine externe InfluxDB (als getrennte VM/Container) ebenfalls betroffen ist, dass diese nicht mehr akzeptiert werden? Muss man die DB importieren? Sorry bin verwirrt…
Habe dieses Problem seit der 2026.03
Laut Logbuch kann nicht mehr in die Datenbank geschrieben werden.
Logger: homeassistant.components.influxdb
Quelle: components/influxdb/__init__.py:661
Integration: InfluxDB (Dokumentation, Probleme)
Erstmals aufgetreten: 03:21:44 (1 Vorkommnis)
Zuletzt protokolliert: 03:21:44
Could not write '[{'measurement': 'kWh', 'tags': {'domain': 'sensor', 'entity_id': 'sfml_eigenverbrauch_dc_yield', 'friendly_name': 'SFML Eigenverbrauch DC Yield', 'source': 'HA'}, 'time': datetime.datetime(2026, 4, 4, 1, 21, 40, 941203, tzinfo=datetime.timezone.utc), ...
configuration.yaml sieht bei mir so aus:
Username und Passwort habe ich gelöscht
influxdb:
tags:
source: HA
tags_attributes:
- friendly_name
default_measurement: state
exclude:
entities:
- zone.home
domains:
- persistent_notification
- person
include:
domains:
- sensor
- binary_sensor
- sun
- light
- cover
entities:
- weather.home
Danach tritt diese Warnung auf:
Logger: homeassistant.helpers.translation
Quelle: helpers/translation.py:226
Erstmals aufgetreten: 03:46:24 (1 Vorkommnis)
Zuletzt protokolliert: 03:46:24
Failed to load integration for translation: Integration 'InfluxDB' not found.
hab das gleiche Problem, was muss ich jetzt machen das influxdb wieder daten schreibt.
Gruß Andy
Ich habe aufgegeben mich mit diesem Problem herumzuschlagen.
Ich muss @hanshiasl Recht geben. Auch ich finde in den aufgelisteten Beiträgen keine Lösung damit die Datenbank wieder funktioniert.
Vielleicht könnte ja einmal jemand, bei dem es funktioniert, seine Sektion aus der configuration.yaml teilen.?
Bei mir läuft die InfoluxDB weiter ohne die angemahnten Änderungen:
Eine Konfiguration ist nicht möglich:
Ich habe hierzu die Änderungen in der configuration.yaml wieder auf den Ursprung zurück gestellt… Nach den Änderungen (s.o.) kamen keine Daten mehr an…
Daher warte und hoffe ich, dass es hierzu noch eine Lösung geben wird…
Ich trage hier noch mal meinen in der configuration.yaml verbliebenen Rest ein. Vielleicht hilft das ja weiter
#---------------------------------------------------------
# InfluxDB2
#
# added: 25. Oct. 2025
# changed: 05. Mar. 2026 - Migration to HA supported config entry Integration
influxdb:
tags:
source: HomeAssistant
default_measurement: units
tags_attributes:
- friendly_name
Am besten dann auch noch schauen, was aus der ursprünglichen Konfiguration in die.storage/core.config_entries bei der Migration übernommen wurde. Siehe dazu Warning "The InfluxDB YAML configuration is being removed" - #26 by silashansen - Configuration - Home Assistant Community
Ich habe es wie folgt bei mir in der configuration.yaml umgebaut:
influxdb:
# username: "xxxxxxxxx"
# password: "xxxxxxxxx"
tags:
source: HA
tags_attributes:
- friendly_name
default_measurement: state
exclude: !include influxdb_exclude.yaml
include: !include influxdb_include.yaml
durch das Ausblenden der beiden Bereiche username und password kommt die Fehlermeldung nun nicht mehr. Die Datenbank wird aber weiter genutzt und Grafana ziegt Daten an.
Einstellungen → Geräte und Dienste da kannst die Integration hinzufügen
Hallo zusammen,
evtl. habe ich noch eine wertvolle Info, die ich beim “Überfliegen” der Beiträge noch nicht gesehen habe.
Wenn man über HA - Geräte und Dienste - InfluxDB öffnet, sollte man einen Eintrag mit der HomeAssistant DB sehen. Dort dann auf die 3 Punkte auf Neu konfigurieren.
Das sah bei mir dann so aus:
Und diese Konfiguration ist falsch. da die DB über Port 8086 (im Standard) angesprochen werden muss.
URL in http://localhost:8086 ändern, dann klappt es wieder.
Übrigens, wenn man mit der falschen Konfiguration OK klickt, bekommt man sogar eine Fehlermeldung. Nur in HA habe ich nie eine solche Meldung erhalten.
Dadurch habe ich nun mind. 2 Monate keine Daten in Grafana rein bekommen. Echt mies.
Vielleicht hilft es ja dem ein oder anderen noch.
Hallo zusammen, gerade sehe ich in HA eine Reparaturmeldung, dass eine installierte App aus Repository entfernt wurde. Betroffen ist InfluxDB.
Was ist denn da los? Die Meldung kam vor zwei Stunden, also gegen 08:00 Uhr. Updates wurden in der Zeit und direkt davor keine installiert.
ratlose Grüße
Axel
Ich bin mit der Reparatur Dingens richtig auf die Schnauze gefallen und meine 3 Jahre alten Dashboards zeigen nur das rote Icon mit dem Ausrufezeichen an. 
Ich hoffe das nicht alle Daten weg sind, diese Bullshit Reparatur Hinwiese (ärgere mich grün und Blau) sind ehrlich gesagt eine Frechheit.
Kann man das rückgängig machen?
Hallo BuFisch.
Ich konnte mit Chatgpt meine gelöschte InfluxDB wieder holen und alte Daten (Datenverlust seind letzem Backup) waren noch da. Ich habe aus einem Backup nur die InfluxDB wieder hergestellt. Dann war die Verbindung auch wieder da. Aus configuration.yaml wurde alles von influxDB gelöscht. Hoffe bei dir funktioniert es auch
1 „Gefällt mir“
HA 2026.9 + InfluxDB – Meine Erfahrungen, Stolperfallen und Lösungen
Dieser Beitrag fasst zusammen, was ich in den letzten Tagen mit dem InfluxDB-Breaking-Change in Home Assistant 2026.9 erlebt habe – inklusive der Bugs, des Frusts und der Lösungen. Vielleicht erspart er dem ein oder anderen ein paar Stunden.
Die Ausgangslage
Ich betreibe Home Assistant auf Proxmox, InfluxDB und Grafana ebenfalls selbst gehostet. Meine InfluxDB-Konfiguration liegt in einer Packages-Datei (influxdb.yaml), wie es viele machen, die ihre HA-Config sauber strukturieren möchten.
Mit HA 2026.9 hat Home Assistant die Verbindungskonfiguration (Host, Port, Token, Bucket usw.) aus YAML entfernt und in die UI-Integration verschoben – ein sogenannter Breaking Change. Was dabei aber niemand klar kommuniziert hat:
Die Zugangsdaten aus der YAML-Datei werden beim ersten Start zwar in die UI-Integration übernommen, aber nicht aus der YAML entfernt.
Das klingt erst harmlos – ist es aber nicht. Was danach passiert: HA hat zwei Konfigurationen gleichzeitig. Irgendwann (nach einem Neustart, einem Token-Wechsel, einem Update) geraten die beiden aus dem Takt. Bei mir äußerte sich das darin, dass ich plötzlich dachte, mein InfluxDB-Token funktioniert nicht mehr. Ich habe den Token neu generiert, neu eingetragen, Verbindungen geprüft – alles scheinbar in Ordnung – und trotzdem keine Daten.
Die Lösung war simpel und ärgerlich: Die alten Zugangsdaten aus der YAML-Datei manuell entfernen. Erst dann griff ausschließlich die UI-Konfiguration und alles funktionierte wieder.
Mein Rat: Wer eine Packages-Datei für InfluxDB nutzt – nach dem Update auf 2026.9 sofort prüfen, ob noch host:, port:, token:, database: oder organization: in der YAML stehen. Wenn ja: raus damit. Nur tags:, exclude:, include: und default_measurement: bleiben in der YAML.
Der Dialog, der die Datenbank löscht
Zweites großes Thema: Der Reperaturdialog im UI, die – die gesamte Datenbank löschen kann. Doch bei den teilweise sehr vielen Mitteilungen die man auch mal schnell abrbeitet und dann versehentlich in ein paar Tagen angeklickt ist es schnell passiert. Eine doppelte Bestätigung oder ein Ignorieren-Button wäre schön gewesen.
Ich nenne das: DAU-Feindlichkeit hinter einer schönen Oberfläche. Man kann natürlich sagen: „Kein Backup, kein Mitleid." Stimmt. Aber ein Feature, das irreversibel jahrelange Messdaten vernichtet, verdient zumindest einen Bestätigungsdialog der klar sagt, was passiert.
Das eigentliche Frust-Thema: Halbherzig ausgerollt
Was mich wirklich ärgert: Dieses Update wurde mitten in einer Phase ausgerollt, in der das Team offensichtlich auf der IFA war. Der Community-Dialog zu den Auswirkungen war dünn, die Doku lückenhaft, und wer in Foren nachgefragt hat, bekam oft kein klares Bild.
Das ist eine Entwicklung, die ich in letzter Zeit öfter wahrnehme: Features werden halb fertig ausgerollt, Breaking Changes werden in den Release Notes erwähnt aber in der Praxis unterschätzt, und die Community darf dann die Feinheiten herausfinden.
Zum Vergleich: ioBroker löst das deutlich eleganter. Dort kann man direkt am einzelnen Datenpunkt einstellen, ob dieser in eine SQL-Datenbank soll oder nicht. Keine riesige Include/Exclude-Config, keine Glob-Pattern-Schlachten – einfach ein Häkchen pro Entity. Warum geht das in Home Assistant nicht über Labels? Labels sind seit einer Weile verfügbar – eine Integration die darauf aufbaut und erlaubt zu sagen „alles mit Label influxdb wird geschrieben" wäre ein enormer Fortschritt.
Stattdessen hat man in HA 2026.9 einen Hybridansatz: UI für die Verbindung, YAML für die Filter. Das ist das Schlechteste aus beiden Welten. Wer YAML pflegt, muss weiterhin YAML pflegen. Wer nur die UI will, versteht nicht warum die Filter nicht im UI sind. Entweder konsequent YAML oder konsequent UI – aber bitte nicht beides gleichzeitig, halbherzig und ohne klare Linie.
Das stille Datenproblem
Das Heimtückischste an diesem ganzen Thema: Wenn InfluxDB keine Daten mehr schreibt, merkt man es nicht.
Home Assistant läuft normal. Kein Fehler, keine Warnung, keine Notification. Grafana zeigt einfach keine neuen Datenpunkte mehr – aber das sieht man nur, wenn man aktiv nachschaut.
Bei mir haben tagelang keine Daten geschrieben – und ich habe es nur zufällig bemerkt, weil ich gerade in Grafana war.
Meine Lösung: Ich habe mir über die HA REST API, einen Helper und eine Automation ein Monitoring gebaut, das mir eine Benachrichtigung schickt, wenn seit 6 Stunden keine Daten mehr in InfluxDB geschrieben wurden.
Das sollte eigentlich out-of-the-box von der Integration kommen – tut es aber nicht.
Die technischen Stolperfallen bei entity_globs
Für alle, die ihre Filter weiter in YAML pflegen – hier die Bugs, die ich konkret getroffen habe:
Bug 1: include.entity_globs funktioniert nicht (2026.9)
Symptom: Keine Daten mehr in InfluxDB nach dem Update, obwohl die Config valide ist.
Ursache: include.entity_globs in Kombination mit dem neuen UI-basierten Config-Entry scheint in 2026.9 kaputt zu sein.
Workaround: Nur include.entities (ohne Globs) für explizite Einzel-Entities verwenden, alles andere über include.domains.
yaml
# KAPUTT in 2026.9:
include:
entity_globs:
- weather.home # funktioniert NICHT
# FUNKTIONIERT:
include:
entities:
- weather.home
Bug 2: exclude.entities ist unzuverlässig (2026.9)
Symptom: Einzel-Entities in der exclude.entities-Liste werden ignoriert, die Entities landen trotzdem in InfluxDB.
Workaround: Alles über entity_globs abdecken. Exakte Matches ohne Wildcard funktionieren in entity_globs per fnmatch genauso wie ein Eintrag in entities:
yaml
# Statt:
exclude:
entities:
- sensor.mein_sensor
# Besser:
exclude:
entity_globs:
- sensor.mein_sensor # exakter Match, keine Wildcard nötig
Bug 3: Reihenfolge exclude/include beachten
Die funktionierende Config hat exclude vor include. Technisch sollte die YAML-Reihenfolge keine Rolle spielen – in der Praxis scheint HA’s Config-Parser das aber anders zu sehen. Im Zweifelsfall an der Reihenfolge des originalen Beispiels in der HA-Doku orientieren.
Was funktioniert – die stabile Config-Struktur
Nach allem Hin und Her ist dies die Struktur, die bei mir stabil läuft:
yaml
influxdb:
default_measurement: state
tags:
instance: prod
source: hass
exclude:
entities:
- zone.home # zone ist nicht in include.domains, daher technisch redundant
domains:
- persistent_notification
- person
- light
- cover
entity_globs:
# ... alle Ausschlüsse hier ...
include:
domains:
- sensor
- binary_sensor
entities:
- weather.home # explizit, nicht via entity_globs!
Kernregeln:
-
excludevorinclude -
include.entity_globsmeiden – stattdesseninclude.entities -
Alles in
exclude.entity_globs– keineexclude.entities-Liste
Fazit
Der InfluxDB-Breaking-Change in HA 2026.9 ist grundsätzlich der richtige Schritt – Verbindungsdaten gehören nicht in YAML-Dateien. Die Umsetzung war aber handwerklich unsauber: fehlende Bereinigung der alten YAML-Einträge, ein Dialog der Daten vernichten kann ohne klare Warnung, Bugs in der Filter-Logik, keine automatische Benachrichtigung bei Schreibausfällen – und obendrauf noch eine fehlende Warnung im HA-Log wenn die Filter-Config ungültig ist oder keine Daten mehr geschrieben werden. Wer nicht aktiv in Grafana schaut, merkt schlicht nichts.
Wer das alles überlebt hat, sitzt jetzt hoffentlich mit einer sauberen Config und läuft wieder stabil. Und hat nebenbei gelernt, dass man sein Daten-Monitoring nie dem Zufall überlassen sollte.
1 „Gefällt mir“