Investigation devices MQTT et autres intégrations en erreur

Bonjour à tous,

Utilisateur depuis 2 ans d’une installation HomeAssistant (boitier green), il aura fallu un problème pour que je m’inscrive finalement ici…

Mon problème

Mon réel problème est que je n’arrive pas à réellement cibler ce qui ne fonctionne plus et que j’ai besoin d’aide / idées pour investiguer plus en profondeur.

J’ai détecté un problème suite à un simple reboot de HA. J’imagine qu’une modificationde config a été réalisée précédemment via un upgrade ou autre et que le reboot l’a « activé » (je n’avais pourtant aucune notif me demander de rebooter suite à un update d’addon).

J’ai détecté ensuite un problème lié à la disponibilité des devices liés à l’intégration MQTT (plus aucune valeur affichées, toutes les entités sont indiquées comme non disponibles.
J’utilise Zigbee2MQTT pour un ensemble de capteurs et vannes thermostatiques et mosquitto broker.
J’ai donc d’abord gratté ceci et ai pu confirmer que:

  • Entre mes devices zigbee et zigbeemqtt, tout roule, je vois les valeurs, je sais envoyer des commandes…
  • Via MQTT esplorer, je sais me connecter au broker je vois bien les topics de zigbeemqtt avec des valeurs qui évoluent
  • Dans les logs des deux, rien d’anormal, (forcément vu les tests ci-dessus)

Du coup, un peu fatigué hier j’ai d’abord restauré le backup de 24h avant ==> Aucune amélioration, toujours le même constat. J’ai donc remis le backup que j’ai fait avant le rollback pour récupérer toutes les données et logs avant/après l’apparition du problème.

En ouvrant des yeux plus réveillés ce matin, je m’apperçoit que le problème est plus conséquent, j’ai pas mal d’intégrations qui ne se chargent plus:

  • Daikin Onecta
  • Devolo Home Network
  • Dyson
  • Meteorologisk

MQTT en tant qu’intégration ne montre pas de problème dans les réglages mais les entités des devices sont juste tous non disponibles. Forcément, toutes les automations etc basées dessus ne fonctionnement plus.
Quelques devices de l’intégration « ESP Home » (compteurs eau et élec) fonctionnent sans soucis.

En investiguant au hasard, je vois que la config réseau (/etc/resolv) semble non fonctionnelle car les DNS ne sont pas résolus.
Je sais pourtant toujours accéder à mon instance depuis mon réseau local.

Les logs n’indiquent rien de bien utile, si quelqu’un pouvait déjà me guider dans le debug pour comprendre le point commun entre tous ces problèmes, ça me ferait pas mal avancer.

Merci d’avance.

Ma configuration


System Information

version core-2025.12.4
installation_type Home Assistant OS
dev false
hassio true
docker true
container_arch aarch64
user root
virtualenv false
python_version 3.13.9
os_name Linux
os_version 6.12.51-haos
arch aarch64
timezone Europe/Brussels
config_dir /config
Home Assistant Community Store
error failed to load: unknown
Home Assistant Cloud
logged_in false
can_reach_cert_server failed to load: timeout
can_reach_cloud_auth failed to load: timeout
can_reach_cloud failed to load: timeout
Home Assistant Supervisor
host_os Home Assistant OS 16.3
update_channel stable
supervisor_version supervisor-2025.12.3
agent_version 1.7.2
docker_version 28.3.3
disk_total 1833.7 GB
disk_used 13.2 GB
nameservers 192.168.1.1
healthy true
supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization
board green
supervisor_api ok
version_api failed to load: timeout
installed_addons File editor (5.8.0), Mosquitto broker (6.5.2), Zigbee2MQTT (2.7.1-1), Terminal & SSH (9.21.0), Silicon Labs Flasher (0.4.0)
Dashboards
dashboards 7
resources 3
views 14
mode storage
Network Configuration
adapters lo (disabled), end0 (enabled, default, auto), docker0 (disabled), hassio (disabled), vethed3c43e (disabled), vethf281c6c (disabled), vethaba48ed (disabled), vethab0775d (disabled), veth6b956c5 (disabled), vethf3953b0 (disabled), veth2cf216d (disabled), veth130b709 (disabled)
ipv4_addresses lo (127.0.0.1/8), end0 (192.168.1.201/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), vethed3c43e (), vethf281c6c (), vethaba48ed (), vethab0775d (), veth6b956c5 (), vethf3953b0 (), veth2cf216d (), veth130b709 ()
ipv6_addresses lo (::1/128), end0 (fe80::f1b:d01c:2ca8:2128/64), docker0 (fe80::74e8:2dff:fe96:8a30/64), hassio (fe80::24c0:10ff:fe4d:d4bb/64), vethed3c43e (fe80::5097:afff:feca:283c/64), vethf281c6c (fe80::2c40:c4ff:fefe:3fc5/64), vethaba48ed (fe80::2cfd:9cff:fe47:9278/64), vethab0775d (fe80::c48c:7cff:feca:3f14/64), veth6b956c5 (fe80::e44c:38ff:fe69:2d74/64), vethf3953b0 (fe80::bce8:1cff:fec8:21a6/64), veth2cf216d (fe80::a4e9:96ff:fee0:830a/64), veth130b709 (fe80::883d:9aff:fe94:8538/64)
announce_addresses 192.168.1.201, fe80::f1b:d01c:2ca8:2128
Recorder
oldest_recorder_run December 11, 2025 at 05:37
current_recorder_run December 27, 2025 at 13:06
estimated_db_size 1418.79 MiB
database_engine sqlite
database_version 3.49.2

Quelques informations en plus, en analysant les autres logs, j’ai un pattern sur les logs de DNS, Audio et multicast qui, juste après le dernier reboot répètent en boucle
exec /init: no such file or directory

Toutes les query DNS sont bloquées. Exemple du log sur « Host »:
2025-12-28 07:06:22.620 homeassistant dockerd[558]: time="2025-12-28T08:06:22.619920482+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.30.33.3:49283" dns-server="udp:172.30.32.3:53" error="read udp 172.30.33.3:49283->172.30.32.3:53: i/o timeout" question=";raw.githubusercontent.com.\tIN\t AAAA"

Depuis une connection SSH:

  • ha dns stats donne Error: Container hassio_dns is not running
  • ha dns restart génère le log suivant dans le log de Host
2025-12-28 08:03:25.279 INFO (SyncWorker_3) [supervisor.docker.manager] Restarting hassio_dns
2025-12-28 08:03:27.178 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-3362' coro=<PluginDns.watchdog_container() done, defined at /usr/src/supervisor/supervisor/plugins/dns.py:348> exception=CoreDNSJobError('Rate limit exceeded, more than 10 calls in 0:30:00')>
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/plugins/dns.py", line 353, in watchdog_container
    return await super().watchdog_container(event)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/plugins/base.py", line 112, in watchdog_container
    await self._restart_after_problem(event.state)
  File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 287, in wrapper
    if not await self._handle_throttling(group_name):
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 552, in _handle_throttling
    raise on_condition(
        f"Rate limit exceeded, more than {self.throttle_max_calls} calls in {self.throttle_period(group_name)}",
    )
supervisor.exceptions.CoreDNSJobError: Rate limit exceeded, more than 10 calls in 0:30:00

Je ne comprend pas ce qui aurait pu mettre cette partie du système sur les genoux car, à part appliquer les mises à jour régulièrement et configurer mes dashboard je n’ai plus rien modifié depuis des mois.
Quelqu’un à une idée pour réparer ceci sans devoir tout ré-installer ?

Après avoir passé pas mal de temps à investiguer et rechercher sur le net + rapport de bug chez HA et étant pas mal impacté pour la gestion du chauffage à la maison j’ai lancé une remise à l’état usine du HA Green et ré-importé le dernier backup.

Le bon point c’est que tout refonctionne comme avant.
Le mauvais point c’est que je ne comprends toujours pas l’origine du problème et donc qu’il pourrait resurvenir un jour et que je n’ai toujours pas de solution.

On dirait que les containers DNS/Audio/Multicast ont été corrompu et j’aurais trouvé plus efficace de simplement pouvoir les reconstruire (ce qui est quand même la base de l’utilisation de containeurs) mais je n’ai trouvé aucune info/doc sur ceci.

Ce sujet a été automatiquement fermé après 2 jours. Aucune réponse n’est permise dorénavant.