Scénarios - Razberry - queue openzwave saturée

[nechry]

Je vais désactiver les refresh en background, de cette façon il n'y aura que les commandes de position et a la fin on reçoit la position finale. Mais on perdra la transition entre les deux.


Sent from my iPad using Tapatalk

[flomuson]

Merci Nechry de ta réactivité mais penses tu que le problemes viennent de là ? car j'ai l'impression d'être le seul à avoir ce problème.. (queue saturée et donc latence lorsque je ferme tous mes volets)

j'ai beau cherché dans le forum, personne n'en parle... je dois avoir une config qui merde quelque part (position du controler, prob de controler, de Raspberry, de Razberry) mais j'avoue ne pas savoir comment chercher pour résoudre mon problème...

[flomuson]

Question : je viens de me rendre compte que dans mes scénarios, la case "Exécuter en avant plan" est à oui.. je ne peux pas tester là mais est ce que ca "justifierait" le problème ?

question subsidiaire : si un scénario avec "Exécuter en avant plan" est à "oui" lance un autre scénario avec "Exécuter en avant plan" à non.... le deuxième scénario tourne t'il avec le contexte du premier (et donc en avant plan) ou a t-il son propre context (et donc pas en avant plan) ?

[nechry]

Moi je drive 3 store en même temps et ils partent en gros les trois en même temps. J'ai les trois cmd de position dans un scénario. Sans option d'exécution spécial. Il faut que je regarde si chez moi lors de cette action j'ai aussi la queue de message qui monte. Mais j'ai une optimisation a faire sur les multilevel qui provoque similaire pour la l'ampoule zipato rgbw. Donc je veux creuser l'histoire.

Moi quand mon scénario s'exécute je suis pas a regarder ou à vouloir l'interrompre. Il ouvre mes stores, ou les ferme et je suis content. C'est des action donc je m'en fou qu'elle prennent plus de temps ou non. Dans tout les cas les cmd zwave sont en queue et passent une après l'autre. Donc je sais qu'elle seront exécutés tôt ou tard


Sent from my iPad using Tapatalk

[flomuson]

EN fait je me suis rendu compte du probleme un peu par hasard... j'ai ouvert mes volets sans faire expres (en pleine nuit) et j'ai voulu les fermer en me disant "zut on va tout voir chez moi..................................................................." sauf que avant qu'il ne se referme... ben ca a eu le temps de s'ouvrir complement....

[nechry]

Bon je viens de tester chez moi, je lance le scénario ouverture et de fermeture tout s'exécute directement sans aucune l'antence. Durant la montée ou la descente, la queue reste a 0. Et je peux sans problème allumer/éteindre des lumières via le dashboard instantanément lors de la montée / descente.

Sur cette base, je ne vais pas "immédiatement" débuter des investigations dans le code pour ce problème précisément. Le désactiver serait dommage pour les autres utilisateurs.

Maintenant je sur une un aeon-labs gen5 on c'est qu'il est plus performant que je zway, mais le zway est beaucoup répondu donc ce problème devrait être remonté par d'autre si vraiment ça serait le problème. Donc on laisse le sujet ouvert si d'autre on aussi des problèmes il pourront commenter, toute fois le sujet du poste n'est peut-être pas suffisamment révélateur. Mais dans tout les cas je vais suivre le problème.


Sent from my iPad using Tapatalk

[nechry]

@flomuson, lance ton scénario d'ouverture ou de fermeture selon l'état actuel. Si tu veux inverser il faut en premier lancer le stop sur chacun puis lancer la commande inverse. Ton scénario d'ouverture peux checker si la puissance est >0 (il bouge) faire un stop puis débuter la cmd. Idem pour la cmd inverse.


Sent from my iPad using Tapatalk

[nechry]

Avec la puissance elle est pas notifier au bon moment il y a du travail a faire pour que le stop suit "intelligent" sinon tu force un stop meme si bouge pas.


Sent from my iPad using Tapatalk

[nechry]

voilà c'est bon je m'étais piégé avec mon sous-scénario.

donc ici j'ai un scénario commun a tout mes déplacement de Store, il regarde si mes store sont en mouvement, la puissance >0, si c'est le cas il stop. attend qu'il bouge plus avec un timeout

Screen Shot 2015-08-28 at 20.36.12.png (181.37 Kio) Consulté 899 fois

ce qui est très important ici c'est l'activation de l'exécution en avant plant

Donc en première action de chaque déplacement je peux appeler ce scénario. pour m'assurer d'un stop avant de débuter

Screen Shot 2015-08-28 at 20.35.50.png (85.5 Kio) Consulté 899 fois

ici pour mon dernier store, j'ai un test si la porte de la terrasse est ouvert (peut-être je suis sur la terrasse) je ne ferme pas celui ci et envoie une notification qu'il aura pas été fermé. c'est un genre de "WatchDog" pour ne pas m'enfermer dehors !

chez moi ça fonctionne plutôt bien, dans tout les cas c'est aussi recommander pour le moteur de ne pas inverser la phase rapidement, le stop aide un petit peut dans cette tâche.

[flomuson]

Merci pour tous ces scenarii ... sauf que j'utilise openzwave avec le razberry.... donc ca confirme que j'ai un problème...

Pour le sujet j'ai en fait plusieurs postes qui a mon avis on la même origine....

[nechry]

