vravolta

Alors, quelques avancées: en virant le smart implant et en le rajoutant, je retrouve bien les paramètres 20 et 21. Le truc qui les fait disparaitre, c'est quand je passe le capteur de monostable à capteur multiniveau (avec pull-up). Pourquoi je fais ca? Car en mode monostable, je n'ai aucun event qui remonte quand le contact est fermé. Celà dit, ma solution n'en est pas une: quand j'approche un aimant de mon capteur, ca ferme le contact (je suis sur que ca fonctionne car j'ai testé à l'ohmmètre), j'ai en un premier temps une valeur plus faible que 10V qui remonte sur la box (typiquement entre 1 et 2V) et 30 secondes après, j'ai une valeur à 10V qui remonte. C'est à peu près cohérent avec ce que j'attends: quand le contact est ouvert, la résistance de pull-up doit appliquer 10V aux bornes d'input 1 et quand il se ferme, on devrait avoir 0. Je suspecte qu'il faut un petit temps pour arriver à 0 et que le rapport part un peu avant que ca n'arrive. Mais ce qui me pose problème, c'est que si je fais plusieurs contacts pendant les 30 s avant que ca ne repasse à 10V sur la box, je n'ai qu'un seul event qui remonte au lieu de plusieurs. Il doit donc y avoir un souci de paramétrage mais je n'ai rien trouvé de probant à ce stade: le paramètre 63 est à 2V et donc à chaque fois que je passe de 10 à moins de 8V, normalement, ca devrait déclencher un rapport. Je ne trouve nulle part de paramètre dont la valeur serait 30 s et expliquerait pourquoi le rapport qui signale le retour à 10V n'arrive qu'après 30 s et pas juste après avoir vu passer l'aimant. Si quelqu'un a une idée de comment paramétrer un smart implant pour qu'il remonte des impulsions de moins d'une seconde, je suis preneur...

J'ai le paramétrage suivant: Je devrais donc avoir un des 2 paramètres 20 ou 21 visibles. Pourtant, ca commence seulement à 24: J'ai donc bien un truc qui ne tourne pas rond dan mon histoire.

J'explore en ce moment une piste: le smart implant dispose de fils bleus annoncés comme étant GND. Mais en les mesurant à l'ohmmètre, il n'y a pas de continuité entre les 2. Je vais donc essayer de tout recabler en n'utilisant que celui se trouvant du coté des entrées = pas celui proche de l'antenne qui n'est jamais utilisé dans aucun schéma de la doc. A voir si ca change quelque chose...

Oui, ces parametres sont bien en place. Cela dit, mon setup est que sur IN1 j'ai un interrupteur magnétique qui se ferme chaque fois qu'un litre passe à travers le compteur. Il n'a donc pas de tension en tant que tel et je ne vois pas trop à quoi sert dan ce cas le seuil de 0.1V. C'est sur IN2 que là j'ai un signal analogique 0-10V qui me donne le niveau de la cuve. Mais lui, j'arrive à le faire fonctionner. Actuellement, j'essaie d'adapter un truc à base de ce tuto Connexion d'un compteur d'eau Gioanola à une centrale FIBARO HC3 qui semble suggérer qu'il faudrait lier IN1 avec OUT1 puis récupérer l'action d'OUT1 pour déclencher l'incrément de la variable globale de compteur. J'avoue que je suis un peu dérouté ici car je croyais que ces OUT servaient à commander physiquement via le bornier du Smart implant des appareils, pas à être utilisé pour générer un évènement qui lui même permet d'incrémenter le compteur. Mais de ce que je vois sur mon setup, c'est que quand je lie IN1 avec OUT1, jamais OUT1 ne se ferme car le device qui semble me remonter un signal du compteur - le smart implant en crée un gros paquet - ne semble pas être IN1. A un moment, en enlevant la coche "utiliser un modèle", j'ai vu apparaitre le paramètre 20, mais désormais, ce n'est plus le cas. Bref, je tâtonne et j'espère que je vais finir par trouver un truc qui fonctionne.

