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 serveur domocharts+V2.0.1.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.1.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 16/05/2025 : Pour ceux qui utilisent une table 'energy': il y a 2 erreurs de syntaxe dans configPlus.inc.php et dans data.php. corrigées par la version 2.0.1 (cela ne concerne que le serveur) Modifié le 16 mai par yves.guern Correction bug => V2.0.1 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) le 6 mai Auteur Signaler Posté(e) le 6 mai (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é le 6 mai par yves.guern
yves.guern Posté(e) le 6 mai Auteur Signaler Posté(e) le 6 mai 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) le 6 mai Signaler Posté(e) le 6 mai 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) le 6 mai Auteur Signaler Posté(e) le 6 mai (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é le 8 mai par yves.guern 1
jojo Posté(e) le 22 mai Signaler Posté(e) le 22 mai Salut @yves.guern, A la lecture du fichier readme, je me rends compte que c'est un travail de malade/fou furieux que tu as fait (je ne sais comment on dit en France, mais en Belgique, c'est un super compliment). Moi qui pensait qu'en 30 min, j'aurais lu et implémenté les instructions. En 2h, j'ai seulement compris partiellement les instructions. Mes capacités informatiques sont très loin d'arriver à la cheville de la tienne ou de celle de @Lazer. Ce dont je suis sûr d'avoir compris, c'est que je dois faire des backups de tout dans tous les sens ... Donc, j'ai quelques questions pour son implémantation (qui pourraient te servir pour compléter ton super fichier readme.pdf afin de ne plus devoir y répondre). - fichier configPlus.inc.php : si on est 100% standard avec le Domochart original de Lazer (ce qui est mon cas, sauf pour les durées de rétention des données brutes - variables $db_interval_* du fichier config.inc.php), on peut l'utiliser tel quel ? - les durées de rétention définies dans le fichier configPlus.inc.php - variable $tTrendsPrm écrasent celles définies dans les variables $db_interval_* du fichier config.inc.php ? - faut-il ensuite lancer un php spécifique pour créer les tables *_hours dans MariaDB ? - je n'ai jamais lancé le fichier trend.php, j'imagine que c'est data.php qui s'en chargeait tous les jours. Mais alors s'il n'est pas modifié, comment le lance-t-il toutes les heures (ceci confirme que je suis le champion pour poser des questions bizarres ...) Merci
yves.guern Posté(e) le 22 mai Auteur Signaler Posté(e) le 22 mai (modifié) Bonsoir Jojo, Merci pour les fleurs, fallait pas... Surtout avant d'avoir essayé! Il y a 5 heures, jojo a dit : des backups de tout dans tous les sens 1 backup vous manque et tout est dépeuplé.... Il y a 5 heures, jojo a dit : fichier config.inc.php), on peut l'utiliser tel quel ? Oui! j'avais mis ce qui me concerne en commentaire. Mais cela ne t'empêche pas: de vérifier que les DLC correspondent bien à tes besoins... de choisir pour quels types de données tu veux créer des tables _hour (et aussi _day &_month) Oui les DLC de config.inc.php sont ignorées (après beaucoup d'hésitations) ET maintenant il faut aussi définir des DLC pour _hour, _day & _month Il y a 5 heures, jojo a dit : .../... pour créer les tables _hours Là je dois avouer que je me suis dit "et mmrrdd.. j'y avais pas pensé". Bon mais ce n'était qu'un coup de fatigue (ou une préalerte Alzheimer)!!! Il suffit de lancer install.php qui s'occupe de tout en fonction de configPlus.inc.php (ie : tu modifies configPlus.inc.php et tu lances install.php) Il y a 5 heures, jojo a dit : je n'ai jamais lancé le fichier trend.php Si si!; Lazer le faisait pour toi, il se relevait toutes les nuits à minuit pour cela . Trend.php était (et est toujours) appelé par le code du home center un peu après minuit et effectue toutes les mises à jour des tables _hour, _day &_month. Pour les tables _hour cela présente l'inconvénient qu'elle ne sont pas à jour avant minuit (mais à minuit il fait nuit: peut-on être à jour alors? Comme aurait dit ton regretté compatriote Devos) Donc il y a une petite modif du code lua qui appelle trend.php toutes les heures (si la variable 'OuiJeSuisImpatient' est armée....) Bonne soirée. Modifié le 22 mai par yves.guern 1
jojo Posté(e) le 23 mai Signaler Posté(e) le 23 mai Merci BEAUCOUP pour tes réponses précises, et qui en plus m'ont fait sourire ! Je met donc cela en oeuvre ce pm
jojo Posté(e) le 24 mai Signaler Posté(e) le 24 mai je suis entrain de finaliser la mise en place. Après lancement du fichier install.php, il a bien créé les tables *_hour, sauf certaines dont domocharts_water_hour Toutes les tables non créées ont cette définition dans le fichierconfigPlus.inc.php 'water' => array('DLC_j' => [ 100, 7*30, 14*30, 365*2], 'trendsType' => [1,1,1], 'addSum' => [true, true, true ] ), //created via database.sql je dois faire qqch de particulier ?
yves.guern Posté(e) le 25 mai Auteur Signaler Posté(e) le 25 mai @Jojo, En réponseS à ta question: Pourquoi vouloir conserver 100 jours de données water (même si cette table va être comprimée) si il y a une table _hour? //created via database.sql signifie que la table n'a pas un format 'simple' et que install.php utilise ce qu'il y a dans le fichier database.sql pour créer ce qu'il faut, il te faut donc modifier database.sql. Les table qui ne se font pas toutes seules sont 'donc' water energy cpu memory & network... Il n'y a que water qui pourrait accepter d'avoir une table '_hour' la table n'a pas un format simple => trend.php ne saura pas 'calculer' les tables hour day et/ou month: il faut lui dire comment faire dans les variables $tSpecialSQLQuerys ou $tVerySpecialPHPQuerys => tu as modifié ['water']['trendType'] à [1,1,1] je ne sais pas ce que cela va faire mais probablement rien de bien... rester avec [0,1,2] me semble une bonne option si tu ne crées pas 'water_hour' ou [1,1,2] dans le cas contraire. pour créer une table '_hour' à la main : il s'agit de table dont la structure est identique à la table '_day'... A+
jojo Posté(e) le 25 mai Signaler Posté(e) le 25 mai Il y a 3 heures, yves.guern a dit : Pourquoi vouloir conserver 100 jours de données water (même si cette table va être comprimée) si il y a une table _hour? je viens de 200 jour, alors je diminue petit à petit. Et justement, les tales *_hour restent vides (j'ai une erreur de configPlus.inc.php ?) Il y a 3 heures, yves.guern a dit : //created via database.sql signifie que la table n'a pas un format 'simple' et que install.php utilise ce qu'il y a dans le fichier database.sql pour créer ce qu'il faut, il te faut donc modifier database.sql. comprend pas ce que je dois faire : je n'ai jamais rien modifié à ce fichier, je suis en 100% standard, donc, selon moi, toutes les tables ont un format 'simple' Il y a 3 heures, yves.guern a dit : Les table qui ne se font pas toutes seules sont 'donc' water energy cpu memory & network... Il n'y a que water qui pourrait accepter d'avoir une table '_hour' En effet pour la création des tables. Mais pourquoi les table autres que water ne pourraient pas avoir de moyenne horaire ? Il y a 3 heures, yves.guern a dit : ['trendType'] à [1,1,1] c'est ce que j'ai mis pour toutes les tables, car ma compréhension était que c'était le basic. Conclusion: je crain qu'il faille être un expert pour utiliser/configurer correctement DomoCharts+. MON idée, serait de fournir une configuration basique standard, qui pourrait être affinée ensuite si on veut aller plus loin. J'était en 100% (sauf durée de rétention des données brutes) standard dans la config initiale. Donc, si je puis soumettre une proposition, fournir des fichiers et config web/lua qui correspondent à cette config, en y ajoutant juste ta compression et les tables *_hour pour les non-experts comme moi (= 95% des membres du forum)
yves.guern Posté(e) le 25 mai Auteur Signaler Posté(e) le 25 mai @Jojo Expert? je ne sais pas... Fournir des fichiers .../... en y ajoutant juste ta compression, sauf erreur c'est bien le fonctionnement par défaut Donner un fichiers de config basique standard, je crois que c'est ce que j'ai fait: Reste à définir ce que c'est que "basique et standard", dans mon esprit ce n'est pas de valider toutes les capacités/possibilités pour se poser des questions après. Je n'ai aucune idée des capacités en mémoire et en CPU des NAS qui vont supporter les calculs et les quantités de données Le configPlus.inc.php fourni est donné à titre d'exemple (et c'est celui que j'utilise pour moi). Dans ce fichier est écrit : * trend ne génère que des requêtes 'standard' sur des tables 'standard': ne cherchez pas à mettre à jour une table '_cpu_month' ou '_energy_month' par exemple avec une valeur de 'trendsType' => [0,2,1] Un peu plus de détails: Pour ce qui est des tables water,rain, energy, cpu, memory & network ce sont des tables pour lesquelles sont mémorisées plusieurs 'choses' à chaque enregistrement. (Ce ne sont pas des tables 'simples'). A partir de ces tables brutes, pour obtenir une des tables dite 'de moyennes' il faut donc dire quoi et comment moyenner, la réponse n'est pas unique... Histoire d'en rajouter une couche: pour la table energy, le calcul qui est fait n'a rien à voir avec une moyenne. pour les autres tables, à la question quoi? on réponds 'le champs "value" ' et à comment? on réponds 'en utilisant la fonction sql "AVG" ') PS: sur ces 6 tables, les tables water et rain sont comprimées les autres sont 'intactes' En résumé: je ne sais faire 'beaucoup de choses' que sur les tables qui ne sont pas water, rain, energy, cpu, memory & network. Pour ces tables il faut se 'contenter' de ce que fait Lazer, au moins pour l'instant. Je déconseille donc de modifier les champs trendsType pour ces 6 lignes dans configPlus.inc.php.
jojo Posté(e) le 25 mai Signaler Posté(e) le 25 mai il y a 19 minutes, yves.guern a dit : Fournir des fichiers .../... en y ajoutant juste ta compression, sauf erreur c'est bien le fonctionnement par défaut Donner un fichiers de config basique standard, je crois que c'est ce que j'ai fait: je me disais que non, car de ma compréhension : 'trendsType' => [1,1,1] (je pense que qqch <> 1, n'est pas standard, mais je me trompe peut-être) 'addSum' => [false,false,false] (sauf true pour ceux dont la somme a un sens, mais false, par défaut, car c'est le fonctionnement actuel) 'sqlValueType' => "tinyint(3) UNSIGNED") ou ce qu'il faut en fonction de ce qui est choisi (soit 2 décimales, soit entier) il y a 37 minutes, yves.guern a dit : Reste à définir ce que c'est que "basique et standard" Le DomoCharts de @Lazer non modifié il y a 43 minutes, yves.guern a dit : Dans ce fichier est écrit : * trend ne génère que des requêtes 'standard' sur des tables 'standard': ne cherchez pas à mettre à jour une table '_cpu_month' ou '_energy_month' par exemple avec une valeur de 'trendsType' => [0,2,1] je n'avais pas vu ce passage (=> sorry), ni même qu'il n'y avait pas de table _cpu_month, donc 'trendsType' => [1,1,1] est une hérésie, et je devrais mettre 'trendsType' => [1,1,0] il y a 50 minutes, yves.guern a dit : Pour ce qui est des tables water,rain, energy, cpu, memory & network ce sont des tables pour lesquelles sont mémorisées plusieurs 'choses' à chaque enregistrement. (Ce ne sont pas des tables 'simples'). je croyais (mais je n'avais jamais regardé en détails) que toutes les tables brutes étaien similaires (traitées de la même manière, avec des données envoyées de la même manière, ...) il y a 57 minutes, yves.guern a dit : la réponse n'est pas unique... je pensais que oui, d'où ma réflexion sur le standard ... il y a une heure, yves.guern a dit : Je déconseille donc de modifier les champs trendsType pour ces 6 lignes dans configPlus.inc.php. En fait, je vais recommencer tout avec ton fichier configPlud.inc.php sans y changer quoi que ce soit ! ==>> MERCI pour ta patience <<==
jojo Posté(e) le 26 mai Signaler Posté(e) le 26 mai j'ai donc (hier) réimporté l'ensemble de tes configurations web et ensuite lancé install.php. Les modifs lua également ok : ---------------------------------------------------------------------------------------------------- -- QuickApp : DomoCharts -- Author : Christophe DRIGET -- Version : 7.11 YGn: V2.0.3 mai 2025 -- Date : January 2022 ---------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------- -- Library : DomoAdds -- Author : Yves Guern -- Version : 2.0.2 -- Date : mai 2025 ---------------------------------------------------------------------------------------------------- Toutes mes tables *_hour restent vides. Les tables brutes continuent d'être mises à jour et ne sont pas purgées => c'est comme s'il continuait d'utiliser la configuration initiale. Et le fichier trend.php est bien le tien : <?php /******************************************************************************/ /*** File : trendNew.php ***/ /*** Author : Christophe DRIGET Yves Guern ***/ /*** Version : 1.1 à partir de la V7.0 de Christophe ***/ /*** History : Avril 2025 : Initial release ***/ /*** Note : Generate trend data in database ***/ /******************************************************************************/ Si ça fonctionne chez toi, c'est que j'ai du louper un truc. On y arrivera ...
yves.guern Posté(e) le 26 mai Auteur Signaler Posté(e) le 26 mai @jojo: As-tu installé le nouveau domochart sur la home box? et mis/vérifié les valeurs des variables locales: NAS_Path pour indiquer le répertoire où tu as installé trend.php et ses copains sur le nas CallTrendEveryH à true (sinon la maj des tables _hour ne se fait qu'à minuit, ce qui n'est pas un drame en soit...) Toutes les heures, la console de la homebox affiche la Mise à Jour des tables _hour: [26.05.2025] [11:38:00] [DEBUG] [QA_DOMOCHARTS(921)]: Total memory in use by Lua : 844.54 KB, CPU consumed : 11795.36 ms ( 0.164 % ) [26.05.2025] [12:00:00] [TRACE] [QA_DOMOCHARTS(921)]: DomoAddsDBCompress: Mis en DB = 2051/6960 (Compression: 71%) [26.05.2025] [12:00:30] [TRACE] [QA_DOMOCHARTS(921)]: Generate trends with:/trend.php?HourTableOnly [26.05.2025] [12:00:33] [DEBUG] [QA_DOMOCHARTS(921)]: Mises à jour des tables '_hour':OK, 77 lines affected [26.05.2025] [12:08:00] [DEBUG] [QA_DOMOCHARTS(921)]: Total memory in use by Lua : 844.54 KB, CPU consumed : 11844.00 ms ( 0.164 % ) [26.05.2025] [12:38:00] [DEBUG] [QA_DOMOCHARTS(921)]: Total memory in use by Lua : 844.54 KB, CPU consumed : 11469.57 ms ( 0.159 % ) [26.05.2025] [13:00:00] [TRACE] [QA_DOMOCHARTS(921)]: DomoAddsDBCompress: Mis en DB = 2066/6960 (Compression: 70%) [26.05.2025] [13:00:31] [TRACE] [QA_DOMOCHARTS(921)]: Generate trends with:/trend.php?HourTableOnly [26.05.2025] [13:00:33] [DEBUG] [QA_DOMOCHARTS(921)]: Mises à jour des tables '_hour':OK, 77 lines affected ... Oui sûr! on va y arriver
jojo Posté(e) le 27 mai Signaler Posté(e) le 27 mai oui, j'ai suivi les instructions de ton document readme.pdf, à partir de la page 2, Installation sur un existant : -modifier le serveur de base de données : "j'y ai écrasé avec l'entièreté de ton répertoire "DM+MajSvrV2.0.1" sans rien changer (par exple configPlus.inc.php)" -il faut modifier domocharts sur la homebox, : j'y ai maintenant 4 fichiers main (avec ton code) DomoCharts (avec le code original de @Lazer) tools (avec le code original de @Lazer) DomoAddsLib (le fichier supplémentaire que tu as demandé) Je crois que je viens de trouver.... Comme j'ai fait une mise à jour du DomoCharts existant, la variable CallTrendEveryH n'existait pas. Je l'ai donc créée manuellement, et le log a changé [27.05.2025] [16:08:01] [TRACE] [QA_DOMOCHARTS_166]: QuickApp DomoCharts avec Modifications DomoAdds, Compression DB active, temps max= 3600s [27.05.2025] [16:08:02] [DEBUG] [QA_DOMOCHARTS_166]: 184 sensors data inserted in DB [27.05.2025] [16:09:00] [TRACE] [QA_DOMOCHARTS_166]: DomoAddsDBCompress: Mis en DB = 179/179 (Compression: 0%) [27.05.2025] [16:09:01] [DEBUG] [QA_DOMOCHARTS_166]: 14 sensors data inserted in DB [27.05.2025] [16:10:00] [TRACE] [QA_DOMOCHARTS_166]: DomoAddsDBCompress: Mis en DB = 9/179 (Compression: 95%) [27.05.2025] [16:10:02] [DEBUG] [QA_DOMOCHARTS_166]: 15 sensors data inserted in DB [27.05.2025] [16:11:00] [TRACE] [QA_DOMOCHARTS_166]: DomoAddsDBCompress: Mis en DB = 19/358 (Compression: 95%) avant, il me semblait avoir l'ancienne version du log de @Lazer J'espère qu'on a trouvé l'erreur. Je te dirai (évidemment) quoi. Si c'était ça le soucis, il y a 2 options pour le régler : rajouter dans le chapitre "-modifier le serveur de base de données :" qu'il faut créer la variable CallTrendEveryH dans le QA modifier le code de main, pour que s'il ne trouve pas la variable, il mette la crée avec une valeur par défaut
jojo Posté(e) le 27 mai Signaler Posté(e) le 27 mai il vient de mettre ceci dans le log. Une piste ? [27.05.2025] [17:00:00] [TRACE] [QA_DOMOCHARTS_166]: DomoAddsDBCompress: Mis en DB = 390/9129 (Compression: 96%) [27.05.2025] [17:00:02] [DEBUG] [QA_DOMOCHARTS_166]: 12 sensors data inserted in DB [27.05.2025] [17:00:32] [TRACE] [QA_DOMOCHARTS_166]: Generate trends with:/trend.php?HourTableOnly [27.05.2025] [17:00:32] [ERROR] [QA_DOMOCHARTS_166]: http://192.168.1.xxx/domocharts/trend.php?HourTableOnly => Error #42S22 => SQLSTATE[42S22]: Column not found: 1054 Unknown column 'time' in 'field list' [27.05.2025] [17:01:01] [DEBUG] [QA_DOMOCHARTS_166]: 17 sensors data inserted in DB [27.05.2025] [17:02:02] [DEBUG] [QA_DOMOCHARTS_166]: 15 sensors data inserted in DB [27.05.2025] [17:03:00] [DEBUG] [QA_DOMOCHARTS_166]: Total memory in use by Lua : 2692.93 KB, CPU consumed : 4930.01 ms ( 0.411 % ) [27.05.2025] [17:03:01] [DEBUG] [QA_DOMOCHARTS_166]: 12 sensors data inserted in DB
jojo Posté(e) le 28 mai Signaler Posté(e) le 28 mai j'ai donc fait les vérifcations suivantes dans MariaDB (avec phpmyadmin). Les tables suivantes _hour ont été créées automatiquement : domocharts_current_hour domocharts_gas_hour domocharts_humidity_hour domocharts_light_hour domocharts_particule_hour domocharts_power_hour domocharts_pressure_hour domocharts_rain_hour domocharts_sound_hour domocharts_temperature_hour domocharts_voltage_hour domocharts_wind_hour Dans la structure, elles toutes le champ 'tilme'. Dans le debug peut-être ajouter lnom de la table qui a généré l'erreur ? Merci de ton aide
yves.guern Posté(e) le 30 mai Auteur Signaler Posté(e) le 30 mai Bonjour jojo, Désolé pour ce début de réponse tardive j'ai passé une bonne partie de ma journée dans les embouteillages hier... Tu as raison il faudrait un debug message plus détaillé mais au premier coup d'oeil la modification n'a pas l'air simple. J'y réfléchi et je te fait savoir. (Ne t'inquiète pas pour la suite, les calculs de 'trends' peuvent remonter loin en arrière: on a un peu de temps...) En attendant: Est-ce que dans ton log homeBox le message à minuit est correct? Pour ce qui est de CallTrendEveryH: elle est expliquée dans Domochart+Manuel.pdf. Mais tu as raison (encore) il y a trop de sous-entendus dans l'explication... A+
yves.guern Posté(e) le 30 mai Auteur Signaler Posté(e) le 30 mai @Jojo: tu vois j'y réfléchi ... Sais tu utiliser 'F12' sous ton explorateur internet? si oui, peux tu m'envoyer une copie de la console au retour de la commande: http://192.168.1.xxx/domocharts/trend.php?HourTableOnly 1
jojo Posté(e) le 30 mai Signaler Posté(e) le 30 mai merci de te pencher sur ma problématique. Est-ce que tu m'as demandé ?
yves.guern Posté(e) le 30 mai Auteur Signaler Posté(e) le 30 mai ???? le second message d'erreur est 'normal' (ou du moins il est ordinaire) Le premier n'a rien à voir avec ce que l'on cherche? Ce pourrait être un problème d'accès au NAS; As tu un user/mot de passe pour/dans domochart.lua (NAS_User/NAS_Password)? Si oui il faudrait modifier l'url à tester.
jojo Posté(e) le 30 mai Signaler Posté(e) le 30 mai (modifié) il y a 19 minutes, yves.guern a dit : Le premier n'a rien à voir avec ce que l'on cherche? je n'y connais rien au F12, mais en effet, il y avait le premier message avant que je lance ta command, puis le second est apparu. il y a 19 minutes, yves.guern a dit : As tu un user/mot de passe pour/dans domochart.lua (NAS_User/NAS_Password)? non, uniquement les valeurs par défaut de @Lazer: -. EDIT : Et le pare-feu est désactivé. As-tu modifié la méthode d'authentification? Modifié le 30 mai par jojo
jojo Posté(e) lundi à 13:00 Signaler Posté(e) lundi à 13:00 remarque générale. J'utilise Grafana pour un "beau" suivi. Avant l'optimisation de la DB en adaptant le LUA pour n'envoyer des données dans la DB, quand cas de changement, j'avais de beaux rectangles (ici pour la consigne de température), maintenant j'ai des "triangles" (car une seule donnée au lieu de toutes les minutes la même). Evidemment, cette optimisation de l'espace utilisé dans la DB reste primordiale, mais il s'agit d'un effet de bord auquel personne ne s'attendait ... Je vais regarder côté Grafana s'il n'y a pas moyen de faire qqch. Evidemment si un expert a une solution, j'achète (gratuitement )
Messages recommandés