OpenZwave n'aime pas certains Vision Security

[Golgautier]

(@nechry si tu peux me dire comment faire pour faire fonctionner ce Multisensor en OZW, je suis preneur ...)

Peut être que je peux aider

Déjà, c'est quoi le souci ? Stabilité zwave ou remontées des valeurs qui ne va pas ?

[Delta4]

@Golgautier
merci pour ta proposition d'aide.
Je ne dis pas que le Multisensor ne fonctionne pas, les infos remontent, c'est bien ce qui me fait dire qu'il y a des "trucs" bizarres dans le OZW : la remontée de l'état de santé du Multisensor est des plus folklo
Par contre, le coût des piles pour les Vision Security est insupportable

[nechry]

@Delta4 c'est quoi les remontée folklo pour le multi, si c'est le timeout déjà expliqué que ce n'est pas important. Il est bien paramètre, pcq oui le truc avec les multi sensor c'est de bien les paramétrer, je ne vais pas revenir sur les valeurs il y a plusieurs threads qui explique très bien.

Le réseau zwwave tombe en topologoy loaded chez moi en 30sec sur mon lab (8 devices) et 3-4min ma prod 45 devices. Je ne sais pas ou tu va chercher tes heures? Si tu parles que tes devices sur piles réveillent et complet leurs interview, la ca veut rien dire si je set des wakeup interval a 2jours mon réseau pourrait prendre une semaine a passer Ready et si j'ai des remote elle ne se réveille pas d'elle même, donc jamais. Mais le réseau est fonctionnel a Topologie loaded, l'ensemble des nodes secteurs et completed et participe au routage de messages.

Non dans le moment, je me répète on a pas de solution pour ces 3 Vision security et ça me fais chier autant qu'a vous, que ce soit qu'aussi j'en possède, mais surtout que je ne comprends pas comment ozw peut empêcher un node de dormir et que ce node ne veulent plus remonter dans ce cas. J'ai aussi gaspiller des piles comme vous, j'ai branché sur un DVM de table pour suivre les cycles utilise une alim externe, mais toujours pas de raisons, mais je suis sur qu'on va trouver. Ce qui reste étrange c'est que d'autres utilisateurs les possèdent et ont 0 problème, dans les même version, même contrôleur...

Ma recommandation reste la même, ne pas utiliser ces devices si il vous ont fait le coup une fois d'ici a ce que l'on ait une solution. Apres libre a vous de prendre d'autre mesures, avoir deux serveurs un zway l'autre ozw.


Sent from my finger

[nechry]

@Delta4 to test actuel en zway c'est avec ou sans jeedom?


Sent from my finger

[Delta4]

Bonjour
@nechry

Le test que je fais en z-way sur un RPI2 Jessie, c'est avec un Jeedom complet, tout est fonctionnel (v1.209.0)

J'ai remis mon Multisensor sur le RPI2 en OZW et là, il fonctionne impecc ... va comprendre

[Delta4]

Pour compléter :
J'ai donc supprimé tous les Vision Security sauf le ZS5101 car je n'ai rien trouvé d'autre pour détecter des vibrations.
Pour le Multisensor, je le trouvais très souvent en dead alors qu'il est à coté de la box. J'ai contrôlé tous les paramètres et je pense qu'ils sont corrects. D'ailleurs sur la config OZW il manque la valeur du paramètre 101 à 225 pour remonter les valeurs (luminosité, temp, humidité et piles)

Enfin je comprends bien que tu sois plus ennuyé que nous encore. Je ne sais pas comment tu procèdes, mais monter un système pour tester les lib OZW sans Jeedom. Il doit y avoir un truc qui passe pas.
Le simple redémarrage de OZW plante les modules en question. Qu'est ce qui est envoyé au module pendant cette phase ? Avant le redémarrage, les modules sont en vie, non plantés

[Delta4]

encore un truc : je ne suis pas trop d'accord sur le fait que le problème soit uniquement le node qui reste réveillé. Je ne pense pas que ce soit significatif.
Le module est planté, l'état du mode est donc n'importe quoi.
Les tests que j'ai déjà faits en OZW donnent un module parfaitement fonctionnel sans limite de temps, le node s'endort normalement. Les choses se gâtent sur un redémarrage de OZW, là c'est plantage immédiat -> il faut retirer la pile. Et quand le module est planté, la pile se vide vitesse V

[nechry]

@Delta4 je veux pas brouiller le post avec le multisensor, mais les paramètres après inclusion sont toujours ceux du constructeur. Donc effectivement le 101 doit être adapter manuellement a 225 sur pile ou 224 sur secteur, le 111 pourrait être sur 15min par exemple. Nous pensons metre en place un système de configuration recommandé post inclusion de module pour forcer certains paramètres, polling ou wakeup interval, et association groups a des valeurs qu'il faut toujours adapter. Mais le chantier n'est pas encore démarrer. L'idée est d'avoir un device fonctionnel sans intervention de l'utilisateur. Apres rien n'empêche d'adapter selon vos besoins spécifique.

Pour revenir au secure dans certain cas ils fonctionnent bien 3-4 jours, interview terminé puis bang, début de leurs insomnie, mais oui la majorité des cas c'est suite a un démarrage. Je dois étudier avec les dévelopeurs de la librairie, si une notification pourrait provoquer ça. Dans tout les cas il y a des chantier en se moment sur la wakeup queue, donc je suis bien confiant d'une solution


Sent from my finger

[Delta4]

Merci pour les précisions.

Maintenant que je n'ai plus qu'un module, je sais qu'il faut que je le redémarre en vitesse pour que la pile tienne un peu plus longtemps.
Ce qui m'ennuie, c'est cette impression de dialogue continu entre OZW et les modules. Je reste persuadé que c'est la cause essentielle des problèmes Mini+. Je vois bien que le réseau Zwave est très chargé même avec peu de modules alors qu'il devrait être relativement silencieux. Il suffit de regarder le "long temps réel" de Jeedom.

Je vous souhaite bon courage en tout cas, merci du boulot

[nechry]

@Delta4 a quelle endroit tu voix que le réseau est bien chargé, je ne parle pas du démarrage bien entendu. Les visions ne discutent pas avec le contrôleur et vise versa, j'ai vraiment des difficulté a comprendre ce que tu essais de m'expliquer


Sent from my finger

[Delta4]

Désolé si je ne suis pas très clair

