Ce matin, sur 2 Jeedom différents ayant la V3 (3.0.19), j’ai une erreur d’historisation des données TX et RX.
0000|[2024-10-20 05:00:07] ERROR : Erreur l'archivage des historiques : {"cmd_id":"5889","archivePackage":3600,"archiveTime":"2024-10-20 03:00:04"} => [MySQL] Error code : 22003 (1264). Out of range value for column '(null)' at row 1 : REPLACE INTO historyArch(cmd_id,`datetime`,value) SELECT cmd_id,MIN(`datetime`),avg(CAST(value AS DECIMAL(12,2))) as value FROM history WHERE `datetime` <= :archiveTime AND cmd_id=:cmd_id AND `value` IS NOT NULL GROUP BY UNIX_TIMESTAMP(`datetime`) DIV :archivePackage
0001|[2024-10-20 05:00:07] ERROR : Erreur l'archivage des historiques : {"cmd_id":"5890","archivePackage":3600,"archiveTime":"2024-10-20 03:00:04"} => [MySQL] Error code : 22003 (1264). Out of range value for column '(null)' at row 1 : REPLACE INTO historyArch(cmd_id,`datetime`,value) SELECT cmd_id,MIN(`datetime`),avg(CAST(value AS DECIMAL(12,2))) as value FROM history WHERE `datetime` <= :archiveTime AND cmd_id=:cmd_id AND `value` IS NOT NULL GROUP BY UNIX_TIMESTAMP(`datetime`) DIV :archivePackage
Pas sûr que le soucis vienne du plugin pour le coup, mais plutôt de jeedom et de son stockage en base de données des valeurs archivées.
Je m’explique : sous Linux, l’unité pour le trafic réseau est en octets, et si on atteint les centaines de giga de trafic (ce qui n’est pas étonnant), le nombre retourné dépasse les 12 chiffres, et visiblement c’est la limite qu’à décidé de mettre jeedom dans les tables d’archivage pour le type DECIMAL (je dis « décidé » car la limite théorique est de mémoire de 65 chiffres pour les decimal)
Je pourrais présenter ces nombres en Ko au lieu d’octets mais cela ne ferait que reculer le problème à plus tard lorsque certains atteindront le Teraoctet de trafic
Il faudrait voir pourquoi jeedom a mis cette limite et s’il est possible de la changer pour prendre en compte ces grands nombres.
@Loic si tu passes par là, tu pourrais sûrement nous en dire plus ? sur le pourquoi du comment ou bien s’il y a une autre manière de faire pour stocker ces grands nombres ?
Bonjour,
Le 12 c’est la limite par defaut de mariadb, je pourrais l’agrandir mais j’ai peur des consequences :
plus de place pris par la table qui est deja la plus grosse de jeedom
plus de temps de traitement (car plus de chiffre)
Le mieux dans ton cas c’est de passer en mo par exemple avec 2 chiffre après la virgule ca devrait permettre d’etre assez precis de pouvoir atteindre le po.
Aujourd’hui, tout le monde est sur des débits relativement conséquents. Donc, une unité en Mio n’est pas déconnant.
Je vais tester en divisant la valeur au niveau de la commande pour voir comment ça se comporte.
Edit : Toujours en erreur malgré la division. La DB doit prendre la valeur d’origine.
Je vais tester en Mo avec deux chiffres après la virgule, c’est une bonne idée, et en effet tu l’as deviné, le but est de garder une bonne précision, en Mo ça devrait aller vu en effet les débits et échanges réseaux que l’on a aujourd’hui.
Merci à tous les deux pour vos avis, je sortirai une nouvelle version dans la journée avec ce changement pour valider que c’est mieux.
la version v3.0.22 béta (disponible sur le market) intègre donc le changement d’unité
Mais pas que pour le trafic réseau, également pour tous les HDD (y compris ceux de Syno), la mémoire et le swap, car en regardant les valeurs que j’ai chez moi, pour certaines j’étais très proche de la limite, voir dépassée.
Mais également pour avoir une cohérence dans les unités des différentes commandes : tout le monde sera en Mo donc maintenant.
J’ai ajouté dans le code, à la mise à jour du plugin, une fonction qui va changer les unités automatiquement pour toutes les commandes existantes, donc besoin de rien faire, le code s’en charge
Par contre ATTENTION : à la prochaine mise à jour des équipements, les nombres récupérés seront dans les nouvelles unités, donc les historiques existants seront totalement faussés !!!
Donc il faudra, pour rester cohérent, supprimer les historiques de ces commandes
Je dirais même que c’est obligatoire.
Je viens de tester est tout fonctionne parfaitement.
Mais à condition de vider l’historique sinon l’erreur d’archivage revient puisque les valeurs bloquantes sont toujours présentes.
On parle de moins de 36 heures depuis la publication de la v3. Ca devrait être supportable
