Plantage et démarrage Z2M bloqués à plusieurs reprises : problème de Dongle?

Bonjour,

Cela fait 3 fois maintenant que Z2M se plante à un moment donné et refuse ensuite de redémarrer normalement.

J’avais déjà eu ça (voir Multiple Error dans le journal Z2M et CPU >50%), mais cette fois les symptomes semblent différents…

Lorsque ça arrive (ce que je vois car plus aucun périphérique zigbee fonctionne, toutes les connexions apparaissent grisée), il me dit que Z2M n’a pas démarré, et dans le journal, j’ai plusieurs fois le message :

Starting Zigbee2MQTT without watchdog.
[2025-03-16 09:22:09] error: 	z2m: Error while starting zigbee-herdsman
[2025-03-16 09:22:09] error: 	z2m: Failed to start zigbee-herdsman
[2025-03-16 09:22:09] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2025-03-16 09:22:09] error: 	z2m: Exiting...
[2025-03-16 09:22:09] error: 	z2m: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:113:27)
    at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/controller.ts:136:29)
    at Zigbee.start (/app/lib/zigbee.ts:69:27)
    at Controller.start (/app/lib/controller.ts:142:13)
    at start (/app/index.js:161:5)

Ca semble dire qu’il ne trouve pas le controleur.
Dans ces cas là, quand je suis sur place, ce qui a marché les fois d’avant, c’est d’éteindre la machine miniPC où est installé HA, retirer la clé, la remettre, réallumer le miniPC et après qq minutes, et avec aussi un démarrage de l’add-on Z2M manuel, ca finit par marcher.

Mais ça fait 4 fois que ça arrive en un mois. Et là, c’est en plus arrivé quand je n’était pas sur place !
J’ai une clé Sonoff ZBDongle-P depuis au moins 2 ans, et c’est la première fois que ça m’arrive.
Avant le plantage (qui a eu lieu cette nuit), le journal ne montre que des messages de périphérique absent (normal, car plusieurs sont non connectés, ou sur des prises éteinttes) et une histoire de calibration de température:

2025-03-15 17:33:32] error: 	z2m: Failed to read state of 'Volet_ch_parent' after reconnect (ZCL command 0x00124b002516daf2/1 genOnOff.read(["onOff"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Timeout - 20246 - 1 - 180 - 6 - 1 after 10000ms))
[2025-03-15 17:42:15] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 17:59:15] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 18:38:16] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 18:49:14] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 19:26:14] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 19:43:14] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 20:22:14] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 20:32:14] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 21:09:14] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 21:26:13] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 21:37:14] error: 	z2m: Failed to read state of 'toilette' after reconnect (ZCL command 0x00124b0023592386/1 genLevelCtrl.read(["currentLevel"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Data request failed with error: 'MAC no ack' (233)))
[2025-03-15 21:45:53] error: 	z2m: Failed to read state of 'toilette' after reconnect (ZCL command 0x00124b0023592386/1 lightingColorCtrl.read(["colorMode","currentX","currentY","enhancedCurrentHue","currentSaturation","colorTemperature"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Data request failed with error: 'MAC no ack' (233)))
[2025-03-15 22:06:13] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 22:16:13] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 22:52:13] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 23:10:12] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 23:48:13] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()
[2025-03-15 23:59:12] error: 	zhc: Failed to apply calibration to 'temperature': 'temperature_precision' is not a number, got string ()

Mais j’ai du mal à me dire que ça viendrait vraiment de là? Et aucune indication sur le device d’où viendrait ce problème de calibration…)
En plus de ce symptome, j’ai un truc bizarre sur la page matériel où la clé semble apparaitre deux fois. Mais il n’y a qu’un seule clé de branchée.

De guerre lasse, ce soir, j’ai aussi essayé de flasher le dernier firmware sur la clé.
D’après Z2M, la version actuelle du firmware est : 20210708.
J’ai donc tenté de mettre
CC1352P2_CC2652P_launchpad_coordinator_20240710.hex
avec le flash programmer -2 de TI
mais ma clé ne passe pas en bootloader. J’ai beau tenter d’appuyer longtemps ou pas sir le bouton physique (après avoir ouvert la clé), rien n’y fait. Le flasheur reste failed.

