Bonjour,
Suite soucis avec ma box domotique, j’ai fait une réinstall de jeedom sur une debian 11, récupéré un backup, et comme l’ancien plugin zwave n’est pas compatible avec debian 11, j’en ai profité pour effectuer la migration vers zwavejs. Migration simple, j’ai bien retrouvé l’ensemble des devices zwave très facilement.
Cependant, suite à cette migration, je constate que mes 3 modules Qubino ZMNHJD1 fils pilote pour des radiateurs électriques passent fréquemment en état Dead pour une durée aléatoire. Ce comportement n’était pas présent avec l’ancien plugin Zwave. J’ai par ailleurs 2 prises connectées zwave+ (une fibaro et une hank) qui normalement assurent la redondance du maillage a +/- 4m de chaque sonde…
J’ai tenté une exclusion/reset + inclusion, rien n’y fait…
Quelqu’un aurait-il rencontré ce problème?
Cordialement,
Yannick
Toujours la même galère, obligé de forcer les changements chaque minutes via un scénario pour qu’avec de la chance les modules ne restent pas dead trop longtemps et reçoivent qd meme une instruction a leur réveil…
Salut,
Histoire de pas te laisser seul avec ton problème, j’ai la version Rail DIN et sous zwave-js-ui (donc sans le plugin Jeedom) : pas de soucis
Mes parents ont aussi la version rail DIN avec le plugin zwave-js de Jeedom et n’ont pas de soucis non plus.
Mais ceci-dit j’ai lu déjà quelques posts et certains ont l’air d’avoir des galères avec les ZMNHJD1.
Est-ce que tu peux faire une capture des groupes de tes modules ?
Ces modules ont des soucis quand on applique la même action à la suite, ça part en timeout et peut ralentir le réseau. Si tu utilises le plugin Thermostat et la répétition des actions, ça peut-être problématique. Moi ce que j’ai fait, j’ai exécuté les on/off via un scenario en vérifiant préalablement les états, y a du mieux depuis 
Merci pour le conseil.
Justement il me semblait qu’avec le plugin Thermostat les instructions de chauffe / arret ne sont pas répétées, et du coup lorsque le module est en statut Dead l’instruction de chauffe est au final perdue. D’où l’obligation que j’ai de forcer la commande (suivant la situation température piece / instruction thermostat) toutes les minutes pour réussir accrocher a un moment le module… Mais meme là, les modules peuvent rester marqués dead pendant plusieurs heures!
N’ayant pas ce problème avant sous openzwave, je me demande si le plugin zwavejs n’a pas une config timeout un peu trop courte pour mes modules…
Si ça passe souvent en DEAD c’est que tu as peut-être un contrôleur zwave avec une version buguée (Z-Wave JS - Z-Wave driver written entirely in JavaScript/TypeScript), à vérifier
C’est une clé Z-wave.me, pas listée dans l’article. Mais bon, pourquoi, pas la mettre a jour, d’autant que le processus a l’air simple. Je vais tester.
Pour les modules Qubino, une mise à jour du firmware n’est possible qu’en renvoyant les modules chez Qubino… bof… et encore je me demande si c’est encore possible suite au rachat par Shelly.
Après tu peux détecter que si le module est DEAD alors réessayer dans une minute via un scénario, c’est là aussi que tu peux vérifier l’état avant de faire un changement.
C’est sur que ça fait un peu bricolage mais sur ce module il ne faut pas trop le solliciter sinon le réseau peut devenir instable, du moins de mon côté. Surtout que tu as des remontées de puissance, bien vérifier de ne pas remonter trop à la seconde, la bande passante c’est le point faible des réseaux domotiques.
Et effectivement pas de MAJ via OTA et même pas sûr que le dernier firmware changera quelques choses.
Ok, merci pour le conseil. En effet, vu le problème et la perte de contrôle sur mes modules de chauffage suite au passage zwavejs, pour pas retrouver mes enfants congelés le matin j’ai fait au plus court et forcé la réapplication de la consigne (chauffe ou arret) chaque minute pour avoir plus de chance de trouver le module alive. Je vais mettre un peu plus de conditions histoire d’alléger le réseau.
Après avec des communications chaque minute sur ces 3 modules, je trouve bizarre que cela puisse produire une charge trop importante sur lees module / sur le réseau ZWave.
On va voir le résultat.
Y a une file d’attente dans Zwave, si ça échoue, ça réessaye plusieurs fois avant de considérer que c’est invalide, donc si tu redemandes derrière, ça peut créer un effet boule de neige qui sature la file d’attente et peut mettre le contrôleur en défaut.
Upgrade firmware de mon controleur Z-Wave.me de 5.25 à 5.34 (maximum): c’est pas mieux.
Je vais désactiver le scénario de retry, voir si les modules restent plus longtemps en alive.
Si pas le cas, je vais travailler sur un renvoi des instructions moins systématique.
Bonjour à tous,
Je découvre zwavejs seulement maintenant - j’avais laissé la sphère domotique de côté comme tout fonctionnait relativement bien chez moi - et je vois notamment ce post.
Ayant justement des modules ZMNHJD1 chez moi, je suis interpelé. Du coup est-ce que les problèmes mentionnés ci-dessus persistent toujours ? Est-ce qu’il y a un inconvénient à rester sur OpenZwave (comme jusque là tout fonctionne encore correctement…)