Passage de Deconz vers JeeZigbee

Bonjour,
Je crée ce sujet juste pour vous donner un petit RETEX sur la mise à jour de mon installation du réseau Zigbee en partant de Deconz remplacé par jeeZigbee.

Ma configuration initiale :
HW :

  • Un Raspberry PI4B 4Go dédié,
  • Une clé Conbee2,
  • Une clé USB de 16 Go (en lieu et place des fragiles cartes µSD)
  • Une passerelle Ikéa
  • Des capteurs de T°, vibration, ouverture d’ouvrants, relais secteur, et de présence de marque AQARA, ainsi que des luminaires TRADFRI d’IKEA avec leurs télécommandes, et quelques détecteurs de présence et relais secteur SONOFF, soit à peu près une soixantaine d’équipements au total.

SW :

  • Jeedom en v4.3.17,
  • Plugins Deconz et Ikea (entre autres),
  • et tout ça tourne avec Raspian GNU/Linux 10 (Buster) 64 bits.

Suite à un achat d’un moteur de rideaux (le modèle ZBCurtain de SONOFF), il s’est avéré que le plugin Deconz qui tournait jusque là sans (trop) de soucis avec une clé Conbee2 et le plugin Ikea (pour assurer la liaison avec la passerelle Ikea qui gérait les luminaires), n’était malheureusement pas capable de le prendre en charge dans l’immédiat (sauf à faire une demande qui prend…le temps que ça prend).

J’ai donc un peu cherché et je suis tombé sur la doc des plugins JeeZigbee et MQTT Manager, qui me semblaient très prometteurs :

  • La reconnaissance de plus de 3000 équipements Zigbee via MQTT, y compris l’ensemble des modules AQARA, IKEA et SONOFF dont je suis principalement équipé,
  • Une représentation graphique du routage Zigbee (fonction absente avec Deconz lorsque l’on tourne sur un RPi sans interface graphique),
  • la possibilité de mettre à jour via OTA le firmware de certains modules (IKEA principalement),
  • les fonctions de binding (association d’une télécommande à un équipement directement sans passer par Jeedom)
  • et visiblement une bonne fiabilité et une bonne robustesse, avec de très bons retours en général.

J’ai donc décidé de sauter le pas, sachant bien sûr qu’il me faudrait obligatoirement passer par l’étape de tout ré-inclure.

Je me suis donc procuré tout d’abord une autre clé contrôleur, la ZBDongle-P de SONOFF, le but étant de faire cohabiter de façon provisoire les deux systèmes Deconz+Conbee2 et JeeZigbee+ZBDongle-P, le temps d’effectuer la bascule des équipements de Deconz vers JeeZigbee.

  1. Première étape, la mise à jour du firmware de la clé ZBDongle-P.
    Livrée avec le firmware en v20210708, j’ai voulu installer la dernière version à jour v20230507 qui, outre le fait que ce firmware est quand même plus récent, permet également de booster par défaut les émissions à +20dbm, ce qui permet de gagner quelques points sur la portée et la fiabilité du réseau Zigbee.
    La procédure, bien expliquée sur le site zigbee2mqtt, n’est pas très compliquée en soi : il suffit de flasher (sous Windows) la clé soit avec le programme Flash Programmer 2 de Texas Instrument, soit en passant par un script python. Perso je n’y suis finalement pas arrivé avec le logiciel de TI qui remontant systématiquement une ‹ error 3 › à chaque tentative. Je l’ai donc finalement flashée en appliquant la procédure du script python, qui elle a très bien fonctionné.

  2. L’installation des plugins JeeZigbee et MQTT Manager
    Conformément à la doc fournie, j’ai procédé à l’installation préalable du plugin MQTT Manager, en activant (en local) le broker Mosquito. Pas de soucis majeurs à noter à ce point. Puis j’ai acheté, installé et configuré le plugin JeeZigbee. Là par contre j’ai eu un petit souci en constatant que si le démon se lançait bien, il s’arrêtait néanmoins systématiquement après quelques secondes en signalant dans les logs que le port utilisé pour communiquer avec la clé n’était pas le bon (ah ? et pourtant…). Rien à faire, j’ai eu beau essayer de modifier le port USB sur lequel était branché la clé, le démon ne démarrait pas.
    Bon, après avoir tout désinstallé et tout réinstallé proprement et dans l’ordre, ça a fini par fonctionner.

Me voici donc avec deux gestionnaires de réseaux Zigbee, prêt à commencer les transferts en douceur.
Je précise que ce travail de transfert, bien qu’un peu pénible en soi (il faut physiquement ré-appairer tous les modules, où qu’ils soient…), a été largement facilité en ce qui me concerne par l’emploi des virtuels.
En effet, j’ai pris l’habitude de faire en sorte que chaque équipement physique (ou pas d’ailleurs…), tels que les luminaires, boutons, actionneurs, capteurs,… soient interfacés à Jeedom uniquement via un virtuel dédié.
Ainsi, en cas de suppression ou ré-inclusion, cela me permet d’éviter d’avoir à retoucher aux multiples scénarios, designs, etc… qui eux ne s’interface qu’avec le virtuel en rapport avec l’équipement en question. Il suffit donc juste de recréer les commandes de cet équipement dans le virtuel associé, et c’est tout ! C’est une fonction très puissante et réellement utile si bien utilisée.

Bon, cela m’a quand même pris deux jours pour transférer l’ensemble de mes équipements, et en prenant bien soin avant tout de sélectionner pour le nouveau réseau un canal zigbee permettant d’éviter toute interférence ou recouvrement possible avec les canaux utilisés par les réseaux Wifi 2,4Ghz détectés dans le voisinage (et donc éviter des potentiels brouillages mutuels).
A l’issue de la ré-inclusion de mes équipements, qui ont tous été détectés sans aucun problème par le plugin et Zigbee2MQTT (contrairement à Deconz d’ailleurs qui me remontait quelques bizarreries sur certains modules), j’ai pu supprimer définitivement le plugin Deconz et débranché la clé Conbee2 (ainsi que la passerelle Ikéa au passage qui ne me servait plus à rien).

Grâce au travail formidable effectué par toute l’équipe sur ce plugin, je trouve des informations complémentaires pertinentes (l’heure de la dernière communication, ou l’état de batterie faible par exemple), qui n’étaient pas présentées avec Deconz, ou ne serait-ce que les visuels des équipements qui sont parfaitement attribués. Je verrai avec le temps pour la stabilité et la fiabilité globale, mais jusqu’à présent rien à dire, tout fonctionne parfaitement et les informations remontent régulièrement et sans problème.
Et finalement j’ai enfin intégré correctement mon nouveau module ZBCurtain, à l’origine de tout ça, mais qui m’aura permis de moderniser l’ensemble du réseau pour un bon moment…

Si ce RETEX peut servir à quelques-uns qui hésiteraient encore, tant mieux !

3 « J'aime »

merci pour ce retour!
Pour ceux qui aurait le même soucis de flashage de la clé et allergique aux script, la solution est ici

Dams

Bonjour Dams,
Merci également pour cette solution permettant de flasher la clé via Flash Programmer 2 !
Je ne l’avais pas vue, et je constate qu’il me suffisait plus que de convertir le firmware du format .hex en .bin pour y parvenir.
Bon, le script Python marche très bien aussi, heureusement qu’il existe plusieurs solutions… :grin:

2 « J'aime »

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