yves.guern

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é?

Bonjour, Comme dit plus haut, j'ai soupçonné le HTTPClient de la HC3 de ne pas être compatible des réponses de type "Transfer-Encoding": " chunked" (ie réponses qui arrivent par morceaux). En fait, une fois enlevé le 's' qui était en trop dans un cookie, cela fonctionne très bien et de façon transparente (on récupère le paquet entier d'un seul coup)! Comme d'habitude le problème se situait entre clavier et chaise. Maintenant j'interroge ma LiveBox 5 sans intermédiaire depuis la HC3. En plus des "données de base" (IP,état du téléphone, de la télé,...) je récupère également des infos sur le débit réel montant/descendant. Merci pour vos coups de main

Merci Lazer d'avoir poussé ma curiosité jusqu'à lire jusqu'au bout (et en détai)l le résultat de --/-- success(response) print(response) end, --/-- Cela et F12, il y a effectivement tout ce qu'il faut pour manipuler les 'gateaux'. Je n'ai plus besoin du Nas pour interroger ma Livebox et récupérer son IP, je considère que c'est un progrès !!! Je vais quand même me permettre de continuer à faire diverger ce sujet: Il y a un http:request vers la Livebox qui me répond en mode "Transfer-Encoding: chunked" Donc je ne récupère rien ou pas grand chose d'autre que le header (et c'est d'autant plus frustrant que les data font moins de 500 bytes)! Le header de mon request indique que je ne connais que ["Accept-Encoding"]= 'gzip, deflate' , cela n'a pas l'air d'intéresser mon correspondant... Il existe des solutions sous connexion TCP mais apparemment la livebox5 ne propose pas de serveur TCP. Et avec les mots clefs http et Chunked je n'ai pas trouvé de piste sur les forum Ce n'est pas indispensable mais serait utile pour surveiller le trafic (en byte/s) de la connexion... Si vous avez une idée...

Bonsoir, Je suis légèrement en train de vendre la peau de l'ours (mon test n'est pas encore assez long) mais cela semble fonctionner (ie avec un self.http). Le bug était bien entre le clavier et la chaise ! Finalement le plus extraordinaire était que cela fonctionne 500 fois ou plus avant de planter, la même chose en C aurait explosé au premier essai. Cela fait partie des mystères de LUA et de son Garbage Collector . En tous cas merci à vous deux! Je profite de votre attention pour poser une question qui n'a qu'un rapport indirect La récupération de l'adresse IP externe de ma LiveBox5 se fait par 4 ou 5 requêtes http. La première utilise un cookie que je n'ai pas su 'manipuler' avec la HC3, je passe donc par un php sur mon NAS pour le faire (script interrogé par l'une des 3 QA qui plantent plantaient) L'un de vous a-t-il eu a faire à ce genre de requête à cookie et trouvé une solution 100% HC3?

Merci, je vais commencer par là...

Ma correction a croisé ta réponse avec laquelle je suis bien d'accord...

Bon alors il ne me reste que l'hypothèse 1 (réponses mal formées...) car les QA qui plantent n'ont qu'un request... Cela ne va pas être beaucoup plus facile à identifier est ce que d'instancier net.HTTPClient à chaque appel en utilisant fonction CallHttp( ...) local http = net.HTTPClient({timeout=10000}) http:request( ../.. end plutôt que: self.http = net.HTTPClient({timeout=10000}) fonction CallHttp(self, ...) self.http:request( ../.. end pose un problème? (pour l'instant je suis sur la 1ere version)

Sur le premier point: le log des réponses fait sur le nas ne montre pas de message mal formé, cela ne garanti pas qu'il ne le soit pas à 100% Sur le second: Qu'appelles tu requêtes parallèles? Est-ce que 2 QA différentes qui postent une requête http en même temps tombe sous cette dénomination? (est-ce que 2 destinations http différentes change la chose?) Si c'est le cas tu viens de me mettre sur une piste très sérieuse/probable: 3 QA qui font 500 requêtes/jour chacune, plus les autres qui en font beaucoup moins mais quand même, ce serait bien le diable s'il n'y en avait pas 2 simultanées tous les 2 jours... Existe-t-il une solution 'élégante' autre que faire passer toutes les requêtes http par une QA qui ne ferait que cela? Merci

Bonjour Lazer, Non, ce que je voulais dire c'est que les 2 pcall des callback n'attrapent rien, ni succès ni erreur en fait elles ne semblent pas appelées Le request proprement dit est bien envoyé au Nas (et executé) Mais la QA semble se planter juste avant l'appel de l'une des callback success ou error du request (et cela environ 1 fois sur 500...) Bonne journée

Bonjour, J'ai besoin d'idées, celles que j'ai vue sur le forum n'ont pas suffit... Je suis passé récemment de HC2 à HC3 et j'ai quelque chose qui tourne bien, de façon stable depuis juillet. 'Stable' ou presque : sur une trentaine de QA, 3 plantent régulièrement (au moins une fois toutes les 48h) avec cette merveilleuse sortie console: [28.11.2023] [13:35:47] [ERROR] [QUICKAPP167]: QuickApp crashed [28.11.2023] [13:35:47] [ERROR] [QUICKAPP167]: Unknown error occurred: Sortie console qui fait bien avancer les choses et oblige à passer en mode Sherlock Je suis passé au firmware 5.150.15 il y a une semaine avec beaucoup d'espoir, mais non, aucun changement. Le point commun de ces 3 QAs est de lancer des requêtes (GET ou POST) vers mon NAS (synology) régulièrement (ie toute les 5 mn soit 300 appels/jour). Ces requêtes lancent des scripts en php. Aucune des autres QA n'utilise le NAS. Et le nombre d’éventuels request/jour effectué est plus limité. J'ai fini par mettre des pcall partout comme Lazer l'explique ici: A savoir: un pcall sur le http:request et 2 sur fSuccess() et fError() (ie les callback success() et error() appellent, sous pcall, des fonctions locales fSuccess() ou fError()) Le NAS log les réponses qu'il a envoyé à la fin de l’exécution du request par le NAS A la fin, en cas de plantage, voici ce que j'observe: le http:request se déroule correctement et rend la main comme attendu. le log du NAS montre que la réponse préparée est bien celle 'attendue' dans des temps constants (<1s) cela semble planter avant l'appel des callback success() ou error() qui commencent par un self:debug("Johnny was here"). => donc le bug n'est pas directement dans mon jardin mais plus profond. Même s'il doit se trouver quelque part entre le clavier et la chaise... D'autre que moi ont-ils eu ce soucis? Vous remerciant par avance... PS: J'oubliais de dire qu’après un rebooot de la box (mais pas lors d'un redémarrage ultérieur de la QA), les requests plantent systématiquement pendant 2mn environ: c'est un début de piste?

Bonjour, A propos de RefreshStateSubscriber et de ceux qui n'en voient pas l’intérêt : L'intérêt est clair: plus aucune scène nécessaire => le code des QA intègre les conditions de déclenchement, il est donc plus facile à lire/maintenir (et on a probablement meilleure réactivité?). Je viens de passer mon HC2 en HC3 et j'ai enlevé ma dernière scène il y a 1 mois (*) Etant (encore) sous 5.130.64 je n'avais pas accès à RefreshStateSubscriber mais j'utilise intensivement la librairie fibaroExtra (de jgab ) et en particulier ses fonctions fibaro.event qui semblent équivalentes, avec une syntaxe a priori plus simple. (https://forum.fibaro.com/topic/54538-fibaroextra/?do=findComment&amp;comment=233501). Donc, pour moi une fonctionnalité du type RefreshStateSubscriber n'est pas une question, c'est un requis . (*) Je pense avoir une version 'stable & kiMarche' depuis 6 mois, la scène que j'ai retirée récemment ne concernait que le démarrage de la HC3. Mon installation a une 50aine de noeuds Z-Wave et une 30aine de QAs

Bonjour, Python c'est un peu âpre au début mais on s'y fait :-) Et aucun doute que cela tourne sur un Synology... Ajouter les icônes de room ne devrait pas être un problème, je peux donner un coup de main Bonne journée

Rebonjour, Je n'avais pas assez testé le cas ou plusieurs QA renouvellent leur icone => yavait un bug dans l'exemple de code Lua Corrigé en V1.0.2