Tout est dit dans le titre ou presque: je vien d'installer un smart implant FGBS 222. Il a en première entrée un ignal analogique 0-10V qui correspond au niveau d'une cuve. A intervalle réguliers, mais pas constant, je vois apparaitre dans l'historique de ma HC3 la valeur en volts. Le device créé lors de l'inclusion du smart implant n'est pas top: il y a bien un paramètre avancé qui permet de choisir un affichage en litres et de dire à combien de litres correspondent 10V, mais pour une raison que j'ignore, quand je fais ca, ca change l'affichage de mon ID 324 alors que je recois dans l'historique de la box le relevés de tension sur l'ID 323 et je ne vois pas comment soit changer l'ID qui bénéficie de la conversion, soit dire à mon ID 324 d'utiliser le signal envoyé par le 323. Bref, ce smart implant me semble un peu trop smart et surtout pas documenté (la doc fournie parle de partout de paramètre 20 mais je ne vois que des paramètres d'ID au delà de 20 et il semblerait que dan la version actuelle des smart implants, ce qui était géré dans les paramètres du début ait été transféré de manière non documentée dans les paramètres avancés du device parent => bref, je ne doute pas que c'est très smart, mais du smart sans doc du comportement, c'est difficile à gérer). Tout ca pour dire que je change mon fusil d'épaule: comme je sais que je recois régulièrement le niveau de la tension sur mon ID 323, mon idée et de faire un quickapp de type senseur multiniveau qui à chaque publication de la valeur de l'ID 323 update sa valeur à lui que je peux ensuite afficher avec le format qui me convient, en l'occurrence dan mon cas, l'idée est d'avoir un slider qui représenterait les pourcentages visuellement avec au dessus, une indication en litres. J'imaginais que c'était un truc qui se ferait en 20 secondes et que des milliers d'utilisateurs l'avaient déjà fait, mai soit je cherche avec les mauvais mots clefs, soit il n'y a rien. C'est plus tricky qu'il n'y parait car il faut trouver ou capturer l'évènement de mise à jour de la valeur du 323 dans la box. Et à part via un scénario, mai je ne vois pas encore précisément trop comment l'écrire, je ne vois pas trop. Par ailleurs, d'un point de vue propreté du setup, je préfèrerais avoir un truc entièrement dans une quickapp plutot que plein de bouts qui se parlent. Après, j'aurai aussi la gestion du compteur à effectuer. Là aussi, je trouve étrange de ne pas trouver dans le monde fibaro de QA toute faite pour catcher un compteur d'impulsion et en faire un affichage cumulé. J'entends bien que ce n'est pas insurmontable de se créer une variable rémanente, d'aller chercher les incréments du générateur d'impulsion, d'appliquer le facteur de conversion, mais on sait tous qu'il y a des manières plus ou moins optimales de le faire avec plus ou moins d'effets de bord et c'est étonnant de ne pas avoir ca sur le marketplace par exemple. Donc si quelqu'un a déjà un code qui fait ca et qui est éprouvé, je suis volontiers preneur, histoire de ne pas perdre du temps à réinventer la roue. Cela dit, pour le moment, mon problème est que mon smart implant ne me remonte pas les impulsions du compteur. Là encore, on recoit du hardware ans aucune doc du fonctionnement et on doit imaginer. A force de lire des pots de personnes ayant implémenté le même compteur, j'ai fini par comprendre que c'était un bête interrupteur magnétique qui se ferme quand un aimant je suppose intégré à mon compteur, passe devant.

Alors au début, j'étais parti sur le fait de remplacer le rotacteur par des relais, ce qui aurait été moins usine à gaz qu'un moteur qui fait tourner un bouton. Mais en fait, le rotacteur a été coulé avec toute une carte de commande dans de la résine (tropicalisé) et donc on ne peut pas accéder à ses contacts sans tout casser. Ensuite, je suis en Suisse où tout ce qui fait du feu est entretenu par un ramoneur officiel et qui n'acceptera en pratique pas de modifications internes d'un appareil homologué comme une chaudière. Donc soit il faut que la modification soit indétectable quand il ouvre la bête pour la contrôler, soit il faut que ce soit "par dessus". Ce qui est étonnant, c'est que les servo de radiomodélisme sont éprouvés, peu chers et ultra répandus tout en ayant plein d'usages et un protocole super simple de commande. Et apparemment, personne n'a songé à ce stade à commercialiser une passerelle entre notre Z-Wave et le protocole de commande des servos. En cherchant sur le web, on voit bien que plein d'amateurs bidouille des choses à base d'arduinos ou ce genre de choses, mais aucun fabricant avec un support digne de ce nom ne semble proposer la chose.

C'est physiquement ce type de chose qu'il me faut. Mais le pilotage par la durée me semble hasardeux et ce d'autant plus que le bouton peut être aussi tourné à la main. Donc il me faut ce principe là, mais avec une logique qui sait évaluer la position effective du servo, exactement comme avec un servo de modélisme. Ces servos coutent une misère (environ 5 EUR en Chine pour des modèles de qualité avec fort couple (2Nm), pignonerie métal et vitesse d'environ 0.1s pour parcourir 60 degrés) et donc ce n'est pas très difficile conceptuellement de faire un bridge entre leur protocole de commande (une série de créneaux dont le ratio temps haut/temps bas donne la position que le servo doit rejoindre) et nos protocoles domotique. On pourrait imaginer un module avec une valeur allant de 0 à 100% en lecture écriture. Si j'écris dedans une valeur, le servo s'y rend puis ne fait plus rien. Si je tourne le bouton à la main, la variable renvoie la valeur correspondant à la position. Et avec ca, on peut piloter simplement n'importe quel rotacteur. Pourtant, il s'emblerait que ca n'existe pas en Plug N Play ou alors je ne connais pas le nom que ca a dans le monde de la domotique.

Dans mon cas, j'ai un bouton à plusieurs positions quand on le tourne: ca passe de arrêt à eau chaude seulement, chauffage seulement, chauffage et eau chaude. Quand je pars pour plusieurs jours, je mets la chaudière sur off car sinon, elle continue de chauffer de l'eau qui ne sera pas consommée (donc en pure perte) et si je ne me suis pas amusé à baisser manuellement la dizaine de thermostats (perdant au passage leur réglage initial), la maison sera également chauffée en pure perte. Mais comme on parle de chauffage basse température, il faut bien 24 heures pour réchauffer la maison. Je pourrais programmer manuellement une heure de retour dans la chaudière, mais c'est fastidieux et si finalement je prolonge ou raccourcis mon séjour, ca ne va plus. Un autre cas c'est quand je suis en mode eau chaude seulement: selon la météo, si je sais qu'il va y avoir du soleil, il est inutile de réchauffer l'eau avec la chaudière en début de journée car le soleil va s'en charger un peu plus tard (solaire thermique). Donc si je veux être optimal, je dois avoir un pilotage dépendant de la météo. Or, nativement, ma chaudière ne connait pas la météo, contrairement à ma box domotique. Pour le dire autrement, en laissant ma chaudière branchée en permanence, j'arrive à avoir quelque chose qui fonctionne tout le temps, mais qui n'est pas optimisé en fonction de ma présence à la maison ou de la météo. Et donc si j'avais l'équivalent d'un servo que je brancherais sur le contacteur de commande de ma chaudière et pilotais via mon réseau domotique, pour pas bien cher, nettement moins que ce que je dépense en énergie supplémentaire si je branche en permanence ma chaudière, je peux piloter la chose intelligemment. A noter que je ne peux pas piloter simplement les circulateurs en sortie de chaudière car ils ne sont pas on-off mais fonctionnent en continu, pilotés eux même par ladite chaudière en fonction de plein de paramètres et donc interférer avec n'est pas une bonne idée: il faut que je donne des instructions à la chaudière qui elle même pilote ensuite tout son système, pas que je bypasse ses ordres (car elle apprend de ses actions et de leurs conséquences. Mais si je bloque ses actions sans qu'elle n'en ait conscience, ca va dérégler tous ses paramètres d'estimation de l'inertie de la maison, calcul de fuites thermiques, etc.).

J'ai une chaudière qui fonctionne très bien mais qui a un défaut: elle n'a pas été prévue pour être domotisée. J'ai regardé avec le fabriquant qui peut me proposer de changer sa carte électronique par une plus récente qui elle est connectable au wifi puis pilotable, mais la facture est pour le moins conséquente et donc le jeu n'en vaut pas la chandelle. Comme les fonctions de base (arrêt, marche pour l'eau chaude, marche pour l'eau chaude et le chauffage) sont toutes pilotables à travers un unique bouton rotatif, je me dis que s'il existait un module domotique qui serait l'équivalent d'un servomoteur, comme dans le monde des véhicules radiocommandés, je pourrais rendre ma chaudière connectée à moindre frais. De Même, j'ai d'autres usages (ouvertures/fermetures de trappes) où un tel module me serait fort utile. Sauf que j'ai beau chercher, je ne trouve rien qui ressemble ou qui puisse être détourné pour l'usage que je souhaite. Quelqu'un a une idée de comment résoudre cette question? J'imagine que je ne suis pas le premier à vouloir piloter un servo via une box domotique. Si cela peut aider, j'ai une HC3 et donc je peux piloter une bonne variété de protocoles.

Bon, ben je vais m'y mettre alors ;-) Les premiers steps seront de trouver comment obtenir une liste des ID des capteurs ayant un historique activé puis de créer un device child de type température. Jusque là, je ne vois pas de souci majeur si ce n'est de trouver la bonne syntaxe. Ce qui me fait un peu plus peur, c'est qu'à priori, le graphique historique des devices température va pointer sur l'historique officiel Fibaro en utilisant sans doute en dur l'ID du device. Il faut donc trouver un moyen de lui dire d'utiliser l'ID du device physique et le cas échéant de pouvoir appliquer une conversion si le range d'un capteur devait être très différent du range usuel des températures. Typiquement, une pression, c'est de l'ordre de 1000 et je ne suis pas certain que le graphe natif de Fibaro sache afficher des valeurs si élevées. Toute idée ou documentation du fonctionnement des graphiques natifs serait bienvenue ;-) .

Le but étant uniquement de faire un affichage en plus, je ne perds pas la fonctionnalité du capteur d'origine avec ma méthode, c'est juste que je voudrais essayer de détourner le seul moyen d'origine qui affiche des graphes pour le faire pour n'importe quel capteur. Un truc du style QA qui scanne tous les capteurs ayant l'historique activé et qui crée un child de type température pour chacun de ces capteurs, child qui du coup aurait la fonctionnalité d'afficher un historique via un graphique. C'est ca mon idée, mais je ne sais pas si c'est techniquement faisable.

Sauf que du coup, si ca résiste au changement de box, ca devient sensible aux MAJ d'OS du NAS, aux changement de version de la DB et à la capacité de tout ce petit monde à se parler. J'ai installé pas mal de choses sur mon NAS, mais force est de constater que ce n'est pas d'une stabilité mythique. Et par ailleurs, pour des raisons de sécurité, je n'aime pas trop exposer mon NAS à l'extérieur. Et là, on n'a pas encore parlé de Yubi qui par construction n'a pas de raison de bien intégrer un serveur web hébergé hors de la galaxie Fibaro. Du coup, se pose une question: si je force le type de capteur à "température", est ce qu'il y a moyen de bidouiller quelque chose pour avoir les graphiques historiques de ce type de capteur? En essayant rapidement (et naïvement), ca ne semblait pas fonctionner, mais il y a peut être une bidouille à effectuer ou peut être qu'il faut passer par un QA qui lit les infos dans l'historique et simule un capteur de température pour les afficher.

Je suis en cours de remplacement de mes anémomètres et pluviomètres Netatmo par du Zwave, dans le but de ne plus devoir dépendre des serveurs capricieux de Netatmo. J'ai donc installé les capteurs, coché le fait d'enregistrer l'historique. Et là, je m'attendais à ce que nativement, ledit historique soit affiché, comme on peut le voir par exemple pour la température du QA Netatmo. Mais en fait, rien, nada. J'ai bien vu le sujet avec export d'une base de données (donc duplication de la data) puis intégration dans un server web qui lui même tourne sur un NAS. Mais je trouve bizarre qu'il faille déployer une telle énergie pour avoir quelque chose de basique et à mon avis indispensable à partir du moment où on dispose d'un historique. N'y a t il pas une option que je n'imagine pas pour que la HC3 affiche l'historique de n'importe quel capteur historisé voire permette de le voir sur Yubi?

Alors je confirme que cette solution fonctionne. Merci!

Concernant le max charging power (et discharge) cela permet de forcer la vitesse de charge/décharge de la batterie stationnaire Fronius, comme dans l’onglet de la gestion de l’énergie, sauf qu’ici, on peut le piloter finement depuis la HC3. Dans mon cas, mon onduleur a une puissance d’ondulation (AC) max de 5.2kW mais mes panneaux peuvent produire jusqu'à 8.2kW (DC). Donc les jours de plein soleil, j’ai intérêt à vider ma batterie sur le réseau en début de journée pour que quand la puissance des panneaux dépasse 5.2kW, l’excédent soit injecté directement dans la batterie qui elle se charge en DC. Sinon, ils sont perdus. Quand je veux forcer la décharge, je fixe une puissance mini de décharge. Et quand je veux éviter que ma batterie ne se charge trop vite (et ne puisse plus encaisser le surplus de production), je mets une puissance max de charge. Ceci est valable les jours de plein soleil car quand il fait gris, j’ai intérêt à maintenir la batterie totalement chargée. Ca, c’est ce à quoi je veux arriver, ce qui implique d’intégrer dans ma QA non seulement la partie Fronius mais aussi les prévisions météo couplées avec mon capteur de luminosité. Et effectivement, il faudra que je me penche sur la création des enfants pour créer ce qui manque dans le QA Fronius qui utilise l’API et pas le Modbus. Un autre avantage de Modbus, c’est qu’il est possible en un seul appel de récupérer l’entier des paramètres là où via l’API, il faut faire une requête par paramètre. Mais au final, je manque de temps en ce moment pour terminer totalement mon projet. En le rendant public, au moins le boulot de debug (les message d’erreur Modbus sont quasi inutilisables car en gros, il répond juste : « j’ai pas compris » dans le meilleur des cas, voire rien du tout tant que tout n’est pas parfaitement formaté. Pour la température de la batterie, je n'ai rien trouvé dans les registres de mon onduleur, mais peut être que selon les modèles, c'est dispo. La seul température que j'ai, c'est celle de l'onduleur qui est dans le bloc I160, adresse absolue de registre 42290.

La bonne nouvelle, c'est qu'on arrive à la même conclusion = les scénarios de la HC3 sont une impasse car bien trop limités en fonctionnalités: je n'avais jamais essayé jusque là car par principe, je me dis que ces trucs graphiques ne génèrent jamais ce dont on a vraiment besoin. Puis je me suis ravisé en me disant qu'après tout, les box domotiques ne sont pas utilisées que par des geeks comme moi qui savent raisonnablement coder et donc que mes problèmes basiques d'automation devraient avoir une solution native simple sur la box car sinon, 80% des gens avec une maison intelligente ne pourraient pas gérer des BSO en fonction de la luminosité. C'est là que je me suis planté. Je viens donc d'installer GEA et je vais me mettre dessus et ce d'autant que j'ai pas mal de choses qui attendaient que je les automatise mais comme je n'avais pas trouvé comment le faire dans les scènes, je me disais que ca venait du fait de mon ignorance de leur fonctionnement. Merci pour le tuyau!

Juste pour être bien sur, GEA, c'est l'interface dans laquelle on fait des scénarios avec du drag & drop, avec une colonne pour les triggers, l'autre pour les actions? Car c'est précisément là que j'ai voulu tenter la chose, mais je n'ai pas trouvé comment lui dire de lancer une action 1 minute après en avoir lancé une autre, d'où l'idée de basculer en LUA en me disant que si ce n'est pas possible avec l'interface graphique, ca doit l'être en codant. Mais si je peux le faire directement dans les scénarios (que je ne connais pas en détail), alors je serai le plus heureux!

OK, je vais poser mon QA modbus Fronius ce matin sur Marketplace. Il faut alors bien lire la doc Fronius sur le Modbus (de mémoire, elle n'est pas dispo en téléchargement sur leur site et il faut leur envoyer un mail pour l'obtenir) car des fois, il faut bouger des paramètres obscurs avant que des modifs soient prises en compte, mais la doc a le mérite d'être bien faite. Toute la couche technique de communication a été écrite, l'entier du paramétrage de mon registre y est (= il existe une sorte de structure standardisée pour les onduleurs modbus de toutes marques, mais selon les modèles, tous les registres ne sont pas exploités).

Effectivement, l'idée est de faire 0%, attendre une minute puis 1%. Sauf que dans une scène, je n'ai pas trouvé comment lui dire d'attendre une minute avant de remonter à 1%: j'ai d'un coté des triggers qui quand ils sont vrais lancent toutes les actions en parallèle et donc je termine avec des stores à 1% sans être passés par la case 0% et donc en pratique, je ne vois jamais le paysage avec mon setup actuel. Après, mais c'est un souci moindre, mes boutons de commande physique ont la possibilité d'être bloqués en position contact, typiquement pour descendre complètement un store sans devoir rester appuyé et quand ils sont dans la position contact fermé, ca donne des comportements bizarres. Mais je pense que je devrais trouver comment gérer la chose dans les paramètres des modules.

Alors dans mon cas, il s'agit de stores à lamelles. Quand on part de tout en haut pour les descendre, les lames se mettent à la verticale puis descendent. Si alors je remonte, les lames passent à l'horizontale la première seconde puis elles remontent. Si je mets directement 25%, les lames descendront jusqu'à la position 25% mais resteront verticales. Je les voudrais horizontales, ce qui permet de bloquer le soleil direct sans pour autant bloquer la vision horizontale. Et cela ne s'obtient qu'en remontant de 1% après avoir baissé à la position souhaitée. J'ai donc besoin de faire une descente puis, une fois terminée, de remonter de 1%. En faisant une scène qui remonte de 1% et en la mettant à la fin de la liste des actions, le résultat est un store qui va directement à 1%. Ce dont j'ai besoin est un store qui va à 0% puis remonte à 1%.

J'ai des stores classiques commandés par un module Fibaro roller shutter. Actuellement, il y a un scenario qui tourne selon la logique de descendre les stores le matin quand il fait chaud et les remonter vers 16:00. Mais ce que je voudrais, c'est les descendre puis les mettre non pas totalement fermés mais en position qui permet quand même de voir dehors, ce qui s'obtient en les remontant 1s après qu'ils soient arrivés en bas. Donc j'avais pour idée d'attendre 60s (durée max de descente) puis de demander aux stores de se mettre à la position de 1% (ce qui correspond à 1s de remontée). Problème: je ne sais pas comment faire dans un scénario pour dire d'attendre une durée donnée avant de lancer une action. Je pourrais écrire toute une QA pour ca, mais je trouve dommage de devoir recoder l'équivalent de mon scénario en lua et de perdre la facilité de modification en déplacant graphiquement des triggers. Quelqu'un a une idée de comment gérer ce souci?

My 2 cents sur ce sujet: j'ai aussi du fronius à la maison et arrivera un moment où tu voudras non seulement lire sur ton onduleur mais aussi écrire pour modifier son comportement. Et là, l'API ne pourra rien pour toi car elle ne peut que lire. Tu devras alors passer via Modbus qui a en plus le mérite d'être bien plus complet et rapide. J'ai déjà écrit une QA avec toutes les briques pour exploiter le Modbus Fronius, mais je ne l'ai pas encore publiée car il faut que je la rende plus compréhensible pour les autres. Mais si tu veux partir dans cette voie, je t'aide volontiers car comme le modbus est un protocole super bas niveau (on envoie des messages en hexa, il faut se gaffer avec les conversions de type qu'on recoit en retour et la gestion des nombres négatifs est un grand moment de solitude).

Now that I could manage my issue with the join callback trrick, here comes another challenge: with the syntax for a,b in pairs(MyTable) do blabla end, I can perform a full scan of a table. But is there a way to stop the scan once I've found what I wanted in MyTable. In other words, is there a syntax to exit a for loop before the fullscan is terminated or is there a possibility to have a while loop on a table?

Ok, I think I got it for the join callback. However, I have a few remaining understanding questions: - why do you use this "complicated" syntax : for i=1,2*n,2 do local a=args[i+1] a[#a+1]=nsucc a[#a+1]=nerr args[i](table.unpack(a)) end and not this simple one: for i=1,2*n,2 do args[i](args[i+1],nsucc, nerr) end I don't understand why you populate a table with values to then unpack the table because your function needs values and not a table. then my second point is that your join callback function calls a predefined number of requests. It can be 3, 4, 5 or whatever http requests I want, but this number is fixed by the syntax (5 calls in your example). In my case, I have a loop and the number of calls it will generate will only be known at execution time, depending on how many registers are described in my registers table. Thus, at the time of writing code, I'm not in a position to know the correct number of arguments to pass to join. Is there a syntax trick to build the correct join call at execution time ? Something like building a string in my loop with the right syntax and then passing that string to something that will execute it? Last, I'm not sure I understand correctly this part of the http request: error = err or function(err) error(url,err) end So please, correct me if I'm wrong: My understanding is that if err is provided as an argument in the call to SendRequest, then this function will be called in case of error while calling http:request. But if err is not provided in the list of arguments when calling SendRequest, a default function will be used and it will be the standard error function function of http:request but with the url parameter fixed, making it a one parameter function. So I understand that the second "err" of the line are just "blind" ((local?) variables = they could have been replaced by any name. So, this code would also have worked: error = err or function(err1) error(url,err1) end To say it differently, the first err has to be err and nothing else and refers to the last argument of SendRequest. the next 2 occurrences of err just refer to a local variable and it's just a coincidence that it bears the same name as the first occurrence of err. Am I correct? Thanks again for your help, much appreciated!

Alors à mon tour de poser une question de base su comment coder proprement en QuickApp: J'ai une fonction, qui travaille en asynchrone (socket TPC) et qui va lire un registre sur mon onduleur. J'ai par ailleurs une fonction, à la logique synchrone, qui fait une boucle for et qui permet de lire l'ensemble des registres. Ceci a pour effet de m'envoyer une rafale de commandes asynchrones dont chacune a sa fonction callback. Et ce que je voudrais, c'est qu'une fois le dernier callback asynchrone effectué, je puisse reprendre le cours de mon exécution synchrone, sachant que rien ne me dit que le dernier callback à terminer soit celui du dernier registre lu. Donc en gros, on parle d'une situation où on n'est plus à gérer avec un unique callback mais une fonction où il y en a 10 qui tournent en parallèle. Ca ressemble donc à un truc du style: for _, register in pairs(register) do registerscan(registerNumber, register.callback) end self:debug("Scan terminé") Et registerscan envoie un message via un TCP socket, recoit une réponse et la traite et je voudrais que le self:debug ne se produise que quand chaque callback a fini de s'exécuter A ce stade, le seul moyen que j'arrive à envisager pour ca est qu'à chaque appel à registerscan, j'incrémente un compteur (variable globale) et qu'à chaque fin de chaque callback, je décrémente ce compteur et que mon self.debug soit une boucle infinie, stoppé quand le compteur vaut 0. Mais je trouve ca mochissime et je veux croire qu'il existe une manière propre de faire que ce soit appelé via une utilisation intelligente de callbacks plutot que via une boucle infinie et une variable globale. Si vous avez une idée pour résoudre ce challenge, je suis preneur!