Bonjour,
Mon problème
Depuis quelques mois, j’ai des galères avec zwave JS. Tout a commencé avec une mise a jour qui m’a fait planté le démarrage de zwave js. En redémarrant un micromodule c’était bon.
Nouvelle mise à jour : impossible cette fois de faire démarrer avec de simples reset. J’ai changé mon dongle, j’ai pris une clef zooz gen5, tout allait pour le mieux, jusqu’à ce matin : coupure sauvage enedis. Au retour du secteur, z wave JS était à nouveau en rade. J’ai beau redémarrer les micromodules, ma box green, ou ma clef zooz USB, rien n’y fait, c’est sensible un peu le zwave non ?
Ma configuration
| version |
core-2026.4.3 |
| installation_type |
Home Assistant OS |
| dev |
false |
| hassio |
true |
| docker |
true |
| container_arch |
aarch64 |
| user |
root |
| virtualenv |
false |
| python_version |
3.14.2 |
| os_name |
Linux |
| os_version |
6.12.77-haos |
| arch |
aarch64 |
| 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 |
2947 |
| Downloaded Repositories |
7 |
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 17.2 |
| update_channel |
stable |
| supervisor_version |
supervisor-2026.04.2 |
| agent_version |
1.8.1 |
| docker_version |
29.3.1 |
| disk_total |
28.0 GB |
| disk_used |
6.9 GB |
| nameservers |
8.8.8.8, fd0f:ee:b0::1, 192.168.1.254 |
| healthy |
true |
| supported |
true |
| host_connectivity |
true |
| supervisor_connectivity |
true |
| ntp_synchronized |
true |
| virtualization |
|
| board |
green |
| supervisor_api |
ok |
| version_api |
ok |
| installed_addons |
Get HACS (1.3.1), File editor (6.0.0), Tailscale (0.28.1), Mosquitto broker (7.0.1), EnOcean MQTT (3.0.0), Zigbee2MQTT (2.9.2-1), Z-Wave JS (1.3.0) |
Dashboards
| dashboards |
3 |
| resources |
2 |
| views |
4 |
| mode |
storage |
Network Configuration
| adapters |
lo (disabled), end0 (enabled, default, auto), docker0 (disabled), hassio (disabled), tailscale0 (disabled), veth30868fc (disabled), veth2ef29b0 (disabled), vetha200066 (disabled), veth445604c (disabled), veth54a21ef (disabled), veth04e6c16 (disabled), veth2be4e5d (disabled), vethee0c2c4 (disabled), veth17d2c84 (disabled), veth2e72606 (disabled), veth9ef4daa (disabled) |
| ipv4_addresses |
lo (127.0.0.1/8), end0 (192.168.1.149/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), tailscale0 (100.123.32.23/32), veth30868fc (), veth2ef29b0 (), vetha200066 (), veth445604c (), veth54a21ef (), veth04e6c16 (), veth2be4e5d (), vethee0c2c4 (), veth17d2c84 (), veth2e72606 (), veth9ef4daa () |
| ipv6_addresses |
lo (::1/128), end0 (2a01:e0a:2d3:8b70:9fe:efcd:b329:8a09/64, fe80::e1e2:9a63:7020:8a5f/64), docker0 (fe80::d056:bcff:fe39:4e6/64), hassio (fd0c:ac1e:2100::1/48, fe80::60a4:ffff:fed3:5234/64), tailscale0 (fd7a:115c:a1e0::8101:208a/128, fe80::de47:68ad:d05e:a610/64), veth30868fc (fe80::6475:34ff:fe7c:a765/64), veth2ef29b0 (fe80::e450:3aff:fe93:52b9/64), vetha200066 (fe80::b478:e3ff:fe5d:f6a5/64), veth445604c (fe80::28e4:6bff:fe33:c7b1/64), veth54a21ef (fe80::8436:26ff:fe9f:eafd/64), veth04e6c16 (fe80::5cd1:fff:fef4:319e/64), veth2be4e5d (fe80::420:26ff:feaf:fc41/64), vethee0c2c4 (fe80::41b:9bff:fed4:eb79/64), veth17d2c84 (fe80::58dc:c8ff:fea4:a386/64), veth2e72606 (fe80::e43e:7dff:fe7f:e113/64), veth9ef4daa (fe80::4810:51ff:fe96:3a0a/64) |
| announce_addresses |
192.168.1.149, 2a01:e0a:2d3:8b70:9fe:efcd:b329:8a09, fe80::e1e2:9a63:7020:8a5f |
Recorder
| oldest_recorder_run |
22 avril 2026 à 17:38 |
| current_recorder_run |
4 mai 2026 à 14:44 |
| estimated_db_size |
147.70 MiB |
| database_engine |
sqlite |
| database_version |
3.49.2 |
___
J’utilise aussi zwavejs depuis toujours sans aucun de ce genre de problème
Poste aussi les logs de l’addon pour tenter de comprendre ce qui bloque
Incroyable d’être le seul a voir ce problème.
Voici les logs de démarrage :
2026-05-04 15:23:10.166 CNTRLR Serial API did not respond, trying again in 10 seconds…
2026-05-04 15:23:30.176 CNTRLR Serial API did not respond, trying again in 15 seconds…
2026-05-04 15:23:55.186 CNTRLR Serial API did not respond, giving up
2026-05-04 15:23:55.192 CNTRLR Starting the hardware watchdog failed: driver instance destroyed (ZW0102)
Tu as quoi comme clef (la zooz gen 5 n’existe pas) ?
Il faut des logs plus complet et le firmware de ta clef.
As tu essayé de débrancher et rebrancher ta clef a chaud ?
Quoi qu’il en soit un onduleur sur ton installation ferrais pas de mal et permettrait d’éteindre et relancer le tout proprement
Je me demande si tu n’as pas un soucis d’usb
Qu’utilises tu comme hôte pour HA ?
C’est une box green. Mon contrôleur enocean fonctionne sans soucis sur l’autre port USB, j’ai même essayé de swapper, rien a faire.
Tu stabilise ton installation avec c’est préférable. Pour le firmware c’est ok c’est le dernier.
Tu es ok sur la sélection des ports ? Tu as essayé de brancher, débrancher la clef ? Tu as plus de logs ?
Oui j’ai :
- débranché rebranché a chaud
- eteind la box, débranché la clef, allumé la box et rebranché la clef.
Je ne sais pas trop où aller chercher d’autres logs, j’ai ça, tjs au démarrage (en boucle :
Citation
Z-Wave JS
· SmartStart
2026-05-04 15:53:07.898 CNTRLR Querying supported RF regions and their information…
2026-05-04 15:53:08.089 CNTRLR supported regions:
· Europe
· USA
· Australia/New Zealand
· Hong Kong
· India
· Israel
· Russia
· China
· USA (Long Range) · superset of USA · ZWLR
· Europe (Long Range) · superset of Europe · ZWLR
· Japan
· Korea
2026-05-04 15:53:08.091 CNTRLR Querying configured RF region…
2026-05-04 15:53:08.111 CNTRLR The controller is using RF region Europe (Long Range)
2026-05-04 15:53:08.112 CNTRLR Querying configured powerlevel…
2026-05-04 15:53:08.131 CNTRLR The powerlevel is 9 dBm (0 dBm calibration)
2026-05-04 15:53:08.133 CNTRLR Querying configured max. Long Range powerlevel…
2026-05-04 15:53:08.152 CNTRLR The max. LR powerlevel is 14.0 dBm
2026-05-04 15:53:08.155 CNTRLR Querying configured Long Range channel information…
2026-05-04 15:53:08.172 CNTRLR received Z-Wave Long Range channel information:
channel: A
supports auto channel selection: true
2026-05-04 15:53:08.175 CNTRLR Performing soft reset…
2026-05-04 15:53:08.190 CNTRLR Waiting for the controller to reconnect…
2026-05-04 15:53:08.297 CNTRLR reconnected and restarted
2026-05-04 15:53:08.300 CNTRLR Starting hardware watchdog…
2026-05-04 15:53:08.305 CNTRLR Switching serial API to 16-bit node IDs…
2026-05-04 15:53:08.312 CNTRLR querying Z-Wave Long Range capabilities…
2026-05-04 15:53:08.338 CNTRLR Switching to 16-bit node IDs successful
2026-05-04 15:53:08.383 CNTRLR received Z-Wave Long Range capabilities:
max. payload size: 148 bytes
nodes:
2026-05-04 15:53:08.385 CNTRLR Switching serial API to 16-bit node IDs…
2026-05-04 15:53:08.399 CNTRLR Switching to 16-bit node IDs successful
2026-05-04 15:53:08.402 CNTRLR querying controller IDs…
2026-05-04 15:53:08.421 CNTRLR received controller IDs:
home ID: 0xc9817e93
own node ID: 1
2026-05-04 15:53:08.424 CNTRLR Enabling TX status report…
2026-05-04 15:53:08.444 CNTRLR Enabling TX status report successful…
2026-05-04 15:53:08.445 CNTRLR finding SUC…
2026-05-04 15:53:08.462 CNTRLR This is the SUC
2026-05-04 15:53:08.897 CNTRLR [Node 006] Embedded device config loaded
2026-05-04 15:53:09.075 CNTRLR [Node 007] Embedded device config loaded
2026-05-04 15:53:09.164 CNTRLR [Node 008] Embedded device config loaded
2026-05-04 15:53:09.210 CNTRLR [Node 009] Embedded device config loaded
2026-05-04 15:53:09.257 CNTRLR [Node 001] Embedded device config loaded
2026-05-04 15:53:09.260 CNTRLR Interview completed
2026-05-04 15:53:09.454 CNTRLR [Node 001] The node is alive.
2026-05-04 15:53:09.468 CNTRLR [Node 001] The node is ready to be used
2026-05-04 15:53:09.632 CNTRLR Interviewing nodes and/or determining their status: 7, 9, 8, 6
2026-05-04 15:53:09.635 CNTRLR » [Node 007] pinging the node…
2026-05-04 15:53:09.658 CNTRLR » [Node 009] pinging the node…
2026-05-04 15:53:09.667 CNTRLR » [Node 008] pinging the node…
2026-05-04 15:53:09.675 CNTRLR [Node 006] The node is asleep.
2026-05-04 15:53:09.690 CNTRLR [Node 006] The node is ready to be used
2026-05-04 15:53:09.826 CNTRLR Retrieving priority route to node 6…
2026-05-04 15:53:10.542 CNTRLR [Node 007] The node did not respond after 1 attempts, it is presumed dead
2026-05-04 15:53:10.547 CNTRLR [Node 007] The node is dead.
2026-05-04 15:53:10.564 CNTRLR [Node 007] ping failed: The node did not acknowledge the command (ZW0204)
2026-05-04 15:53:10.755 CNTRLR [Node 009] The node did not respond after 1 attempts, it is presumed dead
2026-05-04 15:53:10.757 CNTRLR [Node 009] The node is dead.
2026-05-04 15:53:10.765 CNTRLR [Node 009] ping failed: The node did not acknowledge the command (ZW0204)
2026-05-04 15:53:11.843 CNTRLR [Node 008] The node did not respond after 1 attempts, it is presumed dead
2026-05-04 15:53:11.845 CNTRLR [Node 008] The node is dead.
2026-05-04 15:53:11.847 CNTRLR All nodes are ready to be used
2026-05-04 15:53:11.907 CNTRLR [Node 008] ping failed: The node did not acknowledge the command (ZW0204)
s6-rc: info: service legacy-services: stopping
[13:53:27] INFO: Service restart after closing
s6-rc: info: service legacy-services 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: warning: service s6rc-oneshot-runner is marked as essential, not stopping it
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/config.sh
[15:57:17] INFO: No ‹ network_key › detected, setting it to ‹ s0_legacy_key › for backwards compatibility
[15:57:18] INFO: Flushing config to disk due to creation or migration of network key(s)…
[15:57:19] INFO: RF region set to Automatic: Europe
[15:57:19] INFO: Setting RF region to (Europe)
[15:57:19] INFO: Soft-reset set to automatic
[15:57:19] INFO: Virtual Machine not detected, enabling soft-reset
cont-init: info: /etc/cont-init.d/config.sh exited 0
cont-init: info: running /etc/cont-init.d/structure.sh
cont-init: info: /etc/cont-init.d/structure.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun zwave_js (no readiness notification)
s6-rc: info: service legacy-services successfully started
[15:57:20] INFO: Using device: /dev/serial/by-id/usb-Zooz_800_Z-Wave_Stick_533D004242-if00
[15:57:20] INFO: Successfully send discovery information to Home Assistant.
2026-05-04 15:57:30.387 INFO APP: Version: 11.16.2
2026-05-04 15:57:30.405 INFO APP: Application path:/usr/local/lib/node_modules/zwave-js-ui
2026-05-04 15:57:30.407 INFO APP: Store path:/config
C’est parce que ta clé enocéan que ça doit fonctionner suffit que la clé zooz soit en limite de consommation et qu’en pic ça puisse la faire planter
Mais ce n’est qu’une supposition
1 « J'aime »
Tu as bien une rallonge entre la machine et la clef ?
Tu peux faire une capture de la carte de ton réseau si tu l’a ? Ta clef est bien reconnue et fonctionne apparement mais c’est la liaison avec tes modules qui est pas bonne.
Tu peux activer les entités signal noise dans l’appareil représentant ta clef dans l’intégration zwave et donner leurs valeurs :
Ba la clef est indisponible une fois sur deux… Difficile donc de faire remonter ses infos. Pas de rallonge, mais j’ai essayé avec une rallonge de 1m, c’est tout pareil.
En effet, Gemini me dit la même chose, mais je suis surpris qu’un tel problème existe avec une box clef en main…
De plus, mon d’ongle a fonctionné níquel pendant plusieurs semaines, jusqu’à la coupure de ce matin…
Essayes avec un hub USB alimenté
Mais si ton dongle est indisponible effectivement ça peut ressemblet a un problème d’alimentation
C’est sur que ça ressemble à ça… Il ne me reste plus qu’à trouver un hub usb pour tester 
1 « J'aime »
Bon, j’ai debranché le d’ongle pendant 2h, puis je l’ai reconnecté, et tout s’est remis à fonctionner instantanément 
, vraiment étrange.
La coupure a soit mis la clef en vrac et la débranchée rebranchee l’a remise d’aplomb, soit tu as perdu le bon port et branché/rebranché lui a fait retrouver ce que tu avais dans les paramètres.
Surveille les entités que je t’ai donnée plus haut ça peut aussi être un indice de perturbations.
1 « J'aime »
Je vais surveiller ça, merci.
Par contre le débranchement débranchement, je l’ai fais plusieurs fois sans succès… Il fallait peut être laisser l’apps zwave démarrer tranquillement sans d’ongle.
Merci en tout cas pour le coup de main.
Bon, aujourd’hui, j’ai du couper le secteur pour une intervention, j’ai donc eteind proprement ma box HA, et quand j’ai remis le jus, je l’ai laissé redémarrer tranquillement… Et reprobleme de time out sur le port zwave.
J’ai donc essayé de laisser le d’ongle hors ligne quelques heures et en rebranchant, toujours rien.
Je n’en peut plus là, quels logs pourraient aider à y voir plus clair ? Est ce que je dois creuser le Switch USB alimenté alors que ça fonctionne tant que je ne redémarre pas la box… ?
Depis.
Au redémarrage le réseau de reconstruit donc pas impossible qu’à ce moment le dongle ait besoin de plus d’énergie et que lorsqu’il ronronne ça lui suffit largement
