yves.guern Posté(e) le 5 mai Signaler Posté(e) le 5 mai (modifié) DomoCharts+ Version 2.0 J'utilise LE domocharts de Lazer (cf DomoChartsV7) avec bonheur depuis un moment déjà. J’ai fait quelques personnalisations qui peuvent en intéresser d’autres, je partage donc ici. PRESENTATION: Dans les grandes lignes les personnalisations sont : Une librairie de fonctions complémentaires à domoCharts.lua dont la plus intéressante est un filtre qui n'envoie vers la DB que les données qui ont changé depuis le dernier envoi vers la bas de donnée. J'obtiens ainsi une 'compression' de 70% de la taille des envois et donc de la base. Côté serveur, j'ai modifié trend.php pour que certaines données soient aussi moyennées heure par heure. Il me semble en effet que les données brutes représentent une quantité de données trop importante pour être raisonnablement conservée (et utilisable) sur une longue période mais que la moyenne journalière n’est souvent pas assez détaillée. J'ai interfacé "un autre highcharts" que je connaissais du boulot (fusioncharts). Le principal avantage que j'ai trouvé est de pouvoir définir des groupes de données (constitués d'ensemble de capteurs en BdD) à afficher selon 1 ou plusieurs axes Y. Les groupes sont définis dans un fichier json essentiellement par des listes de nom de capteurs. Les deux premiers points (qui ne sont pas aussi indépendants que cette introduction peut laisser entendre) sont suffisamment mûrs pour être partagés ici mais ce n’est pas encore tout à fait le cas du dernier. Pour le moment, j’ai juste fait en sorte que l’interface avec HighCharts puisse accepter des données moyennées sur une heure. INSTALLATION : Il ne s’agit là que de modifications légères du code original ! Le post initial (DomoChartsV7) doit être lu avant d’aller plus loin : il reste une référence pour l’installation et le ‘paramétrage’ de base. Bien sûr, si vous aviez la version précédente, des sauvegardes s’imposent : la FQA, le dossier domocharts/ sur le serveur et la base de donnée… Comme pour domochart, l’installation peut se faire · ‘sur une page blanche’ avec un fichier ‘.fqa’ pour la Box et un ‘.zip’ pour la partie serveur, · ou comme s’il s’agissait d’une mise à jour : à l’aide de fichiers indépendants remplaçant ou complétant ceux qui existent. Dans les deux cas il semble logique de continuer à utiliser la même base de données, mais on peut tout à fait repartir d’une neuve en donnant un nom différent dans config.inc.php. Le fichier joint readme.pdf donne plus de détails sur l'installation de 'la chose' et de ce qu'elle fait. FICHIERS JOINTS : Installation complète : FQA pour HC3:QA_DomoCharts+V2.0.fqa ZIP pour le serveurdomocharts+V2.0.zip Mise à jour de la QA : la librairie:DomoAddsLibV2.0.lua le 'main' modifié:DomoChartsModifieV2.0.lua Mise à jour du serveur : les fichiers modifiés côté serveur:DM+MajSvrV2.0.zip Notes : Ce que fait la QA (et son paramétrage) :DomoChart+Manuel.pdf Synthèse façon ‘readme.txt’ sur les différents éléments et l’installation :readme.pdf Modifié le 5 mai par yves.guern 3
jojo Posté(e) le 5 mai Signaler Posté(e) le 5 mai Whaw merci pour le partage. J'y regarderai à mon retour (je vais me fageller pour ne pas faire ces modifs avant !) Mais question (avec moi, il y en a toujours). Quand on implémentera les modifs, fera-t-il les moyennes horaires sur l'existant ou uniquement sur les nouvelles sonnées ? (je n'ai pas encore regardé) mais j'imagine que pour toutes les tables existantes il y aura en plus une table _hour, qui viendra à côté des tables _day (et _month quand elle existe). Est-ce que le moyennes horaires sont conservées "indéfiniment" ou sont supprimées après un certain temp ? Autre demande que j'avais en suspend : Serait-il possible de créer une table avec du On/Off : on pourrait ainsi historiser quand un lampe est allumée, ou un detecteur enclanché, .... Qu'en penses-tu ?
yves.guern Posté(e) mardi à 05:41 Auteur Signaler Posté(e) mardi à 05:41 (modifié) Bonjour Jojo Il y a 12 heures, jojo a dit : Mais question (avec moi, il y en a toujours). Le fichier Readme.pdf répond à tes questions, (les réponses sont globalement positives avec 'subtilités') Pour les On/Off : Oui ce serait possible mais je ne suis pas loin de penser comme Lazer: "pour quoi faire"?, "comment représenter"?,"que fait-on des changements brefs"?, ... Au début moi aussi j'en avais envie et puis j'ai mis cela de côté... Et toi qui cherche (ou va chercher ) à diminuer la taille de ta base, les On/Off ne vont pas du tout dans le bon sens: Un enregistrement d'une donnée 'binaire' devrait coûter 32 octets/pièce [contre 37octets/pièce pour une température (pourtant enregistrée en 'flottant')]. A priori ton installation comporte plus de On/Off que de capteurs de température, on ne va donc pas du tout dans le bon sens! 50 émetteur/receveur binaires c'est 2.5Mo/jour de données brutes dans la base! => On court à la catastrophe, sauf à ne sélectionner que très peu de devices ce qui revient à répondre (et de façon très raisonnable) aux questions de Lazer ci-dessus... Bonne journée Modifié mardi à 05:42 par yves.guern
yves.guern Posté(e) mardi à 06:47 Auteur Signaler Posté(e) mardi à 06:47 Suite à mon message ci-dessus et pour avoir quelques ordres de grandeur en tête, j'ai calculé l'encombrement des tables de domochart pour une installation avec 100 capteurs: J'ai utilisé 37octets par donnée pour les tables brutes et 47 pour les tables moyennées (il y a au moins 2 valeurs de plus/enregistrement pour ce type de table ). On y voit bien l'intérêt (ou la contrainte) qu'il y a à effacer les vielles données 'brutes' et le compromis intéressant qu'offre la table des moyennes horaires.
jojo Posté(e) mardi à 16:43 Signaler Posté(e) mardi à 16:43 Il y a 10 heures, yves.guern a dit : Le fichier Readme.pdf je m'interdit de le lire avant de partir, car sinon ce sera trop difficile de ne pas l'implémenter. pour le ON/OFF : je suis très surpris qu'une valeur binaire(0 ou 1) consomme 32 octets alors qu'une température (175.95) n'en consomme que 37. Avec 1 octet on peut chiffrer de 0 à 7 ? mon utilisation : savoir si une lampe est On, ou quand porte ouverte ou fermée, quand chauffage, ... évidemment, les moyennes /h , /j ça n'a aucun sens, sauf qu'on pourrait agréger avec la somme des changements sur la période Il y a 10 heures, yves.guern a dit : 2.5Mo/jour ça fait peur, ça décourrage
yves.guern Posté(e) mardi à 19:00 Auteur Signaler Posté(e) mardi à 19:00 (modifié) Le 06/05/2025 à 18:43, jojo a dit : ça fait peur, ça décourrage Mais non ça fait juste réfléchir sur le rapport qualité/prix !!! 37octets pour une température cépamoikildi c'est phpMyAdmin... (voir l'onglet structure,de chaque table, en bas à droite) Avec chaque valeur de température (par exemple) l’enregistrement contient id : index d'enregistrement, on va dire que c'est pour la cuisine interne de MySql device_id: pour savoir où est-ce qu'il a fait aussi chaud que ça? time: quelle heure etait-il? value (enfin): kombien y faisait chaud? et il faut ajouter les index (qui représente plus de 60% de la taille) Primary device_time autres (parfois...) On en 'déduit' qu'en gros les trois premiers items et les deux derniers coûtent ~30 octets. Surtout il ne faut pas pleurer: ce sont eux qui permettent de retrouver/trier les autres !! Modifié jeudi à 05:37 par yves.guern 1
Messages recommandés