Bonsoir,
Est-ce que quelqu’un d’autre a un problème de temporisation dans le réseau z-wave avec les vannes Eurotronic spiritz ?
Sur ma soixantaine d’équipements z-wave, ce sont les seuls équipements à avoir une tempo aussi longue alors que la plus éloignée de trouve à 7-8m de la box.
J’ai beau relancé le démon, soigner les noeuds, recalculer les routes, rien y fait, elles restent avec une tempo démesurément longues.
De fait, régulièrement, elles sont désactivées par Jeedom.
Bien que ça n’a aucune raison d’influer sur le comportement du plugin qui est dans dans dernière version, je suis sur NUC, buster, 4.1.20
Salut,
Ce sont des modules sur piles flirs (comme tu le sais), ce qui explique la latence.
Chez moi ca tourne généralement entre 100ms et 500ms avec parfois des pics à 800ms.
C’est à dire? qu’as-tu configuré?
je n’ai pas ce soucis.
Chez moi ces têtes ont une latence inférieure à 200 ms en permanence. Yc lorsque le niveau de pile est faible.
Deux des têtes sont pourtant en limite de portée de nœuds constitués par des projecteurs Steinel Z-wave.
Au passage : durée des piles sur 4 têtes, sans retirer les piles en été > 2 ans càd 2 hivers complets.
J’ai oublié de préciser que chez moi elles sont encore inclues en sécurisé ce qui rajoute toujours de la latence.
Par contre Qu’as-tu comme réglage de remontée de température etc pour tenir 2 ans ?
Paramètres suivants :
Piles avec taux affiché de 45% pour la vanne la plus lointaine et donc qui doit ajuster son niveau d’émission au max pour communiquer. Pour la plus proche taux de 75%.
La qualité des piles y est pour beaucoup. Je ne prends que des piles Duracell Pro.
Piles installées à l’été 2019.
Salut à tous et merci pour vos retours.
Mes paramètres sont identiques à ceux de @Yves19 à 2 exceptions près.
- Time-out du LCD est de 5 sec.
- Détection ouverture fenêtre à medium
Peut-être que la détection de fenêtre pose un problème, il faut que je vérifie.
En attendant mes latences sont colossales, rien en-dessous de 500ms, ça peut aller jusqu’à 3000ms.
Le seul autre module avec une latence importante (800ms) est un range extender en limite de portée.
Pour la désactivation, je n’ai rien mis justement, dans la config, le paramètre de désactivation d’équipements est à 0 et pourtant les logs disent que Jeedom après 3 tentatives infructueuses a désactivé les modules.
J’ai ouvert un sujet resté sans réponse pour savoir s’il y avait un autre endroit où indiquer le nombre de tentatives avant désactivation.
Avez-vous une idée sur ces différents éléments ?
Bon ben info à connaître.
Lorsque le paramètre de détection de fenêtre passe à disable la latence chute à 300ms pour la plus importante sinon tout est au vert et au beau fixe.
Content 
Sujet clos et merci encore.
T’es sur que c’est pas simplement parce que le module était réveillé du au changement de paramètre ?
Typiquement avec les modules en flirs il suffit de faire 2 ou 3 ping et tu tombes de 500ms à 80ms car le module est déjà réveillé et donc répond plus vite.
Tu as probablement en partie raison puisque la latence remonte régulièrement.
Mais là où elle ne descendait jamais sous une valeur critique malgré les sollicitations du module, maintenant, un simple ping les remet dans dans les valeurs nominales.
J’avais la même latence avant que je ne change le time-out du LCD en le mettant à 5s. Après le changement de valeur, la latence était identique et les ping n’amélioraient rien.
Conclusion, il y encore un loup mais il devient gérable.
D’ailleurs je vais sûrement écrire, sur le modèle de mon scénario de détection de modules dead, un scénario lancé toutes les heures afin de pinguer spécifiquement ces modules.
Moche mais workaround en attendant la solution réelle si elle arrive un jour.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.