jojo

étrange présentation !

plusieurs méthodes  :

1. créer un QA de type "Interrupteur binaire" : quand tu cliques sur l'image, il ouvre si fermé ou ferme si ouvert. Deplus, tu peux charger des images pour ouvert ou fermé, et il fait le taf. Evidemment tu peux adapter le code pour ouvrir/fermer.
2. sur le QA existant faire un test, et si (par exemple) la porte est ouverte, appuyer sur le bouton ouvrir n'aura aucun effet. Tu peux également rajouter un label statut qui affiche si la porte est ouverte ou fermée. Tu  peux également ne faire qu'un seul bouton dont le texte (et l'action) changent en fonction du statut de la porte.

Bref, en LUA, ta (presque) seule limite est ton imagination ...

peut-être qu'il y a eu un sousi lors de l'inclusion ?

Tente ceci alors

1. exclusion
2. reset module
3. ré-inclusion

solution dans Grafana

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 )

il y a 33 minutes, Sowliny a dit :

PS : avec un fond transparent ?

png obligé pour Fibaro ?

c'est ce qui justifiait que tu n'vais jamais le temps ...

Prochain projet : basculer sur HC3 ?

j'ai rien dit, mais je n'ai pas compris ce point.

Pour moi :

1. il vérifiait la  syntaxe
2. il n'exécutait que la fonction onInit()

à la sauvegarde ...

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?

merci de te pencher sur ma problématique.

Est-ce que tu m'as demandé ?

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

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

Il y a 19 heures, Manu31 a dit :

Me reste a afficher la valeur de la VariableCache dans le debug pour controler que tout se fait bien

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 :

1. rajouter dans le chapitre "-modifier le serveur de base de données :" qu'il faut créer la variable CallTrendEveryH dans le QA
2. 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 ...

Il y a 2 heures, Manu31 a dit :

	-- Si la variable est différente de nul, on la remet à 3°C chaques jours
    GEA.add({{"Value!", id["Temp_Piscine"], "40.0"}, {"Time", "04:45"}}, 1*60, "", {"Global", "Temp_Piscine", "3.0"})

ta condition est si <> 40.0, pas si <> de nul

Il y a 2 heures, Manu31 a dit :

 {"Global", "Temp_Piscine", {"Value", id["Temp_EauPiscine"]}}

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.

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

Il y a 2 heures, Kana-chan a dit :

Avez-vous le 2FA d'activer ? 

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

il y a une heure, Kana-chan a dit :

Le compte a bien les droits d'administration ?

oui

il y a une heure, Kana-chan a dit :

Le mot de passe ne comporte pas des caractères trop spéciaux (éviter "!&#" et utiliser seulement "-_" pour voir) ?

que des min/maj & chiffres

il y a une heure, Kana-chan a dit :

Avez-vous le 2FA d'activer

oui, je vais créer un second compte admin sans 2FA (bonne piste, merci)

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)

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 :

1. indépendant du cloud !
2. affichage de la température mesurée et de consigne
3. alimentation hors piles (230VAC ou basse tension DC)
4. sortie d'un contact sec pour commander ma chaudière (je pourrais faire mettre un relais ?)
5. modification de la consigne en local
6. configuration des modes et plannings hebdo via API locale/serveur Web local/HC3
7. 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 ...