J’ai depuis quelques jours (3/4) une perte d’accessibilité de ma box domotique sous Home Assistant sans que je comprenne pourquoi … Après chaque redémarre tout refonctionne parfaitement mais au bout d’un certains temps (12h voire moins) je reperds l’accès.
Hier j’ai pourtant trouvé des erreurs dans mes logs et en cherchant sur le net j’ai trouvé qu’il fallait faire un « ha supervisor repair » mais visiblement ça n’a pas suffit. Je n’ai pas de saturation quelconque (mémoire, cpu, disque) et je ne viens pas d’installer un nouveau add-on ou intégration. Je n’ai pas non plus créé des nouvelles automatisations.
Hier après le « repair » j’ai dû désinstaller et réinstaller frigate et node-red qui ne voulait plus démarrer pour des raisons assez obscures.
Ce matin j’étais donc confiant puisqu’après plus de 12h tout semblait ok mais ce soir rebelotte … perte de connexion.
Est-ce qu’il y a une news que j’aurais pas vu/lu avec la dernière version de Home Assistant qui poserait soucis ?
J’ai récupéré des logs mais à chaque fois ça reste des logs de démarrage pas de l’historique au moment où ça plante … comment faire pour les avoir ?
Je crois que je viens de trouver et j’ai ceci dans les logs :
2023-10-22 16:01:06.094 INFO (MainThread) [homeassistant.components.recorder] Backup start notification, locking database for writes
2023-10-22 16:02:17.923 INFO (MainThread) [homeassistant.components.recorder] Backup end notification, releasing write lock
2023-10-22 16:02:17.924 INFO (Recorder) [homeassistant.components.recorder.core] Database queue backlog reached 23 entries during backup
je ne connais pas ce port mais je testerai si ça resurvient. C’est quoi un port « sans échec » ?
J’ai trouvé une erreur dans mes logs qui revient à de multiples reprises :
Logger: homeassistant.helpers.event
Source: helpers/template.py:570
First occurred: 22:28:06 (26 occurrences)
Last logged: 22:28:07
Error while processing template: Template<template=({{ states('sensor.sun_next_setting') | as_timestamp | timestamp_custom(' %I:%M %p', default=0) }}) renders=6>
Error while processing template: Template<template=({{ states('sensor.sun_next_rising') | as_timestamp | timestamp_custom(' %I:%M %p', default=0) }}) renders=10>
Error while processing template: Template<template=({{ states('sensor.sun_next_setting') | as_timestamp | timestamp_custom(' %I:%M %p', default=0) }}) renders=8>
Error while processing template: Template<template=({{ states('sensor.sun_next_rising') | as_timestamp | timestamp_custom(' %I:%M %p', default=0) }}) renders=22>
Error while processing template: Template<template=({{ states('sensor.sun_next_setting') | as_timestamp | timestamp_custom(' %I:%M %p', default=0) }}) renders=18>
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 568, in async_render
render_result = _render_with_context(self.template, compiled, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 2196, in _render_with_context
return template.render(**kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/jinja2/environment.py", line 1301, in render
self.environment.handle_exception()
File "/usr/local/lib/python3.11/site-packages/jinja2/environment.py", line 936, in handle_exception
raise rewrite_traceback_stack(source=source)
File "<template>", line 1, in top-level template code
File "/usr/local/lib/python3.11/site-packages/jinja2/sandbox.py", line 393, in call
return __context.call(__obj, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: AllStates.__call__() got an unexpected keyword argument 'default'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 694, in async_render_to_info
render_info._result = self.async_render(
^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 570, in async_render
raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: AllStates.__call__() got an unexpected keyword argument 'default'
Mais je ne vois pas trop en quoi cela causera un arrêt de l’instance Home Assistant et sa non accessibilité. Surtout que l’affichage est totalement correcte sur mon dashboard
Information complémentaire, j’ai HA qui me propose une mise à jour de Home Assistante Core Update mais que je n’arrive pas à appliquer ça tourne en rond mais pas de message d’erreur ou autre
Cette après-midi replantage (je n’avais pas vu votre réponse je n’ai pas pu tester le port 4357).
Vu l’heure approximative du plantage je penche pour un soucis avec Samba Backup (plantage entre 15h et 17h, sauvegarde programmée à 16h), car je n’ai pas de sauvegarde de faite.
Par contre dans le fichier log.1 aucune trace inhabituelle, rien sur les logs de samba backup, …
Je viens de « forcer » une sauvegarde en étant sur mon interface et en indiquant de faire une sauvegarder dans 10 minutes (vue capacité CPU et RAM, terminal répertoire backup, add-on log samba, log supervisor, …)
Tout semblait OK puisqu’il a m’a bien généré un backup en local :
Sauf que 2 minutes après plus accès à rien ! Même le port 4357 me renvoi une erreur « Ce site est inaccessible », et bien sûr rien sur mon NAS qui est la destination « à distance » du backup. Je crois donc avoir trouvé mon fauteur de trouble
Reste à comprendre pourquoi d’un coup il se met à me poser des problèmes …
Puisque je n’ai pas eu de plantage suite à l’arrêt de l’add-on Samba Backup, j’ai voulu tenter la mise à jour qui m’était proposé sur Home Assistant Core 2023.10.5 (à partir de 2023.10.3) mais voilà c’était trop beau.
J’ai bien sûr décoché la case demandant de faire un backup au préalable puisque je savais que c’était un peu bancal de ce côté là. Par contre la mise à jour ne s’est pas faite et j’ai même perdu l’accès à Home Assistant, l’observer ne répondait pas non plus donc plantage total a priori.
Après un redémarrage forcé donc, aucune trace d’erreur dans les logs historique (log.1) ni dans Système → Logs → Home Assistant Core / Supervisor …
Où est-ce que je pourrais trouver une log qui m e dirait pourquoi ça a planté : manque d’espace disque, problème CPU, problème RAM, problème lock sur un fichier, n’importe quoi qui me mettrait sur la piste.
J’ai regardé du côté de Système → Correction mais visiblement tout est OK (mouais …)
Merci pour votre aide !
EDIT : Ce soir plantage à nouveau
Dans le fichier log.1 toujours pas d’erreur, les derniers messages sont :
2023-10-25 21:11:15.594 INFO (MainThread) [homeassistant.components.recorder] Backup start notification, locking database for writes
2023-10-25 21:12:26.118 INFO (MainThread) [homeassistant.components.recorder] Backup end notification, releasing write lock
2023-10-25 21:12:26.120 INFO (Recorder) [homeassistant.components.recorder.core] Database queue backlog reached 11 entries during backup
Que je ne comprends pas bien puisque j’ai désactivé l’add-on de backup …
Salut salut, toujours avec le même soucis de mon côté …
J’ai déporté frigate sur mon nas synology via docker au cas où ça pouvait poser soucis en terme de charge cpu/ram mais visiblement ça ne change pas grand chose.
J’ai également fait manuellement un backup via Système → Sauvegarde. Le fichier a bien été généré (suivi faite via terminal dans le répertoire backup) et était même visiblement depuis l’interface ! J’ai commencé à le télécharger et hop perte de connexion '-_-
Et bien sûr aucune information dans les logs qui me permettent de trouver la cause …
Ca tourne sur quelle machine ?
Ca ressemble à un problème de port Ethernet qui se met en vrac.
Si c’est du realtek, il ne faudra pas chercher plus loin…
Home Assistant tourne sur un Intel NUC modèle NUC6CAY
Visiblement c’est un port ethernet « realtek » de ce que je vois sur la doc. Ca serait un soucis connu ? Il est apparu avec la dernière version de Home Assistant ? Ya un contournement ou un correctif ?
Si tu cherches sur google issue realtek ethernet linux tu verras de nombreuses réponses.
Ce n’est pas nouveau.
C’est assez aléatoire, ça peut marcher pour certains, dans certaines versions, pas pour d’autres…
En résumé, c’est pas fiable.
A ma connaissance, pas vraiment. Parfois, une nouvelle version d’un driver améliore les choses. Parfois non.
En gros, dès que tu as un trafic important sur l’interface ça peut arriver.
Je ne sais pas si un port Ethernet via l’usb3 pourrait améliorer les choses, ni si HAOS le supporte.
Du coup le mieux serait de changer de mini-pc pour un qui n’a pas de port ethernet « realtek » ?
Au delà du fait de devoir racheter un mini-pc n’ayant plus de sauvegarde depuis plusieurs jours/semaines je vais devoir tout reconfigurer du coup …
J’ai dû mal quand même à comprendre pourquoi cela m’arrive maintenant alors que tout fonctionnait nickel il y a encore quelques jours/semaines … Il me semblait que l’aléatoire n’existait pas en informatique
D’ailleurs c’est quoi le rapport du plantage avec le port ethernet lors d’une sauvegarde en local ? A priori il n’est pas utilisé et ne devrait pas poser de soucis à ce moment là non ?
Bonjour, as tu essayé d’envoyer un ping via la CLI vers une autre adresse présente sur ton réseau quand c’est planté? tu as installé HAOS directement sur le NUC ou tu passes par un hyperviseur?
Oui j’ai installé Home Assistant OS sur le SSD de mon Intel NUC directement.
Quand tu dis « envoyer un ping via la CLI » tu parles depuis le NUC vers un autre équipement de mon réseau genre mon NAS ? Si c’est bien ça je n’ai jamais essayé car je n’ai pas d’écran ni de clavier sur mon nuc d’installer du coup j’ai pas vraiment la main dessus et je n’ai pas mis en place un système de connexion à distance dessus
ça c’est pas bien
Si c’est réellement un problème de compatibilité entre la carte réseau et HAOS, l’idée serai d’installer un hyperviseur comme Proxmox et faire une VM pour ton HAOS comme ça plus de problème puisque c’est l’hyperviseur qui va gérer la carte. Celle reliée à HAOS sera générée par l’hyperviseur.
j’avais un souci similaire mais qui venait de proxmox lui meme suite à la version 8.
Perte de connexion à HA et autres VM dû à la carte réseau non reconnue par Proxmox.
Je ne sais pas si tu tournes avec proxmox sur ton NUC. Normalement le souci a été réglé par proxmox mais on sait jamais ca peut etre une piste.
Je ne sais si c’est pour moi… mais perso je suis avec Proxmox et je n’ai pas de problème. Mon NUC est un vieux ThinkCentre I5 4ème génération avec 16Go de RAM. IL fait tourner 4VM. Mon HA est stable, rien à voir avec mon RPI3 .
.