@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:
