OpenZwave n'aime pas certains Vision Security

[kouaw]

Il est en vacances comme il a dit sur un autre poste

Envoyé de mon GT-I9300 en utilisant Tapatalk

[Delta4]

J'ai déjà eu l'occasion de m'exprimer à ce sujet : Jeedom est pour moi le meilleur système à l'heure actuelle.

Il est donc beaucoup plus rageant de voir que cette qualité est remise en cause par un problème au niveau de OZW, car sans Zwave, c'est pas pareil

Quand j'ai commencé à prendre en main Jeedom, c'était avec Zway .... voyant que le vent tournait, je suis passé assez rapidement à OpenZwave ... quelle déception ! même (il faut le dire) si la réactivité de l'ensemble était meilleure ... mais à quel prix ! Je suis vite reparti sur Zway ...

Je le redis encore, le travail fantastique des devs de l'équipe Jeedom n'est pas à remettre en cause, au même titre que leur compétence ! mais comme je disais dans mon post précédent, y'a un truc pas clair dans la lib OZW.
Mon avis : tant que ce truc pas clair n'est pas découvert et réglé, les bouts de ficelle et bouts de scotch n'y pourront rien.

Voilà ... et si je suis encore à tout tenter et à rester sur Jeedom, c'est que j'y crois

J'allais oublier : @nechry, @loic (et peut-être à d'autres ...) bonnes vacances

[karayoo]

Comme mon ami strasbourgeois ci dessus, j'ai dû me résoudre à repasser partiellement sous zway.
J'ai donc Ozw pour la plupart de mes modules et zway pour tous les vision security.
Je fais cohabiter un uzb zwave et un razberry branché en usb.
Ça marche au poil, je peux redémarrer, faire des maj, tout est ok. Et les piles ne bougent pas, la preuve que Ozw est en cause malgré que à côté de ça, il marche plutôt pas mal...

[mvar38]

Bonjour,
j'ai egalement le même souci de déchargement des piles en 3 jours depuis le passage en OpenZwave ! etrange !!
Quelqu un a trouvé une solution ? Merci d avance,

[mutmut]

passe tout en beta !
blague mise à part, je tourne en beta sur jeedom 1.212.04 et ozw 1.8.0+1.x.513 et plus ucun soucis avec mon ZG8101.
Dans mon souvenir j'ai dû l'exclure puis suppression puis synchro puis inclusion -> remontée nickel, réveil tard (voir param préco) et piles toujours à 100% pour l'instant (1 mois environ).
Dans mon cas c'est tout bon


mutmut

[Golgautier]

Hello,

Tu es en quelle version d'OZW quand tu es en béta ?

[mutmut]

après vérif sur mon jeedom :
- plugin zwave : 1.8.0
- openzwave : 1.3.523

EDIT : ce n'est plus la beta, c'est devenu la stable depuis https://jeedom.fr/blog/?p=2653

[Golgautier]

Ok merci....

Je me tâte à remettre une pile dans l'appareil pour voir... Ce qui m'étonne c'est que j'étais en béta sur le zwave avant la sortie de la stable, donc je devais être dans la même version que celle qui fonctionnait pour toi, alors que j'avais des soucis. C'est étrange :-/

[nechry]

Il dit qu'il a exclue entre deux a voir, mais j'ai aussi des doutes...


Sent from my finger

[OlivierD]

Bonjour,

Commence-t-on a avoir des pistes sur cette problématique ? Y-a-t-il une raison particulière?
Car de mon côté j'ai une vingtaine de ZD2102 (Zwave Plus) + un contacteur de garage et je ne constate aucun problèmes... Mise à part que la portée de ces composants est plutôt faible, tout fonctionne depuis août...

Est-il possible que ca se mette à tomber en panne ?

[Golgautier]

ZD2102 (Zwave Plus)

Ca existe ça ? Je ne le savais même pas. Possible que ces modules ne souffrent pas du problème car nouvelle génération. Mes modules perso ZD2102 et ZP3102 sont Zwave -tout court-

[nechry]

Visiblement ceux qui ont des devices problematique c'est visible deja. Il ne semble pas que le probleme arrive apres. Du moins c'est ce que j'ai experimente et constate


Sent from my iPhone using Tapatalk

[karayoo]

As-t-on une issue à ce pb ?

[nechry]

Pas encore, mon rapport de bug n'a pas été accepté par la dev team openzwave, pour eux ce sont les devices qui ont un problème dans leur implémentation, ce n'est pas tout faux mais il y a aussi quelque chose a mon avis qui vient d'ozw aussi


Sent from my finger

[Delta4]

Bonjour,

Il est vrai que c'est plus facile de dire : "c'est pas moi, c'est lui ..."
Ces modules fonctionnent sans souci partout, sauf avec OZW ...
même avec Jeedom et Zway, il n'y a aucun problème.
Des autruches zwave ça existe ?

