GAZPAR/GRDF - MetersToHA compatible exigence CAPTCHA

C’est bien le même nombre, j’ai même copié collé du script dans l’URL. Je vais relancer le script en mode trace et non debug. Je n’ai pas ces lignes « deny » dans service.log jusqu’ici

J’ai ceci

2023-10-07 17:51:18,636 : WW :  Traceback (most recent call last): -   File "MetersToHA/apps/meters_to_ha/meters_to_ha.py", line 3151, in doWork -     gazpar_file = crawler.get_gazpar_file() -                   ^^^^^^^^^^^^^^^^^^^^^^^^^ -   File "MetersToHA/apps/meters_to_ha/meters_to_ha.py", line 1545, in get_gazpar_file -     self.__wait.until(document_initialised) -   File "/usr/lib/python3.11/site-packages/selenium/webdriver/support/wait.py", line 86, in until -     value = method(self._driver) -             ^^^^^^^^^^^^^^^^^^^^ -   File "MetersToHA/apps/meters_to_ha/meters_to_ha.py", line 359, in document_initialised -     return driver.execute_script("return true;") -            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -   File "/usr/lib/python3.11/site-packages/selenium/webdriver/remote/webdriver.py", line 404, in execute_script -     return self.execute(command, {"script": script, "args": converted_args})["value"] -            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -   File "/usr/lib/python3.11/site-packages/selenium/webdriver/remote/webdriver.py", line 344, in execute -     self.error_handler.check_response(response) -   File "/usr/lib/python3.11/site-packages/selenium/webdriver/remote/errorhandler.py", line 229, in check_response -     raise exception_class(message, screen, stacktrace) - selenium.common.exceptions.TimeoutException: Message: script timeout -   (Session info: headless chrome=117.0.5938.62) -

« selenium.common.exceptions.TimeoutException »
indique que l’opération avant prend trop de temps.

C’est peut-être mieux de m’envoyer la trace complète par message direct.

C’est fait ; j’ai rajouté veolia dans l’intervalle, qui finit également avec une erreur :confused:

Le premier problème de @hayvan était la vitesse d’exécution - le contournement a été d’augmenter le timeout par défaut (il a été mis à 120).

Ensuite apparaîssait un autre problème qui a finit par apparaître également dans mon installation.
J’ai donc pu l’analyser et trouver une solution. J’espère que c’est également fonctionnel ailleurs.

Avec le add-on il suffit de le redémarrer (le code exécuté est mis à jour lors du redémarrage). Sinon, il faut télécharger MetersToHA (HACS/AppDaemon ou autre).

J’ai enfin fini la contractualisation pour utiliser l’api de grdf.

Plus qu’à faire quelques tests. Ca interesserait du monde de recupérer la conso de son compteur Gazpar de façon automatique ?

6 « J'aime »

Ah bah carrément! Mais ca voudrait dire que tu sais creer un client id et secret? Quel est ta façon de faire?

J’ai effectivement passé toutes les étapes pour avoir le droit à un client_id et secret_id (au passage, les secret_id ne sont pas très sécurisés) …

Donc, oui je peux m’interfacer avec leur API et les abonnés GrDF peuvent me donner leur consentement.

Par contre, il y a peu de chance que je crée une intégration car je ne vais pas trouver le temps.

Je ne sais pas s’il existe un truc générique pour prendre en entrée un JSON et le parser.

Non il faut en connaitre la structure pour le parser correctement.
Le consentement? Que veux-tu dire par là?
Parce que pour moi la seule possibilité est d’etre une societe dans le domaine du gaz non?

La structure, ce sera toujours la même.

Pour le consentement, l’abonné passera par mon site, puis sera redirigé vers GrDf et autorisera que je récupère ses consommations.

Je crois qu’ils sont assez souples sur les entreprises qui peuvent accéder à leur api. Pas besoin dvoir une société relative aux énergies … Il faut juste une société.

Cela a pris du temps pour moi car je n’avais pas le temps de m’en occuper.

Je te repondais sur un parser generique. Ca n’existe pas il faut la structure de la reponse pour faire le parser qui va bien.

Avec le « rest » sensor, on peut facilement le faire : RESTful - Home Assistant

Oui a l’aide de jq sans aucun probleme. C’est ce que je fais pour mon moteur came.

Parfait pourquoi s’embêter avec des intégrations :joy:

Pour parser un json en soi - c.a.d le convertir en une structure interne: c’est présent dans les languages populaires du moment.

Ensuite, il faut quand même un petit serveur auquels les clients se connectent?

CLIENT HA ↔ GATEWAY (client_id - secret_id) ↔ Serveur GRDF.

Si l’API de la gateway est documentée, MetersToHA peut être étendu pour prendre cela comme une source.

Oui c’est pas le json le souci, c’est surtout l’intégration dans HA. Je n’intègre pas ce genre de données de mon côté, je le stocke en Json et je restitue les données sous forme de graph avec une app streamlit.

Pour le serveur web, c’est pas vraiment un problème.

Tu peux donner un exemple de json retourné? Ca nous permettrai de voir la structure et anticiper l’integration :grin:.
En terme de confidentialité des données tu auras acces a quoi si on passe par ton site?

Justement, MetersToHA intègre déjà des données dans HA - si l’outil prends les données sur le gateway elle peuvent être dans le bon format en interne pour réutiliser les fonctions d’intégration dans HA (et autres).

Cela dépend du périmètre du consentement de l’abonné.

Au maximum, c’est :

  • Données de consommation avec une date de début et de fin.
  • Données publiées - Relevés transmis au fournisseur
  • Données informatives - Relevés quotidien (?)
  • Données contractuelles
  • Données techniques
  • Date début consentement
  • Date fin consentement

Il faut que je vois pour le json pas encore certain du format.

Je regarderai cette intégration.