vravolta

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.