yves.guern

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?