yves.guern

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)

Bonjour Lazer, Pour current j'avais pas vu et c'est pourtant un sujet que je suis... Pour water c'est juste que la table water n'est pas tronquée régulièrement, water_day et water_month sont bien mises à jour. Il ne manque donc que 2 lignes...

Bonjour, J'ai trouvé un bug dans Domochart (je travaille beaucoup avec, je ferais d'ailleurs quelques post plus tard...) Les données concernant le courant stockées dans domocharts_current et celle concernant l'eau (domocharts_water) ne sont pas mise a jour par le code inclus dans trends.php. Moralité: elles grandissent indéfiniment... La solution est de rajouter ces lignes dans trend.php, ligne 313 juste avant //*** Gas concentration array_push($response['data'], ExecuteQuery($bdd, 'DELETE FROM domocharts_water WHERE DATE(time) < SUBDATE(CURDATE(), '.$db_interval_water.')')); array_push($response['data'], ExecuteQuery($bdd, 'OPTIMIZE TABLE domocharts_water')); //*** Current array_push($response['data'], ExecuteQuery($bdd, 'DELETE FROM domocharts_current WHERE DATE(time) < SUBDATE(CURDATE(), '.$db_interval_current.')')); array_push($response['data'], ExecuteQuery($bdd, 'OPTIMIZE TABLE domocharts_current')); //*** Gas concentration RQ: les paramètres utilisé par ces lignes (db_interval_water et db_interval_current) sont bien déjà définis dans config.inc.php Bonne journée

Bonjour Lazer, Merci pour ta réponse... J'avais oublié que ce n'est effectivement qu'un surligneur (mais pratique). Quant à CtrlF je n'y avais même pas pensé et ce d'autant moins qu'il ne marche pas sous le web-éditeur de code. Mais dans la console c'est top! Bonne journée

Bonjour, Je déterre un vieux sujet plutôt que d'en ouvrir un nouveau... Chez moi le filtrage des sorties sur la console par la recherche d'un mot dans les résultats ne fonctionne plus. La case 'trouver' existe encore: on peut y mettre 'qqchose' et c'est bien pris en compte dans la requête : https://hc3-000xxxxx/logs?search=QQCHOSE&tag=QA_CHAUFFAGE(348)&type= Mais cela ne filtre rien... (Les filtrages par Tags et Type fonctionnent!) Je suis maintenant en V5.160.42 mais il y a déjà longtemps que cette fonctionnalité ne fonctionne plus (sous entendu qu'elle a marché au début) Je m'en passais jusque là mais aujourd'hui j'en aurais un gros besoin Ya que moi?

Bonjour, A priori ton (second) schéma est bon. Je n'utilise pas ce module de contrôle là (plutôt des fgs 214 ou 222) mais leur programmation doit être la même (dans l'esprit)... Il doit/peut y avoir des paramètres pour: dire que l'entré est reliée à un 'momentary switch' Operating mode ou auto off ou flashmode,... à standard ou off selon le paramètre Si tu donne la référence de ton switch on pourra regarder... Au passage: pour moi un fibaro walli switch c'est un engin Zwave, donne aussi la référence: lui aussi doit être paramétrable bonne journée

