Quick App - DomoCharts - Graphiques sur NAS pour HC3

[Manu31]

Bonjour,

 

je viens de mettre à jour mon serveur et du coup la VM qui héberge Domocharts.

Et pour vous faire part du message d'erreur que j'ai avec la dernière version de PHP

{"success":false,"error":{"code":8192,"message":"Constant FILTER_SANITIZE_STRING is deprecated"}}

Je n'ai pas encore chercher le contournement mais si vous avez eu le pb, je suis preneur

 

En vous remerciant

[Lazer]

Oui on en a parlé quelques pages plus tôt de ce problème-là

 

Il faut remplacer FILTER_SANITIZE_STRING par FILTER_UNSAFE_RAW

 

Modifié le 4 septembre 2023 par Lazer

[Manu31]

il y a 6 minutes, Lazer a dit :

Oui on en a parlé quelques pages plus tôt de ce problème-là

 

Il faut remplacer FILTER_SANITIZE_STRING par FILTER_UNSAFE_RAW

 

Bonjour,

 

Ah super merci  
Si c'est possible de le corriger dans le zip ca serait top 

 

Merci à toi 

[flacon030]

Bonjour

 

Je viens de m’apercevoir que si mon nas reboot, le QA n'arrive plus a envoyer les données se qui est normale, mais une fois le nas a nouveau en marche, je suis obligé de redémarrer la HC3 pour que tous fonctionne a nouveau

 

[09.09.2023] [18:01:02] [WARNING] [QA_DOMOCHARTS_54]: Memorize 10136 sensors data
[09.09.2023] [18:02:00] [TRACE] [QA_DOMOCHARTS_54]: Found 10136 previously stored datas
[09.09.2023] [18:02:00] [ERROR] [QA_DOMOCHARTS_54]: Too much data already in cache
[09.09.2023] [18:02:03] [ERROR] [QA_DOMOCHARTS_54]: http://192.168.1.8:80/domocharts/data.php => Error #08S01 => SQLSTATE[08S01]: Communication link failure: 1153 Got a packet bigger than 'max_allowed_packet' bytes
[09.09.2023] [18:02:03] [WARNING] [QA_DOMOCHARTS_54]: Memorize 10136 sensors data

 

Modifié le 9 septembre 2023 par flacon030

[Lazer]

Ah j'ai le même problème depuis un certain temps (sans que je ne puisse déterminer à quel moment ça a commencé...)

Tu n'es pas obligé de rebooter la HC3, il suffit de forcer le redémarrage du QuickApp.

 

Pour corriger le problème, il faut réduire la mémoire du QA.... perso je suis descendu de 10000 à 5000 mesures, et ça a suffit (pour l'instant ?)

[flacon030]

OK je suis descendu a 5000 on verra dans le temps

Merci

[Lazer]

C'est étonnant, car on n'a pas la même erreur.
Toi tu as une erreur "max_allowed_packet" qui semble indiquer que tu peux augmenter la taille de ce paramètre dans la configuration de ton serveur SQL.

De mon coté c'est une autre erreur, au moment d'insérer les données (nombreuses) dans la table qui échoue... sans que je ne trouve de solution pour le moment.

 

Bref, dans les 2 cas réduire la taille de la mémoire du QA permet de contourner le problème, mais ça diminue l'intérêt de la mémoire...

 

 

EDIT : autre chose, mais je suis surpris que la mémoire se remplisse si vite... ton NAS met 1h à rebooter ?

Parce que juste un reboot, ça dure quelques minutes, et normalement ça passe sans saturer la mémoire.
Chez moi l'erreur apparait quand le NAS est indisponible pendant un long moment, par exemple que je fait des manips dessus, et qu'il est éteint pendant tout ce temps là.

 

Modifié le 9 septembre 2023 par Lazer

[flacon030]

oui il a rebooter après une bonne 1/2 heure le temps de le mettre sous onduleur, et le QA ne se reconnecte plus au nas

Je m'en suis aperçu quelques heures plus tard

Modifié le 9 septembre 2023 par flacon030

[Lazer]

OK, donc en 1/2h tu as eu le temps de remplir la mémoire du QA, c'est cohérent du coup.

[jluc2808]

@lazer merci de cette QA et bravo pour le boulot

 

je viens d'installer la QA et Le serveur php sur mon NAS (qui est à distance), il me semble que ça fonctionne puisque quand je vais dans phpMyadmin et que je consulte le contenu de domotique/domocharts_cpu j'ai des valeur qui sont déjà enregistrées.

 

maintenant j'ai un souci, mais peut-être n'en est-ce pas un ?

quand je veux lancer la partie admin.php j'ai un écran bleu sans rien dedans ? (que ce soit sous chrome/firefox/edge) j'ai fait un F5 , pareil

j'ai cru comprendre que le 1er jour le fait d'avoir no device found devait être normal, mais là aussi si tu peux confirmer.

 

pour être complet, dans le paramétrage de web station, j'ai dû pour d'autres application ouvir les port 81 (http) et 82 (https) pour accéder aux applications web installées et mon gestionnaire par défaut est apache2.2 et pas ngninx (là aussi c'est pour d'autres application qui nécessite apache et pas ngnix )

le lancement de la création de la base avec ces paramètres est OK

[Lazer]

Bravo

Tu peux cliquer dès maintenant sur le bouton "Devices" du QuickApp, ça permettra d'alimenter la base de données et donc de voir le début des graph sans attendre demain, et également de pouvoir utiliser la page admin.php

(ce bouton est automatiquement "cliqué" tous les jours à minuit)

[jluc2808]

ah oui, j'avais pas fait ça (clic sur get devices), maintenant c'est nickel je vois les courbes 

un truc qui m'interpelle 

- j'ai un petit pic de 10% de cpu à 11h24 (le reste du temps c'est entre 4 et 6%) , quand je regarde dans l'historique du HC3 , j'ai strictement rien qui ne se déclenché à cette heure là, j'ai des actions à 11h18 et d'autre à 11h32 mais rien à 11h24, sachant que tous mes serveurs sont en NCP pour la synchro de l'heure. 

[Lazer]

Les pics de CPU ne sont pas liés qu'à l'activité des modules Z-Wave, cela peut aussi provenir du code LUA d'un QuickApp, d'une scène, ou bien encore de nous-même quand on manipule l'interface Web de la box.
En effet, la génération des pages Web est l'activité la plus consommatrice de CPU. Raison pour laquelle je préfère utiliser le suivi du CPU dans DomoCharts (donc hébergé sur un autre serveur/NAS) plutôt que d'utiliser la page de diagnostiques intégrée dans la box qui n'est pas du tout représentative de l'activité normale de la box.

 

Il faudra monitorer sur une plus longue période, mais 4 à 6% de CPU, avec une pointe à 10%, ça n'a rien d'alarmant pour l'instant.

 

Pour comparaison, sur ma box pas mal chargée, mais sans latence perceptible, le CPU ne descend jamais en dessous de 6,9%, et dépasse légèrement les 20% quand j'ai plusieurs onglets ouverts (interface principale, QuickApp en cours d'édition, fenêtre de log, etc).

Les pics ne dépassent pas 10% en usage normal (donc sans page web ouverte)

J'ai un pic 1 fois par semaine lors du backup auto la nuit, vers 40%, mais ce n'est pas représentatif car tous les QA redémarrent à ce moment précis.

 

J'ai pour habitude, dans tous mes QuickApps, de calculer et d'afficher la consommation mémoire et CPU (en ms et en %) afin d'identifier un QA qui occuperait un peu trop de ressource.

Ironie du sort, DomoCharts est l'un de mes QuickApps les plus consommateurs, il faut dire qu'il a 277 mesures à envoyer vers la base de données chaque minute, ce qui fait des tables d'une certaine taille à manipuler.

 

[jluc2808]

 pour l'instant GEA me consomme entre 0.015% et 0.018% et domocharts entre 0.027% et 0.519% avec 79 devices (lors du get devices) et 147 sensors (c'est normal que domocharts dit qu'il insert 147 sensors toutes les minutes - le toutes les minutes c'est lié à mon polling domocharts que j'ai laissé à 1 minute pour l'instant) 

[16.09.2023] [12:04:01] [DEBUG] [QA_DOMOCHARTS_726]: 147 sensors data inserted in DB
[16.09.2023] [12:03:54] [TRACE] [QA_DOMOCHARTS_726]: 79 new devices inserted in DB

 

[Lazer]

Oui c'est normal.
Et tu as plus de sensors que de devices car un device peut embarquer plusieurs sensors.
Exemples : un Wall Plug = power + energy, ou bien un FGMS = light + temperature, etc...

[TitiXsi]

Hello,

 

Je m'intéresse aux stockage des datas et graphs de nos chers capteurs et je vois avec un grand intérêt DomoCharts :).

@Lazer, je dispose d'un SolidRun Cubox 4Core, 4Gde RAM (https://www.solid-run.com/news/mini-computer-cubox-i-4x4/) qui dort mais également d'une freebox delta, quel est selon toi la meilleure option pour l'installation du serveur ?

 

Merci

 

Edit : rajout du lien pour le SolidRun

Modifié le 16 octobre 2023 par TitiXsi

[Lazer]

Certainement pas la Freebox, qui est en location, donc ne t'appartient pas.
Quand tu changeras de box et/ou de fournisseurs, est-ce que tu pourras facilement récupérer les données pour les conserver ?

Tout l'intérêt de DomoCharts c'est de conserver les données sur le long terme, donc ce point me parait essentiel.

(au delà de la migration futur d'équipement matériel, il faut également penser aux sauvegardes, idéalement quotidiennes, pour se prémunir en cas de crash)

 

Je ne connais pas le CuBox, mais je suppose que tu peux y installer l'OS de ton choix... un Linux me parait tout adapté pour cet usage.
Après selon ton niveau de compétences ou ton appétence pour l’apprentissage, tu peux probablement le virtualiser avec Proxmox par exemple, pour créer différentes VM.
 

Perso je suis dans une config hybride :

- la base de données de DomoCharts est gérée par MariaDB sur le Synology (qui est en fait une VM Xpenology de mon serveur)

- sur ce même serveur (virtualisé avec ESXi), j'ai une VM sous Linux dédiée pour le serveur Web, dans lequel j'y ai mis les pages PHP de DomoCharts

- entre les 2, j'ai un firewall pour filtrer tous les flux (pour la sécurité)

Un peu tordu à mettre en place, mais efficace. Ainsi j'ai la visualisation des graphs DomoCharts qui est accessible aussi bien en local qu'à distance, mais la DB SQL reste bien protégée dans le LAN.

[TitiXsi]

Hello, La freebox dispose de 4 racks 2.5 et est nativement un NAS. donc je ne pense pas que la perte de données soient un problème. en revanche, oui, à chaque changement de box, il faut remonter la VM, ce qui peut être plus simple sur le CuBox.

Je travailles sur Unix côté client mais pas côté Serveur... Donc je n'y connais pas grand chose... A voir avec le temps dispo et la motivation... Pourquoi pas un jour/semaine de pluie :-)

[Lazer]

En fait tu peux également tout faire tourner le serveur Web et la base de données sur Windows, avec LAMP c'est facile à mettre en place.
Mais je ne suis pas très fan de Windows sur un serveur, trop lourd à mon gout. Disons que c'est plus adapté à d'autres types d'usage, type serveur Active Directory, Excange, etc, bref tout ce qui fait partie de l'écosystème Microsoft.

[fredokl]

Hello, je viens de m'apercevoir que j'ai cette erreur sur DomoCharts.

J'ai des données jusqu'au 03 novembre dernier et plus rien maintenant.

[05.11.2023] [19:34:03] [ERROR] [QA_DOMOCHARTS_317]: DomoCharts:postAPI() Error #HY000 => SQLSTATE[HY000]: General error: 144 Table './domotique/domocharts_energy' is marked as crashed and last (automatic?) repair failed
[05.11.2023] [19:34:03] [ERROR] [QA_DOMOCHARTS_317]: http://192.168.1.11:80/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 144 Table './domotique/domocharts_energy' is marked as crashed and last (automatic?) repair failed

 

[Lazer]

La table domocharts_energy est crashée dans ta base de données... c'est embêtant car les données contenues dans cette table sont perdues (sur 7 jours donc, j'espère que tu as encore ta table domocharts_energy_day)

Il faut la vider complètement (dans le menu de phpMyAdmin) : uniquement cette table, pas la base entière !
Si tu as une sauvegarde, tu peux la restaurer, mais ça ne vaut peut être pas trop le coup de se prendre la tête vu que tu n'as que 2 jours de perdus. En effet, avant le 3 novembre, les données ont déjà été historisées dans la table _day (enfin normalement... à vérifier)

 

C'est tout de même étonnant, est-ce que tu aurais eu un crash du serveur, un reboot violent, une coupure de courant ?

 

Modifié le 5 novembre 2023 par Lazer

[Bloug]

Docteur est-ce grave ? j'ai zapé pas mal de temps ma BDD qui a planté sur le nas du coup j'ai eu un erreur :

 

[13.11.2023] [06:55:25] [ERROR] [QA_DOMOCHARTS_518]: DomoCharts:postAPI() Error #08S01 => SQLSTATE[08S01]: Communication link failure: 1153 Got a packet bigger than 'max_allowed_packet' bytes
[13.11.2023] [06:55:25] [ERROR] [QA_DOMOCHARTS_518]: http://192.168.1.10/domocharts/data.php => Error #08S01 => SQLSTATE[08S01]: Communication link failure: 1153 Got a packet bigger than 'max_allowed_packet' bytes
[13.11.2023] [06:55:25] [WARNING] [QA_DOMOCHARTS_518]: Memorize 10125 sensors data

J'ai réalisé cette commande dans phpmyadmin pour arrêter l'hémorragie puis redémarrer phpmyadmin :

 

SET GLOBAL max_allowed_packet=1073741824;

 

du coup j'ai plus la même erreur :

 

[13.11.2023] [07:08:26] [ERROR] [QA_DOMOCHARTS_518]: DomoCharts:postAPI() Error #HY000 => SQLSTATE[HY000]: General error: 23 Out of resources when opening file './test/domocharts_energy.MYD' (Errcode: 24 "Too many open files")
[13.11.2023] [07:08:26] [ERROR] [QA_DOMOCHARTS_518]: http://192.168.1.10/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 23 Out of resources when opening file './test/domocharts_energy.MYD' (Errcode: 24 "Too many open files")
[13.11.2023] [07:08:26] [WARNING] [QA_DOMOCHARTS_518]: Memorize 10125 sensors data

 

 

What should I do 

 

Ps : oui " test" c'est bien le nom de ma base :p

 

Modifié le 13 novembre 2023 par Bloug

[Lazer]

Oui c'est grave

Aucune idée de ce qui a pu arriver...

 

On dirait que ta table energy est corrompue, tu peux essayer de la parcourir avec phpMyAdmin ?

Si elle est vraiment corrompue, tu peux appliquer ce qu'on a dit il y a quelques jours ici-même (voir plus haut), à savoir la purger complètement.

[fredokl]

@Lazer Merci pour la réponse. J'ai vidé la table domocharts_energy et j'ai encore la table domocharts_energy_day.

Je n'ai plus d'erreur maintenant...enfin, si on veut. Maintenant les données ont 4 jours de retard!

 

Oui, j'ai eu un gros crash sur mon serveur il y a quelques temps mais je n'avais pas remarqué qu'il y a avait eu un impact sur la BD Domocharts.

J'ai l'impression que les données ne sont pas récupérés par moment.

Voici une capture d'écran de ce matin.

Entre le 08 novembre et le 10 novembre (dernière valeurs enregistrées sur Domocharts), on a l'impression qu'il ne sait rien passé.

 

Modifié le 14 novembre 2023 par fredokl

[Lazer]

Etonnant, car là tu montres le graph de température, donc c'est une table différente d'energy, celle qui était corrompue.

 

Mais... en relisant mieux ton message précédent, on voit dans le log de DomoCharts qu'il mémorisait toutes les données... donc l'erreur sur ta base SQL empêchait l'importe de toutes les données, toutes tables confondues.
Donc normal que tu aies un trou dans les statistiques... malheureusement là c'est perdu à jamais