Affichage des courbes de capteurs sur le dashboard

Salut à tous!

Je créé cette demande de fonctionnalité malgré le fait qu’elle soit déjà bien avancée pour qu’on puisse en parler ensemble sur le forum et pas juste sur GitHub.

Pour la timeline, @euguuu avait commencé à faire une première spécification technique et avait une première PR dès fin 2020. C’était super complet et niveau recherche il était allé très loin !! :slight_smile:

Néanmoins la PR n’était pas terminée, et je n’étais pas d’accord avec tous les choix techniques qui avaient été fait, j’ai donc commencé à travailler sur une autre PR from scratch basé sur les même recherches, mais avec une implémentation différente.

j’ai commencé à travailler dessus cet été (mi-juillet), et c’était pas un développement simple !

Concrètement, ma spécification pour cette fonctionnalité c’était:

  • Affichage de valeurs de capteurs en moins de 50ms quel que soit le dataset (même 2 millions de valeurs de capteurs)
  • Possibilité de changer la temporalité en live par l’utilisateur du dashboard
  • Une UI super simple et claire.
  • Le pré-calcul en arrière-plan des valeurs de capteurs agrégées ne doit pas ralentir Gladys.
  • L’utilisateur doit pouvoir savoir si ces données de capteurs ont été agrégée ou si quelque chose s’est mal déroulée.

Pour l’instant, ça ressemble à ça:

Le grand défi de ce développement, c’est de calculer en arrière-plan les valeurs de capteurs agrégées, et le faire sans ralentir Gladys, et en communiquant avec l’utilisateur.

Une nouvelle vue apparait donc dans Gladys, la vue “tâches en arrière plan”:

A l’avenir, le but est d’intégrer toutes les tâches en arrière plan (scènes, etc…) à cette vue pour donner plus de visibilité à l’utilisateur sur ce qu’il se passe en arrière plan dans son Gladys.

Ma PR est disponible ici:

Je serais preneur de tout retour @contributors :slight_smile:

Pour donner plus de détails sur l’implémentation technique, il y a désormais 3 types d’agrégations:

  • Agrégations horaires: on garde maximum 100 events par heure
  • Agrégations journalières: on garde maximum 100 events par jour
  • Agrégations mensuelles: on garde maximum 100 events par mois

L’objectif est de pouvoir répondre à des requêtes avec différentes temporalités:

  • Donne moi la température de la dernière années (on utilise les données mensuelles)
  • Donne moi la température des 10 dernières minutes (données lives)
  • Donne moi la température des 2 dernières semaines (journalières)

Qu’en pensez vous?

@Terdious Si tu as un peu de temps (à toi de me dire :p) ça serait cool qu’on test ça chez toi avant que je merge, tu en pense quoi ? :slight_smile:

1 Like

Avec grand plaisir !! On va trouver ce temps !!^^
On peut déjà la tester ??
Côté temporalité (^^) tu attends des retours pour quand maxi ?

@Terdious Oui tu peux tester, la branche est dans un état qui marche !

Quand tu veux, je ne déploierai que si des gens l’ont testé avant, donc le plus tôt le mieux :slight_smile:

1 Like

J’ai fait un premier feedback sur github.

J’ai repris ma db de prod mais je n’ai que 24 h de data et je ne sais pas pourquoi.

Merci pour le feedback super complet @VonOx !

Tu es sûr que l’agrégation s’est bien passée, pas normal que tu n’ai que les dernières 24h

Tu as les logs?

En fait c’est sur ma db de prod ( device_state ) que je n’ai que 24H

Tu as du configurer ta DB de prod pour qu’elle ne sauvegarde que 24h de data

Il y a une variable qui défini le temps de rétention

(ça me fait penser qu’on ne l’expose nul part cette variable, il faut que je l’affiche quelque part)

1 Like

Je t’avoue que je sais pas trop comment je me suis retrouvé avec ça ^^
image

J’ai repassé la valeur à 90

Moi je viens de regarder pour tester ton intégration, globalement sur le fonctionnement / ui pas de soucis. J’ai pas vraiment pu tester ton intégration car mon instance de prod n’a aucune donnée en BDD. En gros il existe uniquement les dernières données. J’ai rien touché de particulier à mon instance de prod …

Pour c’est un capteur xiaomi intégré via zigbee2mqtt

