HomeAssistant Container stürzt immer ab - Fehleranalyse

Guten Tag

Nachdem ich zuerst positive Erfahrungen mit Home Assistant machen durfte, habe ich die letzten Wochen nur Probleme damit. Aus unbekannten Gründen stürzt der Container mit Home Assistant regelmäßig nach ca. 20-40 Minuten ab.
Über der Terminal kann ich mit dem Home Assistant OS verbinden und manuell den Container mit Home Assistant neu starten.

Installationsmethode: Home Assistant OS
Core: 2025.6.1
Supervisor: 2025.05.5
Operating System: 15.2
Frontend: 20250531.3

Home Assistant wurde vor mehreren Monaten eingerichtet und dann vom Internet getrennt. Daher die etwas veralteten Versionen. Für die Fehleranalyse sollte das aber keine große Rolle spielen. Freue mich über Hinweise.

Des weiteren suche ich eine Methode, mit der ich regelmäßig prüfen kann, ob der Container noch läuft, und falls nicht, diesen neu starten. Dafür mache ich aber am besten ein eigenes Thema auf: Home Assistant Container aus HAOS neu starten bei beenden

Moin,

darf man erst einmal genauer erfahren was Du Installiert hast, ein HAOS

  • nativ auf einer Hardware
  • als VM in einem anderen Betriebssystem
    • Proxmox,
    • Unraid
    • Linux / Windows mit VirtualBox
  • als Container in einer Docker-Umgebung?

Denn, wenn man das so liest dann, sage ich mal Docker Container, aber eben auch wieder nicht.

Dann wären Logfiles schon ganz nett, oder auch wie sieht der dazugehörige PC aus, welche Ressourcen stehen zur Verfügung, auf welchem Medion wurde installiert,

  • SD-Kardt
  • HDD
  • SSD

Also frei nach Nummer 5 Lebt mehr Input bitte :slight_smile:

VG
Bernd

Danke für den Hinweis, dachte der kleine Info Part den ich aus Home Assistant kopiert habe würde genügen. Hier nochmal ausführlicher:

  • Home Assistant auf einem Raspberry Pi 5 mit einer SSD M.2 installiert

  • Das Abbild war haos_rpi5-64-14.1.img

  • OS Version: Home Assistant OS 15.2

  • Home Assistant Core: 2025.6.1

