Scénarios - Razberry - queue openzwave saturée

[nechry]

@flomuson justement je voulais te mettre en garde aussi pour le refresh. une fois le réseau a atteint topology loaded, je lance en background pour tout les nodes secteur, un refresh des valeurs. c'est pour être sure que l'état réel du moment. du coup si tu viens juste de démarrer ton réseau il est possible que tu sois brouillé dans le test par ces refresh. le mieux serait d'attendre je dirait au pif 30 minutes de sorte a ce que ces refresh soit terminé.

donc oui c'est normal que le refresh lance beaucoup de message en queue, c'est une action sanitaire et non une opération courante.

ton fibaro rgbw, avait été inclus avant le patch color? si oui il faudrait pour bien faire au minimum forcer la régénération de la détection du noeud, sinon exclure et inclure. mais la régénération est normalement suffisante

[flomuson]

Bon en fait je ne suis pas rentré, je n'ai pas pu tester mes volets ce midi... (j'ai acces a distance mais si je m'amuse a les ouvrir/fermer alors que madame est à la maison.... ca va pas plaire.... ce soir, promis je teste

Mon frgbw a été effectivement inclus il y a longtemps, je vais faire un "Regénérer la detection du noeud" et je retente les commandes...

par contre depuis 2 jours je fais plein de refresh/redemarrage... et maintenant j'ai remarqué que la valeur de mon "Etat" est toujours à 99 (si j'appui sur "tester", il me renvoie 99)

Etat2.PNG (58.59 Kio) Consulté 1052 fois

alors que les commandes de positionnement fonctionnent très bien et dans les l'onglet "valeurs" des configuration de mon module, j'ai bien le bon "Level"... dasn mon exemple 14)

Etat1.PNG (53.8 Kio) Consulté 1052 fois

[nechry]

tu as eux surement une notification qui a sauté. et le cache de jeedom n'est pas la valeur z-wave. il faut éventuellement force le refresh pour avoir le cache jeedom en phase.

sinon j'ai fais pas mal de tests et je suis revenue "temporairement" en arrière sur le refresh en background sachant comment vous utiliser vos commandes, Up, Stop, Down exécuté en 3 secondes avec mon algo provoque obligatoirement des latence et congestion dans la queue de message. j'ai donc simplement appliqué l'ancien règle de refresh.

Si je lance Up, puis un Stop, le stop réagit progressivement sur les trois stores dans un délais raisonnablement court (<1sec) dès fois plus long mais c'est aussi relatif a si d'autre msg arrive aussi. la queue de message monte pas trop

j'ai eux quelque fois ou le stop doit être lancé deux fois, mais pour moi se n'est pas une utilisation normale. déjà pour les stores c'est loin d'être conseiller de faire une inversion de phase trop rapidement (je parle ici de faire Up puis directement Down).

dans tout les cas ça semble mieux. ça sera dans la prochaine beta. vous me donnerai le ressenti.

[ReadyB]

Merci beaucoup Nechry !

[flomuson]

Merci Nechry, j'ai hate de tester...

Par contre pour la valeur de mes volet, j'ai vidé le cache Jeedom, redeamrré 40fois.. mais toujours pas de valeur correcte... une idée ?

[nechry]

Oui ton moteur de tâches est dans les choux ou du moins la tâche openzwave


Sent from my iPad using Tapatalk

[briss]

@Nechry,
Je viens de faire le test avec 2 volets en lançant un scénario qui monte les 2 en même temps puis un autre qui les descends.
Visuellement, la queue reste toujours à 0 et les 2 volets partent pile poil en même temps.

J'ai alors rajouté sur les scénarios 3 dimmers et 2 RGB, la queue monte un peut (max 15) mais les ordres sont éxécutés assez rapidement quand même (moins de 2s)

A ta disposition pour faire d'autres tests si nécessaire (le soir).

[nechry]

@briss. Oki donc si on stop pas la commande ça répond dans les temps sans bloquer le reste du réseau comme, je pensais et bonne nouvelle idem avec un razberry ( tu es bien en razberry ?)

Suite des bonne nouvelles demain, ou cette semaine dans la prochaine beta, j'ai désactivé le refresh en continu sur les commandes dimmer. Donc un stop après un up ou down ne fera pas exploser la queue de messages. C'est pas immédiat non plus mais disons que c'est acceptable voir très bien dans la majorité des essais chez moi, 3 stores en parallèle.


Sent from my iPad using Tapatalk

[briss]

@briss. Oki donc si on stop pas la commande ça répond dans les temps sans bloquer le reste du réseau comme, je pensais et bonne nouvelle idem avec un razberry ( tu es bien en razberry ?)

Oui oui c'est bien ça

[alexzen]

Bonjour,
Je pense avoir le même souci avec un fgrmachinarubanled et du coup une queue qui s'allonge.
Je vais test la régénération du noeud pour voir

[flomuson]

J'ai fait des tests hier soir : avec 3 volets, tout est relativement "correcte"... la queue reste à 0 et si je descends mes volets avant la fin, la queue monte à 5/6 mais redescend vite à 0....
Par contre, si je lance mes 7 volets en même temps... c'est la fin des haricots ! là dès la montée, la file d'attente monte à 20 et diminue lentement... très lentement.... et c'est encore pire lorsque que les volets montent et que je les redescends aussitot....
EDIT : bon en fait ca ne le fait pas tout le temps.... donc avec la nouvelle beta ca le fera encore moins...

J'attends de voir ce qui se passera avec la dernière béta

Pour mon fgrgb, j'ai beaucoup d'erreurs d'envoie et de "Node016, ColorRefresh is already in progress. Ignoring Get Request" je trouve et du coup la file d'attente explose .. + 100 et c'est long.... très long (plusieurs minutes) avant de revenir à 0 (par contre lorsque je demande les voisins il répond tout de suite) même après la régénration... je vais essayer de le desincure/inclure... on verra bien...

[briss]

Pour mon fgrgb, j'ai beaucoup d'erreurs d'envoie et de "Node016, ColorRefresh is already in progress. Ignoring Get Request" je trouve et du coup la file d'attente explose .. + 100 et c'est long.... très long (plusieurs minutes) avant de revenir à 0 (par contre lorsque je demande les voisins il répond tout de suite) même après la régénration... je vais essayer de le desincure/inclure... on verra bien...

Je retrouve aussi ces erreur si je demande très rapidement des changements de couleur mais ma queue z-wave n'explose pas (visuellement ne dépasse pas 1).
Comment t'y prends-tu pour obtenir ce phénomène (j'avais déjà constaté des lenteurs suite à la manipulation du RGB mais je n'ai jamais essayé de regarder dans quel cas)

[nechry]

Il y avait anciennement tout les groupes occuper avec alors qu'il faut que le 5. Donc déjà a nettoyer. Ici aussi avec le code actuelle un changement trop rapprocher de couleur peut provoquer une congestion. Ça sera différent dans la prochaine beta.

Dans mon cas je ne change pas non plus non stop les couleurs, j'ai des scènes avec des ambiances de couleur elle sont appliqués.


Sent from my iPad using Tapatalk

[briss]

Moi non plus je ne change pas les couleurs comme ça, c'était juste pour l'essai.
Pour l'association, j'ai déjà corrigé.

[flomuson]

En fait c'est une utilisation "normal".... on essaie de trouver la bonne "couleur" de tous les jours donc on essaie les différentes couleurs, donc forcement on change les couleurs rapidement... ce n'est pas un fonctionnement anormal meme s'il ne sera fait qu'une seule fois...

Et pour infos, lorsqu'on a des invités, la première chose qu'ils essaient de faire c'est de changer les couleurs... au bout de la 2-3eme couleurs ca donne l'impression de ne plus marcher... (et là ils s'en donnent à coeur joie : ca marche pas, c'est pas fiable....).

Disons que ce genre de "fonctionnement" ne donne pas une bonne image de la domotique grand public et donne plutot une impression de quelque chose de pas finie ! (sans parler du coté WAF... ca reste quand même geek)

Je verrai avec la prochaine beta et j'ai quand meme acheté la gen5... je verrai s'il y a une vrai différence (si non je la renvoie )

En tout cas merci pour le boult effectué

[nechry]

Ça ne sera pas encore tit top alors, chaque changement de couleur demande un refresh. Mais dans le cas d'un utilisation normale pour créer des ambiance de couleur sa va fonctionner.


Sent from my iPhone using Tapatalk

[alexzen]

Je regarde de plus en plus les trames du coup et franchement je ne savais pas que le module led de Fibaro causait autant ! il remonte tout le temps sa conso et sa puissance, il faut que je regarde plus pres son paramétrage.
Vous avez un conseil à filer ? (car franchement la conso perso pfff)
D'avance merci.

[nechry]

bon j'ai bien bossé cette après midi sur le refresh en background et c'est vraiment bien maintenant. donc la passage d'une couleur à l'autre sans attente chez moi fonction très bien. spécialement avec l'Ampoule Aeon-labs mais aussi avec le Fibaro. donc ça sera aussi cumulé dans la prochaine béta.

Il me reste encore des travaux pour faire le refresh bout en bout d'un store, c'est donc encore désactivé. j'ai préféré être plus réservé et vous laissez tester. enfin si la beta arrive.

[yogui]

@nechry

est ce que t modif sont dans la derniere beta ?

si non j'ai aussi de gros problemes de latence avec une que qui met plusieurs minutes a ce vider .

[yogui]

Problème résolu jai soigner mon réseau pour la x eme fois depuis ca a laire de le faore