Oui le ressenti est mieux, je te redis dans quelques jours.
1 « J'aime »
Bonsoir,
J’aimerai savoir comment est rafraichit le dashboard?
si c’est cycliquement ou c’est si une valeur change d’etat ?
merci
Normalement c’est du live (en cas de changement d’état, c’est propagé au front)
Mais il y a eu des oublis sur certaines boxs sur lesquels ça n’est pas fait, on a déjà des issues github et @AlexTrovato a fait une PR sur le sujet 
Merci @pierre-gilles
Car effectivement, j’ai des fonctions « Etat » Mqtt, qui ne se rafraichissent pas de temps en temps, je suis obliger de relancer la page de dashboard, mais peut être aussi, que je n’attends pas assez longtemps pour que le rafraichissement s’opère sur le dashboard, car le message Telegram associé, lui arrive bien.
Sur quelle box du dashboard ?
Sur une box " Appareils de la pièce"
Ah, c’est pas normal ça. Normalement cette box fonctionne parfaitement.
En local ou sur Gladys Plus le soucis ?
Bonjour @pierre-gilles
C’est en local, je n’ai pas testé sur G+
Je ne comprends pas, j’ai fabriqué un capteur avec 2 fonctions sur un Esp 8266 qui transmets par Mqtt sur Gladys
il y en a une qui réagit correctement, mais l’autre, comme je te dis, envoie bien le message Telegram lors de son changement d’état, mais ne se met pas à jour sur le dashboard et quand je rafraichis la page web (dashboard) l’affichage de la fonction se met a jour . Je vais approfondir les recherches, je te tiens au courant
Désolé pour le temps que tu as perdu.
Salut,
Je voudrais vérifier quelque chose avec vous (et @pierre-gilles).
Lorsque je charge un dashboard, Gladys doit récupérer 100 valeurs depuis la DB pour les afficher ensuite, correct ?
A ma connaissance, cela n’est pas sensé engendrer une grosse charge disque (i/o). Je n’arrive donc pas a m’expliquer l’utilisation de 100% des IO avec un max à 19Mb/sec lorsque je charge un nouveau dashboard.
Preuve en vidéo :
Non pas exactement, ça dépend de l’interval sélectionné
Ici quand tu demandes les dernières 24h, Gladys utilise l’agrégation horaire (100 valeur par heure)
Sur 24h, ça fait que la DB récupère 100 * 24 = 2400 states PUIS rajoute une couche de downsampling dessus côté CPU pour arriver à 100 states envoyé en réponse de l’API.
Sur ton graphique, tu affiches 6 graphiques * 2 features = 12 requêtes * 2400 = 28,8k states récupérés
Donc ce que tu nous affiches ne m’étonne pas dans l’état actuel !
Après on pourrait faire évoluer la façon dont le filtre « 24h » fonctionne pour utiliser l’agrégation quotidienne (100 valeur / jours), après il faut voir comment ça rend, c’est pas dit que ça soit aussi propre qu’actuellement, il faut faire des tests
Edit: ça marcherait pas, cf post suivant ( Dashboard - Evolutions / Bugs / etc - #134 par pierre-gilles )
Aaaaaaaaaaah je comprends mieux !
J’avais retenu que c’était 100x valeurs sur 1h, 24h, 7j, etc.
Mais non en fait l’aggrégation c’est limité à 24h, et ensuite toutes les données sont récupérées puis calculées à la demande comme tu l’a décris.
Donc en effet, rien d’anormal du tout.
Non, tu avais (presque) bien compris !
Je cite l’article de lancement :
- L’agrégation horaire est calculée chaque heure (l’heure précédente est calculée)
- L’agrégation journalière est calculée chaque jour à minuit (le jour précédent est calculé)
- L’agrégation mensuelle est calculée chaque 1er du mois mois à minuit (le mois précédent est calculée)
Sauf que justement, quand on affiche la vue « dernière 24h », imaginons que tu affiches cette vue à 18h, l’agrégation journalière de la journée en cours n’est pas encore prête ( elle sera calculée à minuit ), donc on utilise l’agrégation horaire qui elle est disponible.
Dans mes essais, j’avais essayé de faire un mix en faisant:
Si tu demandes la vue dashboard à 18h:
- Prendre de 18h à 00h de la veille via l’agrégation journalière
- Prendre de 00h à 17h en utilisant l’agrégation horaire
- Prendre de 17h à 18h en prenant les données live
Sauf que ça rend vraiment pas bien, le mix de donnée fait qu’on voit bien sur le graphique les « acoups », c’est vraiment pas propre.
1 « J'aime »
Merci pour la description, expliqué comme ça c’est tout à fait logique.
Au final j’ai édité mes dashboard pour n’afficher que la dernière heure par défaut. Ensuite au besoin je charge les dernières 24h.
Cela me permet de garder une vrai réactivité et d’éviter de surcharger Gladys pendant 10 à 20 sec.
Sinon faut investir @lmilcent
Blague à part un pi c’est peut être un peu juste pour toi non ?
Je te dit ça car j’ai fait le test et je n’ai pas ce problème ( amd64 / ssd)
3 « J'aime »
Trop bruyant désolé
J’ai pu récupérer un mini PC avec SSD, donc oui clairement ça sera beauuucoup plus costaud. Je l’ai installé mais je n’ai pas encore pris (eu) le temps de faire la migration Gladys.
Quand ça sera fait je vous donnerait mon retour d’expérience sur la différence de latence notamment, ça risque d’être flagrant dans mon cas !
Ensuite il me suffira de recycler mes RPi en caméras RSTP par exemple
1 « J'aime »
La c’est clairement le disque qui est le facteur limitant chez toi, tu es sur une carte micro SD ou un SSD je me rappelle plus ?
A 20mo/sec c’est clairement ni du HDD ni du SSD
C’est bien un RPi 4 basique pour le moment.
1 « J'aime »
8 messages ont été scindés en un nouveau sujet : Impossible de cocher la case « Exécuter seulement si la valeur a changée »