Waouhh
Il y a des condo de luxe dans la Smart 
Ça aurait pu être 2 minute en effet.
Réflexe de vieux PCiste (condo alim à découpage).
A noter cependant que parfois il n’y a pas de résistance de décharge ou de charge passive tout court sur le condo de certains circuits électroniques.
Bon bein après un Stop and Go de 5 min le problème reste entier
Sans certitudes du tout mais je pense qu’il y a un élément dans le réseau zwave qui bloque la première phase d’interview dans certains cas. Si tu te sens l’âme d’investiguer, pour ma part je tenterai de réinterviewer chaque nœud avec un réveil du module pour les nœuds sur piles puis, une fois que tous les modules sont bien découverts, de lancer un soin du réseau et de laisser tourner.
Pourquoi pas relancer une synchronisaton aussi après 1 heure par exemple histoire de voir comment ça réagit.
Ok, je vais faire cela
Le réinterview est en cours, … encore une dizaine
Le seul élément qui semble erratique est une télécommande Nodon qui me renvoi des statuts anarchique, elle se réveille 2 secondes et réapparait en zzz, les commande s’affiche puis 1 heure plus tard plus rien, message pile vide ? mais elle est encore à 67%
Je vais la dégager et retesterai si tout se stabilise un jour …
Je ferai un retour plus tard …
En attendnat merci à tous …
Alain
De retour ce matin avec un constat affligeant !!
En début de semaine, suite à la migration d’openZwave vers JS, j’avais été obligé de réinclure 6 équipements puisqu’ils étaient en « Unknown manufacturer 0xXXXX et Unknown product 0xXXXX » et impossible de les réparer (tout testé) après divers échanges avec la hotline.
La réinclusion a très bien fonctionné depuis, toutes les fonctions testées et actives
Hier, après nos échanges ci-dessus :
J’ai bien exclu la télécommande qui boitait !
Réinterviewé tout mes équipements
Lancer un soin complet du réseau
Résultat : ce matin je retrouve 5 des 6 équipements réinclus dans l’état « Unknown manufacturer 0xXXXX et Unknown product 0xXXXX » HS plus rien ne fonctionne !!! 
Il s’agit de 2 types d’équipements :
2 prises commandées NEO
3/8 Robinets de radiateur Spirit les 5 autre fonctionnent encore
Tous ces équipements fonctionnaient parfaitement depuis des anées avec OpenZwave
On ne peut pas parler de compatibilité puisque les même modèles même firmware fonctionne toujours
Ce n’est pas un dysfonctionnement coté équipement 5 en même temps
Que puis-je faire pour réparer ?
Avez-vous besoin de log ou autre pour donner une piste de solution ?
Merci d’avance pour vos lumières …
Bonjour,
je suis toujours coincé avec des équipements perdus :
« Unknown manufacturer 0xXXXX et Unknown product 0xXXXX »
Comment faire pour les récupérer ??
Est-il possible de refaire une inclusion sans changer d’ID ? puisque le réinterrview ne suffit pas ?
Une âme charitable a-t-elle une piste pour m’en sortir ?
Bonjour,
Bizarre quand même qu’une ré-interview de suffise pas …
Tu peux refaire une inclusion, puis changer l’ID du module dans le 1er onglet du module pour reprendre celui de l’ancien.
Oui mais je perd l’historique
Je l’ai fait sur une des prise commandée et ça fonctionne
Ce qui prouve que les équipements sont ok mais que c’est le plugin qui bug
Mais pour les 3 robinet de radiateur Spirit cela m’embête de perdre l’historique des températures …
N’est il pas possible de forcer la détection du module quand il est en « Unknown manufacturer 0xXXXX et Unknown product 0xXXXX » ?? Comme si il arrivait tout neuf depuis le broker ??
Autre question (sur le même sujet)
Pourquoi n’est il plus possible de choisir soi même le fabriquant et le produit comme on pouvait le faire avec OpenZwave ?
Au pire on se plante et ça fonctionne pas, mais dans mon cas ou les commandes sont créés et le module bien détecté une première fois cela fonctionnerait très probablement …
Pour creuser le sujet des équipements qui tombent en « Unknown manufacturer 0xXXXX et Unknown product 0xXXXX »
J’ai capturé et enregistré l’arbre du neud d’une prise commandée que je venait de réinclure avec succès 30 min avant
Puis j’ai lancé un réinterview du noeud et 10 min plus tard j’ai refait une capture de l’arbre
Conclusion :
Je ne suis pas expert pour identifier les différences mais
L’arbre passe de 2183 lignes à 2474 ?? surprenant
Parmis les différence je retrouve des values added dans le 2ème alors que j’attendais plutôt des values updated non ??
Je peux vous poster les fichiers en balise </> si vous préférez mais je pense que glisser les 2 fichiers dans un comparateur de textes est plus simple…
Arbre PC friteuse new ok 01.txt (42,5 Ko)
Arbre PC friteuse new ok 02.txt (47,4 Ko)
Salut,
Je ne sais pas si on a eu le même pb, mais suite cette dernière maj (coïncidence??) j’ai eu aussi la perte du réseau zwave et protocolinfo sur tout les modules devenus dead. Mon port étant bien configuré en byId sur ma clé usb (aeotec gen 5).
Pour le relancé, pas trouvé d’autre solution que changer le port*, redémarrer le démon, attendre un peu et revenir sur le byId, redémarrer le démon et après pas mal de temps, réinterview des différents noeuds, progressivement c’est revenu à la ‹ normal › mais il m’a fallu la journée pour retrouver tout les modules. Et çà va demander encore qq jours pour que les routes se restabilisent.
*je n’ai pas testé de débrancher la clé 20-30min, çà aurait probablement suffit dans mon cas.
Moi je n’ai jamais eu de problème de mise à jour avec la clé aotec gen5 avec cette config si ça peu aider :
moi avec le port historique /dev/ttyACM0 lors du passage sous ZwaveJS ça dzconnait et il m’a fallut prendre le port byId (comme recommandé)
la dernière maj doit faire planter qq chose chez qq utilisateurs, sans que pour l’instant on puisse savoir vraiement quoi.
ceci dit ce n’est toujours pas fonctionnel, après qq heures les modules repassent en dead puis certain alive et ainsi de suite sans arrêt.
J’ai tout débranché 20 min et je relance. j’attends un peu que le réseau se redécouvre. a suivre…
N’ayant pas trouvé de solution ici, et n’étant pas sûr d’avoir exactement le même soucis que @AlainGew67 j’ai créé mon post pour ne pas polluer