Lazer Posté(e) le 4 novembre Auteur Signaler Posté(e) le 4 novembre Je n'ai pas inventé cette formule de calcul, j'ai repris celle que j'ai trouvé quelque part... sans certitude, mais je crois que c'est de @Steven qui l'avais partagé sur le forum, à l'époque de la HC2. En fait cette formule est un grand classique du calcul d'utilisation CPU sur un ordinateur... les métriques remontés par le noyau donnent un temps processeur cumulé (en "tick" processeur, c'est l'unité élémentaire, basée sur le cycle d'horloge, donc le plus petit temps possible), cela pour l'ensemble des cœurs actifs. C'est valable pour les différents systèmes d'exploitation, Linux, AIX, etc... (Windows aussi je suppose, je n'ai jamais développé avec les API de performance sur cette plateforme). Il faut donc diviser le temps total mesuré par le nombre de cœurs installés pour obtenir le bon pourcentage d'utilisation moyen de la machine. Le facteur 4 c'est juste à cause du nombre de cœurs dans le processeur de la HC3, je crois de mémoire que c'est seulement 2 dans le cas de la HC3 Lite. D'où l'utilisation de la variable nbCPUs qui compte le nombre de cœurs dans la formule. Pour s'assurer de la fiabilité de cette formule effectuée en LUA, il faudrait effectuer un benchmark. Pour cela, écrire un code LUA dans un QuickApp, qui tourne en boucle "à fond la caisse", par exemple en faisant un calcul mathématique simple, et cela pendant de longues minutes. Le code LUA du QuickApp étant mono-threadé, il sera affecté à un seul cœur du processeur. Ce cœur sera donc à 100%. La HC3 disposant de 4 cœurs, la charge moyenne du processeur sera donc de 25% (en pratique un peu plus, car la HC3 fait aussi d'autre choses : moteur Z-Wave, autres QuickApps, scènes, et interface Web qui consomment tous un peu de CPU) La formule de calcul, devrait donc donner un résultat approximativement autour de 25% (1 cœur à 100%, divisé par 4 cœurs pour moyenner sur le processeur du système) Cependant, il y a une grosse limitation. L'API /diagnostics remonte les informations fournies par le noyau Linux, donc précises, sur l'ensemble du système (incluant donc la totalité des processus tournant sur la machine... tant les processus utilisateurs (QuickApps, Scènes, les différents binaires Fibaro) que les processus systèmes (noyau, librairies de gestion des entrées/sorties (stockage, réseau, etc). Cependant, la commande collectgarbage("count") utilisée en LUA pour récupérer la consommation CPU du QuickApp, ne compte que le processus utilisateur proprement dit (rappel : 1 QuickApp = 1 processus utilisateur sous Linux). Impossible donc, depuis un QuickApp, de mesurer l'activité induite par le QuickApp, à savoir les autres processus systèmes et noyau. Exemple, un QuickApp qui appelle l'API de la box fait travailler le serveur Web embarqué ainsi que d'autres processus Fibaro. Cette activité sera "vue" par l'API système /diagnostics, mais pas par l'API LUA locale. De même pour un QuickApp qui fait des requêtes réseau, des affichages dans la console de debug, ou déclenche des activités sur les autres modules (physiques ou QuickApps....) Quoi qu'il en soit, mon test de benchmark proposé précédemment, s'il se contente de faire un calcul mathématique simple en local (une simple addition suffit... ou même pas de calcul du tout, ça peut être une bête boucle infinie de type "while true do end") devrait théoriquement limiter l'activité externe induite par le QuickApp, et donc permettre d'approcher les 25% de charge moyenne de la box, tout en étant lui-même à 100% sur un seul cœur. Ou tout du moins, un bon ordre de grandeur (étant donné, encore une fois, que la box fait aussi autre chose en même temps) Pas simple l'analyse de performance en informatique... Il y a 5 heures, yves.guern a dit : Si un CPU à 4 cœurs est occupé à 20% au total (ie la valeur de cpuDelta/elapsedTime*100) cela signifie que les 4 cœurs sont aussi chargés à 20% (en moyenne) même s'ils n'ont fait chacun que 1/4 du travail total. Oui mais attention, ce cas que tu décris n'est qu'un cas particulier où la charge est équilibrée sur l'ensemble des cores, ce qui est hautement improbable (statistiquement on s'en approche tout de même sur un système chargé avec un grand nombre de processus, car le noyau Linux fait de son mieux pour équilibrer la charge sur les différents cores) Par ailleurs, si tu as suivi mon exposé, tu peux avoir 1 core à 100%, et les autres qui ne font rien, ça fait 25% en moyenne. Ou n'importe quelle autre combinaison de charge de travail (ce qui, dynamiquement, change un grand nombre de fois chaque seconde lorsque le noyau rééquilibre les processus sur les cores) Il y a 5 heures, yves.guern a dit : Dit autrement: 4 cœurs à 100% = 1 CPU à 100% ? Oui. 2
yves.guern Posté(e) le 5 novembre Signaler Posté(e) le 5 novembre Bonjour Lazer, Si tôt dit, si tôt fait, c'est ça le jeune retraité... J'ai fait le test que tu proposes sur un HC3 de secours qui n'avait que cela à faire (lui aussi ) Ce qui est sûr: Le 04/11/2024 à 14:05, Lazer a dit : Pas simple l'analyse de performance en informatique... Et en particulier si on mélange temps CPU et temps d'un core. J'ai donc fait une QA avec une boucle originale qui incrémente la variable j pendant 'un certain temps'. (code joint) Je mesure ce qui est mesurable à la fois par os.clock() & os.time() ainsi qu'avec api.get("/diagnostics") en parallèle sur la même exécution. Voici les résultats: (RQ: HC3 a un CPU 4 cœurs) Résultats de os.clock() & os.time() Durée du test: 66s, Occupation= Delta clock()/Delta Time() = 98.9% Résultats de api.get("/diagnostics") en ticks: | en %: Objet idle system user | idle system user Core 1 6340, 62, 52 | 98.2%, 1.0%, 0.8% Core 2 , , 6527 | 0.0%, 0.0%, 100.0% Core 3 6382, 58, 49 | 98.4%, 0.9%, 0.8% Core 4 6310, 98, 41 | 97.8%, 1.5%, 0.6% Total(CPU) 19032, 218, 6669 | 73.4%, 0.8%, 25.7% Commentaires: La QA s’exécute bien sur 1 seul cœur (ici le Core2) et l'occupation 'user' des autres est quasi nulle L'occupation de ce cœur est bien de 100% Le CPU est bien occupé à 25% (il n'y a que cette QA qui s'execute) Ce dont je n'étais pas conscient c'est que le résultat obtenu par os.clock() n'est pas un temps CPU mais un temps 'cœur' (celui de la QA où l'on pose la question) => si clock/time = 100% cela veut dire que la QA est à fond (mais pas que le CPU l'est). Donc tu as raison. Il faut diviser le temps obtenu via clock/time par le nombre de cœurs pour connaitre la charge que donne une QA au CPU. Ce que je retiens: (Delta clock()/Delta Time()) donne le pourcentage d'occupation du cœur sur lequel s’exécute une QA Une QA s'exécute dans un seul thread et(donc) sur un seul cœur. => Exprimé en % de temps CPU la charge maximale dont dispose une QA est de 25%. (je crois que c'est cette exécution mono thread dont je n'avais pas vu toutes les conséquences) Donc, pour une grosse QA mal foutue, clock/time est plus intuitif et les doses de dopamine plus fortes (4 fois environ) en cours d'optimisation par son auteur . A+ TempsCPU_HC3.lua 1
Lazer Posté(e) le 5 novembre Auteur Signaler Posté(e) le 5 novembre Au top ta mise en pratique Il y a 3 heures, yves.guern a dit : (Delta clock()/Delta Time()) donne le pourcentage d'occupation du cœur sur lequel s’exécute une QA Comme j'aime compliquer les choses, si on avait la possibilité de faire tourner des QuickApps Multi-thread, alors on pourrait faire exécuter notre code en parallèle sur 2, 3 voire 4 cœurs, maximisant ainsi l'utilisation du CPU, et cela afin de .... : Il y a 3 heures, yves.guern a dit : et les doses de dopamine plus fortes (4 fois environ) en cours d'optimisation par son auteur Sérieusement, si on appliquait la formule sans la diviser par le nombre de cœurs, notre QA multi-threadé nous ferait croire qu'on dépasse les 100% d'utilisation (puisque 2 ou plus cœurs travaillent simultanément), ce qui est impossible. Cela dit, je ne te souhaite pas de faire un jour de la programmation multi-thread, sauf si tu aimes te faire des nœuds au cerveau. C'est ultra puissant, mais ça peut vite devenir un vrai sac de nœuds, car on ne maitrise alors plus du tout l'ordre d'exécution du code des différents threads de notre programme, avec des effets de bords pas du tout sympa comme une variable qui est lue avant d'avoir été écrite, ou bien une autre variable qui change de valeur pendant le calcul d'une formule se basant sur cette variable. On doit alors utiliser des mutex et autres joyeusetés du même genre pour gérer de tels conflits d'exécutions... et assez rapidement on conçoit des programmes qui plantent tout seuls, sans prévenir, simplement parce qu'ils se bloquent si plusieurs threads s'attendent l'un et l'autre... Sur le LUA de la HC3, Fibaro nous a proposé un truc très sympa, qui est aussi mis en oeuvre dans tous les langages modernes (JavaScript, etc), c'est l'asynchronisme, dont il y a déjà plusieurs discussions à ce sujet sur le forum. Cela permet, tout en conservant un programme mono-thread, de faire s'exécuter le code de façon non linéaire, puisqu'une fonction peut se terminer (rendre la main au système), ou bien se mettre en attente (du retour d'une requête réseau, un timeout, etc) et ainsi permettre à d'autres bouts de code de s'exécuter. C'est une sorte de multi-thread simplifié, sans l'être vraiment. Tient, d'ailleurs, on peut faire du multi-thread sans forcément avoir plusieurs cœurs, 1 seul suffit... et ça fonctionne ainsi depuis les vieux ordinateurs mono-processeur et mono-cœur. De même, on peut n'avoir que des programmes mono-thread sur un ordinateur multi-processeur et multi-cœur, comme expliqué précédemment, c'est le job du noyau du système d'exploitation que de répartir les programmes et/ou threads sur les différents cœurs/processeurs de la machine. En revanche, comme dit, pour s'exécuter sur plusieurs cœurs et/ou processeurs, un programme doit impérativement être multi-thread. Conséquence de ça, lors de l'apparition des premières machines à plusieurs processeurs (mono-thread) puis des premiers processeurs multi-thread, les applications étaient plus lentes sur la nouvelle génération de machine, bien que vendue plus cher avec l'argumentaire marketing de la performance accrue. En effet, les applications en ce temps là (euh... c'est encore le cas aujourd'hui pour certains programmes.... les QA par exemple, bon mais c'est aussi vrai sur les PC, Smartphones, etc) étant développées en mono-thread, elles étaient incapables de bénéficier de la puissance de calcul supplémentaire apportée par les processeurs/cœurs supplémentaires, l'application est littéralement bridée, ce que démontre parfaitement ton benchmark, incapable d'exploiter la puissance de calcul totale de la machine. Pire que ça, la vitesse d'exécution était réduite, car à génération équivalente, un core sur un processeur mono-core est plus performant qu'un seul core sur un processeur multi-core... cela est dû aux mécanisme interne du processeur qui "perd" du temps à faire fonctionner plusieurs cores en parallèle, ne serait-ce parce qu'en interne, dans sa file d'attente des instruction à exécuter, il doit les diriger vers le bon core. Les joueurs sur PC connaissent bien ce phénomène, plusieurs fois, sur le dernier processeur Intel sorti les performances sont moindre, jusqu'à ce que le studio de développement propose une mise à jour du jeu pour mieux gérer le multithread et le spécificités du nouveau processeur. Déjà vu sur smartphone, avec les processeurs Qualcomm par exemple.
yves.guern Posté(e) le 5 novembre Signaler Posté(e) le 5 novembre il y a 4 minutes, Lazer a dit : Cela dit, je ne te souhaite pas de faire un jour de la programmation multi-thread, sauf si tu aimes te faire des nœuds au cerveau C'était un gros morceau de mon boulot avant la retraite, je crois bien que c'est pour cela que je me suis fait un nœud là . L’asynchrone rime facilement avec le multithread cela ne m'a donc pas réveillé Évidement tout cela ce n'est ni du temps réel ni des traitements complexes mais finalement je trouve que le HC3 fait beaucoup de choses proprement et vite. J'ai environ 40 QA qui tournent pour moins de 15% de CPU en tout: ya encore de la marge!
Lazer Posté(e) le 5 novembre Auteur Signaler Posté(e) le 5 novembre Ah bah alors tu as connu ça Oui, la HC3 est une chouette machine, dont on sous-exploite le potentiel. Je suis en moyenne autour des 11% de CPU la nuit (peu d'activité Z-Wave, et de déclenchement des scénarios instantanés GEA), tandis que ça oscille globalement entre 15 et 22% en cas de présence la journée, avec quelques petits pics au delà de 25%.
henri-allauch Posté(e) le 2 décembre Signaler Posté(e) le 2 décembre J'ai besoin de changer de serveur php+sql je lance un php qui dump la base graph puis la charge sur un nouveau serveur, ça c'est OK. Ensuite j'ai besoin d'informer domochart de ce changement Pour éviter les fausses manip, et pour le faire à distance : Je pense utiliser un truc du genre : -- réinitialiser domochart pour recharger la variable Adresse serveur Php self.QA_Domochart = 128 fibaro.call(self.QA_Domochart, "setVariable", "NAS_Address", 192.168.1.66) fibaro.setTimeout(1*1000, function() fibaro.call (self.QA_Domochart, "onInit") end) A part la perte d'une mise à jour, @lazer vois-tu un autre risque et plus généralement : réinitialiser un QA de cette manière est-ce acceptable ?
Lazer Posté(e) le 2 décembre Auteur Signaler Posté(e) le 2 décembre Bizarre, pourquoi ne pas simplement modifier les variables du QA via l'interface graphique, tu n'y as pas accès ? Autrement tu peux modifier la variable d'un QA directement depuis une URL via l'API de la HC3 : /api/callAction?deviceID=128&name=setVariable&arg1=NAS_Address&arg2=192.168.1.66 ou, à tester : /api/callAction?deviceID=128&name=setVariable&arg1=NAS_Address&arg2="192.168.1.66"
henri-allauch Posté(e) le 2 décembre Signaler Posté(e) le 2 décembre j'ai un QA qui modifie plusieurs autres autres QA pour ce changement de serveur donc c'est plus pratique que de tous les faire les uns après les autres via l'interface graphique Pour les autres QA je charge la variable ( or oninit() ) donc au moment ou j'en ai besoin -> pas de PB j'ai pas besoin de les réinitialiser. Mais pour domochart je ne souhaite pas faire de modifications Je me demandais au niveau du QA si le fait de le relancer par son onInit() c'était comme quand il est relancé par la HC3 Le processus unix de ce QA est peut être killé puis relancé quand c'est le système HC3 qui le réinitialise alors que relancer le onInit() on reste dans le même processus .
Lazer Posté(e) le 2 décembre Auteur Signaler Posté(e) le 2 décembre il y a 24 minutes, henri-allauch a dit : Je me demandais au niveau du QA si le fait de le relancer par son onInit() c'était comme quand il est relancé par la HC3 Non pas du tout onInit() c'est juste une fonction, qui est appelée automatiquement lors du démarrage du QA, mais si celui-ci est déjà en fonctionnement quand on rappelle la fonction, selon comment le QA est codé, il va plus ou moins bien réagir au fait que le onInit soit relancé... Sinon l'astuce que j'avais employé à l'époque de la HC2 dans mon watchdog pour forcer le redémarrage d'un VD/Scène, c'était d'ajouter un saut de ligne à la fin du code LUA et de sauvegarder à nouveau... ce qui provoquait son redémarrage immédiat. Peut être que ça fonctionne aussi avec les QA, mais c'est un peu lourd à mettre en place en LUA.
henri-allauch Posté(e) le 2 décembre Signaler Posté(e) le 2 décembre OK je me doutais un peu que sur des QA complexes on mesure mal les conséquences il y a 6 minutes, Lazer a dit : c'était d'ajouter un saut de ligne à la fin du code LUA Oui ça fonctionne Peut être insérer une fonction appelée de l'extérieur qui le fait planter c'est aussi une solution Merci de tes réponse j'abandonne le re onInit()
jojo Posté(e) le 12 décembre Signaler Posté(e) le 12 décembre Grande première, j'ai une erreur sur le QA. (je le réinstalle enfin sur ma HC3. Voici l'erreur : Y aurait-il des formats régionaux à respecter sur le NAS et/ou la HC3?
Lazer Posté(e) le 12 décembre Auteur Signaler Posté(e) le 12 décembre Tu aurais le log STP ? C'est apparu quand quelles conditions... tu as ajouté un nouveau device et tu lui as donné un nom avec des caractères spéciaux ?
jojo Posté(e) le 12 décembre Signaler Posté(e) le 12 décembre en fait cela faisait longtemps que (je crois) qu'il était down. En fait le QA continuait de collecter... Je l'ai réactivé, en réinstallant une nouvelle DB, etc. En voyant le log, cela me fait penser à une erreur qui aurait déjà été posée, mais je ne me souviens plus de la solution. [12.12.2024] [20:37:02] [WARNING] [QA_DOMOCHARTS_166]: Memorize 5090 sensors data [12.12.2024] [20:38:00] [TRACE] [QA_DOMOCHARTS_166]: Found 5090 previously stored datas [12.12.2024] [20:38:00] [ERROR] [QA_DOMOCHARTS_166]: Too much data already in cache [12.12.2024] [20:38:01] [ERROR] [QA_DOMOCHARTS_166]: http://192.168.x.x/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 23 Out of resources when opening file './domotique/domocharts_energy.MYD' (Errcode: 24 "Too many open files") [12.12.2024] [20:38:01] [WARNING] [QA_DOMOCHARTS_166]: Memorize 5090 sensors data [12.12.2024] [20:39:00] [TRACE] [QA_DOMOCHARTS_166]: Found 5090 previously stored datas [12.12.2024] [20:39:00] [ERROR] [QA_DOMOCHARTS_166]: Too much data already in cache [12.12.2024] [20:39:02] [ERROR] [QA_DOMOCHARTS_166]: http://192.168.x.x/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 23 Out of resources when opening file './domotique/domocharts_energy.MYD' (Errcode: 24 "Too many open files") [12.12.2024] [20:39:02] [WARNING] [QA_DOMOCHARTS_166]: Memorize 5090 sensors data
Lazer Posté(e) le 12 décembre Auteur Signaler Posté(e) le 12 décembre Redémarre le QA, ça va vider sa mémoire cache. Si le problème revient, tu peux diminuer la valeur de la variable Memory. Et enfin, si la table domocharts_energy est toujours en erreur, c'est qu'elle est crashée, alors tu peux la vider (PhpMyAdmin > Opérations > Vider la table (Truncate)) 1
jojo Posté(e) le 13 décembre Signaler Posté(e) le 13 décembre cool, juste un redémarrage et mon log est tout vert ! [13.12.2024] [11:42:00] [TRACE] [QA_DOMOCHARTS_166]: Found 5090 previously stored datas [13.12.2024] [11:42:00] [ERROR] [QA_DOMOCHARTS_166]: Too much data already in cache [13.12.2024] [11:42:01] [ERROR] [QA_DOMOCHARTS_166]: http://192.168.x.x/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 23 Out of resources when opening file './domotique/domocharts_energy.MYD' (Errcode: 24 "Too many open files") [13.12.2024] [11:42:01] [WARNING] [QA_DOMOCHARTS_166]: Memorize 5090 sensors data [13.12.2024] [11:43:00] [TRACE] [QA_DOMOCHARTS_166]: Found 5090 previously stored datas [13.12.2024] [11:43:00] [ERROR] [QA_DOMOCHARTS_166]: Too much data already in cache [13.12.2024] [11:43:01] [ERROR] [QA_DOMOCHARTS_166]: http://192.168.x.x/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 23 Out of resources when opening file './domotique/domocharts_energy.MYD' (Errcode: 24 "Too many open files") [13.12.2024] [11:43:01] [WARNING] [QA_DOMOCHARTS_166]: Memorize 5090 sensors data [13.12.2024] [11:44:00] [TRACE] [QA_DOMOCHARTS_166]: Found 5090 previously stored datas [13.12.2024] [11:44:00] [ERROR] [QA_DOMOCHARTS_166]: Too much data already in cache [13.12.2024] [11:44:01] [ERROR] [QA_DOMOCHARTS_166]: http://192.168.x.x/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 23 Out of resources when opening file './domotique/domocharts_energy.MYD' (Errcode: 24 "Too many open files") [13.12.2024] [11:44:01] [WARNING] [QA_DOMOCHARTS_166]: Memorize 5090 sensors data [13.12.2024] [11:44:10] [TRACE] [QA_DOMOCHARTS_166]: [13.12.2024] [11:44:10] [TRACE] [QA_DOMOCHARTS_166]: QuickApp DomoCharts v7.11 - Initialization [13.12.2024] [11:44:10] [TRACE] [QA_DOMOCHARTS_166]: [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: Using tools library v2.20 [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: Using DomoCharts library v7.10 [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: DomoCharts library successfully initialized [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: Refresh interval : 60 seconds [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: NAS URL : http://192.168.x.x/domocharts [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: Maximum memory : 5000 measures [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: Battery query time : 23:00 [13.12.2024] [11:44:10] [DEBUG] [QA_DOMOCHARTS_166]: Time is 11:44:10, first loop at 11:45:00 in 50 seconds... [13.12.2024] [11:45:02] [DEBUG] [QA_DOMOCHARTS_166]: 176 sensors data inserted in DB 1
jojo Posté(e) le 14 décembre Signaler Posté(e) le 14 décembre en fait je voulais remettre Domochart en place car ma PAC va très mal et je voulais voir via la conso de courant [A] de la PAC quand elle tournait ou pas. Je la mesure par des module Aeon HEM. Dans la HC3, on a des graphes pour W, mais pas pour A (et j'ai l'habitude de travailler avec A) Dans l'interface d'administration, je vois bien mes devices Dans phpMyAdmin, la table domocharts_current est bien remplie (et d'ailleur je l'avais vidée hier au cas où; et donc dans l'interface j'ai toujours (et pas de soucis pour d'autres types de graphe) Qu'ai-je fait de mal ?
Lazer Posté(e) le 14 décembre Auteur Signaler Posté(e) le 14 décembre Dans ton navigateur, press F12 pour voir les outils de développement et regarde la Console :
jojo Posté(e) le 15 décembre Signaler Posté(e) le 15 décembre est-ce que ceci peut t'aider à m'aider ?
Lazer Posté(e) le 15 décembre Auteur Signaler Posté(e) le 15 décembre Hum..... il doit manquer une ligne de configuration dans le fichier config.js Mais ça veut dire que ça n'a jamais fonctionné tel quel ??? Essaye d'ajouter ça : {type:'current', title: 'Courant', yaxis: 'Courant (A)', tooltip: 'A'}, {type:'current_day', title: 'Historique de courant (moyenne journalière)', yaxis: 'Courant (A)', tooltip: 'A'},
jojo Posté(e) le 15 décembre Signaler Posté(e) le 15 décembre je n'ai jamais essayé au-parant avec le courant. Et chez toi as-tu des devices qui remontent le courant dans Domochart ? J'ai ajouté test 2 lignes à la fin du fichier (je n'y connais rien, donc c'est surement pas où il fallait) et plus rien ne fonctionne (= même erreur déjà sur les températures). Voici mon fichier modifié : config.js Mais lors de la "réactivation" de mon Domochart, J'ai vu dans MariaDB qu'il y avait déjà une DB domotique, que j'ai renommée en domotique_old (on ne sait jamais) Et aussi dans le fichier config.inc.php, ça ne fonctionnait qu'avec l'IP localhost, et pas avec l'IP de mon NAS (192.168.x.x) config.inc - Copy.php Peut-être une piste de réflexion ?
Lazer Posté(e) le 15 décembre Auteur Signaler Posté(e) le 15 décembre Oui j'ai bien des devices de type courant, je t'avais justement partagé ma capture d'écran de ma console qui est OK. Je ne peux pas télécharger ton fichier, mais si tu mets ça n'importe où dans le fichier config.js ça ne risque pas de fonctionner ! Regarde la structure du fichier, tu verras vite où il faut ajouter les 2 lignes... tu as normalement déjà des 10zaines de lignes pour les temperatures, humidiité, voltage, etc... C'est dans le tableau : const chartsConfig = [
jojo Posté(e) le 15 décembre Signaler Posté(e) le 15 décembre GENIAL ! En effet, je me disais bien que ajouté n'importe où ce n'était pas bon. Chez moi je n'avais pas const chartsConfig = [ mais var chartsConfig = [ qui n'avait pas les entrées que tu m'as dites. Je crois savoir d'où provient l'erreur. J'avais rechargé le fichier .zip du premier post, mais c'est la v7.00. Or maintenant tu as sorti la v7.11 qui corrige des bugs, ... C'est donc peut-être parce que j'utilise cette première version du php que j'ai toutes mes erreurs, dont celle de la non connection en entrant l'IP de mon NAS ? Peux-tu adapter le premier post ? MERCI en tout cas, maintenant j'ai l'historique de mes intensité !
Lazer Posté(e) le 15 décembre Auteur Signaler Posté(e) le 15 décembre (modifié) Tu veux modifier quoi dans le 1er post ? SI j'en crois ce qui est écrit : Le QA est en v7.11, mais les pages Web n'ont pas été touchées et toujours en 7.0 Après si tu joues à l'apprenti sorcier avec tes fichiers, pense à faire des copies de sauvegarde pour revenir en arrière... là je ne peux pas faire grand chose pour t'empêcher de faire des bêtises. Notamment depuis 2 posts tu parles d'IP de ton NAS, ça n'a aucun rapport avec le problème des graphiques de courant dont il est question. EDIT : chez moi les graphiques de courant fonctionnent car j'ai dû faire la modification de mes fichiers de config. Peut être même qu'on en a déjà parlé quelque part sur le topic... je ne me souviens plus, il faudrait rechercher. Modifié le 15 décembre par Lazer
fredokl Posté(e) le 15 décembre Signaler Posté(e) le 15 décembre (modifié) Je pense que @jojoparle du fichier 'domochart_v7.0.zip' car dans le fichier config.js la ligne 'const chartsConfig = [' n'y est pas mais c'est 'var chartsConfig = ['. Chez moi c'est pareille. peut-être utilises-tu une version non distribué? EDIT: @Lazer, nos messages se sont croisés. Modifié le 15 décembre par fredokl
Lazer Posté(e) le 15 décembre Auteur Signaler Posté(e) le 15 décembre Oui désolé pour l'histoire du const versus var c'est parce que j'ai modifié mon fichier, mais c'est pas important, c'est vraiment du détail, c'est une micro-optimisation que j'ai faite, et effectivement non partagée.
Messages recommandés