RS600807 Posté(e) le 30 juin Signaler Posté(e) le 30 juin Disons que le comportement que tu observes est similaire au mien. Par contre, et j'en profite pour répondre à @TitiXsi par rapport à nos échanges en privé sur le sujet, j'ai comparé le token qui est rentré dans le QA de @Sankotronic et c'est là que les choses sont drôles (ou pas)! En effet, le token utilisé par le QA de @Sankotronic ne correspond pas au token que j'ai envoyé pour test & vérif à @TitiXsi (et qui était supposé arriver à expiration hier). Or je suis sûr de lui avoir envoyé le bon puisque je n'avais que celui-ci (c'était le token historique) et un autre dont la durée de vie était expirée avant même de l'avoir utilisé (ce qui a donné naissance à mes publications sur le fil de discussion il y aquelques jours). Ce qui laisse donc penser que le QA de @Sankotronic est allé chercher un nouveau token tout seul et que ça a fonctionné... alors qu'en toute logique je ne peux pas me connecter à leur site pour en générer un nouveau manuellement. Donc, on peut écarter les pistes au niveau du nom d'utilisateur, de mot de passe, ou de redirection de ports. Correct ? Maintenant, il y a bel et bien un pb quelque part. Mais à mon niveau, je ne sais pas dire précisément où ça débloque...et pourquoi (puisque cela fonctionnait avant très bien)
TitiXsi Posté(e) le 30 juin Auteur Signaler Posté(e) le 30 juin Efface ton token Chez sanko on va voir si il va chercher un nouveau token maintenant...
RS600807 Posté(e) le 30 juin Signaler Posté(e) le 30 juin Alors si je lui retire le token, le QA de Sanko ne va pas chercher tout seul un nouveau token. Mais par contre, il y a une subtilité visiblement entre son QA et le tien (et celui de Lazer aussi je pense). Dans les paramètres, il demande de rentrer un ID de session. Or, je ne crois pas qu'on puisse le trouver spontanément. En revanche, dans le log de ton QA, on voit apparaître un paramètre dans le décodage de la réponse: "enlighten_4_session". Valeur qui change à chaque tentative de connexion. J'ai donc récupéré un numéro de session en lançant ton QA. Puis je l'ai rentré dans le QA de Sanko et là il va chercher tout seul un nouveau token. Quand je regarde la gueule de ce nouveau numéro, c'est "presque" la même chose que le token historique, avec simplement la dernière séquence après le "." qui change et une autre portion au milieu également différente. Je viens de répéter cette opération sans changer l'ID de session, j'ai supprimé le token et l'ai laissé vide et il retrouve un token sans pb. Il semblerait qu'il soit capable de retrouver un token tout seul dès lors que l'ID de session n'est pas trop vieux (quel laps de temps ?). Dans le résultat de mon premier test effectué (cf la première ligne de mon post), l'ID de session date de plus de 25j.
TitiXsi Posté(e) le 30 juin Auteur Signaler Posté(e) le 30 juin (modifié) Je n'ai pas le temps c'est Clairement pas mon domaine de compétences cette récupération ... De mémoire j'avais copié la méthode de lazer bien plus compétant que moi. Si besoin @Sankotronicpourra nous donner la main sur ça gestion de token et de session. Édit : je veux bien tes 2 token HS et valable pour voir ce qui change... Modifié le 30 juin par TitiXsi
RS600807 Posté(e) le 1 juillet Signaler Posté(e) le 1 juillet Le 22/11/2025 à 13:37, Sankotronic a dit : Hi @TitiXsi, To refresh token you need to store serial ID of the Envoy and login credentials to refresh token. With that you first request session ID: local url="https://enlighten.enphaseenergy.com/login/login.json" local payload='{"user":{"email":"'..self.userName..'","password": "'..self.userPassword..'"}}' self.http:request(url,{options={checkCertificate=false,method='POST',headers={['Accept']='application/json',['Content-Type']='application/json',},data=payload,timeout=10000}, to get new session ID. After you get session ID then you call: local url="https://entrez.enphaseenergy.com/tokens" local payload='{"session_id":"'..self.sessionID..'","serial_num":"'..self.serialNO..'","username":"'..self.userName..'"}' self.http:request(url,{options={checkCertificate=false,method='POST',headers={['Accept']='application/json',['Content-Type']='application/json',},data=payload,timeout=10000}, to get token. As you can see from my code you do need session ID, serial NO and user name to get new token. NOTE that if if any of the above request fails then there must be delay of at least 5 minutes before you can try to get new session ID and the token again. Not to wait for long time I reduced lifespan of the token to few hours for testing purposes. I can do that because I store time when token was generated and then I add time until when it must be refreshed. En fait, je crois que @Sankotronic avait donné la réponse il y a quelque temps. Je n'ai pas moi non plus les compétences à mon niveau (disons même encore moins que toi) pour écrire correctement tout cela. Ceci étant, ça n'explique pas pourquoi on ne peut plus se logger correctement pour récupérer un token manuellement. Et côté Enphase, ils me renvoient vers un autre service qui ne semble pas très réactif et ça n'avance pas. Assez lamentable de leur part tout cela...
Sankotronic Posté(e) le 3 juillet Signaler Posté(e) le 3 juillet Hello to all, I do not quite understand what is the problem on your side. It is true that my quick app is encrypted, but I already posted a hint how to write code to get token automatically without needing to generate it manually here: and I'm willing to share complete code if anyone is interested.
TitiXsi Posté(e) lundi à 15:04 Auteur Signaler Posté(e) lundi à 15:04 Effectivement RS600807, Sanko m'avais aiguillé sur le code à suivre... néanmoins ,ce n'était pas si simple pour moi à l'époque. Hello Sanko, I have tried in nov 2025 to include your sharing in my code without success, without time to perform the investigation ...
Lazer Posté(e) lundi à 15:15 Signaler Posté(e) lundi à 15:15 (modifié) De mon coté j'ai résolu le problème avec mon QuickApp. J'utilisais une astuce pour que le QA récupère automatiquement le Serial Number de la passerelle Envoy sans devoir l'entrer manuellement... sauf que cette astuce ne fonctionne plus, car la page d'info permettant de récupérer ce numéro de série est maintenant protégée... il faut donc le token, qu'on essaye justement d'obtenir, donc ça tourne en boucle, le serpent se mort la queue.... Donc j'ai modifié mon code pour que l'utilisateur saisisse manuellement le numéro de série dans une variable du QA. Et tant qu'à faire, à chaque démarrage du QA (ce qui arrive 1 fois par semaine avec le backup auto de la box), le QA demande un nouveau token, ce qui permet (normalement) d'avoir toujours un token d'avance valable entre 355 et 365 jours.... autant repousser la prochaine échéance des problèmes le plus tard possible... ça fait quelques jours que ça tourne bien comme ça, je partagerai la mise à jour sur le topic de mon QA. Modifié lundi à 15:15 par Lazer
Messages recommandés