Dé-inclusion spontanée de luminaires/télécommandes/prise connectée/détecteur mvt Ikéa Trädfri

Bonjour,

J’ai constaté un phénomène plutôt bizarre aujourd’hui avec des ampoules/télécommandes/détecteur de mouvement/prises Ikéa, que je ne m’explique pas. :thinking:

Pour contextualiser, je travaille en ce moment à dockeriser un container Jeedom en v4.3.23 / Debian 11 sur un RPi5 (en Debian 12 donc…), l’idée étant de permuter à court terme mon RPi4B actuel par ce RPi5 en attendant une v4.4 stable.
Tout fonctionne parfaitement (installation, paramétrages, restauration des sauvegardes, etc…) et j’en suis arrivé à la phase où j’ai souhaité effectuer un ultime test en ‹ vrai ›.
L’idée est donc :

  • d’injecter sur le RPi5 une sauvegarde du système actuel,
  • de désactiver sur cette sauvegarde les plugins JeeZigbee et MQTT Manager (utilisés dans mon réseau réel avec une clé ZBDongle+P) + quelques autres pour être sûr qu’il n’y ait pas d’interférences,
  • d’installer et activer Deconz,
  • Et enfin au final de plugger une clé Conbee2, déjà utilisée auparavant sur mon ancien réseau principal, afin de créer un petit réseau Zigbee secondaire de test avec quelques modules en rab, mais qui sera complétement indépendant de mon réseau principal.

Les trois premières étapes sont OK. Je branche donc ma clé Conbee2 sur le RPi5 et démarre le container, Jeedom démarre…

Et là, c’est le drame…

En effet, au moment même où Jeedom se lancait sur mon rpi5, TOUT mes luminaires se sont déconnectés et allumés en même temps de mon réseau principal dans la maison, comme un seul homme, ainsi que TOUT les autres modules Trädfri, ! :skull_and_crossbones: :skull_and_crossbones: :skull_and_crossbones:
Je n’ai même pas lancé une inclusion ou fait quoique ce soit d’autre, c’est à priori juste lié au démarrage du démon Deconz.

Évidemment, plus aucun de ces modules ne répondaient aux commandes lancées à partir de mon réseau principal, ni plus aucune télécommandes associées avec certains des luminaires.

Au résultat, j’ai coupé court à l’expérimentation en stoppant le container et passé un bon bout de temps à récupérer cette situation…

Bon, maintenant je me pose la question : why ?

Je ne pense pas que mon process de test soit en cause : il est en effet tout à fait possible de faire cohabiter deux réseaux Zigbee ensemble, ce que j’ai d’ailleurs déjà expérimenté l’été dernier lorsque je suis passé de Deconz à JeeZigbee.
Et je confirme bien que seuls mes modules de la gamme Trädfri d’Ikéa (lumières, prises connectées, détecteur de présence, télécommandes) ont été concernés par cette dé-inclusion spontanée (comment l’appeler autrement ?). Tous les autres modules (Aqara, Sonoff, Legrand,…) n’ont pas bronché et sont restés fidèles.
Alors quoi ? Ces modules Trädfri auraient-ils gardé quelque part en mémoire leur ancienne clé maîtresse et l’ont ralliée dès sa réapparition sur les ondes ?
Le plugin Deconz, malgré une désinstallation en règle il y a quelques mois de mon système, aurait laissé des fichiers de configuration dans les sauvegardes (mais je n’ai rien vu dans le répertoire des plugins…) ? Quelqu’un aurait-il déjà constaté un tel phénomène, voire aurait une explication rationnelle ?
A votre avis ?
Merci d’avance…

Quelques infos :

Sur le RPi5

Le plugin Deconz (sans la clé Conbee 2, démon stoppé, installation visiblement OK) :

La page santé

