Bonjour à tous,
Je suis toujours en train de développer mon plugin Home Connect et j’en suis à la phase (cruciale pour moi qui suis très faible sur ce sujet) du démon.
Après bien des hésitations j’ai choisi de faire un démon en Python et j’en suis au stade où l’installation des dépendances est OK, le démon tourne et je suis capable de lui envoyer la liste des identifiants des appareils ménagers quand on la met à jour lors d’une synchronisation et le démon est aussi capable de renvoyer des informations vers Jeedom.
L’api Home Connect utilise une authentification OAuth2 donc mon démon a besoin du token pour faire une requête au serveur Home Connect afin de recevoir les Server Send Events pour chaque appareil ménager.
Je le lui passe donc au départ.
J’ai dans lma classe homeconnect un cron qui lorsque le token expire dans moins de 30 secondes le renouvelle et donc j’ai besoin à ce moment là de passer au démon le nouveau token.
Je me pose peut être des questions idiotes mais je me demandais s’il valait mieux que j’arrête le démon puis que je le relance avec le nouveau token ou bien alors que je le lui passe exactement de la même manière que je lui passe la liste des appareils ménagers ?
Je répète c’est peut-être une question idiote mais il faut tenir compte que mes connaissances dans ces domaines : OAuth2, démon, Server Send Events sont faibles, donc j’aimerai l’avis de quelqu’un d’expérimenté.
Merci beaucoup de votre aide.
Salut,
Souvent en oauth2 tu vas avoir un refresh token qui te permet de renouveler ton access token.
Donc ton démon devrait pouvoir renouveler cela tout seul.
En fait, pareil pour le access token, comment voudrais-tu gérer cela? ce n’est pas ton démon qui fait l’auth?
je ne comprend pas bien le flux que tu imagines, que veux-tu dire « je passe le token à mon démon », depuis le code php j’imagine, mais comment l’obtiens-tu là alors?
Quels sont les flux d’authentification dispo?
Bonjour Mips,
Un grand merci pour ta réponse.
Et non en fait je suis parti d’un plugin non fini fait il y a deux ou trois ans par Sartog, donc j’ai repris et beaucoup augmenté son code qui était tout en php.
Toute la phase d’authentification (qui est assez complexe car le plugin supporte 2 modes un mode réel où il agit sur des appareils physiques et un mode démo où il agit sur des « simulateurs » mis à disposition sur le serveur Home Connect et les développeurs de Home Connect ont trouvé le moyen qu’il y ait de subtiles différences entre les deux modes.
Je manque certes d’expérience mais je n’ai jamais vu une API aussi complexe et aussi fouillis que celle là.
Par exemple je viens de me rendre compte hier au soir que la commande « départ différé » des fours et des lave-vaisselle se comportait différemment ds autres options de programme: pour les autres options on sélectionne l’option, on l’envoie au serveur qui valide et ensuite seulement une fois toutes les options choisies, on lance le programme alors que pour le départ différé on doit envoyer la commande dans le json du lancement du programme !
Enfin bref : tel que j’ai conçu le programme tout est géré en php excepté une chose : pour chaque appareil connecté mon démon va faire une requête HTTP (oui pour les Server Send Events ou SSE c’est du HTTP) avec bien sûr le token que lui a transmis le php et recevoir les événements du serveur qu’il passera au callback en php pour traitement.
Bien sûr je pourrai tout changer et rprendre le plugin à la base mais à part des détails comme cette histoire de départ différé çà fonctionne bien et mes testeurs me remontent de moins en moins de bugs.
Donc mon code php gère déjà tout : la procédure d’authentification, la réception du access token et du refresh token et le rafraichissement du token quand il est sur le point d’expirer.
Et ce token est utilisé partout dans mon code php.
Pa le log, je sais que tout se passe bien et que renouvellement du token se fait bien chaque jour et toutes mes requêtes au serveur fournissent bien les bonnes réponses.
Mon « seul » problème (si on peut dire, toute la partie SSE n’est pas encore écrite) est de communiquer l’access token au démon chaque fois qu’il change. D’où ma question : j’arrête le démon et je le relance avec le nouveau token ou bien je lui le passe de la même manière que je lui passe les identifiants des appareils ménagers (que je récupère par une procédure de synchronisation en php qui est déjà écrite et qui tourne).
Je sais que je ne fais pas toujours les choses de manière « académique » car comme je n’ai jamais suivi de cours d’informatique j’improvise mes solutions qui ne sont pas toujours celles qu’il aurait fallu choisir donc si tu pense que je dois tout reprendre à la base en gérant tout du côté du démon, n’hésite pas à me le dire
Je viens de penser à une troisième solution : le php gère l’authentification et la récupération du code pour obtenir un token qu’il passe au démon et le démon gère lui l’obtention du access token et du refresh token et rafraichit le token quand il y en a besoin et le passe à mon php par le callback
Je peux tenter de t’aider si tu veux. Dans mes limites de temps surtout.
J’ai du gérer un client sse pour mon plug-in arlo c’est par ce moyen que je pouvais recevoir les events, je l’ai fait en python.
Sse c’est pas le truc le plus simple à mettre en place (surtout sans specifications) mais une fois qu’on a compris et que c’est en place ça marche bien, moi je n’aime pas trop, et c’est surtout orienté browser à la base.
Je comprend mieux ou tu en es pour la gestion des tokens maintenant.
Alors python vs Php c’est une discussion de « religion »; dans tous ces débats sur une solution, il faut bien garder à l’esprit qu’il n’y a pas UNE bonne solution et UNE mauvaise mais juste plusieurs avec des avantages et inconvénients.
Après moi je suis plutôt d’avis de ne pas avoir 2 backends : avoir une partie en Php pour les appelles sortant et un démon en python pour les évents c’est dommage et ça va apporter son lot de complexités.
Mais clairement refaire toute la partie déjà en Php si ça fonctionne, c’est dommage.
Du coup je me suis demandé si d’autres avaient déjà fait un client sse en php (même si ça paraît étrange sur le concept) et on trouve quelques trucs: une piste à explorer p-e ?
Y a-t-il une gestion de « keep alive » a faire sur le stream ou pas ? (Si tu sais)
Un grand merci pour ta proposition d’aide
L adocumentation de l’API est là :
https://developer.home-connect.com/docs/general/endpoints_dataencoding
La partie SSE est dans le menu Events
Je vois bien KEEP-ALIVE dans l’availability matrix
https://developer.home-connect.com/docs/monitoring/availabilitymatrix
Je vais être honnête j’ai un peu l’impression de m’être attaqué à un morceau un peu gros pour moi. Mais je sais qu’avec de la patience et de la ténacité on arrive à beaucoup de choses.
Mon travail sans le demon est dans la branche beta de mon github
C’est celle qui est envoyée sur le market et utilisée par mes testeurs (le problème c’est que les appareils Home Connect sont chers, j’attends un lave vaisselle dont la livraison a été reculée au 15 février et pas question pour moi d’en acheter un autre dans un futur proche donc je repose presque entièrement sur 4 ou 5 testeurs et aussi ce que j’arrive à tester en mode démo avec les appareils virtuels)
Je vais envoyer l’état actuel de mon démon qui est une coquille vide sans la partie SSE que je n’ai pas encore faite dans une autre branche pour que tu puisses y jeter un oeil.
Juste pour tester j’ai fait le code de part et d’autre pour envoyer le token au démon quand je le renouvelle je vais attendre que çà se produise pour voir si çà marche (les token sont valables 24h)
Lors de ma recherche j’avais trouvé un projet en nodejs
Et un autre en Python
J’ai aussi compris des trucs en lisant le projet homebridge home connect