Script pour grdf (pas veolia)

Bonjour à tous,
je galère depuis des jours avec ce script pour grdf (pas veolia) et je ne comprend vraiment pas pourquoi ça ne marche pas :
mon installation :
RPI3 avec home assistant OS
appdaemon installé et configuré avec toutes les options
HACS installé, et meterstoha à jour
j’ai un compte 2captcha avec des sous dessus !

quand je lance l’event call_grdf
le log se rempli bien et il bloque à Click on connexion :

2023-06-21 09:22:59,936 : OK :  
2023-06-21 09:23:44,927 : OK : Waiting for cookie popup 
2023-06-21 09:24:00,378 : OK : Click on deny 
2023-06-21 09:24:14,070 : OK : Connexion au site GRDF 
2023-06-21 09:24:17,285 : OK : Waiting for Password 
2023-06-21 09:24:25,660 : OK : Waiting for Email 
2023-06-21 09:25:01,717 : OK : Type Email 
2023-06-21 09:25:02,867 : OK : Type Password 
2023-06-21 09:25:05,880 : ~~ : Proceed with captcha resolution 2Captcha Service response OK|73880302268
2023-06-21 09:25:05,881 : ~~ :  Sleeping for 10 seconds to wait for 2Captcha
2023-06-21 09:25:16,536 : ~~ :  2Captcha Service response CAPCHA_NOT_READY
2023-06-21 09:25:16,542 : ~~ :  Sleeping for 10 seconds to wait for 2Captcha
2023-06-21 09:25:26,880 : ~~ :  2Captcha Service response CAPCHA_NOT_READY
2023-06-21 09:25:26,887 : ~~ :  Sleeping for 10 seconds to wait for 2Captcha
2023-06-21 09:25:37,239 : ~~ :  2Captcha Service response CAPCHA_NOT_READY
2023-06-21 09:25:37,240 : ~~ :  Sleeping for 10 seconds to wait for 2Captcha
2023-06-21 09:25:47,628 : ~~ :  2Captcha Service response CAPCHA_NOT_READY
2023-06-21 09:25:47,629 : ~~ :  Sleeping for 10 seconds to wait for 2Captcha
2023-06-21 09:25:58,017 : ~~ :  2Captcha Service response OK|03AL8dmw-c_hR8AO8GHZR8jjSJX7He2sKYd034_ZgpblOHAVGxFU50HiGsFhQoTHUZVHRXuI1e2qLZZrqZ4g-FrJy35AEHr3ioG1dyYMJzXHILl2YpPitdQnEDWDDB89mqEa70kSbJX48wzVKf4-pVYaLFd66EXt-oFR9JtxiMQgN6TqUxAP9SGbW5qUeJqSIT73Q7bbYsvda4oEoleAFXcA62T7eeDk-PmqrjuTIveIlNNzyBWIPpZ7EI8CSfrmN8insC2dLoWD1cz4UGsdfbKDqgYd_2KJH1sstI1Ow6sC7J5muEaX85-KdafWnlWhsXYDtDRgiz2Dx1oaKcQ3tul5VuY0UOxygkv_xYiCHralJmYTrTvy_RJ4sT1dVEN8vR--68xTc1OwVf6nrm8iqo-rlDUrWDimxUiaZoDcpxQc9BY7Yu7-5OwHKbr4Ei3rBli1nnKuoYA0Mwr_v7LzjXF8BX2ywB7UJKlYoa9-ZT66gqVShzqEnmvmmeik83-GqPW4bBZ0E4pQc-7BahOEYN25eM7GyF1FCivr3SBdN4MR7iyB81XQ81JAEZlBxSzgLxSaGYOXNGDVU-T0-e5vF0NS0xuXqO7d31XN9sg9NO5PLnI9GssK-TP0Jm3pD-brGthzkPTiarWCVP
2023-06-21 09:26:03,982 : OK : Automatic resultution succeededWait for Button xpath://input[@value='Connexion'] 
2023-06-21 09:26:03,984 : ~~ : Wait before clicking (1.9s) 
2023-06-21 09:26:09,483 : OK : Click on connexion ```

le log appdaemon indique :

2023-06-21 09:26:58.210013 WARNING AppDaemon: Excessive time spent in callback ‹ call_meters_to_ha() in grdf ›, Thread ‹ thread.thread-0 › - now complete after 304.16498 seconds (limit=10)```

voici mon config.json

{
  "grdf_login": "elmattt@xxxxxxx",
  "grdf_password": "xxxxxxxx",
  "grdf_pce": "xxxxxxxxx",
  "ha_server": "http://192.168.0.50:8123",
  "ha_token": "xxxxxxxxx",
  "2captcha_token": "xxxxxxxxx",
  "type": "ha",
  "timeout": "60"
}```

mon apps.yaml

grdf:
module: meters_to_ha_appdaemon
class: MetersToHA
event_name: call_grdf
config_file: /config/gaz/config.json```

une autre erreur que je rencontre apres avoir eu la premiere erreur est la suivant :

2023-06-21 09:32:22,198 : OK : End loading Home Assistant configuration 
2023-06-21 09:32:22,199 : ~~ :  Check availability of "geckodriver"+"firefox" or "chromedriver"+"chromium"
2023-06-21 09:32:22,200 : OK :  Found chromium binary
2023-06-21 09:32:22,269 : OK : Check Home Assistant connectivity 
2023-06-21 09:32:31,421 : OK : Try starting ChromiumStart virtual display (chromium) 
2023-06-21 09:33:36,389 : EE : Start the browser Message: unknown error: DevToolsActivePort file doesn't exist```

si quelqu'un à une idée ca m'intéresse ^^

d'avance merci !

Hello.
Je te propose de partir sur un nouveau sujet, car comme tu l’indiques, c’est sans rapport avec Veolia (idf en plus)

super merci beaucoup :wink:

En complément, tu peux sans doute préciser la source de ton script (ou du tuto que tu as suivi), il y tellement de choses disponibles partout que ce n’est pas forcement évident de parler de la même chose

j’ai suivi le tuto du github

qui est d’ailleurs bien complet !

1 « J'aime »

Le succès ne semble pas loin car la clef de captache est récupér" et l’étape après « Click on connexion » c’est normalement la récupération des données.

Quand cela fonctionne on a une suite comme ceci:

2023-06-21 23:53:30,389 : OK : Click on connexion
2023-06-21 23:53:49,975 : -- : Writing /config/csv/historique_gazpar.json Parsing JSON file
2023-06-21 23:53:50,033 : -- :  From sensor.grdf_xxxxx_kwh: {'entity_id': 'sensor.grdf_xxxx_kwh', 'state': '49.0', 'attributes': {'date_time': '2023-06-19T06:00:00+02:00', 'unit_of_measu

La deuxième erreur est probablement la suite de la première - lorsque la première tentative ne réussi pas, une deuxième est tentée avec la même session . Le problème de la première tenative impacte visiblement le deuxième. Donc on ne se concentre pas plus dessu.

Parmi les options pour AppDaemon, y-a-t-il:

  keep_output: true
  outfile: /config/appdaemon/apps/testgrdf.log
  errfile: /config/appdaemon/apps/testgrdferr.log

Cela permet d’obtenir éventuellement qqs infos supplémentaires. Sinon dans /config/appdaemon/apps/MetersToHA il y aussi service.log (d’ou les extraits viennent je suppose).

testgrdferr.log est en principe vide, et testgrdf.log comporte qqchse comme "Get_state_file /config/csv/meters2ha_state.json (il y a "download_folder": "/config/csv", dans mon config.json .

Sinon, il y a la methode de voir avec « –debug » et uns serveur X sur le PC Windows, ou natif sous linux pour voir ce qui se passe.
Ou utiliser docker pour vérifier si c’est un problème de version/performance.

Actuellement, avec Current version: 0.13.1 sur un ancien NUC de type x86 cela fonctionne.

Bonjour,

j’ai rajouté les options pour appdaemon :

j’ai relancé le script et voici le résultat dans le log appdaemon :

2023-06-22 09:50:41.684519 INFO grdf: Execute ['python3', '/config/appdaemon/apps/MetersToHA/meters_to_ha.py', '-r', '-c', '/config/gaz/config.json', '--keep-output']
2023-06-22 09:55:26.290667 WARNING AppDaemon: Excessive time spent in utility loop: 2525.0ms, 16.0ms in check_app_updates(), 2509.0ms in other
2023-06-22 09:55:41.853112 ERROR grdf: TimeoutExpired(['python3', '/config/appdaemon/apps/MetersToHA/meters_to_ha.py', '-r', '-c', '/config/gaz/config.json', '--keep-output'], 299.9998772379986)
2023-06-22 09:55:41.918623 INFO grdf: Done MetersToHA
2023-06-22 09:55:41.981021 WARNING AppDaemon: Excessive time spent in callback 'call_meters_to_ha() in grdf', Thread 'thread.thread-0' - now complete after 300.961147 seconds (limit=10)

rien dans testgrdf.log et testgrdferr.log

et mon service.log s’arrête tout seul à :

2023-06-22 09:50:49,433 : OK : End loading Home Assistant configuration 
2023-06-22 09:50:49,434 : ~~ :  Check availability of "geckodriver"+"firefox" or "chromedriver"+"chromium"
2023-06-22 09:50:49,435 : OK :  Found chromium binary
2023-06-22 09:50:49,496 : OK : Check Home Assistant connectivity 
2023-06-22 09:50:53,864 : OK : Try starting ChromiumStart virtual display (chromium) 
2023-06-22 09:52:25,744 : OK : Start the browser 
2023-06-22 09:52:25,771 : OK :  
2023-06-22 09:53:39,206 : OK : Waiting for cookie popup 
2023-06-22 09:53:42,194 : OK : Click on deny 
2023-06-22 09:53:52,137 : OK : Connexion au site GRDF 
2023-06-22 09:53:54,181 : OK : Waiting for Password 
2023-06-22 09:54:15,573 : OK : Waiting for Email 
2023-06-22 09:55:35,590 : OK : Type Email 
2023-06-22 09:55:38,497 : OK : Type Password 

j’ai l’impression que quelque chose arrête le script en cours de route non ??

En apparence le traitement de la connexion n’abouti pas complètement - si on considère que dans les premières traces il y a bien une ifnormation indiquant le clic sur « Connexion ».

J’ai ajouté quelques traces complémentaires à MetersToHA pour voir si le process s’arrête à Connexion ou après.

Perso, j’essaierai de voir su sur PC (avec docker), le processsus aboutit ou pas. Et aussi le mode -debug (nécessite un serveur X ). Peut-êter que le Pi3 ne peut fournir la mémoire nécessaire ou il est trop occupé par ailleurs ce qui peut entrainer les ralentissements, en particulier s’il est en train de « swapper » à fond.