Je prends le cas d'un ZP3102.
Ce que j'ai remarqué :
1 - le réseau zwave fonctionne, le ZP3102 détecte bien la présence et fait un flash avec la petite led rouge sur le module. Jeedom indique bien cette détection.
2 - j'arrête Jeedom, donc OZW s'arrête aussi
3 - pendant l'arrêt de OZW, une détection du ZP3102 fait clignoter la petite led en question, bien qu'aucun contrôleur ne soit connecté au réseau. Le détecteur fonctionne toujours (pour rien d'ailleurs) ; il n'est pas planté.
4 - je redemarre Jeedom, donc OZW redémarre aussi (normal !) et cela suffit à planter le ZP3102 très rapidement, pendant le démarrage de OZW (probablement) et là c'est fichu pour le ZP3102.

Pfff, pas facile à expliquer....

[Golgautier]

@Delta4 : Ca c'était clair déjà

La question de Nechry pose sur ça :

Ce qui m'ennuie, c'est cette impression de dialogue continu entre OZW et les modules. Je reste persuadé que c'est la cause essentielle des problèmes Mini+. Je vois bien que le réseau Zwave est très chargé même avec peu de modules alors qu'il devrait être relativement silencieux. Il suffit de regarder le "long temps réel" de Jeedom.

[Delta4]

ah oui, je n'avais pas vu la "correction automatique" je parlais du "log temps réel" de Jeedom dans le menu admin.
On voit aussi dans la console OZW

[Golgautier]

Tu vois des messages de tes modules piles ou uniquement des messages des modules sur secteur ?

Perso, les modules sur secteur causent beaucoup (remontée de conso électrique en général), mais ceux à piles sont discrets...

Enfin, j'ai une question sur la stabilité du réseau sous OZW. Tu n'as pas un appareil Wifi près de ton contrôleur qui gêne ? Perso, j'ai eu un réseau peu stable il y a 15j, un truc de fou. Et bien, en mettant le contrôleur Zwave au bout d'une rallonge USB, tout est rentré dans l'ordre (sûrement la faute au wifi de mon PC Jeedom qui interférait)

[nechry]

@Delta4 ou la console discute c'est normale, un On/Off va provoqué un jolie paquet de lignes par exemple. Un HEM mal configuré vas pourrir complètement de messages. Mais ce n'est pas une instabilité c'est juste une fenêtre sur ce qui se passe.

Les devices zwave fond de l'association direct se qui signifie que même sans contrôleur ou jeedom up, ils continue a communiquer avec les devices associer. Donc c'est normal que ton sensor continue a envoyer des messages même si jeedom est stopé. Par exemple si tu fais une association entre ton détecteur de fumé et un store, même si c'est ton jeedom qui est en feu les store vont s'ouvrir pour t'aider a évacuer ta maison, sans qu'un scénario intervient.

Je vais continuer a regarder ce qui se passe lors du démarrage, je suis sur on va trouver, juste la si je traine dans mon bureau ma femme me fais des gros yeux, je suis supposé être en convalescence...


Sent from my finger

[Golgautier]

Je vais continuer a regarder ce qui se passe lors du démarrage, je suis sur on va trouver, juste la si je traine dans mon bureau ma femme me fais des gros yeux, je suis supposé être en convalescence...

Elle sera encore plus longue si tu traines trop longtemps dans le bureau

[ppet17]

Bonjour j'ai 5 ZD2102 détecteur d'ouverture. Ils restent tous en unknown. Apres exclusion et réinclusion ils marchent 1 journée. Piles vidées vitesse grand V. Idem avec 2 détecteurs de choc de la même marque...
Les derniers modules Qubino ne sont pas reconnus correctement, etc.
Je n'ai que des galère depuis la migration. J'ai arrêté ma Mini+ pour la déplacer vers le centre de la maison, au redémarrage tous mes modules sont en unknown !!! Je commence à en avoir marre des galères.
J'ai l'impression qu'il y avait quand même beaucoup moins de problèmes avec zway server qu'avec OpenZwave !! Le problème c'est que les derniers modules du marché n'ont pas de fichiers de conf pour zway server, donc on est dans la merde: OpenZwave est une cata et zway server n'est plus supporté! Faut il que je retourne sur ma box Zipabox ? J'ai franchement pas envie, mais je n'installe pas une domotique pour faire joujou avecou faire du dev mais pour qu'elle me simplifie la vie

[Golgautier]

@ppet17
Pour tes modules unknown, une solution a été développée et devrait être dans la prochaine mise à jour (beta ou stable, je ne sais pas). En attendant, tu peux la faire "à la main" : tu regardes le fichier zwcfg_*.xml qui se trouve dans ton /usr/python-openzwave. Tu trouve le même fichier qui se trouve dans un de tes répertoires de backup (/usr/share/nginx/www/jeedom/tmp/backup/plugin_backup/openzwave/) et tu le copies avant de démarrer ton plugin OZW, et tu retrouveras ta conf

Pour les Vision Security qui se vident, des pistent de travail sont à l'étude, sois un peu patient

[ppet17]

J'ai 11 modules Vision Security: ne marchent pas avec Jeedom, marchent avec Zipabox. Ils sont critiques pour mon système d'alarme !
Mes nouveaux Aeontech Gen5 ne marchent pas correctement avec Jeedom, marchent avec Zipabox
Mes nouveaux Qubino zwave+ ne marchent pas correctement avec Jeedom, marchent avec Zipabox
C'est bien de faire des évolutions d'ordre cosmétique dans l'interface, mais si les modules ne communiquent pas avec la box, on n'a pas les fonctionnalités minimum obligatoires.

D'après vous quelle décision je vais prendre? je vais attendre que 20 de mes modules soient enfin pris en compte correctement par Jeedom sans être obligé d'y passer des heures carrées de tests, réinclusions , modifs de paramétres, bidouilles en tous genres à chaque reboot ?

Le passage à Openzwave a juste été une cata sans solution de backup. Période de test et de validation réduite au minimum. J'ai l'impression de me retrouver dans la position d'un beta testeur avec en face un fournisseur qui n'a pas de tests automatisés de non-régression et qui investit prioritairement dans l'interface graphique alors que les services zwave sont en perte de supervision sur la moitié des marques de modules domotiques.

[mutmut]

Tu as la possibilité d'utiliser ta zipabox en "noeud zwave" pour tes modules bancals et jeedom pour le reste (pilotés par des virtuels, je te l'accorde ça va faire un peu de boulot pour associer jeedom et zipa).
J'ai aussi une zipa mais que j'ai totalement arrêté, la gestion des scénario/virtuel/script est beaucoup plus sympa dans jeedom.
Pour la partie alarme, j'ai une HC2 que je peux activer/désactiver à partir de jeedom via le plugin qui va bien.
Donc rien n'empêche d'utiliser 2 systèmes (ok c'est pas top) mais tu sépares la partie alarme de la partie domotique (avec contrôle de la partie alarme par la domotique:) )