vravolta

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.

Oui, mais vu qu'en pratique il est très hors de ma portée de créer un QA qui réplique le device IP camera, le fait de pouvoir modifier des variables d'un autre QA n'a du coup pas vraiment d'intérêt. Donc cette piste doit être abandonnée. Et du coup la question, c'est de savoir si du LUA peut créer des devices (qui donc ne sont pas des QA) au même titre qu'il est possible de le faire manuellement dans la box en cliquant sur ajouter un appareil puis en choisissant IP camera comme type d'appareil (et donc pas QA). Dans la liste qui apparait, on voit que camera IP est à coté de QuickApp = c'est de nature différente, ca j'ai compris désormais. Mais est ce qu'un QA peut créer autre chose que des QA, c'est la question que je me pose.

Et si on oublie le coté parent enfant et qu'on parle d'un QA qui créerait un device standard avec du code LUA, c'est impossible? Et si c'est possible, est ce qu'il est possible depuis un QA de modifier les variables d'un device existant?

Alors l'idée, c'est de créer un QA qui va attaquer l'API Netatmo pour récupérer les infos de connexion = le token d'accès à la camera. A partir de là, le QA saurait générer l'adresse d'accès à la camera tant pour les images que pour la commande de la lumière. Et il aurait en fils 2 devices: une camera IP dont il aurait juste rempli automatiquement les paramètres et une QA que j'ai déjà codé, qui est de type lumière et se comporte en pratique exactement comme n'importe quelle lumière pilotée par un module Fibaro. Je ne veux en aucun cas toucher ou répliquer un code de device standard qui existe déjà, juste créer ce device et lui fixer les bons paramètres. Pour le dire autrement, aujourd'hui, j'ai un device IP camera avec des paramètres inintelligibles et un device QA qui se comporte comme une lumière, avec les mêmes paramètres inintelligibles que la camera IP. Et demain, je voudrais arriver à une situation où j'ai un QA parent à qui je donne des paramètres compréhensibles d'un humain = concrètement, un username et un password. Et lui il fait tout le job fastidieux d'attaquer l'API pour obtenir les paramètres inintelligibles et les passe à un QA fils et un device IP camera fils. Autre manière de voir la chose, il me faudrait trouver comment créer avec du code LUA un device IP camera (pas grave s'il n'est pas fils) et une fois créé, lui fixer ses paramètres (= la valeur de certaines de ses variables, son nom, sa pièce, etc.). Si j'ai ca, je comprends que faire de ma QA qui gère la lumière une QA fille de la QA qui va chercher les paramètres inintelligibles ne devrait pas poser de soucis et donc que j'aurai atteint mon but.

OK, donc concrètement, il n'est pas juste possible de faire qu'une quick app parent puisse générer un enfant d'un type fibaro pourtant proposé dans la liste des devices et de juste en paramétrer correctement les variables pour qu'il fonctionne? Car mon but n'est pas de réécrire une quick app qui réplique le type ipcamera de fibaro, juste de réutiliser ce type en lui remplissant les paramètre pour que ca fonctionne, paramètre qui eux même sont communs avec la lumière. Autre possibilité: est ce que je pourrais avoir une ipcamera en parent et créer une device de type lumière qui serait son enfant et hériterait de ses paramètres?

