vravolta

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!

Alors en fait, j'avais bien compris le fonctionnement des variables et de l'histoire du contexte, mais pour une raison que j'ignore, ca ne fonctionnait pas comme ca devait en théorie. C'est pour ca que j'ai essayé de passer par les labels. Pui en me reconnectant en local plutot qu'à distance, le même code non modifié, qui ne fonctionnait pas, s'est mis à marcher, me confirmant que ma compréhension initiale des contextes était la bonne. Je dois avoir un truc sur ma configuration car de même, quand j'ai tenté la mise à jour de ce weekend, ca a tout planté et j'ai du restaurer depuis ma sauvegarde.. Après, vu toutes mes bidouilles de dev en ce moment où je ne suis pas certain que tous les sockets que j'ouvre sont fermés, etc., je pense que ca peut expliquer des comportements anormaux.

Et je continue de me répondre à moi même: je pense qu'il y avait un souci avec ma box en connexion à distance car en me connectant en local dessus, ca fonctionne sans souci avec les variables globales. J'ai au passage découvert que je pouvais me passer le contexte parent quand j'exécute une sous fonction et que je pouvais alors updater les variables globales du parent plutot que celles du "self" dans lequel je me trouve. En fait, il faut faire attention à ne pas se mélanger les pédales entre tous les self qui sont le contexte le plus bas dans lequel on se trouve, mais il est possible de faire référence, pour peu qu'on s'en soit transmis les valeurs, aux selfs parent.

I've kind of workarrounded the thing by using a global value to bypass my incapacity to get the caption value of my button with this. I find this dirty, but at least, it works. And don't ask me why, but the first code was not actually updating the caption on my screen, the second one is. That's really a mystery to me: function QuickApp:BtnConnect(event) local btnName = event.elementName if self.ConnectStatus == "Disconnected" then self:connect() self.ConnectStatus = "Connected" self:updateView(btnName, "text", "Disconnect") else -- Disconnect self:disconnect() self.ConnectStatus = "Disconnected" self:updateView(btnName, "text", "Connect") end end

Alors j'arrive désormais bien à communiquer via le Modbus TCP de ma batterie et donc j'attaque la partie interface maintenant que le code de communication TCP fonctionne. Et je bute sur 2 types de soucis: - je n'arrive pas à faire un bêtre truc = un bouton sur lequel il est écrit initialement "Connect" et qui quand je clique dessus me connecte puis affiche "Disconnect" pour que le prochain appui lance non pas une connexion mais une déconnexion. J'ai essayé naivement le code suivant, mais ca ne fonctionne pas: function QuickApp:BtnConnectClick(event) local btnName = event.elementName if btnName.text =="Connect" then self:connect() self:updateView(btnName, "text", "Disconnect") else -- Disconnect self:disconnect() self:updateView(btnName, "text", "Connect") end end Autre problème sans doute hyper basique: autant, quand je suis dans le contexte de la lecture des messages Modbus, c'est simple d'afficher les valeurs lues dans un "Label", autant, je n'ai pas trouvé de manière de récupérer ces valeurs en dehors du contexte. Donc typiquement, je vais chercher des paramètres comme le niveau de charge max toléré par la batterie, je les affiche dans un label, c'est tout OK. Autant, si après, lors d'une autre connexion, je veux calculer 80% de cette valeur pour mettre à jour les paramètres de charge de ma batterie, je n'ai rien trouvé de raisonnable pour récupérer cette valeur à part déclarer une variable globale dans l'onglet variable de ma QuickApp, la remplir puis la lire. C'est moche car on parle de données hypertechniques que l'utilisateur ne devrait pas avoir à voir dans sa liste de variables et encore moins pouvoir éditer ou changer. Donc en gros, ce dont j'aurais besoin, c'est d'un variable globale accessible depuis n'importe quel contexte de mon main mais qui n'apparaisse pas dans l'onglet variables. Et à terme, il me faudrait la possibilité de faire que depuis une autre QA, je puisse récupérer ces variables et les mettre à jour pour que depuis toute QA, je puisse savoir quel est le courant de charge de la batterie et le modifier s'il ne me plait pas. Donc en quelque sorte, faire l'équivalent d'une API pour mon QA.

Donc si je comprends bien, l'idée c'est de mettre en place une manière de "sniffer" ce que fait le navigateur quand je crée manuellement une quickapp ipcamera puis lui set ses variables. Je vais obtenir des calls à l'API HTTP de ma HC3 et donc en répliquant ces calls via net.HTTPclient en lua, je devrais obtenir du code lua de création d'une ipcamera ainsi que de set de ses valeurs. En tout cas, j'en profite pour te dire un grand merci pour tes réponses: je découvre le monde de la domotique qui m'a l'air vraiment prometteur car un nombre affolant de choses peuvent y être intégrées et une fois qu'on a tout concentré sur une seule plateforme, c'est que du bonheur à faire interagir. Certes, il faut tâtonner car c'est loin d'être 100% plug & play, mais ca ouvre un paquet de possibilités. J'ai en parallèle plein de projets dont le plus lourd sera certainement le fait de ne pas juste monitorer mon onduleur via son API mais d'en modifier les paramètres, ce qui se fait via modbus tcp et donc un layer plus bas que le HTTP où on se retrouve à aller lire directement des octets dans des registres pour créer en lua la couche supplémentaire qui manque.