une chose est sure c'est pas openzwave en cause il est beaucoup plus réactif que zway. donc plutôt le dongle aeon-labs vs le razberry

[flomuson]

Si j'achète un dongl je peux transférer les modules ? Sans inclure/desinclure ? J'ai vu cette option dans les actions.... je vais faire un nveau sujet sur la latence/queue razberry / d'ongles aeon

[nechry]

Je pense c'est un peux rapide de vouloir changer , sauf si tu avais déjà prévu pour d'autre raisons. Il faudrait attendre que d'autre confirme ou non se comportement.

C'est pas encore userfriendly de faire un transfert de contrôleur. On a pas de vrai marche à suivre. Mais dans tout les cas avec un gen5 aeon-labs c'est plus simple puisque tu peux tout faire en mode déconnecté. Et il n'y a pas besoin de démonter tes fibaros, un triple clique sur le bouton2 et t'en en inclusion/exclusion. Avec le nombre de node que tu as ça serait plus rapide que se battre avec les fonctions de transfert de rôle. J'ai passé 45nodes en 2h environ, lors de mon changement zstick v2 a gen5


Sent from my iPad using Tapatalk

[flomuson]

Quel outils peuvent m'aider pour trouver le problème ? Comment savoir si c le raspberry ou autre ? Je suis un peu perdu

[ReadyB]

Salut, je réponds rapidement.
J'ai exactement le même soucis de congestion depuis mon passage de ZWAY à Openzwave. 3 volets roulants commandés part des modules fibaro. Jeedom sur un RPi2 + RaZberry

La queue zwave se remplit et sature le système, comme pour flomuson. Quand c'est le cas, tout devient très lent à réagir dans ma domotique, parfois 30 secondes de délai.

J'en avait parlé sur le forum et Loïc m'avait demandé de vérifier que tous mes modules étaient bien associés sur les 3 groupes avec jeedom, malheureusement ça n'a rien changé.

Je confirme que ce n'est pas un problème isolé. J'ai un collègue qui rencontre aussi ce comportement avec son système et des modules qubino volet roulant. Ça ne viendrait donc pas des modules. En revanche le problème est constant lors de la fermeture de les 3 volets roulants via un virtuel. Et je me répète suis ZWAY tout fonctionnait parfaitement ! Vraiment parfaitement, les volets descendaient tous instantanément, pouvaient être stoppé en cours de descente pour être remonté de suite sans se poser de question.

Je peux vous donnez des logs ou tout autre info pour aider à régler ce soucis car c'est vraiment dommage d'avoir un système aussi bon que jeedom mais des lenteurs exaspérantes parfois.

À votre disposition pour aider !

[flomuson]

Alors ca tu ne peux pas savoir comme je me sens moins seul tout d'un coup.... Meme si ca ne résout pas le problème et que j'hésite toujours a changer de contrôleur...
Maintenant que nous sommes plusieurs (3) le problème en devient un... Par contre je me demande si c'est pour tous le monde pareil (mini+, raspberry2.. ) et les autres ne le disent pas ou si c'est un défaut du razberry.... Ou autre.....

Je suis également à disposition si besoin de log ou de test....

[briss]

Bonjour,
J'ai aussi des problèmes de lenteur mais pas uniquement avec les scénarios.
En regardant la queue Z-wave au moment de ces lenteur, elle est très remplie (parfois une centaine).
Si j'attends que le queue soit vide avant de lancer mon scénario, tout est OK!!!
Après analyse, je me suis demandé si ce n'était pas au moment du réveil des modules sur piles (j'en ai 2) mais je ne suis pas sûr car mes wakeup sont sur 4H!
Autre constat, ces lenteurs se produisaient régulièrement après l'utilisation de mes modules Fibaro RGBW(j'en ai 2).(Association sur les 5 groupes)

Du coup, j'ai fait l'inverse de ce qu'a demandé Loic en ne laissant l'association que sur le groupe qui concerne le contrôleur.
Ca a l'air nettement mieux... A suivre.

[nechry]

Donc en gros 2 fois par jour vous avez un 30 secondes de délais sur les commandes... Depuis quand êtes-vous passé en ouw? Pcq si c'est le fameux refresh il est en place depuis 2-3 semaines. Sinon hier j'ai due faire 30 aller retour et rien eux comme problème


Sent from my iPad using Tapatalk

[flomuson]

C'est un peu réducteur de dire ca... Moi par exemple en fonction du soleil j'ouvre ou je ferme donc disons 4-5 fois par jours et pendant ce temps tout ce qui est zwave fonctionne 30s après (lumière ou ordre par exemple).. D'ailleurs même le scénario a des latences : Les dernières commandes... se lancent avec du retard

Je n'ai pas de module sur batteries et avant j'avais le contrôleur dans les 3 groupes.. Mais c'était pareil...

J'ai ce problème depuis le début de la migration (au moment de la 1er stable de openzwave)

[nechry]

Oki donc ça élimine bien le refresh. Par contre j'ai beau lancer à fond le mouvement sur mes 3 stores et j'ai pas le problème donc c'est plus difficile a si je ne peux reproduire. Ou le gen5 est beaucoup plus performant que je pense, mais ça me semble trop gros pour être vraiment que ça...

Lorsque tu bouges tes stores en journée, j'imagine que se sont de petits déplacements ? Et même avec ça tu a une latences plus longe que le mouvement? Ça serait extrêmement ça.


Sent from my iPad using Tapatalk