Je cherche pourquoi il stocke pas plus de données …

keep_history à un … J’ai l’impression qu’il y a un bug …

Ah pareil ! Je c herchais ou était cette valeur

2 personnes qui ont la même chose bizarre :smiley:

Oui je cherchais aussi sur l’UI et si d’autres ont ce soucis ça pourrait être intéressant de l’afficher

Bizarre tout ça, je vais enquêter :slight_smile:

Et oui clairement il faut afficher la valeur dans l’UI maintenant qu’on utiliser l’historique

Pour information, @VonOx m’a fait un premier retour sur Github, auquel je viens de répondre ici: Add the ability to vizualize device states on the dashboard by Pierre-Gilles · Pull Request #1248 · GladysAssistant/Gladys · GitHub

Plein de bon retours, autant des bugs que des améliorations pratiques pour que la fonctionnalité soit vraiment utile pour l’utilisateur final.

C’est d’ailleurs ce genre de retour qui m’intéresse plus, je veux que vous disiez si selon vous c’est une fonctionnalité utile et utilisable, ou si il manque des choses.

L’objectif c’est d’avoir un truc en même temps:

  • Très design
  • Configurable et flexible comme un Grafana
  • Mais très facile à utiliser, et avec des valeurs par défaut qui mâche le travail et qui donne un bon rendu sans trop de configuration.

Du coup je vais améliorer ma copie et essayer de proposer une deuxième itération corrigée :slightly_smiling_face:

2 Likes

Petite preview de sur quoi je bosse depuis ce matin, un affichage clean des erreurs dans la vue “tâches en arrière-plan” ! :slight_smile:

J’ai toujours été contre l’affichage des logs pures dans l’UI (car on sait ce que ça donne, ensuite on est flemmard et on fait des intégrations où on demande aux gens d’aller chercher des IDs dans les logs :joy:), en revanche je suis pour une vue de ce style, où:

  • Toutes les erreurs connues sont traduites, et la marche à suivre est clairement expliquée pour l’utilisateur. Exemple ici avec une erreur simple: Gladys a redémarré alors qu’une tâche tournait: c’est un comportement normal, et il faut le préciser.
  • Pour les erreurs inconnues, on l’affiche telle quelle pour que l’utilisateur puisse nous faire un retour, ensuite deux solutions:
    • C’est un bug, on corrige le bug
    • C’est une erreur qui peut arriver dans certains conditions (pas un bug): Exemple “OUT_OF_MEMORY”/“DISK FULL”, etc… Dans ce cas, on ajoute cette erreur à la liste d’erreur traduite, avec un message clair, et avec une marche à suivre pour résoudre l’erreur.

Voilà à quoi ressemble la vue pour l’instant:

Vous en pensez quoi ? :slight_smile:

1 Like

On est le matin :smirk:

C’est clair car l’erreur est contextualisee par rapport à la tâche.

Un accès au log complet pourrai être un plus ( ça évite à l’utilisateur de faire du ssh) mais c’est un autre sujet.

1 Like

:joy:

C’est l’erreur complète.

Dans le cas de l’agrégation des capteurs, comme Node.js est single thread, je voulais pas bloquer le thread Gladys principale, et donc l’agrégation est faite dans un worker séparé.

Le log qui est affichée là est le log d’erreur complète envoyée par le worker, donc il n’y a rien de plus à aller voir en SSH :slight_smile:

Dans tous les cas, normalement il ne devrait pas y avoir d’erreur. J’ai ajouté ça justement pour qu’on soit prêt le jour où on pousse une bêtise, ou le jour où quelqu’un avec une énorme DB se prend une limitation technique de sa machine (comme ça on le voit), mais normalement ce cas ne devrait pas arriver très fréquemment.

1 Like

Je parlais plus du log général, là tu le cas des tâches background.

Mon idée c’était plutôt pour tout ce qui est services etc…
C’est pour ça que je disais que c’était un autre sujet.

1 Like

La next step pour moi, et c’est une tâche en arrière plan, c’est d’ajouter l’exécution des scènes à cette vue.

L’objectif c’est de pouvoir voir ce qui s’est passé:

  • Pourquoi un trigger a été validé ? Ou pas ?
  • Le plan d’exécution de la scène, et les différentes conditions validée / ou pas

Après ça sera hors de cette PR.