yves.guern

Bonjour Eric Moi aussi je suis passé à 7.3 et moi aussi cela plantait . et pas de la faute du filtre sanitaire (donc pour toi il y a peut être 2 choses à faire...) PHP oui c'est la bonne piste! Paskeu lorsque tu es passé à 7.3 'ytaprévenu' que cela allait mal se passer. Moi aussi je me suis dit on verra bien. Et ce fut le drame Après tâtonnements : c'est webstation qui plante en n'assurant plus les services PHP. Pour les rétablir : ouvrir WebStation dans le centre de paquets dans la "vue d'ensembl"e vérifier que php 8.2 est bien actif: (éventuellement desactiver/desinstaller les autres versions php) toujours dans WebStation, dans l'onglet "Parametres du langage script">"PHP": Vérifier le profil par défaut: il faut qu'il soit 'disponible' et pointe vers php8.2 double cliquer dessus, on tombe sur les paramètres de PHP: dans l'onglet "extensions" valider l'activation des modules requis. C'est là que j'en ai eu marre et que j'en ai validé plein. Sûr qu'ils ne sont pas tous nécessaires! Au point que je vais la faire à l'envers: ceux que je n'ai pas validés sont: bz2,calendar,dba,imagick,phar,sodium, sysvmsg, sysvsem, sysvshm (Il me semble que Lazer avait fait une liste des modules vraiment requis...) A chaque fois que l'on veut tester une modif (ou un paquet de modifs) Centre de paquets > Apache Server >Stop puis restart Et voilà.... PS j'ai bien dit "Après tâtonnements" j'espère qu'ils n'avaient rien modifié d'indispensable... A+

J'utilise des thermostats aeotec: bof! Avec le HC3 (ou HC2) cela fonctionne mais pas comme ce que laisse penser la notice. Principaux défauts : consommation piles (2 jeux/an), seul le mode 'HEAT' est utilisable dans la pratique, comportement parfois curieux lorsque la température est proche de la consigne.

Bonjour, La chose s'appelle un disjoncteur d'abonné. Et, malgré son nom il n'appartient pas à l'abonné qui ne peut intervenir que sur les plots de sortie après l'avoir désarmé. Une 'exception': lorsque le compteur (linky) est loin (plus de 30m) du point d'utilisation. L'installation a alors 2 disjoncteurs d'abonné, un à coté du compteur l'autre dans la maison. Dans ce cas le second est propriété de l'utilisateur. Je suis dans ce cas et il m'est arrivé de changer moi même ce second disjoncteur arrivé en fin de vie (il ne voulait plus réenclencher). Mais grâce au premier disjoncteur j'ai fait le remplacement en toute sécurité. Sources: c'est clair là: LEGRAND et ici LABRICOELEC. Le but du compteur linky étant aussi (surtout?) de virer du personnel, toute intervention physique sur place doit être devenue un cauchemar de DRH.... D'où le jeu de patate chaude dont vous êtes victime

???? 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: 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

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+

@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 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, 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+

Bonsoir Jojo, Merci pour les fleurs, fallait pas... Surtout avant d'avoir essayé! 1 backup vous manque et tout est dépeuplé.... 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 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) 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.

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

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.

Bonjour Jojo 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

Yen a pas un de vous deux qui croit aux théories sur la Synchronicité par hasard?

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)