Histoire de me familiariser avec la question des child devices dans les quick apps, je me suis dit qu'un bon sujet de travail serait ma camera Netatmo Presence. A ce jour, elle est d'un coté déclarée sur ma HC3 comme une camera IP et de l'autre, comme une lumière vu que je peux en piloter l'allumage du projecteur. J'avais pour idée de créer une quick app pour un device parent à qui je fournis l'adresse IP de la camera et mon username/password Netatmo et que ce dernier me crée en device child, le device de type lumière (qui lui même est une quick app que j'ai déjà développée) et le device de type camera avec les bons paramètres remplis grace au travail du quick app parent qui irait chercher dans l'API Netatmo les bonnes valeurs. Sauf que voila, j'ai beau chercher de partout, je ne trouve à aucun moment d'exemple de code qui ajouterait une camera IP en device child d'une quick app. J'ai des exemples pour des sondes de température, des switches, mais jamais de camera. Quelque a t il une idée de comment faire?

Sinon, en copiant le cookie de auth.tesla.com recu dans postman et en le passant en dur en paramètre du header d'une nouvelle requête avec comme url l'url de redirection, j'obtiens enfin un statut 200 avec un body pas vide. Il est illisible car a priori codé en gzip (aucune idée de s'il existe un moyen en lua de décoder le gzip mais avec un peu de chance, comme c'est moi qui signale dans les options que j'accepte le gzip, si je ne spécifie rien, il m'enverra le résultat non zippé). Ce qui est fou, c'est que là, je peux voir les cookies dans le header (donc ceux de www.tesla.com). Donc reste à comprendre comment je faire pour récupérer le cookie de auth.tesla.com dans la première requête et je serai arrivée à avoir le statut 200 du premier step de l'authentification. Mais là, j'avoue ne pas avoir d'idée de comment le trouver ou, si je ne le trouve pas, comment paramétrer la requête http initiale pour que quand elle fait la redirection, elle passe le cookie qu'elle recoit. Pour math.random, c'est ce que je suspectais. N'y a t il pas un moyen de forcer math.random à débuter à un endroit pseudo aléatoire genre en se basant sur l'heure du moment où il est appelé?

Alors il accepte l'option redirect= true/false (pas dans le header mais dans les paramètres d'appel de NET.HTPclient naturellement), mais ca ne change rien, même erreur. J'ai tendance à penser que je suis dans la situation suivante: je dois initialement me connecter à www.auth.tesla.com: c'est ce que dit de faire la doc non officielle de l'API et c'est le seul domaine qui fonctionne (= pas d'erreur 4xx) dans le paramètre host. Face à cela, je recois une erreur 301 avec une location pour la redirection qui est https://www.tesla.com/? Si je regarde mes cookies postman sur la requête qui fonctionne, j'ai un cookie de auth.tesla.com qui s'appelle tesla-auth.sid qui contient une valeur du même nom. Puis j'ai 5 cookies qui proviennent de tesla.com (sans le auth devant et donc du site vers lequel il y a redirection). Je subodore donc que la logique est de se connecter à auth.tesla.com, de recevoir une erreur 301 et le cookie tesla-auth.sid, de se laisser rediriger alors vers tesla.com en fournissant alors dans le header le cookie tesla-auth.sid qui ouvrira la porte pour recevoir la page HTML que je vais ensuite devoir parser pour récupérer les infos des steps suivants de l'authentification pour transformer mon login/password en token directement utilisable. A noter que si dans postman, je prends l'uri de redirection sans fournir le cookie = dans une requête séparée, j'obtiens une page html mais qui n'est pas celle avec les sections cachées qui contiennent la bonne info. Donc il y a bien un truc à comprendre avec ce cookie. Le hic, c'est que dans le header de retour sur la requête qui retourne l'erreur 301 en lua, je n'ai rien qui ressemble à un cookie et donc je ne peux pas le récupérer pour le réinjecter lors d'un appel à l'uri de redirection. A priori ce cookie n'est caché nulle part dans la réponse que je recois de l'erreur 301 car je la scanne sur toutes les tables et je ne trouve rien. A noter un truc bizarre que j'ai noté au passage: à chaque appel de ma fonction, je génère 2 chaines de caractère supposées aléatoires à base de math.random (et à chaque génération, je remet la variable à ""). Mais pourtant, mes chaines sont toujours les mêmes, comme si math.random donnait toujours la même série de résultat aboutissant donc à une chaine pas du tout aléatoire.

Alors j'ai eu une petite avancée ce soir: ce qu'il me manquait dans le header par rapport à Postman était le paramètre Host. Je ne comprends pas trop à quoi ca sert de le préciser car de facto, si j'envoie une requete à https:// tesla.com, ca me semble assez clair que le host souhaité est www.tesla.com. Mais bon, en ajoutant cette info, je suis passé d'une erreur 401 à une erreur 301, ce qui est un vrai bon signe car désormais Tesla non seulement comprend ma requête mais ne refuse pas d'y répondre. Je dois desormais comprendre comment faire pour que NET.httpclient ne suive pas la redirection. En effet, apparemment, c'est un piège de tesla selon la doc non officielle de l'API (et je confirme que si je saisis l'uri de redirection dans postman, ca retourne une erreur 404). Ce que je ne comprends pas, c'est que postman arrive à avoir un statut 200, qui ait le paramètre de suivi auto des redirections en cas d'erreur 3xx activé ou non. Donc je continue d'investiguer. Pour comprendre ce que Postman fait pour arriver au statut 200 plutot qu'au 301. Sinon, super merci pour les boucles qui permettent de lire l'entier de ce qui se trouve dans response. J'ai désormais une boucle sur response elle même qui me retourne status (301), data (vide) et le header puis une boucle sur le header qui est lui même une table pour lire ce qu'il contient (et c'est là que je trouve l'adresse fake de redirection). Si vous avez des idées de comment gérer cette erreur 301 (à mon avis, il faudrait que je puisse dire à mon code de ne pas la suivre et mais en même, s'il la suivait, il devrait être en erreur 404 et pas 301. Donc il y a un truc que j'ai du zapper dans cette histoire.

Alors pour la question de la reponse en html, en fait, l’API Tesla est non officielle et lors du premier step d’interrogation, un de ses moyens de protection est de renvoyer une page html qui trompera un navigateur (avec de la recirection vers un site non existant ) mais qui contient dans ses cookies et des sections cachées des infos pour la suite de l’authentification qui elle se termine ensuite par du json que je sais facilement manipuler. Et donc toute mon problème actuel, c’est de comprendre pourquoi ma requete lancée via lua qui est la meme en termes d’url que celle de postman donne un resultat different. Hormis le contenu du header, je ne vois pas trop ce qui peut changer. Je me demande si ce n’est pas lié au fait que c’est du https et pas du http et que le client http du lua de la HC3 ne saurait pas le gerer et en ferait du simple http pas s? Bref, je vais creuser toutes ces pistes!

Merci pour l’info, je vais creuser dans ce sens. Mais ne faut il pas autoriser avant quelque part les cookies? l’autre point est que quand j’affiche via self:debug ka variable response, je n’ai rien sachant que c’est supposé retourner du html. Et à ce sujet, au meme titre qu’il y a des fonctions natives pour decoder du json, est ce qu’il existe quelque chose pour le html?

Après avoir cherché un weekend complet, je n'arrive pas à trouver un tuto ou un exemple correctement documenté relatif à la gestion des cookies. Le contexte est le suivant: je me lance dans le fait d'attaquer l'API Tesla. Pour cela, je dois envoyer une commande GET au server d'authentification. J'ai réussi sans souci à générer une requête qui fonctionne correctement avec Postman. Mais quand je la donne à net.HTTPclient, je récupère une erreur 403 de la part du server qui donc comprend ma requête (logique, il la comprend aussi via postman) mais refuse d'y répondre. Je suspecte que la cause est liée au fait que quand cette requête est envoyée au serveur, celui ci retourne un certain nombre de cookie. Je les vois apparaitre dans postman. Mais comme je ne trouve nulle part d'option pour gérer les cookies pour net.httpclient, j'imagine que c'est paramétré par défaut pour refuser les cookies ce qui doit entrainer le refus de la part du serveur tesla de fournir une réponse. Donc concrètement, j'aimerais pouvoir paramétrer le client http pour qu'il accepte les cookies que lui retournera le server tesla puis ensuite pour pouvoir les manipuler car je devrai ensuite pouvoir les réutiliser pour les requêtes suivantes. La seule chose que j'ai trouvée, mais ca remonte à 2015 pour le dernier update, c'était un package en lua qui créait une fonction request modifiée qui semblait pouvoir gérer les cookies. Mais de ce que j'en ai compris en la lisant, c'était pour envoyer un cookie, pas pour en recevoir et c'est du code pour HC2 aors que je suis sur une HC3. Donc si une bonne âme pouvait éclairer ma lanterne, ce serait top. Dans le même style, même si c'est moins problématique car je peux contourner, si je voulais faire propre dans la gestion de ma borne de recharge, je ne devrais pas récupérer son adresse mac manuellement sur l'app qui la gère mais via une interrogation via UDP en multicast qui devrait selon moi retourner en unicast une réponse. Je pense, sans pouvoir le vérifier, que j'ai réussi à envoyer le message d'interrogation en UDP, mais il me faudrait faire tourner un listener dans mon QA pour récupérer la réponse vu qu'elle arrivera en unicast qui est, selon ce que j'ai compris, du TCP. Toute aide ou piste serait vivement appréciée ;-)

Bonjour à tous, petit nouveau dans le monde des box domotique, j'ai acheté fin 2022 une HC3 afin d'automatiser ma maison. Comme pas mal de monde, je cherche à intégrer de manière intelligente le fonctionnement de mes panneaux photovoltaiques, de ma borne de recharge, de ma voiture électrique en tenant compte de la météo venir. Et de ce fait, je me retrouve à essayer comme je peux de bidouiller avec net.httpclient et ses options dont je peine à trouver la documentation.