@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é ), et m’envoyer une DB où il y a le problème effectivement (ça serait le top pour débugger )
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 :
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
@lmilcent Je viens de regarder ta base de donnée que tu m’as envoyé, et je suis très surpris de son contenu
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:
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
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
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.