yves.guern

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

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

Sans enfoncer des portes ouvertes... En fait il y a aussi un détecteur de porte ouverte/fermée et l'alarme n'est enclenchée que si la serrure est actionnée 'juste après' la fermeture de la porte. Jusque là cela marche (même quand nous prêtons la maison).

Bonjour, Pour résoudre cela j'ai mis un switch au fond de la serrure qui détecte que l'on a donné un tour de clef. Au bout d'une minute HC3 enclenche l'alarme.

Bonjour Chistb Voici un bout de code pour commencer. Comme dit Lazer, côté Fibaro, la finition de cette fonctionnalité laisse à désirer (valeur par défaut en particulier) function QuickApp:onInit() -- .../... -- exemple pour mettre trois choix dans une droplist nommée "DropBtn" : -- (le champ 'text' est celui que l'on voit sur l'UI, le champ value est ce qui est retourné par l'évennement) local tOptions = {{text="Choix1",type="option",value="1"}, {text="Choix2",type="option",value="2"}, {text="Choix3",type="option",value="toto"}} self:updateView("DropBtn", "options", tOptions) self.sCurrentChoice = tOptions[1].value -- .../... end function QuickApp:onDropBtn(evt) self.sCurrentChoice = evt.values[1] --peut valloir "1","2" ou "toto" -- .../... end

Bonjour, Est-ce que l'un d'entre vous a remarqué une nouveauté: .../... Quick Apps Improved auto-naming of QuickApp elements and labels. Added switch support. Added dropdown list support. .../... Je viens de l'essayer, cela fonctionne pas mal, on peut même changer la liste des choix 'au vol'. MAIS: je n'arrive pas à forcer (rendre visible sur le bouton) la valeur par défaut au démarrage de l'application (ou au changement de la liste). Quelqu'un a-t-il déjà joué avec cette nouveauté?