Depuis quelques jours, HA redémarre tout seul plusieurs fois par jour. Voilà ce que je trouve dans les logs :
24-02-04 00:31:23 ERROR (MainThread) [supervisor.homeassistant.api] Error on call https://172.30.32.1:8123/api/core/state: Cannot connect to host 172.30.32.1:8123 ssl:False [Connection reset by peer]
24-02-04 00:31:23 WARNING (MainThread) [supervisor.misc.tasks] Watchdog miss API response from Home Assistant
24-02-04 00:31:23 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Cannot proxy websocket message of unsupported type: 257
24-02-04 00:31:23 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API connection is closed
24-02-04 00:31:28 WARNING (MainThread) [supervisor.homeassistant.core] Watchdog found Home Assistant failed, restarting...
24-02-04 00:31:28 INFO (SyncWorker_2) [supervisor.docker.manager] Starting homeassistant
C’est arrivé avant que je n’applique les dernières MAJ du Core et de Z2M. Je ne sais pas à quoi correspond l’IP en question. Une idée de ce dont il s’agit?
System Information
version
core-2024.1.6
installation_type
Home Assistant OS
dev
false
hassio
true
docker
true
user
root
virtualenv
false
python_version
3.11.6
os_name
Linux
os_version
6.1.63-haos-raspi
arch
aarch64
timezone
Europe/Paris
config_dir
/config
Home Assistant Community Store
GitHub API
ok
GitHub Content
ok
GitHub Web
ok
GitHub API Calls Remaining
5000
Installed Version
1.33.0
Stage
running
Available Repositories
1381
Downloaded Repositories
31
Home Assistant Cloud
logged_in
false
can_reach_cert_server
ok
can_reach_cloud_auth
ok
can_reach_cloud
ok
Home Assistant Supervisor
host_os
Home Assistant OS 11.4
update_channel
stable
supervisor_version
supervisor-2023.12.1
agent_version
1.6.0
docker_version
24.0.7
disk_total
916.2 GB
disk_used
206.8 GB
healthy
true
supported
true
board
rpi4-64
supervisor_api
ok
version_api
ok
installed_addons
Duck DNS (1.15.0), File editor (5.7.0), Frigate (Full Access) (0.12.1), Node-RED (17.0.4), Samba Backup (5.2.0), Samba share (12.2.0), Terminal & SSH (9.8.1), Zigbee2MQTT (1.35.2-1), go2rtc (1.8.5), Studio Code Server (5.15.0)
Salut,
c’est une IP du réseau interne de Docker, surement celle du container HA.
Peux tu partager ta config, comme demandé dans un nouveau sujet, ça pourrait aider quelqu’un pour t’orienter.
L’erreur en elle même je ne saurais dire exactement, mais comme ça parle de SSL, tu n’aurais pas tenté d’activer HTTPS pour un accès extérieur?
Merci pour ta réponse et désolé d’avoir oublié la recopie de la config, voilà qui est corrigé. Merci pour l’info au sujet de Docker… Mais qu’en faire? Je n’ai pas tenté récemment d’ouvrir un accès extérieur en SSL.
Alors vu la liste des addons (frigate, go2rtc, studio) et la taille de la base à 16Go… Sur un pi4, ça me semble pas tellement étonnant que ce soit pas stable…
Tu crois que c’est ça? Le problème est apparu il y a quelques jours seulement, tout est installé depuis des mois. Studio est désactivé par défaut. Go2rtc je n’en ai plus besoin, je vais le virer, Nodered aussi, je n’ai jamais réussi à le faire fonctionner. Je vais faire un peu de ménage pour voir. Et depuis quelques temps je réfléchis aussi à passer sur une machine plus puissante…
Perso j’ai pas vraiment de doute, 16Go c’est colossale. Tu avais déjà un souci de taille au moins d’aout (90j d’historiques) mais à priori tu n’as pas pris le temps de traiter, là c’est pire
J’ai du mal avec le principe de la course à l’armement… Il y a quand même tout un tas d’autres trucs pour avoir une config efficace sans pour autant changer d’infra
Alors il y a un truc qui m’échappe. Suite à l’épisode d’août j’ai passé le délai de conservation de 90 à 14 jours… Et lancé un purge au niveau du recorder. Là je viens d’abaisser à 10 jours… pourquoi ma database ne diminue pas? Je ne vérifiais pas dans corrections/infos system, je n’avais pas repéré cette information à cet endroit là, c’est aujourd’hui que je le découvre grâce à ta remarque. Je vais creuser ça. A l’époque on regardait la taille de mes backups, donc c’est ça que j’ai surveillé et ça n’augmente pas.j
C’est pas uniquement la durée qu’il faut modifier, mais aussi les infos que tu y mets… ça fait partie des autres éléments de config du recorder.
Et quand tu lances une purge manuelle , il faut aussi penser à cocher la case ‹ repack ›, sinon la taille du fichier n’est pas recalculée
Merci. J’ai passé du temps à lire à ce sujet et à configurer tout ça aujourd’hui.
Bizarrement, ma base de données, qui avait déjà diminuée à 13Go a planté (corrupt) et une nouvelle repart de zéro. Finalement pourquoi pas…
Mais ce soir, alors que la nouvelle database fait seulement 650Ko, re-plantage.
Peu avant le plantage, j’avais lancé une purge avec repack, car je n’avais pas vu que la base avait planté vers 21h et que la nouvelle faisait seulement 650Ko. Malgré tout, ça ne devrait pas faire planter HA ?
24-02-06 00:17:15 WARNING (MainThread) [supervisor.addons.options] Unknown option 'base_topic' for Zigbee2MQTT (45df7312_zigbee2mqtt)
24-02-06 00:19:59 WARNING (MainThread) [supervisor.homeassistant.websocket] Connection is closed
24-02-06 00:19:59 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-83321' coro=<HomeAssistantWebSocket.async_supervisor_event() done, defined at /usr/src/supervisor/supervisor/homeassistant/websocket.py:318> exception=AttributeError("'NoneType' object has no attribute 'close'")>
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 263, in async_send_message
await self._client.async_send_command(message)
File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 93, in async_send_command
return await self._futures[message["id"]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
supervisor.exceptions.HomeAssistantWSConnectionError: Connection was closed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 323, in async_supervisor_event
await self.async_send_message(
File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 265, in async_send_message
await self._client.close()
^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'close'
24-02-06 00:19:59 ERROR (MainThread) [supervisor.homeassistant.api] Error on call https://172.30.32.1:8123/api/core/state: Cannot connect to host 172.30.32.1:8123 ssl:False [Connection reset by peer]
24-02-06 00:20:04 WARNING (MainThread) [supervisor.homeassistant.core] Watchdog found Home Assistant failed, restarting...
C’est pas les websocket qui plante l’accès à la base.
Les corruptions sont e’et général liées à un arrêt un peu sauvage. À voir aussi si tu ne jouais pas avec le fichier à ce moment là
Bref, là tu as une base légère, tu laisse tourner. Pas de purge manuelle etc. Tu mets juste la surveillance de la taille en place
OK merci Pulpy. Pour l’erreur d’hier ça devait être dû aux manips manuelles. Malheureusement ce soir un reboot sauvage, avec les mêmes logs que ces derniers jours vient de se produire, ça ne venait donc pas de la database (qui en est à 270Mo).
24-02-07 00:49:49 INFO (MainThread) [supervisor.host.info] Updating local host information
24-02-07 00:49:50 WARNING (MainThread) [supervisor.homeassistant.websocket] Connection is closed
24-02-07 00:49:50 ERROR (MainThread) [supervisor.homeassistant.api] Error on call https://172.30.32.1:8123/api/core/state: Cannot connect to host 172.30.32.1:8123 ssl:False [Connection reset by peer]
24-02-07 00:49:52 INFO (MainThread) [supervisor.host.services] Updating service information
24-02-07 00:49:52 INFO (MainThread) [supervisor.host.network] Updating local network information
24-02-07 00:49:52 INFO (MainThread) [supervisor.host.sound] Updating PulseAudio information
24-02-07 00:49:52 INFO (MainThread) [supervisor.host.manager] Host information reload completed
24-02-07 00:49:56 WARNING (MainThread) [supervisor.homeassistant.core] Watchdog found Home Assistant failed, restarting...
24-02-07 00:49:56 INFO (SyncWorker_5) [supervisor.docker.manager] Starting homeassistant
Quand tout se passe bien, ça ressemble à ça :
24-02-06 22:43:04 INFO (MainThread) [supervisor.host.info] Updating local host information
24-02-06 22:43:05 INFO (MainThread) [supervisor.host.services] Updating service information
24-02-06 22:43:05 INFO (MainThread) [supervisor.host.network] Updating local network information
24-02-06 22:43:05 INFO (MainThread) [supervisor.host.sound] Updating PulseAudio information
24-02-06 22:43:06 INFO (MainThread) [supervisor.host.manager] Host information reload completed
C’est donc dans la séquence « Updating local host information » que ça déconne.
Il y a toujours des reboot environ 5 fois par jour… A chaque fois je retrouve d’une manière ou d’une autre dans les logs : websocket API connexion is closed…
Le Pi est déjà sur onduleur.
24-02-07 23:36:25 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state running
24-02-07 23:36:25 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete
24-02-07 23:37:34 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
24-02-07 23:40:17 WARNING (MainThread) [supervisor.addons.options] Unknown option 'base_topic' for Zigbee2MQTT (45df7312_zigbee2mqtt)
24-02-07 23:45:17 WARNING (MainThread) [supervisor.addons.options] Unknown option 'base_topic' for Zigbee2MQTT (45df7312_zigbee2mqtt)
24-02-07 23:48:13 WARNING (MainThread) [supervisor.homeassistant.websocket] Connection is closed
24-02-07 23:48:18 WARNING (MainThread) [supervisor.homeassistant.core] Watchdog found Home Assistant failed, restarting...
24-02-07 23:48:18 INFO (SyncWorker_0) [supervisor.docker.manager] Starting homeassistant
OK, je vais suivre tes pistes. Premier truc que j’ai remarqué : j’ai une automation qui éteint l’alimentation de ma clé Coral à la fermeture de HA et la rallume au boot, car parfois cette alim bloque le démarrage. Il y avait un souci dans ma programmation et il arrivait que la prise ne se rallume pas. Depuis que j’ai corrigé ça j’ai beaucoup moins de reboot (donc ça va dans ton sens de souci électrique)… Mais malheureusement il y en a eu un hier soir. Pour savoir si c’est lié à l’onduleur j’ai repassé le Pi sur le courant directement, et on va voir.
Je vais aussi mettre en place la surveillance du Pi comme tu le dis, je dois aussi mettre en place la surveillance de la database, dès que je trouve le temps…
Alors j’ai avancé sur le sujet et suivant tes conseils Pulpy.
J’ai commandé, reçu et finalement changé les batteries de mon onduleur aujourd’hui.
Entre temps j’ai mis en place la surveillance de la base de données qui gonfle malgré les mesures que j’ai prises (5Go aujourd’hui). Je surveille aussi le processeur et la mémoire.
Il semble que les reboots étaient liés à une suractivité du Pi : demande de processeur à 100%.
Et surtout, j’avais écrit des automatisations de cette façon :
Sans action ou temporisation dedans. Je crois que c’est ça qui grillait le Pi. C’était une manière d’utiliser l’IU pour faire un ‹ wait template ›. ‹ Attendre un déclencheur › ne convenait pas, car il ne se déclenche pas si le changement d’état a déjà eu lieu. Du coup je me suis un peu renseigné et j’ai utilisé ‹ wait_template › et je n’ai plus de soucis.
Il n’en reste pas moins que mon Pi est assez lent car il est très chargé. C’est Frigate avec ses 8 caméras qui consomment beaucoup. Même avec une clé Coral il reste du travail pour le Pi. Si j’éteins Frigate je tombe à 20% de processeur au lieu de 60% en mode « repos ».
Je pense que je vais devoir faire évoluer ma configuation vers quelque chose de plus puissant, ne serait-ce que pour ne plus avoir à cliquer et attendre 10 secondes avant de voir la ligne se déplier dans mes plus grosses automations.
Quitte à refaire une config, je créerai le serveur z2m sur la même machine que HA, car cela crée peut-être des lags liés au réseau. A l’époque, j’avais installé mosquitto sur mon synology car j’imaginais avoir deux HA reliés au même serveur. J’ai compris depuis qu’il y avait beaucoup plus simple et fiable et surtout ma dépendance discute parfaitement avec la maison via les relais zigbee (pas de souci de ce côté là du réseau).