Bonjour Jojo, Je ne garanti pas à 100% que ce qui suit va fonctionner pour toi, mon utilisation n'est pas 100% celle là... Il y a probablement une solution (au moins un début) en utilisant le champ "userDescription" qui est présent dans les properties de chaque device. C'est un champ libre ou chacun peut y écrire ce qu'il souhaite. Ce qui est intéressant c'est que domochart peut filtrer les devices qu'il cherche selon ce champ. Il y a 2 ou 3 chose à faire: dans domochart.lua modifier la définition des devices à récolter et installer ce filtre suplémentaire: -- là ou tu as ajouté tes définitions, ajouter un field 'userDescription' : { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto", userDescription="heat" , visible = "true", dead = "false", property = "heatingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID HeatingDevices setpoints { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto", userDescription="cool" , visible = "true", dead = "false", property = "coolingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID CoolingDevices setpoints --autour des lignes 597 il y a la définition des filtres: -- Get datas from API local typeFilter = sensor.fibaroType and ("&type=" .. tools:urlencode(sensor.fibaroType) ) or "" local visibleFilter = sensor.visible and ("&visible=" .. tools:urlencode(sensor.visible) ) or "" local interfaceFilter = sensor.interface and ("&interface=" .. tools:urlencode(sensor.interface) ) or "" local parentFilter = sensor.parentId and ("&parentId=" .. tools:urlencode(sensor.parentId) ) or "" local unitFilter = sensor.unit and ("&property=[unit," .. tools:urlencode(sensor.unit) .. "]") or "" local deadFilter = sensor.dead and ("&property=[dead," .. tools:urlencode(sensor.dead) .. "]") or "" local energyFilter = type(sensor.showEnergy) == "boolean" and ("&property=[showEnergy," .. tostring(sensor.showEnergy) .. "]") or "" -- il faut y ajouter la ligne: local usrDscFilter = sensor.userDescription and ("&property=[userDescription," .. tools:urlencode(sensor.userDescription) .. "]") or "" -- et modifier la ligne 610 (à peu près 610...) local url = "/devices?enabled=true" .. typeFilter .. visibleFilter .. interfaceFilter .. parentFilter .. unitFilter .. deadFilter .. energyFilter -- pour y intégrer ce nouveau filtre: local url = "/devices?enabled=true" .. typeFilter .. visibleFilter .. interfaceFilter .. parentFilter .. unitFilter .. deadFilter .. energyFilter .. usrDscFilter dans ton code de gestion/surveillance de la PAC Il ne reste plus qu'à lui faire écrire le mot cool ou heat dans le champ userDescription selon le mode de la PAC. Quelque chose du genre: if (CurModeHeatCool ~= LastModeHeatCool) then begin for CooltargetIds = ..... do begin fibaro.call(CooltargetIds, "setProperty", "userDescription",(CurModeHeatCool=="Cool") and "cool" or "heat") LastModeHeatCool = CurModeHeatCool end end En espérant que cela fonctionne pour toi

En fait je posais la question paskeu j'ai une "vielle" HC2 dont je ne me sert plus et quelqu'un me demande 'si elle a beaucoup servi'. Vu que l'usure du disque dépends beaucoup du nombre d'écriture et que j'avais fait beaucoup d'effort à ce sujet, je me demandais s'il y avait une façon 'objective' de répondre à cette question...

Bonsoir, Je profite de ce sujet pour poser une question (d'un coup d’œil rapide je n'ai pas vu que cette question est déjà venue sur la table...) Est-ce qu'il y a un moyen de chiffrer la santé d'un HC2 (ou HC3) et en particulier du disque? PS: Avant qu'il ne crashe A+

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!

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

Bonjour Lazer, Depuis 6 mois, j'utilise domochart (vers un NAS Synology) et je trouve cette QA géniale. J'utilise autre chose que grafana pour la visualisation mais c'est la seule "modification" que j'ai faite. Cela m'a permis de corriger et optimiser certaines QA qui ne l'étaient manifestement pas... A propos de temps CPU je pense avoir repéré un bug dans la fonction tools:garbage(interval) inclue dans le zip Initialement, je cherchais à diminuer le nombre de débug à la console et je me suis aperçu qu'il y a un désaccord entre la sortie de domochart sur sa consommation de CPU (en%) et la valeur obtenue par l'utilisation de collectgarbage("collect") ou de api.get("/diagnostics"): un facteur 4. Pour moi, dans print(cpuDelta/elapsedTime*100/self.nbCPUs), la division par le nombre de cœurs n'est pas nécessaire/significative: 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. Dit autrement: 4 cœurs à 100% = 1 CPU à 100% ?

Bonjour Sakkhho, Comme demandé, voilà en pièce jointe un extrait de mon code. (C'est un extrait, pas un fqa qui fonctionne...) J'ai laissé l'initialisation des variables, les deux fonctions qui interrogent EDF et celles qui décodent les réponses. A titre d'info j'ai laissé aussi la construction des messages pour l'interface à partir des données décodées. J'ai ajouté quelque commentaires... Je suis de retour à la maison donc je peux répondre 'rapidement' s'il y a des questions. QA_Tempo.lua