yves.guern

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

Bonsoir Sakkhho, Oui les adresses que j'ai proposées et ce qu'il faut en attendre fonctionnent toujours comme indiqué. J'utilise les morceaux de code de mon post dans une 'qa à moi' il faudrait donc les adapter pour les mettre ailleurs. Je ne suis pas chez moi avant 2 semaines; s'il faut que je participe à cette adaptation il faudra être patient...

Bonjour à tous, Oui EDF a changé l'adresse et le contenu des info "tempo". et, en prime, il y a eu un bug 'façon stagiaire' le 31 aout, toujours pas corrigé le 1er sept (pour cause konétè dimanche)? probablement lié au fait que c'est le 1er Sep que le calendrier Tempo change... Maintenant c'est stable. Depuis 3 jours... Pour la couleur du jour ou du lendemain: j'utilise une nouvelle adresse qui retourne le calendrier des jours 'en cours' ou plus exactement entre deux dates à fournir dans l'url. Le code est le suivant: local curtime = os.time() local sDemain = os.date("%Y-%m-%d",curtime+86400) local sPremier = os.date("%Y-%m-%d",curtime-6*86400) URL = https://api-commerce.edf.fr/commerce/activet/v1/calendrier-jours-effacement?option=TEMPO&dateApplicationBorneInf="..sPremier.."&dateApplicationBorneSup="..sDemain.."&identifiantConsommateur=src EDF retourne alors un tableau des couleurs qui va de sPremier (il y a 6 jours dans mon code), à sDemain. Chaque élément du tableau retourné (dans json.decode(response.data).content.options[1].calendrier) contient un champ "dateApplication" qui est la date du jour en question (pour contrôle?) et sa couleur dans le champ "statut" sous la forme "TEMPO_XXXX", XXX étant la couleur du jour RQ: Je ne demande qu'un nombre restreint de jours pour limiter la taille du message à recevoir/traiter, objectivement 6 c'est déjà trop, 2 suffiraient !!! Et, quelque soit la valeur de sPremier, les données qui nous intéressent (aujourd'hui et Demain) sont les deux dernières valeurs du tableau retourné) MAIS L'utilisation brutale de l'url ci dessus provoque le message d'erreur signalé plus haut: {"errors":[{"code":"ATM_HTTP_400","description":"La syntaxe de la requête est erronée.","severity":"ERROR","type":"TECHNICAL"}],"content":null} J'ai (donc) ajouté un header à la requête en recopiant (presque) celui vu sous firefox. C'est une copie bête! L'ensemble des champs ne doit pas être utile mais cela fonctionne: function QuickApp:onInit() .../... self.EDFoptions={checkCertificate=false,method='GET',timeout=5000, headers = { ["Host"] = 'api-commerce.edf.fr', ["User-Agent"] = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0', ["Accept"] = 'application/json, text/plain, */*', ["Accept-Language"] = 'fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3', --["Accept-Encoding"] = 'gzip, deflate, br, zstd', ["Referer"] = 'https://particulier.edf.fr/', ["content-type"] = 'application/json', ["Situation-Usage"] = 'Jours Effacement', ["X-Request-Id"] = tostring(curtime)..460, ["Application-Origine-Controlee"] = 'site_RC', ["Origin"] = 'https://particulier.edf.fr', ["Sec-Fetch-Dest"] = 'empty', ["Sec-Fetch-Mode"] = 'no-cors', ["Sec-Fetch-Site"] = 'same-site', ["Connection"] = 'keep-alive', ["TE"] = 'trailers', ["Priority"] = 'u=4', ["Pragma"] = 'no-cache', ["Cache-Control"] = 'no-cache' }} self.http = net.HTTPClient({timeout=20000}) .../... end function getEDFData(self) local sDemain = os.date("%Y-%m-%d",curtime+86400) local sPremier = os.date("%Y-%m-%d",curtime-6*86400) local url = "https://api-commerce.edf.fr/commerce/activet/v1/calendrier-jours-effacement? option=TEMPO&dateApplicationBorneInf="..sPremier.."&dateApplicationBorneSup="..sDemain.."&identifiantConsommateur=src" self.EDFoptions.headers["X-Request-Id"] = tostring(curtime)..460 self.http:request(url,{ options = self.EDFoptions, success = function(response) self.webData = json.decode(response.data) self.tCalendar = self.webData.content.options[1].calendrier ..../..... error = function(response) ..../..... }) end J'ai commenté ["Accept-Encoding"] = 'gzip, deflate, br, zstd', car sinon le site EDF encode la réponse et, avec le lua de la HC3, je suis comme une poule avec un couteau, ce sera le sujet d'une autre question.... Notez le champ du header "X-Request-Id" qui n'est pas un champ fixe du header et qui doit(?) être mis à l'heure unix (en ms) à chaque appel Avec cela j'ai retrouvé le fonctionnement normal que j'avais avec l'url d'avant: local curtime = os.time() url = "https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=" self.http:request(url..(os.date("%Y-%m-%d",curtime)).."&_="..curtime.."542",{ options={checkCertificate=false,method='GET',timeout=5000}, ..../.... L'adresse https://api-commerce.edf.fr/commerce/activet/v1/saisons/search?option=TEMPO&dateReference=2024-09-03 donne le nombre de jour restant pour chaque couleur. Le retour est un Json: errors [] content 0 typeJourEff "TEMPO_BLANC" libelle "TEMPO BLANC 2024 2025" nombreJours 43 premierJour "2024-09-01" dernierJour "2025-08-31" premierJourExclu null dernierJourExclu null nombreJoursTires 0 etat "OUVERTE" 1 typeJourEff "TEMPO_BLEU" libelle "TEMPO BLEU 2024 2025" nombreJours 300 premierJour "2024-09-01" dernierJour "2025-08-31" premierJourExclu null dernierJourExclu null nombreJoursTires 4 etat "OUVERTE" 2 typeJourEff "TEMPO_ROUGE" libelle "TEMPO ROUGE 2024 2025" nombreJours 22 premierJour "2024-11-01" dernierJour "2025-03-31" premierJourExclu null dernierJourExclu null nombreJoursTires 0 etat "NON_COMMENCEE" Notez, si vous êtes pointilleux, qu’après 11h cela vous donne le nombre de jours 'consommés' en date du lendemain. C'est en fait la somme des jours "Tirés" par EDF à l'heure de l'interrogation. Du coup je ne suis pas bien sûr de la signification de la date que l'on doit donner dans l'URL.... notez que 'utilise le même header mais qu'il n'est pas nécessaire.

Bonjour Lazer, Sous firefox et chrome l'affichage du nombre de pages d'un sujet est curieux/incomplet: les boutons Suivante/ Précédente & Premiere page /Dernière page (ainsi que les numéro de page) sont bien là mais invisibles Encore plus Ouf: cela n'est pas vrai sur tout les sujet, par exemple celui dans le quel je post cette remarque ???? Ya que moi?

Je me joins à jojo pour te remercier !!!!

Au fait: on parle de combien ? C'est en € ou en k€/an?

Le deuxième paragraphe est forcément celui qui coince le plus! Pour le premier j'ai peut être une solution: du cash sous enveloppe :-) ? Une auto entreprise est-elle une 'solution' (malgré 20% de 'pertes') Et si les donateurs donnent directement au fournisseur final? Au moins la première année cela doit pouvoir se faire? A+

Bonjour, J'ai 2 PC sous windows 10 (à jour) et firefox (à jour) l'un me permet d'accéder à ce forum l'autre pas. Après avoir vérifié quelle différence pouvait expliquer cela j'ai conclu que c'est parce que je ne me suis pas déconnecté du forum avec le PC 'qui fonctioonne'. Je crois comprendre que j'enfonce une porte ouverte en lisant les post de Lazer... Donc, pour donner un peu d'intérêt à ce post: Si besoin, je participerais à la levée de fonds pour la survie du site. A+

Bonjour Lazer, A la suite de ton post: Je me permet: 1) de te remercier d'avoir découvert self:updateView("NomDuBouton","selectedItem","toto"), pour moi c'est tout ce qu'il manquait pour rendre cette fonctionnalité réellement utilisable. => comment as tu fait? ou as-tu appris le polonais (dans une notice de calculatrice HP)? 2) de te 'corriger' à propos des listes de choix dynamiques/statiques: on peut utiliser un chargement dynamique de la liste avec self:updateView("NomDuBouton", "options", Liste_d_Options) mais il ne faut appeler cette fonction "qu'une fois". Effectivement à chaque appel, la sélection précédente disparait (sauf à appeler ensuite ta fonction magique!) Donc il ne faut appeler self:updateView("NomDuBouton", "options", Liste_d_Options) que si la liste d'option a effectivement changé (et surement pas dans la callback associée au bouton de la liste...) Mais désormais, associé à ta fonction il y a moyen de faire ce que l'on souhaite! Je viens de modifier 2 de mes QA en ce sens et c'est très BÔ! Une d'entre-elle permet de modifier les paramètres de configuration des devices sans template. Il y a 2 listes dynamiques dans la QA: L'ID du device et le N°du paramètre (dont la liste varie en fonction de l'ID) Merci! Bonne journée

Je suis d'accord avec jojo (je ne suis pas sûr que ce soit une info importante en soi...) Effectivement mélanger les fonctions je suis trop 'vieux' pour y faire 100% confiance. A VTT j'ai un (vrai) GPS sur mon guidon et un téléphone dans la poche "au cas où". Trop méfiant ou trop riche, c'est vrai que la question se pose? Pour revenir au sujet: mon HC3 (et avant HC2) ne fait qu'appuyer sur le bouton 'mise en marche' de la télécommande d'une alarme dont la marque commence par 'Diag'. Un 'push' sur mon téléphone confirme que l'alarme en question a été activée ou pas. Le désarmement est manuel, indépendant de Fibaro-Nice et même de FibraceDeNice