[Edit du 02/03/24]
Bon, après quelques heures d’analyses un peu plus poussées, il s’avère que non seulement les modules Trädfri se sont tous déconnectés comme mentionné ci-dessus, mais également quelques autres modules d’autres marques (environ 30% de mes modules) : des capteurs de T°, vibrations, et mouvements de la gamme Aqara, et des capteurs de mouvement SONOFF.
Si pour certains modules leur déconnexion du réseau principal peut s’expliquer par le fait qu’ils étaient liés à certains routeurs Trädfri qui ont subitement cessé d’exister sur ce réseau, pour d’autres c’est plus énigmatique car ils étaient en portée directe de la clé contrôleur du réseau principal qui elle n’a jamais cessée de fonctionner normalement.
Et donc ils n’avaient vraiment aucune raison de se déconnecter de par leur propre chef…
L’activation de cette seconde clé contrôleur Conbee2 a vraiment mis une belle pagaille dans mon réseau principal… :thinking:

Bonjour alors j’ai rien compris a ta procédure anarchique mais pour information sur deconz, les information réseau sont sur la clé, et les informations appareil sur l’hôte. Donc ça suit la clé.

Bonjour,

C’est sûr ça ?
J’ai toujours compris que la clé ne conservait justement quasiment aucune information sur le réseau utilisé, ce qui lui permet justement d’être complétement interchangeable… Voir par exemple ce fil de discussion (c’est n’est pas le seul…) : Passage de Deconz à Zigbee via une VM - #2 par Yves19

Désolé, je vais résumer pour être plus clair :

  • Je veux tester une installation de Jeedom en version stable (v4.3.x) sur RPi5. Mais comme les RPi5 ne fonctionnent qu’avec Debian 12, qui à ce jour ne fonctionne bien qu’avec Jeedom en v4.4.x Alpha, je dockerise donc mon Jeedom v4.3.23/Debian 11 sur le RPi5.
    Et ça, ça marche bien (l’installation, la mise en route, restauration des sauvegardes, etc…). :slightly_smiling_face:

  • Là où ça s’est gâté, c’est que lorsque j’ai souhaité faire un ultime test ‹ grandeur nature › en pluggant une ancienne clé Conbee2 que j’ai dispo (pour éviter de stopper mon réseau ops en récupérant ma clé sonoff qui le gère), ca m’a foutu en l’air 40% de mon réseau Zigbee actuel juste en activant le démon Deconz au démarrage (à priori…). Ce à quoi je ne m’attendais pas vraiment puisque pour moi, la clé Conbee2 ne contient rien et n’a donc aucune mémoire du/des réseaux et des équipements avec lesquels il était installé. Quant au plugin Deconz que j’ai réinstallé (et pas seulement désactivé puis réactivé), il n’est pas sensé utiliser des vieilles configs avec ses équipements, planquées je ne sais où, sauf erreur de ma part…Et dans ce cas, où se trouverait ces fichiers, puisque le répertoire Deconz (dans le répertoire Plugin) n’existait pas avant sa réinstallation ?

Donc voilà, je trouve ce comportement un peu bizarre et pas du tout conforme à la théorie… :thinking:

Zwave c’est sur la clef, Zigbee ce n’est pas le cas

Oui, tout à fait d’accord :+1:… Je parle bien de Zigbee, je n’ai aucun équipement en Zwave.

Sur a 100%, les information réseau, clé, MAC adresse et ect sont stocké sur la clé.
Et Yves dit la même chose.

Oui la clef Conbee2 ne contient que peu d’information sur la topologie du réseau sinon l’ID réseau lui m^me et les clefs de cryptage.

Les informations sur les appareils sont sur la machine, ce qui fait que rien n’est reconnu, mais les infos pour permettre aux appareils de rejoindre le réseau sont la.

Je ne pense pas que mon process de test soit en cause : il est en effet tout à fait possible de faire cohabiter deux réseaux Zigbee ensemble, ce que j’ai d’ailleurs déjà expérimenté l’été dernier lorsque je suis passé de Deconz à JeeZigbee.

On ne fait jamais ça, c’est contre productif, et il faut mettre en place des barrières. Tu as configuré toi même les MAC adress des coordinateurs ?

Le fichier de configuration deconz s’apelle zll.db de mémoire et se trouve dans

/usr/share/deCONZ

sur une installation classique.

puisque le répertoire Deconz (dans le répertoire Plugin)

Ce n’est pas la qu’il faut aller voir, on parle de deconz l’application, pas du plugin deconz, rien a voir avec un dossier Jeedom.

En passant les dockers sont quelque chose de TRES complexes, n’écoutes pas celui qui dit que c’est facile qu’il y a juste a installer une image, et demandes lui plutôt comment modifier un fichier texte intégré au docker, il va vite disparaitre.

Bonjour,

Merci pour cette réponse complète, qui m’apporte en effet quelques éléments que je n’avais pas perçu.

Ok, je n’avais sans doute pas tout compris, mais je prends en compte. Dans ce cas, je comprend que pour avoir une clé totalement vierge et éviter ce qu’il m’est arrivé, il faut au préalable effectuer une procédure de RAZ via Phoscon j’imagine… Je vais regarder de mon côté comment appliquer cette procédure.

Oui, je suis d’accord. Mais dans le contexte, ce second réseau n’a pas d’autre objectif que de tester si tout est bien configuré côté container du RPi5, et cela ne devait servir que très ponctuellement. J’avais en effet un doute sur la bonne configuration des ports USB du container (bon, là du coup je n’en ai plus, ca marche bien… :grin:)
Je n’ai pas touché aux @ MAC qui sont donc restés les mêmes (sans doute un élément d’explication supplémentaire).

Oui, vu merci. J’ai en effet ce répertoire sur mon système de base et opérationnel (RPi4B) à partir duquel j’ai rapatrié mes sauvegardes Jeedom vers le container sur RPi5.
Mais je n’ai trouvé aucun fichier nommé zll.db (y compris dans les s/répertoires), c’est peut-être dans un autre fichier.
Du coup, je comprend que les sauvegardes Jeedom intègrent également tout ou partie de certains des fichiers contenus dans ce répertoire ?

Oui, je comprend bien, on parle donc ici de l’application Phoscon, indépendant de Jeedom. Comme je suis parti d’une nouvelle installation sur le RPi5 et que je ne lui ai injecté qu’une sauvegarde Jeedom, je suis parti du principe que seul le dossier créé dans Jeedom (« /html/plugins/ », lors de l’installation du plugin) aurait été injecté. D’où ma question plus haut…

Ca c’est pas faux en effet, je m’en suis bien rendu compte…
J’essaie d’apprendre justement comment ça fonctionne parce que ça me semble prometteur pour d’autres projets, ainsi qu’en termes de maintenance.
L’objectif pour l’instant est de simplement faire tourner de façon satisfaisante un Jeedom 4.3.x sur support Debian 11, sur un Rpi5 prévu de ne fonctionner qu’avec un Debian 12, mais sans faire d’autres manips ultérieures que des mises à jours ou installations de plugins au sein de Jeedom.
Et je n’en suis pas très loin je pense…

Merci en tout cas ! :+1:

Bonne question.
Ça doit dépendre du type de sauvegarde, backup image (très utilisé avec les dockers) ou backup donnée , il y a moyen de faire un backup du réseau deconz seul en passant par Phoscon, ou en utilisant l’API mais je sais pas si le plugin jeedom y arrive, il y a plein d’issues la dessus.

Il y a plein d’issues avec des personnes qui re-installent jeedom et ou deconz ne marche plus, la franchement j’ai pas testé, je ne sais pas ce que fait jeedom.

Ok, merci.
Je continuerai de mon côté, mais avec plus de précautions cette fois, histoire de ne pas réitérer cette expérience… 48h après, j’en suis encore à devoir ré-inclure méthodiquement quelques modules récalcitrants (non critiques heureusement) qui, sans jamais avoir posés de soucis jusque là, se mettent depuis à ne plus répondre quelques temps après leur énième ré-inclusion…
:slightly_smiling_face: