Plugin Z-Wave Version 2016-08-17 Stable

[nechry]

Je peux aussi te donner le flag à modifier si tu as envie de tester et me dire la differance


Sent from my iPhone using Tapatalk

[nechry]

@dric @znation le problème des case a cocher qui ne sont pas visible sera corrigé via un patch dans jeedom core 2.3.x donc dans la prochaine update core a venir prochainement


Sent from my finger

[nechry]

@Ekinox

dans /var/www/html/plugins/openzwave/resources/openzwaved/openzwaved.py
ligne 762:

Code : Tout sélectionner

options.addOptionBool("AssumeAwake", True)

passer l'option à False:

Code : Tout sélectionner

options.addOptionBool("AssumeAwake", False)

puis redémarrer le réseau

[Ekinox]

Tu peux stp via l'écran de santée zwave regarder si t'es modules secteurs aurait beaucoup de timeout?

Sur 15 modules sur secteur, juste après le démarrage (topology loaded), j'avais 4 timeout; ils ont disparus très rapidement après le démarrage; à priori, çà doit être OK.
J'ai remarqué que j'ai pas mal de modules sur pile (environ la moitié) dont les voisins sont OK; j'avais souvenir qu'il fallait attendre leur réveil; je ne sais pas si c'est lié à cette version, mais c'est une bonne chose.

[znation]

@dric @znation le problème des case a cocher qui ne sont pas visible sera corrigé via un patch dans jeedom core 2.3.x donc dans la prochaine update core a venir prochainement


Sent from my finger

Merci pour l'info nechry, c'est loin d'etre critique mais c'etait pratique, on attendra le quickfix.

Sinon pour parler de mon retour sur le demarrage du reseau zwave, perso avant cette version d'openzwave, j'avais une queue sortante à 30 max et un reseau opérationnel en 1 minute environ, la je monte à 120 en queue et un reseau OK en quasi 4 minutes . J'ai 34 noeuds sur mon reseau (15 sur secteur et 19 sur pile, essentiellement des smoke sensor et yeux fibaro)

C'est sur qu'on redemarre pas le reseau tous les 4 doigts mais ca allonge fortement quand meme. D'ailleurs ça m'avait inquiété de voir ce temps si long leur du 1er redemarrage je me demandais pourquoi c'etait beaucoupplus long que d'habitude, maintenant j'ai la réponse.

[Ekinox]

dans /var/www/html/plugins/openzwave/resources/openzwaved/openzwaved.py
ligne 762:
passer l'option à False:
puis redémarrer le réseau

Fait. Le réseau démarre en 60 secondes (10 fois plus vite). J'ai moins de modules sur piles prêts, mais ce n'est pas gênant pour moi.
Quel est l'impact de garder ce paramétrage ? (réseau moins fiable, autre ?...)

[dric]

@dric @znation le problème des case a cocher qui ne sont pas visible sera corrigé via un patch dans jeedom core 2.3.x donc dans la prochaine update core a venir prochainement


Sent from my finger

Parfait merci !

[nechry]

@Ekinox alors, cette option plus un patch au seins de la librairie openzwave corrige un problème qu'on avait rencontré sur des modules de la marque Vision Secure qui se drainaient de leur piles en 24h pcq il ne retournaient plus en veille suite a un re démarrage du plugin.

L'option à True, dit au moteur zwave que le module sur piles sont réveillé et qu'ils devraient répondre, la réalité et bien sur différente. Le contrôleur va donc demander au module des informations, comme il pense qu'il va répondre, ces informations n'arriveront pas et le timeout de non réponse arrivera. donc si la proportion de module sur piles est élevé on peut constater une différence, je ne m'attendais toute fois pas à un facteur x10 comme chez toi.

D'une par si pas touché par ce problème je dirais que pas obligatoire d'avoir ce flag à True, bien que ça soit la valeur recommandé, due moins celle par défaut dans openzwave. après oui c'est dommage de démarrer en 10min mais normalement vous ne démarrer pas souvent, due moins j'espère.

Il n'est tout fois pas dit que d'autres modules pourrait avoir un problème similaire du coup ça serait mieux d'avoir actif.

je vais réfléchir si j'ajoute une option dans la page de configuration du plugin pour vous laisser le choix de modifier ce paramètre, avec la valeur par défaut à True (une approche on va dire pessimiste)

[znation]

@Ekinox alors, cette option plus un patch au seins de la librairie openzwave corrige un problème qu'on avait rencontré sur des modules de la marque Vision Secure qui se drainaient de leur piles en 24h pcq il ne retournaient plus en veille suite a un re démarrage du plugin.

