yves.guern

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

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+