Das HAOS läuft stabil. Nur der Home Assistant Container wird immer wieder beendet. Da mein Home Assistant ohne Internetverbindung läuft, könnten es auch Fehlermeldungen sein die den Speicher überfluten oder ähnliches. Dagegen spricht, dass auf der SSD noch reichlich Platz ist und nach 5 Stunden (so lange läuft es nicht immer) noch 4 von 8 GB auf dem HAOS vorhanden sind (Davon 700 MB von HomeAssistant belegt.

HAOS verwendet Docker Container. Davon laufen auch eine ganze Menge und bis auf Home Assistant alle stabil (whisper, piper, matter-server etc. pp.)

Wo finde ich den die passenden Logfiles? HAOS verwendet scheinbar ein Journal und keine Logdateien mehr aber journalctl existiert auch nicht.

docker logs --since 1h homeassistant

2025-08-24 17:28:46.982 ERROR (MainThread) \[homeassistant.components.automation.hausture\] Aufnahme Haustüre: Error executing script. Error for choose at pos 1: Device not connected to local push notifications


2025-08-24 17:28:46.982 ERROR (MainThread) [homeassistant.components.automation.hausture] Error while executing automation automation.hausture: Device not connected to local push notifications2025-08-24 17:29:51.117 ERROR (MainThread) [metno] Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error ‘ClientConnectorDNSError’
2025-08-24 17:35:56.421 ERROR (MainThread) [metno] Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error ‘ClientConnectorDNSError’

Zigbee mach von Anfang an viele Fehlermeldungen, da werden einfach Fehler wie Gerät Offline scheinbar nicht abgefangen:

2025-08-24 17:38:23.773 ERROR (MainThread) [zigpy.zcl] [0x7882:1:0x0020] Traceback (most recent call last):File “/usr/local/lib/python3.13/site-packages/zigpy/device.py”, line 381, in requestreturn await req.result^^^^^^^^^^^^^^^^asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:  Traceback (most recent call last):File “/usr/local/lib/python3.13/site-packages/zigpy/zcl/init.py”, line 378, in requestreturn await self._endpoint.request(^^^^^^^^^^^^^^^^^^^^^^^^^^^^^…<9 lines>…)^File “/usr/local/lib/python3.13/site-packages/zigpy/endpoint.py”, line 270, in requestreturn await self.device.request(^^^^^^^^^^^^^^^^^^^^^^^^^^…<11 lines>…)^File “/usr/local/lib/python3.13/site-packages/zigpy/device.py”, line 380, in requestasync with asyncio_timeout(timeout):~~~~~~~~~~~~~~~^^^^^^^^^File “/usr/local/lib/python3.13/asyncio/timeouts.py”, line 116, in aexitraise TimeoutError from exc_valTimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/general.py”, line 710, in check_in_responseawait self.checkin_response(True, self.CHECKIN_FAST_POLL_TIMEOUT, tsn=tsn)File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/init.py”, line 85, in wrapperwith wrap_zigpy_exceptions():~~~~~~~^^File “/usr/local/lib/python3.13/contextlib.py”, line 162, in exitself.gen.throw(value)^^^^^^^File “/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/init.py”, line 70, in wrap_zigpy_exceptionsraise ZHAException(“Failed to send request: device did not respond”) from exczha.exceptions.ZHAException: Failed to send request: device did not respond

Und hier noch ein Wallpanel Error: Das brauche ich erstmal nicht mehr. Habe ich das selbst installiert? Beim entfernen habe ich wallpanel.js an vielen verschiedenen Stellen im System gefunden und daher dann auf dem System gelassen:

TypeError: can’t access property “user”, elHass.__hass is undefined
startup (/local/wallpanel.js:3346:2)
waitForEnv (/local/wallpanel.js:3342:2)
/local/wallpanel.js:3407:11

Du willst deine HA-Container, der aussteigt aus HA raus überwachen - hab ich das richtig verstanden ?

Wenn ja, wie soll das den gehen ?

Das musst schon von einem externen System aus machen, besser wäre es aber mal den Grund zu suchen, warum der ständig aussteigt, weil das ist nicht normal.

Hallo, ja den Grund suche ich ja auch. Trotzdem sehe ich es alt vorteilhaft an, wenn das Basissystem HAOS prüft ob der Docker Container “homeassistant” noch läuft. Und falls nicht diesen neu startet. Das hat auch bei der Fehleranalyse den Vorteil, da die Zeiten protokolliert werden.

Wie das gehen soll? Ich muss auf dem HAOS ein Skript zum laufen bekommen, dass alle 5 Minuten aufgerufen wird. Aber wie man das hinbekommt, das versuche ich hier zu erfragen. Notfalls muss man das wirklich über einen zusätzlichen Container machen, was ich aber vermeiden will.

Ich habe das Problem, dass mein Home Assistant Container regelmäßig beendet wird. Dem Grund dafür möchte ich gerade in einem anderen Thema auf den Grund gehen. HomeAssistant Container stürzt immer ab - Fehleranalyse

Schon vor diesem Problem, war es aber so, dass es manchmal unerwartet nicht lief, gerade wenn man ein paar Tage nicht zuhause war.

Hier wollte ich nun nach Tipps fragen, wie ich aus einem Home Assistant OS heraus prüfen kann, ob der Container noch läuft und diesen ggf. neu zu starten.

Ich habe mir dafür bereits Skripte angelegt, die auch die Zeiten protokollieren. Nur konnte ich keinen Ort im HAOS finden, unter dem so ein Skript funktioniert. Es ist ja kein vollständiges Linux System.

docker ps -a --filter “name=homeassistant” zeigt den laufenden ContainerSpeichernutzung nach einer Stunde ca. 8%
“ha core status” zeigt an ob der Container noch läuft!?
mit docker “ha core start” könnte ich es neu starten.

Dachte erst an einen Cronjob aber Cron schein auf dem HAOS nicht nutzbar oder vorhanden zu sein.

Freue mich über Vorschläge - Danke

Oh, warum wurden den hier die beiden grundsätzlich verschiedenen Themen von mir zusammen gelegt?

Das ein Thema bezog sich nur darauf, wie ich ein Skript auf HAOS regelmäßig laufen lassen kann.

Das andere auf das Problem mit der Fehleranalyse und den Programmabstürzen

:crayon:by HarryP: Zusammenführung Mehrfachpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)

Weil es die gleiche Problematik betrifft und sonst erstmal alle Fragen doppelt gestellt werden, wie auch drüben erklärt.

Ich habe die Erfahrung gemacht, dass es schnell unübersichtlich wird. Wie gesagt, bei dem einen Thema ging es nur darum, wie ich ein Skript ausführe. Aber ok, ist dann halt so.

Moin,