L'option à True, dit au moteur zwave que le module sur piles sont réveillé et qu'ils devraient répondre, la réalité et bien sur différente. Le contrôleur va donc demander au module des informations, comme il pense qu'il va répondre, ces informations n'arriveront pas et le timeout de non réponse arrivera. donc si la proportion de module sur piles est élevé on peut constater une différence, je ne m'attendais toute fois pas à un facteur x10 comme chez toi.

D'une par si pas touché par ce problème je dirais que pas obligatoire d'avoir ce flag à True, bien que ça soit la valeur recommandé, due moins celle par défaut dans openzwave. après oui c'est dommage de démarrer en 10min mais normalement vous ne démarrer pas souvent, due moins j'espère.

Il n'est tout fois pas dit que d'autres modules pourrait avoir un problème similaire du coup ça serait mieux d'avoir actif.

je vais réfléchir si j'ajoute une option dans la page de configuration du plugin pour vous laisser le choix de modifier ce paramètre, avec la valeur par défaut à True (une approche on va dire pessimiste)

Le but en effet est que ça fonctionne, vision security ou pas.

Une proposition, possible ou pas, serait que si le plugin detecte un peripherique vision security impacté par le soucis, positionne le flag a true ou false ...

Perso j'ai apparemment un vision security (detecteur d'ouverture http://www.domadoo.fr/fr/peripheriques/ ... 52326.html) mais je ne pense pas que j'etais impacté par le bug vu que je suis toujours a 100% et ça fait 2-3 mois que je l'ai

[nechry]

@znation, le demon doit être lancé avec l'option déjà définie, je ne peux pas la modifier après coup selon les modules présent ou non. En plus pour de module identique autant modele que version certains avec des problèmes d'autre non, donc pas vraiment possible. Si configurable ça sera par l'utilisateur mais par sur une détection.


Sent from my finger

[juju78y]

Bonsoir,
pour ma part la MAJ à tres bien fonctionnée.
Cdt,
Julien

[dric]

@dric @znation le problème des case a cocher qui ne sont pas visible sera corrigé via un patch dans jeedom core 2.3.x donc dans la prochaine update core a venir prochainement


Sent from my finger

Parfait merci !

Mise à jour 2.3.18 >> les checks sont de retour !!!

[znation]

@dric @znation le problème des case a cocher qui ne sont pas visible sera corrigé via un patch dans jeedom core 2.3.x donc dans la prochaine update core a venir prochainement


Sent from my finger

Parfait merci !

Mise à jour 2.3.18 >> les checks sont de retour !!!

Idem merciii !

[nechry]

je n'ai que remonté le problème, c'est loic qui a fait le travail

[zep57]

@stravinsky pour les voisins pas ok, faut essayer de soigner le réseau, mais je pense le mieux sera de stopper débrancher le contrôleur un petit 5min

c'est parfait ça à marché sans problémes ^^

merci

J'avais aussi ce problème qui a été réglé en enlevant 5mn le contrôleur mais là de nouveau tous les voisins NOK!

Je voudrais comprendre pourquoi ça s'est reproduit de nouveau?
Ou chercher l'erreur avant d'enlever de nouveau le razberry pour 5 mn?

Ps; j'ai que du fibaro et un ZD2102(le coupable?)

[nechry]

je pense plus le coupable est le razberry , mais pourquoi je ne sais pas sinon j'aurais essayé de trouver une solution moins contraignante que de devoir retirer le contrôleur.

[zep57]

Merci
C'est un jeedom officiel de août 2014 (donc ancien modèle de razberry)
Je voulais passer a une clef usb , mais j'ai vu un article sur une nouvelle carte raz qui devrais sortir.
Si je retrouve je poste.
L'article parlais de l'ouverture du protocole dont tu a déjà parlé quelque part.

[zep57]

J'ai retrouvé:
http://www.touteladomotique.com/index.p ... 9FO5JiLTIU

"Au rayon des nouveautés, Zwave.me annonce pour bientot un nouveau Razberry. Cette nouvelle puce permettra deux évolutions :

- La principale, c'est une amélioration de l'antenne (qui sera bien meilleure que la précédente). Et la possibilité de connecter sa propre antenne extérieure si certains en veulent plus.

- La seconde nouveauté est plus pour les bricoleurs (car il faudra souder pour l'activer). Il sera possible d'ajouter la fonction d'horloge au Razberry pour que le Raspberry Pi reste à l'heure, même après une coupure de courant."

Attendre ou passer a une clef GEN5?

[zep57]

@nechry
Pour information
J'ai décoché: -soigner le réseau 2X par semaine et -activer les tests sanitaires.
Et mon problème de voisins NOK s'est résolu de lui même en quelques minutes (sans retirer le raz)

[nechry]

Je pense pas que ça puisse avoir une influence. Bon les tests sanitaires c'est recommander de les activer


Sent from my iPhone using Tapatalk