Help! Problème avec l'agrégation?

@lmilcent J’avoue que j’avais complètement zappé ce bug! Je n’arrive pas à le reproduire chez moi, au vu de tes logs ça ressemble à un jeu de donnée particulier qui fait crasher la lib de downsampling qu’on utilise (downsample sur npm)

Est-ce que tu pourrais créer une issue GitHub sur le repo Gladys (sinon dans 10 minutes j’ai oublié :stuck_out_tongue: ), et m’envoyer une DB où il y a le problème effectivement (ça serait le top pour débugger :slight_smile: )

Merci !

@lmilcent Merci! J’ai édité le titre de l’issue. (le bug NaN c’est un autre bug, rien à voir :slight_smile: )

Même erreur de mon côté, concernant l’agrégation, pour ma part ça semble provenir des données issus des cryptos (le Shiba) qui est toujours en dessous de 0, je me demande si ça ne vient pas du nombre de décimal prise en compte dans le calcul qu’utilise la bibliothèque pour faire son aggrégation :

Cela fonctionne sur la dernière heure car je récupère les infos toutes le 5 minutes (donc surement pas d’agreg) mais pas sur la journée ou le mois.

Merci pour ton message @Albenss , je pense que certaines agrégations ont pu planter à cause d’un cas similaire.
Par exemple mon device mqtt pour gérer la présence recevait “present” avant de recevoir “1” maintenant.

Mais ça fait plusieurs mois que j’ai fait le changement déjà, et toujours des échecs.

D’une manière générale, l’erreur devrait être plus précise :innocent:

@lmilcent Je viens de regarder ta base de donnée que tu m’as envoyé, et je suis très surpris de son contenu :smiley:

Tu as des device_feature_state dont la value est “NaN” (Not a Number). C’est super étrange que ce se soit inséré d’ailleurs, vu que le champs est un “double precision”, et “NaN” n’est pas un double precision…

Forcément, ça fait crasher l’aggrégation qui attend des valeurs numériques, pas un string.

Après enquête, ces valeurs proviennent de l’intégration Zigbee2mqtt.

J’ai créé une issue GitHub pour qu’on fixe le problème:

  • Rajouter une migration DB pour cleaner ces lignes qui ne devraient pas être là
  • Voir pourquoi la validation et la DB ont accepté ces valeurs qui ne sont pas des Number.

En attendant, @lmilcent et @Albenss, la query SQL pour fixer vos DBs est:

DELETE FROM t_device_feature_state WHERE value = 'NaN';

@lmilcent De manière plus générale, je ne sais pas si tu tiens à toutes tes données historiques de capteurs (tu les garde toutes), mais je te conseillerais de faire un clean sur certains deviceFeatures très verbose, car actuellement pour faire l’agrégation sur mon Mac, certains capteurs contenait tellement de valeurs que ça prenait plus de 1.5 Gb de RAM pour faire l’agrégation totale (vu que comme c’est une première agrégation, ça commence du début. Ce sera pas le cas par la suite)

Sinon, en enlevant les NaN, ça marche très bien chez moi sur ta DB:

1 « J'aime »

J’ai lancé la suppression des valeurs incorrectes. Je vais voir pour les autres équipements qui sont verbeux… Fonction à prévoir ? :wink:

Tu veux dire une fonctionnalité pour supprimer des anciennes valeurs de capteurs par capteur ?

Oui exactement, une fonctionnalité pour permettre à chacun de décider s’il souhaite supprimer tout l’historique à certaines dates, conserver ou non les valeurs agrégées à ces dates là, etc.

Ma DB fait déjà 2.8Go, ça commence à prendre de la place :wink:

Une solution pour toi déjà, tu peux mettre une durée maximum de rétention dans les paramètres:

Si tu mets « 3 mois », ça va virer déjà tout ce qui est plus vieux (toutes les 4h, Gladys clean les vieilles valeurs)

Après effectivement une manière de purger par device pourrait être intéressante

Tu créé une demande de fonctionnalités ? :slight_smile:

Pour le moment, comme on ne peut pas nativement consulter l’historique, je vais faire ça, mais est-ce que ça supprime aussi l’aggrégation ?
Car j’aimerais pouvoir garder l’affichage sur un an dans les dashboard.

C’est fonctionnel ! Par contre, Gladys a du mal à répondre pendant l’aggrégation j’ai l’impression, qui a pris 21 minutes pour les valeurs journalières.

Vu que toi l’agrégation n’est pas calculée à cause du bug, ça va tout virer (vu que l’agrégation n’a pas été faite, tu n’as que les données brutes)

Dans ton cas, je pense que ça vaut le coup d’aller en DB supprimer les deviceFeatureState trop verbose.

Tu peux faire cette requête pour voir les features les plus verbose:

SELECT COUNT(id), device_feature_id
FROM t_device_feature_state
GROUP BY device_feature_id
ORDER BY COUNT(id) DESC;

Pour info j’ai fais tourner cette query sur la DB que tu m’as envoyé, et tu as plusieurs features avec des states en millions.

Ensuite tu fais:

DELETE FROM t_device_feature_state WHERE device_feature_id = '';

En remplaçant avec les ids que tu veux virer.

Vu que c’est ta première intégration, si ton Pi n’a pas beaucoup de core (ou un disque trop lent), c’est possible que ça ralentisse Gladys lors de la première agrégation.

Normalement c’est pas bloquant (c’est un process à part), mais bon forcément la première agrégation prend pas mal de ressources :slight_smile:

En effet, c’est possible. Mais pourquoi mes graphiques fonctionnent quand même sur toutes les périodes dans ce cas ?

Pourquoi ils ne fonctionneraient pas ? Je te suis pas :smiley:

Ton agrégation a l’air d’avoir fonctionné, tu as donc accès aux valeurs sur les graphiques

Tu parles de “première agrégation”, donc sans données agrégées comment sont affichés les graphiques ?
Si j’ai bien compris d’après toi mes données n’étaient jamais agrégées (ou pas totalement), ce qui pour moi devrait se traduire par “pas de graphique”.

Enfin bref, désormais c’est résolu ! L’agrégation est fonctionnelle sur le mensuel et le journalier ! Merci beaucoup pour ton investigation.

Exactement, normalement tu ne devais pas avoir de graphique sans agregation, à part le graphique « dernière heure » qui utilise les données live

C’est d’ailleurs ce que j’ai constaté sur ta base que tu m’as envoyé, sans agregation les graphiques ne fonctionnaient pas !

Et bien détrompe toi, j’avais des graphiques sur toutes les périodes : dernières données, 24h, 7j, 30j :slight_smile:

C’est donc que l’agregation avait fonctionné en partie :slight_smile: Sans agregation de toute façon ces vues ne fonctionnent pas

A post was split to a new topic: Statistiques utilisation containers en CLI