Ja, das ist bekannt, wenn man HAOS nutzt.
Wenn Du noch per ssh auf die Kiste kommst, oder nach einem reboot, dann kannst Du im Verzeichnis in dem die configuratin.yaml liegt schauen, da liegen drei Dateien

➜  ~ ls -la homeassistant/*.log*  
-rw-r--r--    1 root     root       3623782 Aug 24 19:00 homeassistant/home-assistant.log
-rw-r--r--    1 root     root       1571726 Aug 23 10:40 homeassistant/home-assistant.log.1
-rw-r--r--    1 root     root             0 Aug 23 10:40 homeassistant/home-assistant.log.fault
➜  ~ 

Wobei die erste .log die aktuelle ist, die mit .log.1 die von vor dem Reboot ist.

Du wirst Dein Ha aber auch so in die Knie zwingen, sobald Du Integrationen oder Erweiterungen installiert hast, die eine Internetanbindung brauchen und Du Dir dann irgendwann das System zum stillstand bringen, weil zu viele Fehler, das sieht man schon an den Einträgen, das etwas nicht erreicht wird, also entweder den Internetzugriff erlauben oder alle Erweiterungen, Integrationen deaktivieren, die einen brauchen.
Danach schauen, ob der RasPI durchläuft.

Dann denke ich, nicht böse gemeint, auch wenn Du Dich mit Docker auskennst, sollte man in HA nicht wirklich damit herumspielen, denn da sind einige Container, die aufeinander aufbauen, wenn man da an einem was macht, kann das auch auf den anderen durchschlagen.

Dann würde ich auch mal den RasPI auf eventuelle Hardwaredefekte untersuchen, also mal ein Memory-Test, oder einen CPU-Stresstest

VG
Bernd

Vielen Dank für deine Tipps, konnte die Logdateien nun auch finden.

Hier sehe ich ,dass es auch zu Programmfehlern kommt, wenn ein Gerät nicht erreichbar ist:

Beispiel OnVif Kamera:


2025-08-03 09:42:13.328 ERROR (MainThread) \[homeassistant.components.onvif\] TapoCCC200C: validation error while creating webhook subscription: Missing element Address (Subscribe.ConsumerReference.Address)
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/onvif/event.py”, line 539, in \_async_create_webhook_subscription
self.\_notification_manager = await self.\_device.create_notification_manager(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
…<3 lines>…
)
^
File “/usr/local/lib/python3.13/site-packages/onvif/client.py”, line 529, in create_notification_manager
await manager.start()
File “/usr/local/lib/python3.13/site-packages/onvif/managers.py”, line 70, in start
renewal_call_at = await self.\_start()
^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/onvif/managers.py”, line 225, in \_start
result = await notify_service.Subscribe(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
…<4 lines>…
)
^
File “/usr/local/lib/python3.13/site-packages/zeep/proxy.py”, line 64, in **call**
return await self.\_proxy.\_binding.send_async(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
…<5 lines>…
)
^
File “/usr/local/lib/python3.13/site-packages/zeep/wsdl/bindings/soap.py”, line 152, in send_async
envelope, http_headers = self.\_create(
\~\~\~\~\~\~\~\~\~\~\~\~^
operation, args, kwargs, client=client, options=options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File “/usr/local/lib/python3.13/site-packages/zeep/wsdl/bindings/soap.py”, line 73, in \_create
serialized = operation_obj.create(\*args, \*\*kwargs)
File “/usr/local/lib/python3.13/site-packages/zeep/wsdl/definitions.py”, line 225, in create
return self.input.serialize(\*args, \*\*kwargs)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/wsdl/messages/soap.py”, line 80, in serialize
self.body.render(body, body_value)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/element.py”, line 232, in render
self.\_render_value_item(parent, value, render_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/element.py”, line 256, in \_render_value_item
return self.type.render(node, value, None, render_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/types/complex.py”, line 301, in render
element.render(node, element_value, child_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/indicators.py”, line 249, in render
element.render(parent, element_value, child_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/element.py”, line 232, in render
self.\_render_value_item(parent, value, render_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/element.py”, line 256, in \_render_value_item
return self.type.render(node, value, None, render_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/types/complex.py”, line 301, in render
element.render(node, element_value, child_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/indicators.py”, line 249, in render
element.render(parent, element_value, child_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/element.py”, line 226, in render
self.validate(value, render_path)
\~\~\~\~\~\~\~\~\~\~\~\~\~^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/zeep/xsd/elements/element.py”, line 284, in validate
raise exceptions.ValidationError(
“Missing element %s” % (self.name), path=render_path
)
zeep.exceptions.ValidationError: Missing element Address (Subscribe.ConsumerReference.Address)

2025-08-03 09:42:17.351 WARNING (MainThread) \[homeassistant.setup\] Setup of battery_notes is taking over 10 seconds.
2025-08-03 09:42:17.352 WARNING (MainThread) \[custom_components.battery_notes.library_updater\] Unable to update library, will retry later.
2025-08-03 09:42:20.690 ERROR (MainThread) \[metno\] Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error ‘ClientConnectorDNSError’
2025-08-03 09:42:53.721 ERROR (MainThread) \[kasa.smart.smartdevice\] Error querying 192.168.5.130 for modules ‘Time, AutoOff, DeviceModule, Energy, PowerProtection’ after first update: ('Unable to query the device: 192.168.5.130: ', TimeoutError())

Das mit dem Stresstest ist grundsätzlich eine gute Idee, aber ich bezweifle das sehr, da in den ganzen letzten Monaten immer nur dieser eine Container betroffen war. Das werde ich bei Gelegenheit aber mal prüfen, dazu muss ich dann aber erst eine SD-Karte vorbereiten.

Ja, dass man die Container bzw. Orchestrierung nicht einfach ändern kann, habe ich schon festgestellt :slight_smile:

Wichtigste Frage für mich aktuell wäre noch, ob es eine Möglichkeit gibt regelmäßig ein Skript ausführen lassen zu können. Damit ich den Container Status prüfen und ggf. neu starten kann.

Moin,

bitte für Code oder Logs die Code-Tags </> nutzen, dann liest sich das besser

Das ist ja auch normal, wenn Du sagst, der RasPI hat kein Netz, was das dann alles auch für die interne Kommunikation heißt, kann ich nicht sagen, da ich nicht weiß, was Du genau gemacht hast, also eine Firewall oder im Router nur den Netzverkehr ins böse Internet abgestellt hast :man_shrugging:

Und dann wird es dem Rechner irgendwann zu blöd und er stellt die Arbeit ein.

Also ich würde einmal, entweder

  • den RasPI ins Internet lassen und schauen, ob es dann stabil läuft, oder
  • alle Integrationen, die eine Internetverbindung brauchen deaktivieren und dann schauen, ob es geht.

VG
Bernd

P.S.: ok, mein Hinweis mit dem Code-Tag ist hinfällig :slight_smile:

Update: Ich habe die Ursache inzwischen eingrenzen können.

Das Problem waren vor allem die Tapo-Kameras und die Kasa-Steckdosen. Die ONVIF-Integration der Tapo-Kameras wirft regelmäßig Validation-Errors, und die Kasa-Geräte laufen in Timeouts. Wenn sich das über 20–40 Minuten aufstaut, reißt es den ganzen Container mit.

Dazu kommt die Met.no-Wetterintegration, die bei einem System ohne Internet natürlich ständig DNS-Fehler produziert. Die habe ich jetzt entfernt.

Mein Fazit nach über einem Jahr mit Tapo/TP-Link: Ich bin nicht wirklich zufrieden. Die Kameras haben ein 1024-bit SSL-Zertifikat, das von neuerer Software abgelehnt wird, ONVIF macht Probleme, und ohne die Tapo-App bekommt man die neueren Modelle (C310 v2) gar nicht erst eingerichtet, weil TP-Link einen Cloud-Account erzwingt.

Ich bin inzwischen auf Reolink umgestiegen (RLC-510WA). Einrichtung komplett ohne Herstellerapp über ein Python-Skript (reolink-aio), sauberes RTSP, native HA-Integration, und die Verarbeitungsqualität ist spürbar besser. Seitdem keine Abstürze mehr.

Kurzfassung: Wer mit Tapo-Abstürzen kämpft — prüft mal, ob die ONVIF- und Kasa-Integrationen die Fehlerquelle sind. Und wer eine Alternative sucht: Reolink funktioniert bei mir deutlich stabiler.

Zudem habe ich mein HomeAssistant inzwischen auf einem RPi4 ohne Docker am laufen, doppelt so schnell wie das mit Container auf dem RPi5! Updates 30 MB statt 2.1 GB, viel weniger RAM-Verbrauch, und wesentlich stabiler als alles was ich in dem einen Jahr mit Docker ertragen musste.

Oder einfach mal die hier fast immer bei Tapo Kameras erwähnte Tapo camera control integration nutzen. Macht unter anderem auch bei mir seit Jahren mit 6 Kameras 0 Probleme. :wink: