Soucis sur mon réseau z-wave

Tags: #<Tag:0x00007f38555f7438>

Bonjour,

@Mips a raison, il faut attendre de visualiser le temps qu’a mis le réseau à démarrer dans l’écran « réseau Zwave -> résumé » avant toute chose. Un réseau correctement configuré doit démarrer rapidement, quelques minutes max.

En théorie, cela devrait démarrer en quelques secondes, mais à cause des nombreux messages non gérés par la librairie openzwave, on a énormément de timeout. En fait, chaque fois que vous avez le temps de visualiser la queue du contrôleur figée sur un nombre donné (>0) l’espace de quelques secondes, c’est un message non géré (pour un réseau bien configuré et en dehors des pannes matérielles bien sur).:fire:

Il faut savoir que les échanges lorsqu’ils fonctionnent sont de l’ordre de la millisecondes, ce qui est déjà extrêmement lent pour un protocole de communication mais n’oublions pas que le protocole répond à des contrainte de basse consommation, d’où le bas débit. On est bien loin des débits gigabytes éthernet, mais à l’échelle humaine on ne devrait absolument pas avoir le temps de se rendre compte de quoi que ce soit.

Yes, c’est la priorité dans ton cas. Cela ne réglera pas tes problèmes de queue qui ne se dépile plus. Mais cela stabilisera tes communications. Lorsque tu auras placé le dongle, il faudra que tu soignes l’ensemble de ton réseau.

Tu n’utiliserais pas l’API REST du plugin Zwave par hasard ? Via un script ou n’importe quoi d’autre ?

Je ne sais pas si c’est le module qui envoie des ordres spontanément. Je crois plus que c’est le plugin Jeedom qui scrute et interroge plusieurs fois en se disant « j’espère bien avoir la bonne réponse à la fin de tout ça ». C’est pareil chez moi. Je te propose de te concentrer sur ce qui te pose vraiment problème (latences et blocage de la queue) :wink:

Pour le coup ça je n’ai jamais eu. De ce que je comprend ta machine perd les pédales en parsant les messages (j’ai l’impression que ce sont les messages reçus, mais je ne suis pas sûr sur ce coup là). Si c’est les messages reçus, il se peut que ça vienne des perturbations (introduisant du non sens dans tes trames d’où des erreurs de parsing), et le fait d’éloigner le dongle zwave de toutes perturbations électromagnétiques peut améliorer les choses. Si c’est un problème au niveau des accès à ton port USB sur ta machine, je n’ai pas d’idée dans l’immédiat à part essayer un autre port USB.

Si tu héberges sur autre chose qu’une machine dédiée (un simple raspberry pi suffit), ton problème peut venir d’interactions avec le monde extérieur (tout le reste qui tourne sur cette même machine). C’est l’une des raisons pour lesquelles j’ai exclu l’hébergement de Jeedom sur le Synology. Une autre raison est que lors des mises à jour du DSM, tu ne peux jamais être sûr que tout va continuer de bien fonctionner. D’ailleurs le service est interrompu pendant la mise à jour du Synology. Toutes ces raisons font que je ne trouve pas cette solution viable pour un Jeedom de production, où une qualité de service est attendue. En revanche c’est très bien pour faire du test ou prendre en main l’interface avant d’acheter quoi que ce soit.

Lorsque la queue zwave est bloquée, tu peux essayer de regarder du côté de la commande « htop ». Ca ne va pas te dépanner, mais je suis curieux de savoir si le processus qui héberge ton démon zwave est toujours là et dans quel état. Pour ma part quand j’ai eu ce problème, j’utilisais l’API REST, et je l’ai constaté avec une utilisation du processeur constante. J’ai déjà remonté ce problème, je n’ai pas eu de retour pour l’instant.

source : Queue zwave qui monte

@Domatizer Je conseille de faire du sécurisé tant que possible. Il faut bien sur changer la clé Zwave par défaut avant la première inclusion (attention il faut la remettre à chaque mise à jour du plugin !). Je n’ai pas refait les tests effectués par @nechry mais je lui fait confiance, pour dire que seule la payload est chiffrée et que réseau chiffré et non chiffré cohabitent pour le routage. En tant qu’ingénieur et développeur, c’est aussi ce qui me parait le plus logique. Il faudrait vérifier au niveau du protocole pour être 100% sûr.

source : https://nechry-automation.ch/2018/01/22/modifier-cle-de-securite-zwave/
source : https://nechry-automation.ch/2018/01/25/maillage-mixte/

S’il est vrai que l’inclusion sécurisée génère un peu plus de traffic, cela ne devrait pas se sentir à l’échelle humaine. Malheureusement la librairie openzwave n’implémente que très peu de choses, et n’a pas fait des classes de sécurité sa priorité. Nous subissons donc de nombreux timeout sur ce traffic supplémentaire, et donc des ralentissements perceptibles. Cela ne doit en aucun cas se traduire par un ordre qui n’a pas été exécuté. Uniquement des ralentissements.

J’espère avoir répondu à vos questions,
Bonne journée à tous,
Pierre (Mav3656)
Helper Officiel Jeedom.

Merci @Mav3656 pour tes réponses.

Dans la doc du plugin, il est écrit la même chose.

Depuis l’apparition du Z-Wave+, il est possible de sécuriser les échanges entre le contrôleur et les noeuds. Il est donc recommandé de faire les inclusions en mode Sécurisé

C’est ce que j’ai fait au début pour tous les modules et j’ai choisi le Z-Wave pour ça aussi.

J’avais vu cette info bien après. Dommage que la clé ne soit pas modifiable dans Jeedom facilement en début d’installation. Je n’ai pas le courage de tout recommencer. Je ne le ferai pas avant 1 an ou 2 lorsque les ennuis du Z-Wave auront disparus. Car il faut être bien motivé pour exclure puis ré inclure tous les modules…

Ok pour de la latence. Mais certains ordres ne sont bien pas exécutés comme démontrés précédemment.

D’après mes nombreuses lectures sur les forums, mon ressenti est que jusqu’en 2018, openzwave fonctionnait bien. Je ne sais pas qui c’est passé en 2019, mais des gens qui n’avaient pas de soucis avant ont commencé a galérer. D’où ce post [avis] fiabilité z-wave et plugin openzwave
Depuis, peu de mises à jour…

En attendant d’avoir la nouvelle version d’openzwave 1.6 ou autre plugin basé sur le SDK, je cherche à obtenir un réseau stable, même si je n’ai pas accès à toutes les fonctions, mais il faut que que ça marche.

Ma conclusion actuelle est que le mode sécurisé fonctionne, oui mais aléatoirement avec les modules Fibaro Motion Sensor 2. Peut-être que c’est la faute d’autres modules ? Je n’en sais rien mais depuis que ces détecteurs sont non sécurisés, je peux enfin faire confiance en ma gestion de la présence. J’ai laissé tous les capteurs de portes/fenêtre en sécurisé, il y a tout de même des problèmes de collisions, mais cela reste gérable.

Voici les conséquences sur le comptage du nombre de présences confirmées dans la maison.
Presence
Passage en mode non sécurisé le 25 mars, pas de changement de scenarii, même matériel, nous sommes toujours 3 personnes présentes, pas de visites depuis début mars et bien confinées depuis mi-mars. Ce nombre ne doit donc pas dépasser 3. En mode sécurisé avant le 25 mars, ça déconnait plusieurs fois par jour. Depuis 2 semaines, c’est clean.

Actuellement, j’en suis entre 0 et 10 lignes d’erreur sur 10000 lignes de log openzwaved (avec un pic d’une trentaine au démarrage). J’ai bien avancé ce moi-ci. Prochaines étapes : passer en non sécurisé les Fibaro Dimmer 2 qui ne le sont pas, puis tous les capteurs de portes et enfin tous les autres modules.

