Bonjour,
Mon problème
Bonjour, je fais suite a mon dernier sujet "l'enfer z wave JS". Malgré plusieurs mise a jour, et différentes façon de faire, mon z wave met toujours une plombe a se rétablir après un arrêt ou une mise a jour système.
Après ces deux événements, j'ai un timeout lors du chargement du dongle USB. Pour rétablir tout ça, je dois débrancher la clef au moins 2/3h, rebrancher et c'est ok. C'est juste super penible, et surtout, je ne comprend absolument pas ce qu'apporte cette pause pour que la boucle zwave fonctionne à nouveau.
Mon contrôleur USB est tout neuf, j'ai seulement 4 modules, dont 2 tout neufs, mais que de la marque (fibaro et zooz). J'ai beau débrancher les modules un a un ça ne change absolument rien a la procédure de redémarrage...
Si quelqu'un a une bonne piste qui n'a pas déjà été citée (alimentation du port par exemple), je serais vraiment reconnaissant 
Ma configuration
[center]## System Information
| version |
core-2026.7.1 |
| installation_type |
Home Assistant OS |
| dev |
false |
| hassio |
true |
| docker |
true |
| container_arch |
aarch64 |
| user |
root |
| virtualenv |
false |
| python_version |
3.14.6 |
| os_name |
Linux |
| os_version |
6.18.37-haos |
| arch |
aarch64 |
| timezone |
Europe/Paris |
| config_dir |
/config |
Home Assistant Cloud
| logged_in |
false |
| can_reach_cert_server |
ok |
| can_reach_cloud_auth |
ok |
| can_reach_cloud |
ok |
HACS
| GitHub API |
ok |
| GitHub Content |
ok |
| GitHub Web |
ok |
| HACS Data |
ok |
| GitHub API Calls Remaining |
4996 |
| Installed Version |
2.0.5 |
| Stage |
running |
| Available Repositories |
3461 |
| Downloaded Repositories |
7 |
Home Assistant Supervisor
| host_os |
Home Assistant OS 18.1 |
| update_channel |
stable |
| supervisor_version |
supervisor-2026.06.2 |
| agent_version |
1.9.0 |
| docker_version |
29.5.3 |
| disk_total |
28.0 GB |
| disk_used |
6.9 GB |
| nameservers |
8.8.8.8, 192.168.1.254, fd0f:ee:b0::1 |
| healthy |
true |
| supported |
true |
| host_connectivity |
true |
| supervisor_connectivity |
true |
| ntp_synchronized |
true |
| virtualization |
|
| board |
green |
| disk_life_time |
0 % |
| 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.1.0), EnOcean MQTT (3.1.0), Zigbee2MQTT (2.12.1-1), Z-Wave JS (1.5.0) |
Dashboards
| dashboards |
3 |
| resources |
2 |
| views |
4 |
| mode |
storage |
Network Configuration
| adapters |
lo (disabled), end0 (enabled, default, auto), docker0 (disabled), hassio (disabled), veth21794a9 (disabled), veth834dfe8 (disabled), vethc3b8597 (disabled), veth80aec1f (disabled), veth2e14362 (disabled), vetha01cb00 (disabled), vethbce9e81 (disabled), tailscale0 (disabled), veth6fc78cb (disabled), veth1db996f (disabled), veth2f082d0 (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), veth21794a9 (), veth834dfe8 (), vethc3b8597 (), veth80aec1f (), veth2e14362 (), vetha01cb00 (), vethbce9e81 (), tailscale0 (), veth6fc78cb (), veth1db996f (), veth2f082d0 () |
| ipv6_addresses |
lo (::1/128), end0 (2a01:e0a:2d3:8b70:9fe:efcd:b329:8a09/64, fe80::e1e2:9a63:7020:8a5f/64), docker0 (fd2c:95e0:b34b::1/64, fe80::180b:42ff:fe20:a35e/64), hassio (fd0c:ac1e:2100::1/48, fe80::c01e:b7ff:fe1d:51f0/64), veth21794a9 (fe80::7472:2dff:fe1d:a64/64), veth834dfe8 (fe80::4cc5:cff:fef9:5a01/64), vethc3b8597 (fe80::a07b:feff:fe3f:e903/64), veth80aec1f (fe80::5c5c:24ff:fe26:4af9/64), veth2e14362 (fe80::a8c0:46ff:fe4d:fdae/64), vetha01cb00 (fe80::7816:f8ff:fed5:49c1/64), vethbce9e81 (fe80::3c25:7dff:fe6d:df2b/64), tailscale0 (fe80::906d:b09d:fdaf:e97e/64), veth6fc78cb (fe80::e495:eff:fe0d:a721/64), veth1db996f (fe80::7062:b6ff:feec:213e/64), veth2f082d0 (fe80::1c21:2aff:fe0c:3312/64) |
| announce_addresses |
192.168.1.149, 2a01:e0a:2d3:8b70:9fe:efcd:b329:8a09, fe80::e1e2:9a63:7020:8a5f |
Recorder
| oldest_recorder_run |
4 juin 2026 à 08:56 |
| current_recorder_run |
6 juillet 2026 à 21:57 |
| estimated_db_size |
165.58 MiB |
| database_engine |
sqlite |
| database_version |
3.53.2 |
___
Tu écartes l'alimentation du port mais tu as essayé sur un hub usb autoalimenté ?
Tu peux faire une photo de ton installation pour voir comment elle est organisée ?
Tu as écarté la piste de la perturbation de fréquence ?
Voici mon installation .
J'ai testé avec une rallonge USB pour éviter les perturbations de fréquences, ça n'a rien changé.
J'ai en effet essayé avec un hub usb alimenté, idem.
Ce qui m'interroge, c'est pourquoi, en attendant systématiquement quelques heures ça fonctionne níquel, et ce de façon durable (jusqu'au prochain redémarrage).
La rallonge règle les perturbations venant de ta machine pas du reste. Tu as regardé comment évoluent les entitées que je t'avais montrés dans le précédent poste ?
Tu as une jeedom atlas pas loin qui contient une puce zwave, tu as aussi une clef enocean, un transformateur...
Tu as essayé sans l'adapteur, la clef zwave directement sur le port ?
En effet, je n'ai pas encore débranché ma jeedom, en tout cas ça fonctionnait niquel avec elle.
J'avais regardé ce dont tu m'avais parlé (de mémoire), et ça ne m'avait rien indiqué.
Je ne suis pas d'avoir essayé sans l'adaptateur. C'était pour pouvoir brancher le d'ongle car les ports USB sont trop proches et empêche le branchement de deux clefs.
Et donc, pour toi, le fait d'attendre 2 ou 3h, permettrait de résoudre les interférences ? 
Non mais cela permet d'oublier la table de routage qui doit se refaire à chaque fois. Donc ça communique à fond avec beaucoup de messages pendant un temps pour tout rétablir. Puis quand le réseau reprends son rythme ça part en live.
Il faudrait que tu actives toutes les entités de diagnostique de ta clef et que tu les partage. Idem si tu pouvais fournir un fichier de log plus grand que la dernière fois comprenant dans l'ideal le moment où ça tombe.
Les seuls logs que j'ai trouvé intéressants, c'était celui de zwave js, qui parlait de timeout lors de la connexion au contrôler zwave.
Pour la table de routage c'est intéressant ça ! J'ai peut être un module Switch fibaro qui déconne un peu, mais bon, je n'ai pas eu l'impression que ça changeait la chose de le débrancher. La table de routage qui se réinitialisé ça voudrait dire qu'il y a du bazard dans la communication avec ou entre les modules, c'est ça ?
Non c'est du au fait qu'il n'y a pas eu de communication depuis longtemps donc il refait la table.
Oui pardon, mais le fait que ça fonctionne mieux ça pourrait être du à ce reset. D'ailleurs, on ne peut pas forcer le reset de la table de routage ? Ça pourrait aider.
Tu as la possibilité de réparer l'ensemble du réseau et c'est probablement ce qui se fait au reboot. Ce qui se passe au reboot c'est que tu as des échanges assez intensifs et donc dans le lot, tu as des paquets qui se perdent, mais la majorité arrivent donc la conexion tient tant bien que mal. Après ce n'est qu'une hypothèse, sans suivis des entités de dignostique et plus de log compliqué d'en dire plus.
