Quick App - DomoCharts - Graphiques sur NAS pour HC3

[henri-allauch 225]

Fait

[henri-allauch 225]

Lors du trend j'ai un warning : 

[15.03.2021] [00:02:22] [WARNING] [QA_DOMOCHARTS_46]: insert into domocharts_rain_day : 0 lines affected - Error 1055 : SQLSTATE[42000] Expression #6 of SELECT list is not in GROUP BY clause and contains nonaggregated column 't1.max_value' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

Je n'ai pas de sonde rain,  mais la table domocharts_rain existe, par contre il n'y a pas de type rain dans la table domochars_type 

 

je pense qu'une des raisons de cette erreur provient de la ligne 408 de trend.php

		WHERE
			DATE(r.time) = t1.date
			AND r.device_id = t1.device_id
		GROUP BY
			1,
			device_id

Le 1, serait à remplacer par date,

 

A confirmer par @Lazer

 

[Lazer 8 496]

ça c'est curieux, je n'arrive pas à reproduire le message d'erreur, même avec une table vide comme toi.

 

Apparemment ce message d'erreur apparait en fonction du paramétrage du serveur SQL.

Tu utilises MariaDB sur Synology ou autre chose ? Quelle version ?

 

Et si tu remplaces 1 par date dans la clause GROUP BY, ça fonctionne ?

Je ne me souviens plus pourquoi j'ai mis 1 à vrai dire... donc erreur ou bonne raison, mystère.

 

EDIT : avec juste date il dit que c'est ambigu, donc il faut l'écrire ainsi :

		GROUP BY
			DATE(r.time),
			device_id

 

EDIT 2 : bon bah du coup je sais pourquoi j'ai mis 1, ça désigne le 1er champ SELECT, donc c'est censé être identique à la syntaxe que je viens de donner juste au dessus.

 

EDIT 3 : j'aurais dû commencer par lire le message d'erreur, ce qui ne lui plait pas c'est le t1.max_value issu de la sous-requête.... mais je ne comprends pas trop pourquoi...

 

EDIT 4 : essaye comme ceci, sans garantie (puisque je ne peux pas reproduire sur mon serveur SQL) :

		GROUP BY
			1,
			device_id,
			6

 

Modifié 15 mars 2021 par Lazer

[henri-allauch 225]

je suis sur my SQL  Apache  ubuntu

mais c'est pas bloquant 

dès que je peux Je vais essayer de faire la req direct avec phpadmin 

 

Edit : mysqld  Ver 5.7.33-0ubuntu0.18.04.1 for Linux on x86_64 ((Ubuntu))

Modifié 15 mars 2021 par henri-allauch

[henri-allauch 225]

Il y a 13 heures, Lazer a dit :

GROUP BY 1, device_id, 6

Cette solution supprime  le warning chez moi

 

[mprinfo 3 356]

je viens d’installer Mariadb, php, apache et adminer sur debian 10

 

j'ai ensuite transféré ma base sql avec phpadmin pour avoir un fichier SQL

 

Par contre le transfère de la base a planter lorsque j'ai voulu l'importé avec adminer au départ fichier trop gros donc j'ai modifier un paramètre pour augmenter la taille

Ensuite plus d'erreur mais impossible de l'importer

 

J'ai donc fais cela en manuel

j'ai dans un premier temps lancé le script de[mention=133]lazer[/mention] pour créer la base sql  et ensuite en ligne de commande importé le fichier SQL

Cela fonctionne Nickel merci[mention=133]lazer[/mention]

 

 

 

 

 

[flacon030 153]

perso j'utilise mysqldumper

https://github.com/DSB/MySQLDumper/archive/refs/heads/master.zip

Cela permet de faire des backup et des restaurations de base mysql même de gros volume

 

un tuto est ici par exemple

http://forums.phpbb-fr.com/documentation/base-de-donnees/mysqldumper-sauvegarde-amp-restauration-de-la-base-de-donnees-a162-view.html

Modifié 21 mars 2021 par flacon030

[henri-allauch 225]

@Lazer

J'ai installé 3 wallplug exclus de ma HC2, et inclus dans la Hc3 vers 18h00 hier. Elle non pas ou peu de consommation.

 

je trouve ce matin dans energy-day des valeurs de 28 54 et 961 ?? 

On démarre avec ces valeurs dans le champs index de domochart energy dès les premieres données insérées

 

Est ce une memoire des ces consommations qui ne sont pas mise à 0 lors d'une exclusion du device ?

 

PS: On retrouve ces valeurs dans energy des devices mais je n'ai pas regardé avant de les insérer dans la HC3 

      Et dans le domochart de la HC2 il n'y a pas les index energy

 

 

Modifié 27 mars 2021 par henri-allauch

[BenjyNet 1 200]

Oh. Intéressant comme REX ça.

[Lazer 8 496]

Oui c'est très probable, le WP aurait conservé son cumul de consommation après l'exclusion/inclusion.

 

DomoCharts récupère l'énergie de la veille depuis le panneau de consommation d'énergie de la HC3, donc déjà tu peux regarder les valeurs que tu as là :

 

Si tu veux le faire précisément via l'API comme le fait DomoCharts, c'est cette URL, il faudra remplacer l'IP, le timestamp de début, le timestamp de fin, et l'ID du WP :

http://192.168.1.1/api/energy/1612215000/1612251000/compare/devices/power/123

Et tu regardes la valeur du champ kWh dans le JSON retourné.

 

 

Ensuite, tu peux aller dans la base, avec phpMyAdmin par exemple, pour remettre à zéro les valeur pour cette première journée dans la table domocharts_energy_day afin de corriger le problème, et surtout de ne pas pourrir les graphs avec des valeurs aberrantes.

[henri-allauch 225]

curieux :  tout est a 0 

 

[{"id":161,"name":"Prise Perruches","kWh":0.0,"W":0.0,"min":0.0,"max":0.0,"avg":0.0}]

 

 

Oui je vais mettre à 0 les valeurs incorrecte pas de pB

 

 

Modifié 27 mars 2021 par henri-allauch

[Lazer 8 496]

Ah étrange ça

J'espère que ce n'est pas un bug de DomoCharts du coup, car il est censé récupérer exactement ce qu'il est retourné par l'API

[henri-allauch 225]

oui mais le 961 et les autres valeurs  il ne l'a pas inventé le premier coup

 28 54 et 961  ces valeurs semble cohérente / aux appareils connecté dessus sur HC2

J'ai installé hier un WP neuf et là c'est correct  

 

 

[Lazer 8 496]

Tu es sûr de ne pas t'être trompé dans le calcul des timestamps ?

 

Dans le doute prend une plage plus large, donc un timestamps de début largement avant l'inclusion du module.

Attention aussi aux timezone, en ce moment on est à GMT+1 (plus pour longtemps)

Donc tu mets genre 24h avant, tu es tranquille avec ça.

[henri-allauch 225]

du 25/3/  10h00  au 27/3 15h00  insertion 26/3 apm

 

 

 

Modifié 27 mars 2021 par henri-allauch

[henri-allauch 225]

 

A Cette première insertion dans energy d'ou vient la valeur 961 dans index  ( elle est # pour les 2 autres WP insérés   donc lue qq part)

Modifié 27 mars 2021 par henri-allauch

[Lazer 8 496]

Elle doit être lue dans le champ energy du json du module (auquel cas ça confirme qu'il a conservé son historique depuis sa sortie d'usine)

Du coup la conso journalière a été calculée à partir de la différence des index.

Si tu regardes la toute première value de ce module dans la table domotique_energy, ça doit être non nul

[henri-allauch 225]

Je pense comme toi

oui la valeur est dans le json energy

il y a 27 minutes, Lazer a dit :

la toute première value de ce module dans la table domotique_energy,

c'est bien celle de la table ci-dessus

Demain après les insertions des energy day de 00h02 qui devraient être correctes je met à 0 les lignes erronées.

Je pense que Exclusion ne veut pas dire Reset 

Le tout c'est de le savoir et de faire un reset du module avant l'insertion

[Lazer 8 496]

Oui voilà, tout à fait, il faut penser à faire le reset avec le bouton en suivant la doc.

 

Du coup je me demande si le bouton de suppression de l'historique de consommation sur la HC2 demande au module d'effacer son historique. A mon avis non, je suppose que ce n'est que l'historique interne à la box, dans sa base de données.

[henri-allauch 225]

@Lazer

Les calculs pour le energy_day sont corrects, ce qui confirme les discussions d'hier.

 

Par contre pour tous mes WP, j'ai constaté lors du trend : 

[28.03.2021] [00:02:22] [DEBUG] [QA_DOMOCHARTS_46]: insert into domocharts_power_day : 7 lines affected
[28.03.2021] [00:02:22] [DEBUG] [QA_DOMOCHARTS_46]: delete from domocharts_power : 4314 lines affected
[28.03.2021] [00:02:22] [DEBUG] [QA_DOMOCHARTS_46]: optimize table domocharts_power : 1 lines affected
[28.03.2021] [00:02:22] [DEBUG] [QA_DOMOCHARTS_46]: insert into domocharts_power_month : 0 lines affected

[28.03.2021] [00:02:22] [WARNING] [QA_DOMOCHARTS_46]: update domocharts_energy : 0 lines affected - Error 1221 : SQLSTATE[HY000] Incorrect usage of UPDATE and ORDER BY
[28.03.2021] [00:02:22] [WARNING] [QA_DOMOCHARTS_46]: update domocharts_energy : 0 lines affected - Error 1221 : SQLSTATE[HY000] Incorrect usage of UPDATE and ORDER BY
[28.03.2021] [00:02:22] [WARNING] [QA_DOMOCHARTS_46]: update domocharts_energy : 0 lines affected - Error 1221 : SQLSTATE[HY000] Incorrect usage of UPDATE and ORDER BY
[28.03.2021] [00:02:22] [WARNING] [QA_DOMOCHARTS_46]: update domocharts_energy : 0 lines affected - Error 1221 : SQLSTATE[HY000] Incorrect usage of UPDATE and ORDER BY
[28.03.2021] [00:02:22] [WARNING] [QA_DOMOCHARTS_46]: update domocharts_energy : 0 lines affected - Error 1221 : SQLSTATE[HY000] Incorrect usage of UPDATE and ORDER BY

[28.03.2021] [00:02:22] [DEBUG] [QA_DOMOCHARTS_46]: delete from domocharts_energy : 0 lines affected
[28.03.2021] [00:02:22] [DEBUG] [QA_DOMOCHARTS_46]: optimize table domocharts_energy : 1 lines affected
[28.03.2021] [00:02:22] [DEBUG] [QA_DOMOCHARTS_46]: insert into domocharts_water_day : 0 lines affected

La requête SQL Update n'accepte pas le Order By  de la ligne 250 de Trend.php

à ton avis, On peut lever le Order by ?

 

[Lazer 8 496]

Étrange.... encore un comportement différent avec ton serveur SQL.

 

Oui tu peux retirer la clause ORDER BY id, elle n'est là que pour faire joli (classer les lignes insérées dans la table)

 

[henri-allauch 225]

Mais un update n'insère pas il se contente de modifier les champs sauf la clé non ? 

Modifié 28 mars 2021 par henri-allauch

[Lazer 8 496]

Euh oui exact, j'ai peut être répondu un peu trop vite.

 

Cette requête correspond à la phrase suivante que j'avais expliqué dans ce post : https://www.domotique-fibaro.fr/topic/14935-quick-app-domocharts-graphiques-sur-nas-pour-hc3/?do=findComment&comment=237481

"... la page trend.php recalcule tous les champs value de la table domocharts_energy à partir des index ..."

 

Elle n'est pas indispensable, mais utile pour une bonne précision des calculs en cas de perte de connexion entre la HC3 et le NAS pendant plusieurs minutes, et cela uniquement pour les modules du 1er cas décrit, c'est à dire ceux qui reportent une énergie.

C'est le cas de ton Wall Plug justement.

 

Mais là comme ça, je ne sais pas quel sera son comportement sans la clause ORDER BY... Il faudrait que je me replonge dedans.

[ggpublic 22]

Sans doute un point évident pour ceux qui connaissaient le fonctionnement sur HC2 mais il serait peut-être utile de (re)préciser dans le tuto l'existence la page XXX/domocharts/admin.php pour la gestion de l'affichage des devices ?

 

Je viens de repartir sur un domocharts tout neuf avec mon HC3... aucun pb, tout baigne  

 

Can't wait the next step with Grafana 

 

 

[Lazer 8 496]

Exact, j'ai oublié de le recopier sur le nouveau tuto

 

Grafana ça viendra mais plus tard, mais le concept est ultra simple : installer Grafana quelque part sur le réseau, et le configurer pour aller taper dans la base SQL de DomoCharts. A partir de là, on génère mes graphs qu'on veut, l'immense intérêt était de pouvoir consolider les données de plusieurs tables différentes. Exemple : consommation du chauffage en fonction de la température, etc.

 

En revanche le paramétrage de Grafana est loin d'être intuitif je trouve. Dès fois je me demande pourquoi cet outil est devenu aussi populaire (la mode surement....)