ezsp ne fait pas usage de ces problèmes de réseau/route signalés par l’adaptateur (masqués). ember est, car ils peuvent être utiles. Consultez la section Aide ici pour plus de détails (ce sera bientôt dans la documentation z2m) sur la façon dont la journalisation ember peut vous aider à trouver des problèmes dans votre réseau.
Pour les erreurs réseau/route : quelques-unes d’entre elles sont normales, c’est juste le réseau qui vit sa vie. Vous pouvez également en obtenir plusieurs au démarrage de z2m ou lors d’une jonction (encore une fois, c’est juste le réseau qui se décide ). Cela peut cependant indiquer un problème lorsque vous commencez à en voir beaucoup pendant le fonctionnement normal, en particulier s’il s’agit du même appareil ou d’appareils situés dans la même zone (cela peut signifier qu’un routeur ne fait pas son travail correctement).
Juste pour être clair : les erreurs réseau/route ne sont pas nécessairement un « problème ». Elles se sont produites avec ezsp too, vous ne les avez simplement pas vues car ezsp ne les utilise pas. ember le fait car elles peuvent être utiles pour dépanner votre propre réseau. Comme je l’ai dit, cela peut indiquer un problème si vous en recevez beaucoup (cela ne signifie pas que votre réseau ne fonctionne pas, mais il est probable qu’un ou plusieurs de vos routeurs ne font pas leur travail correctement, ou qu’ils subissent peut-être des interférences sur la bande 2,4 GHz). C’était déjà seulement un warning , sera abaissé à info dans la prochaine version pour éviter la panique.
Pour savoir quel appareil est en cause, sur l’erreur, il y a un chiffre à la fin. Il faut le convertir en hexadécimal .
Pour ma part c’est résolu, j’ai refais une nouvelle installation donc avec la mise à jours de clé SONOFF à jour, contrairement à la fois précédente ou j’ai effectué l’upgrade.
Version de Zigbee2MQTT 1.41.0
Révision du coordinateur 7.4.4 [GA]
Justement c’est suite à la réinstallation complète de Z2M dans un LXC Proxmox + nouvel adaptateur Zigbee + réappairage de tous mes devices (une 100aine !), que j’ai maintenant cette « info/alerte »
zh:ember:ezsp: Received network/route error ROUTE_ERROR_ADDRESS_CONFLICT for "0".
Effectivement c’est juste une info mais c’est extrémement verbeux et « 0 » ne se traduit pas en apparence à un équipement particulier.
J’ai vu sur le forum anglophone que le seul moyen de s’en débarrasser suite à une migration comme mon cas c’est de repartir de 0 sur une install propre et de tout réappairer
Je crois que je vais faire avec, pas un problème si ce n’était que dans les logs mais à chaque fois que j’ouvre l’interface web je suis inondé de messages
Non je n’ai pas eu besoin de réappairer
Comme expliqué dans un autre post j’ai juste eu un souci avec coordinator_backup.json qui n’arrivait pas à se recréer mais j’ai réglé le problème
Vous devez réassocier tous vos appareils lorsque :
Modification de la clé réseau ( network_key ) ou panID ( pan_id ) dans configuration.yaml .
Changer le canal Zigbee ( channel ) dans le configuration.yaml peut nécessiter la réparation de certains appareils, lisez la documentation pour plus d’informations .
Passage de zStack 1.x à 3.x. (s’applique uniquement à CC2530 et CC2531)
Le changement d’adaptateur nécessite une réparation, sauf lorsque :
Lorsque les adaptateurs sont identiques, la réparation n’est pas nécessaire (par exemple CC2531 → CC2531)
Le passage d’un adaptateur basé sur CC2530 ou CC2531 à un adaptateur basé sur CC2538/CC2652/CC1352 ne nécessite pas de réparation (par exemple CC2531 → CC2652) (sauf lorsqu’il change la version zStack, voir ci-dessus).
La commutation entre les adaptateurs basés sur CC2538, CC2652 et CC1352 ne nécessite pas de réparation (par exemple CC2538 → CC2652)
Eh bien ça marche
J’ai eu juste deux boutons xiaomi et deux prises sur une cinquantaine d’équipements qui n’ont pas voulu remonter, tout le reste fonctionne,
Bonjour,
Bon j’admets que j’avais tort et qu’on doit toujours suivre les conseils documentés, pour ceux qui lisent ces post, essayer de migrer d’une sonoff P à une sonoff E sans réappairer est une mauvaise idée.
Même si je suis arrivé à recréer le fichier coordinator_backup.json avec une astuce, dans tous les cas c’est instable pour beaucoup d’équipements.
Au final je suis reparti d’une install propre et j’ai réappairé mes 52 équipements, ça m’a pris une partie de ma journée hier, heureusement mes équipements ont des identifications cohérentes et j’avais coché « Modifier l’ID de l’entité sous Home Assistant » dans zigbee2mqtt
Je n’ai rien perdu.
Maintenant j’espère que celui qui a dit plusieurs fois sur ce forum que la clé sonoff E était la plus performante et plus puissante avait raison car j’ai transféré la sonoff P sur mon instance zigbee2mqtt secondaire qui avait beaucoup moins d’équipements, ça m’aurait pris moins de temps d’y mettre la sonoff E