Voilà, malheureusement, je ne suis pas prêt d’aller faire du sécurisé avant un moment…

Salut et merci pour les explications.

J’ai donc fais quelques modifications.

Je suis passé en V4 from scratch (en installant tout de même des plugins …).
J’ai re-syncrhronisé ma clef zwave et donc réimporté les modules. J’ai dû tous les renommer.
J’ai utilisé une rallonge USB pour éloigner la clefs de la box et du NAS QNAP sur lequel tourne la VM Debian Buster (USB2 indiqué dans la conf de la VM).

Le réseau zwave démarre en 286 secondes (variant suivant les fois).

Déjà dès le départ dans la santé zwave il manque plein de noms. Il suffit d’aller sur l’équipement, de sauver sans rien toucher et le nom apparait dans la santé zwave … ça sent un peu le bug.

image

Je soigne un noeud, 2 noeuds, j’attends bien que la queue retombe à 0 à chaque fois et pouf au 3eme noeud ça par en vrille.

A ce moment là @Mav3656 voila l’état du htop. Le processus python qui gère le zwave prends tout le CPU et reste comme ça jusqu’à reboot du daemon ou kill du processus en question.

image

Au départ je me suis dit, bon ben c’est ce module qui pose problème. Je reboot je recommence et ça le fait avec un autre module. Je reboot une 5eme fois et cette fois c’est caremment le module zwave qui ne vois plus les voisins. On tente de soigner le noeud mais ça fait rien et au bout d’un moment le CPU repart à 100%…

Qu’est-ce que c’est énervant :angry: :angry:

Je pars remettre la clef zwave en directe sur le port USB parce que là visiblement je m’en sort pas !

Bon évidemment ça marche pas mieux et ça plante également.

Possible que ce soit la clef Zwave qui déconne ? Vous avez déjà eu ce genre de cas ?
Au dernier reboot elle ne voyait même plus de voisins alors que les modules si … c’est totalement incompréhensible.

Je veux bien tenter d’acheter une machine physique avec un SSD pour mettre proxmox dessus à la place du NAS mais je vois moyennement pourquoi ça marcherait mieux …
Qu’est-ce qui se fait de bien pour pas trop cher ? Je trouve les NUC un peu cher quand même.

Bonsoir,
Quel serait ton budget?
Ceci étant, je serais surpris que les problèmes viennent de la plateforme.
J’ai d’abord eu un RPI3 maintenant un miniPC à base de I5.
Mes clés sont toutes branchées côte à côte sur les ports USB du pc et à part le Zigbee pour lequel je perds régulièrement des noeuds, je sais que le problème vient du maillage et je suis en train de l’améliorer, ça tourne comme une horloge.
Auparavant sur RPI3 les clés étaient toutes branchées sur un hub autoalimenté placé juste à côté du RPI. Là encore, pas de problème.
Peut-être la chance, alors j’en profite.

Salut,

Disons 150-200€, ça me parait pas trop mal. Sauf si c’est moins bien que mon QNAP 253A encore que lui n’a pas que ça a faire tourner … il a tout ses propres services.

Après peut-être que QNAP a une mauvaise gestion des ports USB et de la virtualisation !?
Ou alors comme je disais, que la clef que j’ai (Vision ZU1401-5) est à la ramasse.

C’est pas facile à dire mais j’ai l’impression qu’au départ j’avais moins de soucis, que c’était plutôt invisible à part quelques ordres qui ne passaient pas.
Maintenant depuis que la queue zwave ne dépile plus parce que le processus monte à 100% assez souvent ça devient vraiment galère de faire avec.

Alors ce qui est impossible à dire c’est si c’est à cause d’un problème matériel, d’un update du QNAP ou autre qui a foutu le bronx ou bien à force de rajouter des fonctionnalités et donc d’un confit entre le core et des plugins.

Entre parenthèse, sais-tu si le plugin fullyKiosk fonctionne bien en V4 car ce n’est pas annoncé comme tel et je l’ai tout de même installé sur ma récente V4.

Merki

Bonsoir @Bison

J’ai eu la même réflexion que toi en ce début d’année quand rien ne marchait correctement. J’avais hésité entre idéalement la Jeedom Pro, la JeedUp, un NUC, un vieux PC portable. Mais mettre 200€ ou 400€ dans du matos pour ne pas être sûr du résultat. Je n’ai pas franchi le pas et depuis, en persévérant, cela fonctionne bien mieux. A terme je passerai sur quelque chose de plus puissant car je suis toujours entre 1 et 2 de CPU.

Je suppose que tu as repris ta sauvegarde. Donc Jeedom n’a pas perdu les équipements. Dans un premier temps, ne te lance pas dans des exclusions/inclusions. Il faut d’abord que tu retrouves tous tes modules avec les noms.

Ouais, je trouve aussi que la syncho entre Jeedom/openzwave et la clé est limite. Souvent, dans la configuration, les paramètres du module de l’onglet Paramètre ne correspondent pas avec les paramètres réel du module. Donc, je fais « Actualiser les paramètres » plusieurs fois et je vais réveiller les modules sur piles. Combien de fois j’ai rentré les mêmes valeurs des paramètres inutilement, je croyais que le module les avait perdus, mais en fait, non, c’est Jeedom/openzwave qui n’avait pas les bonnes valeurs.

J’avais lu sur le net qu’il fallait prendre la Aeotec Z-stick Gen 5 et rien d’autre, c’est la meilleure à ce jour. Dans le doute, j’avais pris ce modèle. Je ne voulais pas gratter 30€ pour avoir des emmerdes ensuite.

Il faut que tu règles en priorité tes nœuds inconnus au niveau du plugin.

Quelque chose se passe mal autour de la communication avec ta clé zwave qui fait planter le démon. Sauf erreur de ma part tu ne m’as pas répondu. Utilises tu par un quelconque moyen l’API REST proposée par le plugin zwave ?

Je n’ai pas de solution miracle a te proposer. En revanche je peux te proposer des tests à faire pour essayer de cibler le ou les problèmes que tu rencontres. Pour commencer je te propose de remettre la rallonge USB pour te mettre dans de bonnes conditions. Ensuite, à des fins de débug et diagnostiques, essaie de faire un test avec un Jeedom from scratch, aucun autre plugin / script ou scénario qui tourne. Essaies d’abord de faire fonctionner tout ton réseau zwave. De pouvoir ne serait-ce que soigner tes noeuds un par un sans jamais que ça plante, envoyer des commandes depuis le dashboard. Ce genre de test. Si déjà ça ne fonctionne pas sur ta plateforme, on peut se poser la question « puisque ça peut marcher, la preuve ça tourne chez d’autres, est-ce que mon problème vient de la clé ou de l’environnement/plateforme sur lequel je le fais tourner ? »

Pour ce faire : t’es il possible de tester ta clé sur un autre hard, si t’as un pc qui traine ou n’importe quoi d’autre, tu installes Jeedom et tu fais que du zwave avec tout ton réseau et tu regardes si tu arrives à tout piloter/soigner ?

Pour résumer, on part du principe que ça peut marcher puisque ça marche chez d’autres. On détermine :

  • si ça vient de quelque-chose que tu utilises sur Jeedom qui fout la grouille (pour ça on repart from scratch et on met rien d’autre)
  • si ça vient de l’environnement HOST du Jeedom ou de sa configuration : pour ça on test sur un autre environnement tout simple, un RPI ou vieux pc qu’on met sous debian stretch (version officielle supportée pour Jeedom) et qui fait que ça.
  • si ça vient de la clé : la faut tester avec une autre clé. Si les tests du dessus ne sont pas concluant, et si tu peux te le permettre, investi quelques dizaines d’euros sur l’Aeotec gen 5 et refait les tests ci dessus. Elle est en vente sur Domadoo, revendeur « de confiance » (c’est mon avis) et SAV irréprochable si t’as un retour faire.