[nechry]

Le device a tout de même un problème, il faut trouver le moyen de contournement en ozw. Ce que les autres on trouvés je présume.


Sent from my finger

[Delta4]

@nechry

(J'espère que tu vas bien....)

C'est sûr que ces modules ont un problème : il n'est pas normal qu'on puisse planter un module par certaines commandes.
Ceci étant, ce sont des modules anciens qui étaient utilisés très souvent.
Force est de constater que OZW (quelle que soit la plateforme) ne sait pas les utiliser.

Je suis obligé d'en utiliser encore (au prix trop élevé que coûte un module zwave) et c'est vraiment la galère.

Je doutais déjà qu'une solution apparaisse, mais si la team ozw ne reconnait même pas le problème ... ben, il ne sera jamais résolu

et ce n'est pas le seul : par ex le mimi keypad rfid qui ne remonte pas le dernier badge...

[Edit] Attention tout de même : les modules concernés par ce problème sont toujours notés "compatibles" dans la liste, alors qu'ils ne le sont pas.

[nechry]

Pour le keypad rfid j'ai un issue ouverte et accepté, mais il n'y a pas eux d'avancé dessus. Un des dev possède le lecteur donc sera en mesure d'expérimenter avec. J'ai déjà fournie pas mal d'info. Je relancerai a l'occasion. Pour les visions on va "normalement" en envoyer a la dev team pour qu'ils puissent constater le problème. C'est nodes ont un soucis dans le wakeup CC, c'est le devoir du node de retourner en veille, on pas revenir encore sur c'est pas moi c'est lui. J'ai aussi un peut perdue espoirs, mais avec le device en main il y a des chances de dire a mais oui c'est ca.


Sent from my finger

[Delta4]

Merci pour les infos sur le mini keypad rfid. Allez, on y croit
Pour les Visions Security, là, j'y crois plus

[nordix]

Ces modules ne sont pas en problèmes à mon sens, après plusieurs investigations, il semble que dans une configuration de réseau Zwave donnée, ils peuvent se comporter d'une drôle de manière. Entre autres lorsque l'étape de Query n'est pas complétée sur le module, ozw essayera de constamment de faire des requêtes sur le module l'empêchant peut-être d'aller en sleep mode.

D'autre part, OZW diffère des autres stack propriétaires par le fait que le statut des modules n'est pas maintenu, on dira qu'il est stateless. J'ai un réseau zwave avec 2 contrôleurs, Vera et Jeedom OZW. Lorsque je redémarre la Vera, tout est fonctionnel de suite, les statuts rentrent pour tous les modules, les infos également, car la Vera a maintenu sur disque en cache (ou sur sur son module zwave) toutes les données des modules, leur état initial, la table de routage, etc...et aucun Query Stage n'a lieu lors du redémarrage. Uniquement lorsqu'une config est changée ou lorsqu'un heal est demandé que la phase de query (dite Poll) est en fonction.

J'ai fais des tests pour étayer ce constat, redémarrant la Vera et en même temps changeant le statut d'un détecteur de porte et le statut n'est pas mis à jour et si ce détecteur n'est pas déclenché de nouveau la Vera le pensera toujours au même statut qu'avant le redémarrage... Il n'y pas de query car le stack zwave de la Vera sauvegarde les status sur une ram non volatile ou disque.

SI je redémarre OZW, dans ce cas aucun statut n'est connu. Ce qui s'affiche sur le dash ce sont les données cachées de Jeedom pas d'OZW. On le vois très bien dans la config des modules, au niveau valeur où tout à N/A .. Ces données ne seront mises à jour que lors du Query_Stage. Ce Query_stage interroge tous les modules pour connaitre: Les valeurs dynamiques, statiques, les voisins, les associations, bref tout ce qui peut changer et ça peut être long, très long si les réseaux sont importants! Bien sûr durant la phase de démarrage, le réseau n'est pas à 100% fonctionnel, spécialement pour les modules Vizion, les class semblent être perdues carrément.

Par conséquent, les modules Vizion ne doivent pas supporter d'être interrogés à tout va, à chaque redémarrage d'OZW et si la config du module n'est pas bonne par exemple, (j'ai un cas de module avec lequel zwave voit 128 instances, un Vizion), le module devra rester en éveil durant tout l’interrogation. Je ne pense pas que ces modules ont été conçus pour être interrogés à tout va!

OZW doit murir et devenir Statefull, il doit sauvegarder tout ce qu'il lui faut pour un redémarrage rapide et pouvoir de suite être fonctionnel. Les données de config peuvent attendre soit le prochain Heal soit dans une phase ultérieure de Query. Bref je crois que c'est la cause principale de ce comportement d'OZW avec les Vizion et d'autre modules qui ne supportent pas être interrogés constamment.