J’ai aussi essayé avec la méthode de l’add-on zigstar (cf Home Assistant - Flasher la clé Sonoff Zigbee avec l'add-on Zigstar) , mais ça n’a pas marché non plus avec l’erreur :

 Add-on: ZigStar TI CC2652P/P7 FW Flasher
 ZigStar TI CC2652P/P7 firmware flasher add-on
-----------------------------------------------------------
 Add-on version: 0.4.1
 You are running the latest version of this add-on.
 System: Home Assistant OS 14.2  (amd64 / qemux86-64)
 Home Assistant Core: 2025.2.5
 Home Assistant Supervisor: 2025.03.3
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service banner successfully started
s6-rc: info: service cc2652-flasher: starting
[00:02:05] INFO: Starting CC2652P flasher with Sonoff /dev/ttyUSB2
Setting filename to /root/firmware.hex
sonoff
Opening port /dev/ttyUSB2, baud 500000
Reading data from /root/firmware.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
[00:02:07] INFO: cc2652-flasher-up script exited with code 1
s6-rc: warning: unable to start service cc2652-flasher: command exited 1
s6-rc: info: service banner: stopping
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.
s6-rc: info: service banner successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Est ce un signe qu’elle commence à être HS.
Si j’en achète une autre identique, est ce qu’il faudra que je refasse un apparaige???

Si vous avez des idées de solution pour résoudre ces pannes de Z2M ou de dongle…
Un grand merci d’avance…

Ma configuration


HA installé sur une machine proxmox, avec la clé bien déclarée (pas de changement depuis longtemps)

Dans Z2M, comme add-on de HA, ainsi que MQTT

serial:
  port: >-
    /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_d0dff4b8ce12ec11af5121c7bd930c07-if00-port0
  adapter: zstack

et ma configuration HA complète extraite:

System Information

version core-2025.2.5
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.13.1
os_name Linux
os_version 6.6.73-haos
arch x86_64
timezone Europe/Paris
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
HACS Data ok
GitHub API Calls Remaining 5000
Installed Version 2.0.5
Stage running
Available Repositories 1598
Downloaded Repositories 47
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 14.2
update_channel stable
supervisor_version supervisor-2025.03.3
agent_version 1.6.0
docker_version 27.2.0
disk_total 62.3 GB
disk_used 27.7 GB
healthy true
supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization kvm
board ova
supervisor_api ok
version_api ok
installed_addons Terminal & SSH (9.16.0), Samba share (12.5.0), File editor (5.8.0), Duck DNS (1.18.0), Log Viewer (0.17.1), Node-RED (19.0.2), MariaDB (2.7.2), Home Assistant Google Drive Backup (0.112.1), HassOS SSH port 22222 Configurator (0.9.3), Mosquitto broker (6.5.0), Zigbee2MQTT (2.1.3-1), Studio Code Server (5.18.3), Frigate Proxy (1.5), Gazpar 2 MQTT (0.8.9), MyElectricalData (0.13.2), Matter Server (7.0.0), OpenThread Border Router (2.13.0)
Dashboards
dashboards 5
resources 30
views 53
mode storage
Network Configuration
adapters lo (disabled), enp0s18 (enabled, default, auto), docker0 (disabled), hassio (disabled), vethe9826ad (disabled), vethcc563d0 (disabled), veth23a7436 (disabled), veth52c1833 (disabled), vethd55312d (disabled), veth715f378 (disabled), veth5287f21 (disabled), veth4e8bf84 (disabled), vethe038915 (disabled), vethefcf745 (disabled), vethf4dbc2d (disabled)
ipv4_addresses lo (127.0.0.1/8), enp0s18 (192.168.1.199/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), vethe9826ad (), vethcc563d0 (), veth23a7436 (), veth52c1833 (), vethd55312d (), veth715f378 (), veth5287f21 (), veth4e8bf84 (), vethe038915 (), vethefcf745 (), vethf4dbc2d ()
ipv6_addresses lo (::1/128), enp0s18 (2a01:e0a:838:ef40:a15:2220:c0e8:b934/64, fe80::16f0:2aa9:52e3:4686/64), docker0 (fe80::42:83ff:fe98:c8ae/64), hassio (fe80::42:2cff:feae:11ef/64), vethe9826ad (fe80::58bb:b5ff:fe15:2e8/64), vethcc563d0 (fe80::a027:c0ff:fe87:b4d2/64), veth23a7436 (fe80::c4dc:98ff:feb5:9789/64), veth52c1833 (fe80::f097:2ff:fe28:6eb6/64), vethd55312d (fe80::7812:2bff:fe08:3158/64), veth715f378 (fe80::f41c:b9ff:fefa:d6cc/64), veth5287f21 (fe80::c421:f2ff:feb7:e377/64), veth4e8bf84 (fe80::ac80:6ff:feb1:a60c/64), vethe038915 (fe80::b87f:a8ff:fe79:430a/64), vethefcf745 (fe80::2899:27ff:fe72:b0ef/64), vethf4dbc2d (fe80::40b:14ff:fe5c:b0a/64)
announce_addresses 192.168.1.199, 2a01:e0a:838:ef40:a15:2220:c0e8:b934, fe80::16f0:2aa9:52e3:4686
Recorder
oldest_recorder_run 2 mars 2025 à 15:24
current_recorder_run 16 mars 2025 à 23:01
estimated_db_size 2115.73 MiB
database_engine mysql
database_version 10.11.6
Xiaomi Miot Auto
component_version 1.0.12
can_reach_server ok
can_reach_spec ok
logged_accounts 1
total_devices 2

Bonjour à tous,

je devrais recevoir une nouvelle clé Sonoff ZBDongle-P aujourd’hui… Mais avant de faire la manip, est ce que vous partagez mon analyse?
Il y a un problème au niveau de mon dongle (fait qu’il ne passe pas en bootloader,… et autres symptomes) ?
Ca pourrait être du au firmware très ancine (2021) qui aurait un pb de comm° avec des device plus récents mis sur le réseau (rien de révolutionnaire pourtant…) ?

Merci de vos indications, avant queje ne me lance dans une migration de clé.

Bonjour,
avant de changer la clé, tu avais vu ce tuto ?

Zigbee2MQTT étais bien stoppé avant de faire le flash de la clé ?
Perso, j’utilise le firmware 20221226, je ne suis pas passé sur le dernier, ayant vu des soucis chez certain.

Tu as bien stoppé l’addon Zigstar, après le flash, pour relancer Zigbee2MQTT ?

Merci de ta réponse @WarC0zes

Oui, j’ai aussi essayé l’add-on, et j’avais stoppé les add-on MQTT et Z2M pour la manip. Mais là aussi, message d’erreur disant que la clé n’était apparemment pas passée en bootloader

Tu n’aurais pas un souci avec la configuration de l’USB Passtrough sur ta VM pour la clé ?

Je vais regarder et le refaire au cas où, car j’avais normalement déjà bien pris en compte le passthrough.
Je mettrai à jour ce message en fonction du résultat…

Je confirme que le firmware 20221226 est le plus stable pour sonof p. J’ai longuement testé les version plus récentes ce n est pas stable du tout.

Par expérience il faut le laisser sur la machine sans passer par un hub pour encore plus de stabilité et surtout pas sur port usb3

1 « J'aime »

Merci du retour, ca confirme que j’ai bien fait de ne pas y passer :wink:

Bonjour,

ce weekend, j’ai passé pas mal de temps à résoudre mes petits soucis, et je pense avoir pas mal couvert pas mal les causes possibles de plantage, sans être pour autant sûr de LA cause racine.

Déjà, lors d’une sauvegarde automatique journalière de mon noeud proxmox, ça a bien planté (au niveau du proxmox, en boucle de sauvegarde, impossible d’en sortir) et là, c’est tout le noeud et donc la VM dessus qui étaient on-hold. Impossible de réaccèder au serveur. Et même en redémarrant le mini-PC. Corruption de fond…

Aux grands maux les grands remèdes, j’ai donc réinstallé proxmox intégralement, puis restauré une sauvegarde de la veille, et ça a bien marché ! :sweat_smile:
Ca prend surtout du temps à reconnecter le mini-pc à un clavier, ecran etc. En tout, 1h-1h30

Tan qu’à y être, j’ai flashé la nouvelle clé Sonoff Zbdongle-P reçue 3 jours avant, avec le firmware 20221226. Là, le flash s’est passé nominalement.
J’ai ensuite fait une sauvegarde HA et Z2M, et fait la migration de l’ancienne vers la nouvelle clé (cf FAQ | Zigbee2MQTT).
En mettant la nouvelle clé (après avoir changé l’adresse serial dans la config Z2M (et sur le passthrough proxmox), tout s’est bien reconnecté.
Pas besoin de refaire l’appairage, nickel.

PS : j’ai retenté de flasher l’ancienne clé ZB, et là, bizarre, ca s’est bien passé. J’ai une clé ZB en 20221226 en rab…

Et voilà, tout est redémarré. Je vais attendre 1 à 2 semaines avant de crier victoire, mais déjà toute l’opération de RaZ et restauration était un exercice en soi (un peu stressant, car pendant tout ce temps là, les volets ne se sont pas ouverts, et le WAF en a pris un coup…)

1 « J'aime »

Pour info,
depuis les changements et opérations listées dans le post précédent, je n’ai plus eu d’autre souci de réseau Zigbee.
Donc, c’était soit l’ancienne clé qui a commencé à être défectueuse (et la nouvelle marche mieux), soit le passage au firmware 20221226 a permis d’être plus robuste à l’élément perturbateur du réseau (qui est peut-être toujours là).
J’ai gardé l’ancienne clé, flashée finalement aussi en 20221226, si un jour j’ai un autre réseau à monter. Je verrai à ce moment là.