Bon courage :wink:

Remarque concernant la clé Aeotec gen5, cette clé a une petite batterie qui te permet de faire des inclusions NON SÉCURISÉE mais facilement dans toute ta maison. Si tu veux faire des inclusions sécurisées il faut la laissée connectée à Jeedom (raison : la clé de sécurité n’est pas contenu dans le contrôleur USB).

Autre remarque : si tu testes avec une autre clé, il faut que tes autres modules ne soient plus appariés à ton ancienne clé. Pour ça tu peux au choix faire des exclusions ou reset tes modules.

Autre remarque : on croit gagner du temps mais parfois c’est plus compliqué de repartir d’un backup que de réinclure les modules proprement. Tu peux reset ton contrôleur zwave dans les actions du plugin zwave. Attention si tu fais ça, tu devras exclure ou reset tes modules pour qu’ils acceptent d’être réinclus. De plus pense à supprimer tes équipements dans le plugin zwave (ou au moins mettre à 0 la valeur du « node I’d » de tes équipements obsolètes si tu ne veux pas les supprimer) avant de réinclure les modules.

Autre remarque : il n’est pas possible de soigner le contrôleur principal. En revanche ce problème se règle facilement en cliquant sur « rafraîchir les infos du module » sur le contrôleur principal. Tu verras apparaître les vrais voisins du contrôleur. Ce problème ne devrait pas arriver en théorie, et je n’ai pas réussi à mettre en évidence une situation pour le reproduire de manière systématique.

J’ai déjà vu ça. De mémoire tu te retrouves dans cette situation si tu utilises le bouton orange « régénérer la détection du nœud » mais ce n’est peut-être pas le seul cas… Comme tu l’as dit tout rentre dans l’ordre en cliquant sur le bouton pour rafraîchir les paramètres. C’est le plugin qui n’avait pas les bonnes infos.

Autre remarque : la Jeedom smart fonctionne très bien et me semble bien dimensionner pour héberger Jeedom, et le service pack power qui vient avec te permet d’avoir un dns à vie avec certificat de sécurité valide pour attaquer en HTTPS. L’hébergement sur EMMC est un bon compromis en rapidité et fiabilité.

Bonne journée à tous,
Pierre (Mav3656)
Helper Officiel Jeedom.

Salut,

Non justement j’avais installé une Debian Buster pour tester la V4 il y a déjà quelques temps et j’en ai profité pour tout refaire afin de ne conserver que l’essentiel car parfois on test des trucs et on garde les scénarios ou autres widget dont on ne se sert finalement plus.
Les équipements ont été re-crées en appuyant sur « Synchroniser » mais du coup avec les noms par défaut correspondant au modèle. Il me parait donc normal d’avoir eu à les renommer.

En effet, j’ai fini par comprendre ça également. Il suffit de faire un actualiser les paramètres pour reprendre les informations du module, pas de soucis. Ce dont je parle est juste dans la « Santé zwave » ou seul 3 modules sont identifés, les autres sont unknown ce qui est anormal.
Si je retourne sauver les paramètres de l’équipement zwave sans apporter aucune modification le nom correcte apparait dans la « Santé zwave », jusqu’au prochain reboot du Daemon…

J’ai lu sur Domotique-store qu’il fallait éviter cette clef sur RPi4 car problème apparemment avec Buster.
Du coup vu que mon but était de basculer sur la V4 avec une Debian Buster … est-ce que c’est un bon plan de prendre cette clef ? Est-ce que le problème n’est que sur RPi4 et n’apparait pas si Debian Buster est installé sur un PC ?

Pas de noeud réellement inconnus, juste ce bug dans la « Santé zwave »

Le seul truc que j’utilise en API REST me semble t’il (sinon c’est involontaire), c’est une requête Jeedom qui vient d’un autre Jeedom externe afin de le monitorer (il remonte l’état d’une prise). Suite à ta remarque j’avais stoppé le scénario du Jeedom externe qui envoi l’info via API REST.

@Mav3656, ok donc l’idée est de repartir à nouveau sur une Debian Stretch pour toi. Mais on peut tout à fait installer la V4 dessus ?

Je pourrais remonter à nouveau une VM sur le QNAP avec juste Debian Stretch + Jeedom V4 puis Synchroniser la clef et enfin essayer de soigner les noeuds un par un.

Si déjà ça ne fonctionne pas … j’aviserai avec un autre matériel.

Oui je vais surement me laisser tenter suivant le résultat au dessus ou même pour avoir un backup mais même remarque qu’au dessus, est-ce que cette clef fonctionne sur Debian Buster pour la suite ?

Si ça réapparaît au prochain reboot il y a un truc qui se passe vraiment pas correctement. Comme si des informations n’étaient pas persistées. Peux tu dire si ça fait pareil sous stretch en v4 ? Si oui, veux tu essayer stretch en V3 juste pour le test ?

N’oublie pas de mettre à jour le core et les plugins, et de forcer la réinstallation des dépendances du plugin zwave après une installation.

Pas d’info la dessus.
Stretch étant maintenu jusqu’en juin 2022 tu n’as pas de souci à te faire, je pense qu’il y aura du changement si ce problème existe réellement sur Buster d’ici là. Il sera toujours temps d’y passer plus tard.

Je pense que oui. Pour moi Stretch est la version officiellement supportée, au moins pour la V3. As tu vu ou lu quelque part une information contraire ?

Bonne journée,
Pierre (Mav3656)
Helper Officiel Jeedom.

Bonjour,

La clé Aeotec fonctionne sans problème sous Buster et Jeedom v4.

Bon courage !

Le souci c’est le pi4 avec cette clé.

Antoine

@Bison
Tu es reparti de zéro, c’est lourd de tout recommencer.

Tu avais pourtant un très bon maillage. Donc ton matos était déjà correct. C’est bon signe.
Il aurait été peut-être préférable de continuer sur ton ancienne config et de passer en non sécurisé les modules un par un.

J’ai lu que la clé Aeon n’était pas compatible avec les ports USB3 du RPi4, il fallait passer par un Hub USB2.

En théorie, c’est bien. Mais on ne voit pas trop ce qu’on fait. Ensuite, il faut retrouver ses petits avec les ID lors de la synchronisation. Vu comment une inclusion peut mal se passer, il vaut mieux les faire une par une. Perso, je préfère laisser la clé sur Jeedom pour voir ce qui se passe lors les inclusions.

Salut,
J’ai acheté mon miniPC sur Ali.
Il est basé sur un I5 et m’est revenu à 150€ avec 8go de ram et j’ai ajouté dessus une SSD que j’avais dans un tioir.
Pas de VM, je sais que c’est 'argement surdimensionné mais aucun problème depuis que je l’ai.

C’est ce que j’ai commencé par faire il y a quelques jours en fait. Passer les 3 modules qui étaient sécurisés en non sécurisés mais comme ça n’a rien arrangé j’ai poursuivi les investigations.

Le problème n’est forcement si régulier que ça, par exemple depuis que j’ai à nouveau remis la rallonge USB comme conseillé et reboot le Daemon zwave, je n’ai rien touché et le réseau fonctionne.
Je suis sûr qu’au bout d’un moment ça va partir en vrille mais je ne sais pas quand.

Ce que j’ai remarqué hier en revanche c’est que je n’arrive pas à soigner les modules puisque assez vite au bout du 2eme, 3eme, 4eme (?), et bien le process python passe à 100% et ne redescend plus.

@mich0111, ok merci

@Madcow et @Tonio16 merci pour la confirmation, il faut donc juste éviter le RPi4 avec cette clef. Ce n’est pas juste un pb de Debian Buster

