J3R3M Posté(e) le 12 février 2019 Signaler Posté(e) le 12 février 2019 (modifié) Bonsoir à tous, Plusieurs mois après mon post cherchant à comprendre un peu plus en profondeur le comportement de la HC2 dans certains cas, on avait mis en évidence que mes scènes étaient certainement en cause pour expliquer certaines lenteurs. Je suis quasiment reparti de zéro pour mes scènes principales afin que ce soit plus clair et plus réfléchi, puisque des options avaient été rajoutée par-ci par-là avec le temps. Il n'y a pas de changement flagrant de vitesse d'exécution par rapport aux versions précédentes, mais les codes sont plus propres et, même si ça m'a pris pas mal de temps, c'est quand même mieux et j'ai tenu compte de ce que j'avais appris dans le post ci-dessus. J'en ai également profité pour faire une étude des réactions de la HC2 en fonction des triggers, via des scènes de tests et un VD pour analyser les résultats. Le but de cette "étude" était de comprendre pourquoi, dans certaines situations, une scène s'exécutant habituellement très rapidement mettait plus de temps dans certains cas, souvent lorsque son trigger n'avait pas été sollicité depuis un moment. La Démarche - Mes scènes de pièces peuvent être exécutées par deux types de Triggers : les FGMS001 et certaines Variables Globales (dont la valeur est modifiée par des caméras IP). - À la fin de mes scènes de Pièces, je mettais à jour une Variable Globale "LastMove_NomPiece" afin de remonter le timestamp après exécution de la scène - J'ai créé des scènes démarrées uniquement par un trigger et ce, pour chaque trigger. Cette scène mettant uniquement à jour une Variable Globale "LastTrigg_NomPiece" - Enfin, j'ai créé un VD qui triait les Timestamp de LastMove_***, LastTrigg_*** et surtout, l'information device.LastBreached de chaque Device physique Les Résultats - Bonne nouvelle! Les valeurs dde LastMove_*** et LastTrigg_*** étaient bien souvent les mêmes. Au pire, elles varient d'une seconde, ce qui est largement acceptable vues les vérifications et actions effectuées - Il y a rarement de latence lorsque le trigger est une Variable Globale. Mais cela arrive quand même quelques fois. - Etrangement, la valeur device.LastBreached est souvent la même que LastTrigg_***. Cependant et sans pouvoir l'expliquer, j'ai déjà eu des écarts de plus de 45s. Et là, c'est très long. Le Bilan Et bien, il me paraît évident qu'il y a un problème au niveau des triggers des scènes! Un peu comme si quelque chose ralentissait/empêchait parfois la communication entre le device et la box. Ce qui pourrait expliquer que l'information LastBreached soit bonne et que le détection se fasse plus tard, lorsque la HC2 reçoit l'information. Pourtant, le maillage a été refait puisque des modules avaient changé de place. Des modules qui passaient par d'autres modules pour contacter la HC2 le font désormais directement, tandis que c'est l'inverse pour d'autres. Peut être avez-vous d'autres hypothèses ? Pour le coup, je pense avoir écarté le problème venant de mes scènes. J'ai effectué ces tests pendant quelques jours et je n'ai pas pu mettre en évidence de relation entre ces différentes lenteurs, mis à part le fait qu'elles survenaient généralement lorsque le module n'avait pas été sollicité depuis un léger moment. De plus, ces lenteurs ne sont absolument pas automatiques... Je pense avoir fait un travail d'analyse correct. Cependant maintenant, je m'en remets à vous Qu'en pensez-vous ? Avez-vous une idée qui me permettrait de régler ce léger soucis ? Modifié le 13 février 2019 par J3R3M
pepite Posté(e) le 13 février 2019 Signaler Posté(e) le 13 février 2019 Il y a 11 heures, J3R3M a dit : De plus, ces lenteurs ne sont absolument pas automatiques... Et là c'est le drame pour le debug ;-) : l'aléatoire....
J3R3M Posté(e) le 13 février 2019 Auteur Signaler Posté(e) le 13 février 2019 Je suis tout-à-fait d'accord. C'est d'ailleurs le plus embêtant pour n'importe quel dépannage :-/ Ce matin, j'ai eu un temps record de plus d'une minute entre le déclenchement de la scène et le LastBreached du module. Ça commence à faire long dans le noir!
J3R3M Posté(e) le 13 février 2019 Auteur Signaler Posté(e) le 13 février 2019 Petite mise à jour : j'ai constaté avoir un léger délai lorsque le trigger était une caméra (donc une Variable Globale), dans de rares cas. Visiblement, le problème ne viendrait donc pas uniquement des FGMS-001, mais plus généralement de tous les triggers de scènes. Un peu comme s'il fallait parfois un peu de temps à la HC2 pour déclencher les scènes associées à leurs triggers. Néanmoins lorsque le trigger est une Variable Globale, cela reste néanmoins léger, même si cela a mis une dizaine de secondes (il y a quelques instants), cela reste beaucoup que la minute de latente que j'ai eu ce matin sur un FGMS-001.
pepite Posté(e) le 13 février 2019 Signaler Posté(e) le 13 février 2019 Je veux bien te croire 1 min dans le noir, surtout s'il y a des escaliers ;-) heuuuu Il est clair dans tous les cas que de passer par la box pour les scènes est plus long qu'en association directe. Ne peux tu pas mettre 1 ou 2 FGMS en association directe pour la lumière au moins ? Mais dans ce cas faut dire adieu aux conditions :-( mais très peu de latence.
jojo Posté(e) le 13 février 2019 Signaler Posté(e) le 13 février 2019 Il y a 1 heure, pepite a dit : Il est clair faux, il fait noir s'il n'y a pas de lumière le soir 2
J3R3M Posté(e) le 13 février 2019 Auteur Signaler Posté(e) le 13 février 2019 Il y a 2 heures, pepite a dit : Ne peux tu pas mettre 1 ou 2 FGMS en association directe pour la lumière au moins ? Mais dans ce cas faut dire adieu aux conditions :-( mais très peu de latence. C'est un sujet qui avait évoqué avec Lazer. À mon sens, l'association directe n'a aucun intérêt dans une installation domotique. Il y a bien d'autres solutions moins coûteuses pour qu'une lampe s'allume à la détection d'un mouvement. Effectivement, dire adieu aux conditions n'est pas envisageable dans ma situation, un paquet de vérifications sont effectuées lors de la détection d'un mouvement, ainsi que différentes actions en fonction de la pièce dans laquelle le mouvement a été détecté Il y a 2 heures, jojo a dit : faux, il fait noir s'il n'y a pas de lumière le soir Mon autre personnalité est triste de ne pas me l'avoir faite, celle-ci!
GCaster Posté(e) le 13 février 2019 Signaler Posté(e) le 13 février 2019 Salut @J3R3M, et les autres, Je rencontre le même problème que toi. J'ai cru un temps que la cause était liée à ma HC2, puis j'ai pris un bon petit PC que j'avais sous le pouce, je lui ai clapé un Domoticz et une clé ZWave USB, j'ai mis dessus 4 périphériques (inutile de dire que quand ça marche c'est fluide!! ) mais là PAF (le chien) : j'ai parfois -rarement mais parfois- exactement le même comportement sous Domoticz. Donc la cause n'est pas la box HC2! Déjà très intéressant à savoir!! Du coup, j'ai fait d'autres recherches (j'ai d'ailleurs posé la question sur ce forum mais seul l'écho m'a répondu ou à peu près ... sans rancune aucune les gars, je sais que c'est pas évident ... Et puis la réponse est peut-être quelque part et si ça tombe c'est moi qui cherche mal ...) et il semblerait que ce soit un problème de saturation du réseau ZWave qui provoque ça, je l'ai déduit suite à un échange avec le service technique Fibaro (genre je réponds après 10 minutes, ils répondent après trois semaines, forcément à ce rythme pour avoir une conversation un peu fournie ça prend vite 2 mois...). Seulement voilà : je n'ai aucun outil pour analyser cette saturation, et si je soupçonne franchement (une ou plusieurs de) mes FGT-001 d'en être la cause, j'avoue que c'est très pénible comme recherche. Ca prend la blinde de temps et ça donne juste envie de tout jeter par la fenêtre. Bon courage pour tes recherches et si quelqu'un connaît un outil d'analyse du trafic réseau ZWave je suis preneur!
J3R3M Posté(e) le 14 février 2019 Auteur Signaler Posté(e) le 14 février 2019 (modifié) Salut @GCaster, Il y a 6 heures, GCaster a dit : Déjà très intéressant à savoir!! En effet!! Il y a 6 heures, GCaster a dit : j'ai d'ailleurs posé la question sur ce forum mais seul l'écho m'a répondu ou à peu près ... sans rancune aucune les gars, je sais que c'est pas évident ... Et puis la réponse est peut-être quelque part et si ça tombe c'est moi qui cherche mal ... Aucun soucis, cela m'arrive et arrive à d'autres également. En fait, Home Center est devenu, bien que toujours performante, un système vieillissant. Un système qui a eu son heure de gloire et qui a perdu pas mal de parts de marchés en faveur de Jeedom, pour ne citer que celui-ci. Les plus résistants ont combiné Jeedom à Home Center. Je dis cela pour exprimer simplement que la puissante communauté qui a pu exister il y a quelques années (et que je n'ai pas connu) n'est plus forcément présente et que les problèmes les plus subtiles ne trouvent pas forcément réponse. Il y a 6 heures, GCaster a dit : genre je réponds après 10 minutes, ils répondent après trois semaines, forcément à ce rythme pour avoir une conversation un peu fournie ça prend vite 2 mois... Ahhhh, bienvenue en 2019, la technologie d'internet rapproche les gens, mais pas les délais de réponse! Il y a 6 heures, GCaster a dit : Seulement voilà : je n'ai aucun outil pour analyser cette saturation À ce jour, il ne me semble pas que cet outil existe, mais c'est une piste à suivre effectivement. Il y a 6 heures, GCaster a dit : Bon courage pour tes recherches et si quelqu'un connaît un outil d'analyse du trafic réseau ZWave je suis preneur! Merci à toi de ton intervention, celle-ci est très intéressante et fait avancer la problématique, sans le moindre doute. De cela me vient une réflexion basique, mais n'aurait-on pas une configuration des modules peu ordinaire? As-tu changé la configuration et les paramètres de tes modules en les passant d'un système à un autre? De mon côté, j'ai effectivement changé les paramètres d'origine, sans avoir mis un taux de réveil de fou, ni une remontée hyper régulière, mais il peut être intéressant d'échanger sur ces paramètres, ne serait-ce que pour mettre en valeur, ou, au contraire, mettre de côté cette éventualité de mauvais paramètres réglés. Modifié le 14 février 2019 par J3R3M
GCaster Posté(e) le 14 février 2019 Signaler Posté(e) le 14 février 2019 Hello! Non, aucun paramètre particulier sur les modules réinstallés. D'aillleurs en les réinstallant j'ai fait un reset (d'autant que je ne savais plus à ce moment supprimer des modules de ma HC2, entretemps le service technique s'est connecté pour arranger ça). Par contre, mais là je m'aventure sur une piste que je ne saurais vérifier dans l'état actuel de mes connaissances, je me dis que si le réseau ZWave est saturé, puisqu'il s'agit d'une longueur d'onde, il serait tout à fait possible que des modules liés à la HC2 fassent saturer le réseau, et que ça ait des incidences sur les communications de Domoticz? A nouveau si quelqu'un de plus calé que moi me lit, ce serait cool d'infirmer ou confirmer mon idée! Par contre, pour les modules en place côté HC2, j'ai certainement à droite à gauche un paramètre où il était écrit "touche pas à ça p'tit c**" et où j'ai cliqué quand même... Difficile de trouver lequel, mais au risque de me répéter, je soupçonne fortement les FGT-001 que j'ai manifestement achetées trop tôt au vu du nombre de problèmes qu'elles m'ont déjà causés. ++
Messages recommandés