jojo

tu peux d'mander qu'il t'envoie un mail à chaque changement de la Variable Cache

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

dan ton test Value+ sur la valeur du module (cfr ce @Lazer a expliqué)

juste la même règle, mais sans les "

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 ...

ta condition est si <> 40.0, pas si <> de nul tu dois rajout {"Repeat"} dans tes actions, car ta condition ne change plus dès qu'elle est respectée la première fois. Tu devrais recevoir une notif à 4h20, puis plus rien. (ce n'est donc pas lié au firmware de la box.

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) Le DomoCharts de @Lazer non modifié 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] 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, ...) je pensais que oui, d'où ma réflexion sur le standard ... En fait, je vais recommencer tout avec ton fichier configPlud.inc.php sans y changer quoi que ce soit ! ==>> MERCI pour ta patience <<==

YYEESS ! c'était ça le problème => merci !

oui que des min/maj & chiffres oui, je vais créer un second compte admin sans 2FA (bonne piste, merci)

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 ?) 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' En effet pour la création des tables. Mais pourquoi les table autres que water ne pourraient pas avoir de moyenne horaire ? 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)

Merci de ta réponse. En fait j'utilise ton code (car avec celui que j'avais avant, le QA crachait). Je suis sûr de l'IP et du port, car quand j'entre une autre IP, j'ai 24.05.2025] [18:28:17] [TRACE] [QA_SYNOMAIN_1463]: ========================================== [24.05.2025] [18:28:17] [DEBUG] [QA_SYNOMAIN_1463]: onInit [24.05.2025] [18:28:20] [TRACE] [QA_SYNOMAIN_1463]: erreur No route to host et il me dit que le serveur est éteint (logique...) Quand j'entre des faux credential (lignes 36 & 37 de ton code), j'ai le log qui boucle sur Message [2, 6]. Donc je les ai fait vérifier par mon épouse, et tout est bon ET Le pare-feu du syno est désactivé. Et j'ai la même erreur sur tous mes Synos (j'en ai 3) Je ne sais donc plus dans quelle direction chercher.

Bonjour les Amis, Il y a longtemps (quand j'étais encore naïf) j'ai installé un Nest Learning thermostat. Il y a 1 mois, j'ai reçu un mail de Google m'informant qu'à partir du 25/10/2025 je ne pourrais plus le contrôler depuis mon PC ou à distance (et pourtant tout fonctionne parfaitement bien) => obsolescence programmée => vive le cloud. Evidemment ils me proposent d'en acheter un autre (également cloudé), mais évidemment que ton ! Je cherche donc un nouveau thermostat. Voici mon cahier des charges : indépendant du cloud ! affichage de la température mesurée et de consigne alimentation hors piles (230VAC ou basse tension DC) sortie d'un contact sec pour commander ma chaudière (je pourrais faire mettre un relais ?) modification de la consigne en local configuration des modes et plannings hebdo via API locale/serveur Web local/HC3 fonctionnement autonome, même si HC3 morte J'ai pensé au HeatIt Z-TRM6. Serait-ce un bon choix (ai-je bien lu sa doc ???) ? Merci de vos avis éclairés.

merci pour ta réponse complète et détaillées. J'espérais pouvoir récupérer les infos du "bidule" en étant 100% local, sans passer par leur serveur (je hais de plus en plus tout ce qui est cloud : exple J'acheté un thermostat Nest il ya longtemps, il fonctionne encore parfaitement et je vais devoir en changer car d'ici octobre, je ne pourrai plus le contrôler à distance , car je dois passer par le cloud Google ) Je ne ferai donc plus avoir ...

lit par exemple ceci où @Lazer utilise dans le LUA de main des fonction définies dans d'autres fichiers

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 ?

Merci BEAUCOUP pour tes réponses précises, et qui en plus m'ont fait sourire ! Je met donc cela en oeuvre ce pm

juste, merci du rappel, j'avais déjà eu le soucis, mais j'avais oublié => merci. Par contre je n'arrive toujours à avoir des retours : [23.05.2025] [11:44:21] [TRACE] [QA_SYNOMAIN_1463]: ========================================== [23.05.2025] [11:44:21] [DEBUG] [QA_SYNOMAIN_1463]: onInit [23.05.2025] [11:44:21] [TRACE] [QA_SYNOMAIN_1463]: Check Connect OK [23.05.2025] [11:44:21] [TRACE] [QA_SYNOMAIN_1463]: Version API Synology OK [23.05.2025] [11:44:21] [DEBUG] [QA_SYNOMAIN_1463]: Messages [1, 6] [23.05.2025] [11:44:24] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:26] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:28] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:30] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:32] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:34] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:36] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:38] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:40] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:42] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:44] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:46] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:48] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:50] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:52] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:54] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:56] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:44:58] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:45:00] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:45:02] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] [23.05.2025] [11:45:04] [DEBUG] [QA_SYNOMAIN_1463]: Messages [2, 6] une bonne idée ?

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

zut, je n'ai pas retrouvé ta ligne de code dans le code original. Comme il y a eu tellement de modifs dans tous les sens, je ne sais plus ce qui fonctionne ... Si quelqu'un a un code fonctionnel avec DSM7.2 s'il pouvait le partager (en PJ avec l'extension .LUA - car .TXT n'est pas accepté par le forum) ce serait GENIAL. Et quel port utilise-t-on dans la config : 80 ou 5000 ? Merci BEAUCOUP

et ça fonctionne du coup ?

les Belges n'ont pas de chance. Car du coup je l'ai également implémenté, et j'ai une erreur similaire [20.05.2025] [18:13:00] [ERROR] [QUICKAPP1463]: QuickApp crashed [20.05.2025] [18:13:00] [ERROR] [QUICKAPP1463]: main.lua:174: attempt to index a nil value (global 'jsonTable') je cherche ... Je me demande si je n'avais pas lu qqpart qu'il fallait changer qqch si on était sous DSM 7.2. Je vais lire tout le sujet (ce qui prendra du temp avec 0.5/10) pour trouver

il semble pouvoir parler avec ton Syno =(ce serait le bon port ? - mais lequel as-tu essayé ici 80 ou 5000?) [19.05.2025] [17:25:23] [DEBUG] [QA_180_DS 918+]: onInit [19.05.2025] [17:25:23] [TRACE] [QA_180_DS 918+]: Check Connect OK mail le syno retour qqch que la HC3 n'aime pas: (en ligne 172) [19.05.2025] [17:25:23] [ERROR] [QUICKAPP180]: main.lua:172: attempt to concatenate a nil value (field 'pathAuth')

par défaut il n'est pas activé : ControlPannel -> Sécurité -> Parre-feu

quitte à dire des bêtises : le port du DSM ce n'est pas 5000 (http) ou 5001 (https) ? as-tu désactivé le fire-wall du syno ? (on ne sait jamais)

décidément le nombre de super présentations augmente sur le forum ! (restons positif, lol)