Il faut aller doucement. Étape par étape. Ne pas cliquer partout (chose que je faisais au début car ne comprenant rien). Module par module, mise à jour des voisins, réveil de tous les modules, redémarrage. Bien observer le log. Recommencer avec un autre module.
Ces opérations surchargent le réseau, il y aura du drop, mais faut continuer, quand c’est fini (on ne sait jamais facilement quand le soin du réseau est fin, une barre de progression avec un % serait sympa pour toutes actions qui peuvent prendre du temps), hop un redémarrage ou plusieurs, tu ne touches plus à rien et tu surveilles le log en mode Info.

C’est l’USB3 du RPi4 qui semple poser souci avec la clé Aeotec ou l’inverse.

C’est une mise a jour des voisins qu’il faut faire et non l’action de soigner un noeud ?

Et tu proposes de faire :

Mise à jour des voisins d’un noeud
Réveil des modules qui dorment
Attendre 1mn / observer les logs
Redémarrage du daemon zwave

Recommencer …

Tu te rends compte du temps à consacrer à l’opération s’il faut redémarrer le daemon zwave à chaque mise à jour des noeuds ? J’ai mal du comprendre :grinning:

Question : si par hasard j’opère ces opérations de soin massivement depuis une nouvelle VM debian stretch + Jeedom V4, est-ce que ça sera ok pour rebrancher la clef sur le jeedom actuel car c’est la clef qui stock tout ?

Derrière « Soigner le noeud », je ne sais pas quelles sont les opérations effectuées. Ça ne mange pas de pain de le faire. Si tout les paramètres sont présents, un petit « Rafraichir les valeurs du noeud » ne fait pas de mal non plus. Pour la mise à jour des voisins, tu peux en faire 2 ou 3 à la fois ou plus, mais trop à la fois, cela peut planter aussi le réseau.

A toi de voir ce qui va le plus vite, mais quand le réseau est planté, la mise à jour des voisins peut ne pas être finie à ce moment là. Oui, ce sera long. Moi je ne compte plus les semaines que j’ai passées à nettoyer, opérer, soigner, panser, surveiller le malade, analyser sa maladie !

Oui, c’est la clé qui stocke tout. Mais avec un réseau tout clean stocké dans la clé, ce ne sera pas clean dans un nouveau Jeedom au début. La synchro vers Jeedom peut être galère, comme précisé plus haut, ou il faut rentrer dans équipement faire un Sauvegarder pour faire bien la correspondance avec l’ID, Puis faire rafraîchir les paramètres dans Configuration. Du boulot en plus, donc je te conseillerais d’effectuer les opérations directement sur ta version finale de Jeedom pour ne le faire qu’une fois.

Ben comme apparemment avec ma Debian Buster + Jeedom V4 je n’arrive pas à soigner noeud par noeud sans qu’à un moment donné le processus délire irrémédiablement, je ne vois pas trop comment le faire sur un Jeedom prêt à l’emploi c’est à dire avec plugins, scénarios, design, widgets.

Je pense que l’idée de @Mav3656 c’est de partir d’une fresh installation sans rien dessus pour vérifier si le fait de soigner pose problème. Ça permet de s’assurer que le matériel n’est pas en cause (VM sur QNAP + clef USB zwave). C’est vrai que si ça fonctionne à ce stade alors on pourrait sûrement en déduire que c’est l’un des plugin/widget qui viendrait interférer et planter le processus.

Maintenant ça peut aussi visiblement venir d’un module au vu de l’expérience du post Juste pour comprendre :) qui s’est terminé par un défonçage du module à la pioche :scream:

Je ne sais pas si tu peux sauvegarder ta clé comme la Aeotec, faire un reset de ta clé, puis réinclure quelques modules pour voir si le réseau tient
Si ça fonctionne, tu es bon pour les inclure un par un et voir ce qui ne vas pas à un moment donné. Bon ce sera encore plus long que la mise à jour des voisins…

Oui, si tu arrives à savoir lequel, tu peux toujours l’exclure du réseau temporairement.
Concernant le message de @BizZ62 , ah oui, j’ai adoré son coup de pioche et j’ai bien rigolé :smiley: