Veolia-idf SEDIF - suivi consommation eau potable

Je pensais que c’était résolu du coup.

Je commencerai par remplacer https://xxxxxxxx.duckdns.org:8123/api/ par https://home-assistant.local:8123 ou https://xxxxxxxx.duckdns.org dans la configuration comme valeur pour « ha_server ».

Je suis un peu étonné que https://home-assistant.local:8123 fonctionne car le certificat SSL (pour le https) ne devrait pas être valide.
Je suppose qu’une redirection de port est déjà en place qqpart car https://xxxxxxxx.duckdns.org sans specifier le port fonctionne (https c’est par défaut le port 443).

Sinon, on peut rediriger le port sur la box de 443 à l’ip interne + port 8123 si HA est configuré en https sur ce port et que le HTTPS est géré sur home-assistant.

Merci Le-top, cette étape semble fonctionner. J’ai juste enlevé le « :8123 » de l’adresse duckdns dans « ha_server » … mais je ne suis pas encore au bout de mes peines.
J’ai maintenant un problème pour Display:

Xephyr program closed. command: [‹ Xephyr ›, ‹ -br ›, ‹ -screen ›, ‹ 1280x1024x24 ›, ‹ -displayfd ›, ‹ 6 ›, ‹ -resizeable ›] stderr: b’\nXephyr cannot open host display. Is DISPLAY set?\n’

Je précise que j’utilise en addon via AppDaemon en ayant suivi scrupuleusement les instructions. Je n’ai pas mis de « DISPLAY » dans apps.yaml:

veolia_idf:
module: veolia_idf
class: VeoliaIDF
config_file: /config/appdaemon/apps/veolia-idf/config.json
debug_veolia: true
outfile: /config/veolia_script.log
errfile: /config/veolia_script_err.log
script: /config/appdaemon/apps/veolia-idf/veolia-idf-domoticz.py

et dans mon config.json, j’ai bien mis:
« chromium »: « /usr/bin/chromium-browser »,

Pour AppDaemon je charge bien tout:
init_commands: []
python_packages:

  • selenium
  • PyVirtualDisplay
    system_packages:
  • py-urllib3
  • py3-colorama
  • xvfb
  • py3-pip
  • xorg-server-xephyr
  • chromium-chromedriver
  • chromium
  • py3-openssl
  • py3-pysocks
  • py3-wsproto
  • py3-sniffio
  • py3-async_generator
  • py3-sortedcontainers
  • py3-attrs
  • py3-outcome
  • py3-trio

Une idée svp ? Merci beaucoup.

Il ne faut pas activer le débogue qui a besion d’un « DISPLAY » permettant de visualiser le navigateur. C.a.d. un Serveur X tel que VcXsrv ou installé de base dans une distribution *nix avec interface graphique.
DISPLAY doit alors être possitionné à qqchse comme :« 192.168.0.25:0 ».

Sans l’option « debug », il y a un serveur X local (xorg-server-xephyr) sur un écran virtuel (xvfb) qui est utilisé. Et c’est le mode de fonctionnement souhaité.

Merci le_top, gros progrès, j’ai maintenant récupéré des data avec 2 sensors: sensor.veolia_xxxxxxx_period_total et sensor.veolia_xxxxxxx_total.

1 « J'aime »

Pour ceux qui veulent ou ont besoin de lancer en mode débug, je viens de découvrir un serveur X pour PC très facile à mettre en oeuvre:

Mobaxterm Portable.

Je recommande car:

  • « Sans installation »;
  • Lance un Serveur X automatiquement;
  • Un popop pour demander l’autorisation lorsque le process tente de se connecter;
  • Il suffit alors de définir DISPLAY à <IP_OU_NOM_RESEAU_PC>:0 après avoir lancé ce logiciel et accepté l’accès aux réseaux privés.

Bonjour je tente d’intégrer MetersToHA mais lors de mes tests ce n’est pas concluant :

historique_gazpaz.json :

{"%NUM_COMPTEUR%":{"idPce":"%NUM_COMPTEUR%","releves":[],"frequence":null}}

service.log :

> 2023-02-09 01:06:09,299 : -- : Writing /config/appdaemon/apps/MetersToHA/historique_gazpar.json Parsing JSON file
2023-02-09 01:06:09,505 : EE :  url=https://%URL%/api/states/sensor.gas_consumption_kwh - (code = 404)
content=b'{"message":"Entity not found."}')
2023-02-09 01:06:09,622 : OK : Close Browser 
2023-02-09 01:06:09,625 : OK : Close Display 
2023-02-09 01:06:09,625 : EE :  Ended with error : // re-run the program with '--debug' option

testgrdf.log :

  File "/config/appdaemon/apps/MetersToHA/meters_to_ha.py", line 2587, in doWork
    injector.update_grdf_device(gazpar_file)
  File "/config/appdaemon/apps/MetersToHA/meters_to_ha.py", line 1973, in update_grdf_device
    response = self.open_url(HA_API_SENSOR_FORMAT % (sensor,))
  File "/config/appdaemon/apps/MetersToHA/meters_to_ha.py", line 1823, in open_url
    raise RuntimeError(
RuntimeError: url=https://%URL%/api/states/sensor.gas_consumption_kwh - (code = 404)
content=b'{"message":"Entity not found."}')

Une piste pour m’aiguiller ?

Le cas ou c’est une nouvelle mise en place n’était pas bien traité - je pense que c’est ok désormais (code modifié).

(Je suppose aussi que l’extrait « historique_gazpar.json » n’est que partielle et que la liste des « releves » n’est pas vide.)

Bonjour, petit problème depuis quelques jours de « file download timeout »

2023-03-03 10:36:09,420 : OK : Wait for button Telechargement
2023-03-03 10:36:09,462 : ~~ : Wait before clicking (10.0s)
2023-03-03 10:36:36,405 : OK : Click on button Telechargement
2023-03-03 10:37:07,750 : EE : Wait for end of download to /config/appdaemon/apps/veolia-idf/historique_jours_litres.csv
Get & Save ‹ /config/appdaemon/apps/veolia-idf/error.png › File download timeout
2023-03-03 10:37:07,946 : OK : Close Browser
2023-03-03 10:37:07,950 : OK : Close Display
2023-03-03 10:37:07,951 : OK :
2023-03-03 10:37:07,951 : EE : Ended with error : // re-run the program with ‹ –debug ›

Une petite idée de comment résoudre celà svp?
Merci bcp

Je viens de vérifier si puor moi cela fonctionne: oui, c’est ok.

En principe (selon la trace) il y a une image sous ‹ /config/appdaemon/apps/veolia-idf/error.png › qui peut éventuellement donner une idée.
L’est le contenu du navigateur après l’expiration du clic sur le bouton téléchargement.

Après — pour aller plus loin — cela se corse un peu. Il faut avoir un serveur X accessible depuis la machine ou l’on exécute veolia-idf. J’en touche un peu plus dans le projet dérivé « MetersToHA » .

A priori il y a eu 30 secondes d’attente entre le clic sur téléchargement est l’expiration ce qui devrait quand même être suffisant.

Regardons déjà error.png.

Bonjour le_top,
le fichier error.png ne donne rien, c’est juste une copie d’ecran du website veolia qui donne mes données, rien lié à l’erreur.
Je me suis en DEBUG avec un DISPLAY, et tout fonctionne bien, les données sont bien récupérées ainsi que le fichier .csv.
mais dès que je ne suis plus en DEBUG j’ai cette erreur de timeout.
Après quelques recherches sur l’erreur il semble que celà vienne de « webdriver ».
par exemple:

Je ne suis pas développeur donc çà ne me parle pas beaucoup, mais je voulais reporter ce problème.
Si vous avez une idée pour le résoudre, idées bienvenues.
Merci.

Le fait que cela fonctionne en mode débogue, c’est déjà « un début ».

error.png - Même si cela n’affiche pas d’erreur, étant une capture de l’écran au moment du "timeout’ cela donne quand même un indice. D’acprès ce que je comprend de la description, c’est une page graphique ou l’on voit le bouton « Télécharger la période », et non une image ou l’on voit le contenu d’un CSV.

Ce n’est pas en soi un problème de ChromeDriver qui entraine un timeout. Je me demande s’il n’y pas un problème d’écriture du fichier csv. Le script conclus à un timeout s’il ne voit pas l’apparition du fichier à l’endroit attendu qui peut être défini dans la config et qui devrait donc s’écrire à l’endroit « /config/appdaemon/apps/veolia-idf/historique_jours_litres.csv » . Je suppose que ce fichier ne se trouve pas à cet endroit (sinon, le script a un problème pour « le voir »).

S’il y a un fichier « chromedriver.log » (dans mon cas « /config/chromedriver »), on y trouve une trace de la recherche du bouton Télécharger la période (avec « charger la p » pour éviter les accents):

[1678495581.991][INFO]: [dea49767b4d98367e93f43619d223fc6] COMMAND FindElement {
   "using": "xpath",
   "value": "//button[contains(text(),\"charger la p\")]"
}

Suivi d’une réponse:

[1678495582.065][INFO]: [dea49767b4d98367e93f43619d223fc6] RESPONSE FindElement {
   "element-6066-11e4-a52e-4f735466cecf": "d9f452ae-e0a4-40db-b03c-bf9063a16f56"
}

Ou l’identifiant sert plus tard dans une demande de clic (sur ce bouton pour télécharger, qui mène dans mon cas rapidement à la fin du script (divers ok):

[1678495592.232][INFO]: [dea49767b4d98367e93f43619d223fc6] COMMAND ClickElement {
   "id": "d9f452ae-e0a4-40db-b03c-bf9063a16f56"
}
[1678495592.232][INFO]: [dea49767b4d98367e93f43619d223fc6] COMMAND ClickElement {
   "id": "d9f452ae-e0a4-40db-b03c-bf9063a16f56"
}
[1678495592.232][INFO]: Waiting for pending navigations...
[1678495592.234][INFO]: Done waiting for pending navigations. Status: ok
[1678495592.504][INFO]: Waiting for pending navigations...
[1678495592.530][INFO]: Done waiting for pending navigations. Status: ok
[1678495592.530][INFO]: [dea49767b4d98367e93f43619d223fc6] RESPONSE ClickElement
[1678495592.702][INFO]: [dea49767b4d98367e93f43619d223fc6] COMMAND Quit {
}
[1678495592.805][INFO]: [dea49767b4d98367e93f43619d223fc6] RESPONSE Quit

Il y a peut-être une indication de problème d’écriture.

Personnellement j’ai défini "download_folder": "/config/csv",, avec un répertoire /config/csv qui existe.

Et voici ma configuration dans ‹ apps.yaml › ou keep_csv: true permet de garder le fichier csv après exécution du script:

veolia_idf:
  module: veolia_idf
  class: VeoliaIDF
  log_folder: /config
  config_file: /config/veolia-idf/config.json
  keep_csv: true
  outfile: /config/appdaemon/apps/test.log
  errfile: /config/appdaemon/apps/testerr.log

Il est possible de définir et augmenter la valeur « timeout » dans le fichier de configuration « …json », je suggère aussi de définer le download_folder à un autre endroit pour vérifier si ce n’est donc pas un pb d’écriture:

   [...]
    "download_folder": "/config",
    "type": "ha",
    "timeout": "90"
}

J’ai testé de mon côté sans mettre le download_folder, et le script fini bien en laissant le fichier sous /config/appdaemon/apps/veolia_idf/historique_jours_litres.csv .

merci le_top.
Ton commentaire sur le error.png est exact, je ne vois pas le contenu du .csv.
J’ai paramétré comme toi le répertoire download du csv, en « /config/csv » qui existe de même que le keep_csv: true et le reste également. J’ai augmenté à 90 la valeur du timeout.
Résultat: en mode DEBUG, tout fonctionne, le fichier csv avec les données est bien présent au bon endroit, mais en mode normal, même erreur.
A noter que j’ai ceci dans le veolia_script_err.log, mais ce n’est qu’un warning:

/config/appdaemon/apps/veolia-idf/veolia-idf-domoticz.py:302: DeprecationWarning: firefox_profile has been deprecated, please use an Options object
fp = webdriver.FirefoxProfile()

/config/appdaemon/apps/veolia-idf/veolia-idf-domoticz.py:303: DeprecationWarning: Setting a profile has been deprecated. Please use the set_preference and install_addons methods
opts.profile = fp

/config/appdaemon/apps/veolia-idf/veolia-idf-domoticz.py:329: DeprecationWarning: service_log_path has been deprecated, please pass in a Service object
self.__browser = webdriver.Firefox(
/config/appdaemon/apps/veolia-idf/veolia-idf-domoticz.py:410: DeprecationWarning: executable_path has been deprecated, please pass in a Service object
self.__browser = webdriver.Chrome(

Je sèche… je peux t’envoyer le log complet si nécessaire mais rien d’anormal a priori.
A noter que je suis sous Synology en VMM avec les dernières versions de tout.

Je ne vois pas ce qui entraine la différence en mode débug.

Les warnings concernant les options sont effectivement pas critiques.

Toutefois, en évoluant veolia-idf vers MetersToHA, j’ai modifié la façon de passer les paramètres. MetersToHA c’est à la base veolia-idf pour y ajouter GRDF.
Je viens de voir que c’est là que j’ai ajouté la trace « chromedriver.log » - la configuration n’est pas présente dans veolia-idf.

Je propose de faire un essai avec MetersToHA.

Le fichier de configuration json peut être maintenu.

Voici ma configuration dans ‹ apps.yaml › pour veolia-idf et MetersToHA (pour veolia):

veolia_idf:
  module: veolia_idf
  class: VeoliaIDF
  # event_name: call_veolia
  # log: veolia
  # optional
  log_folder: /config
  # optional (Default: "config.json" in directory of `veolia-idf-domoticz.py`)
  config_file: /config/veolia-idf/config.json
  # optional (Default: "<REALMODULESCRIPTPATH>/veolia-idf-domoticz.py")
  # script: /config/veolia-idf/veolia-idf-domoticz.py
  # optional (Default: false) - add --keep_csv option
  keep_csv: true
  # optional (Default: false) - add --debug option
  # debug_veolia: true
  # DISPLAY: "192.168.1.1:0"
  # optional (Default: None) - Set file for stdout of script call
  outfile: /config/appdaemon/apps/test.log
  # optional (Default: None) - Set file for stderr of script call
  errfile: /config/appdaemon/apps/testerr.log

veolia:
  module: meters_to_ha_appdaemon
  class: MetersToHA
  event_name: call_veolia2
  extra_opts: [--screenshot,--veolia]
  # log: veolia
  # optional
  log_folder: /config
  # optional (Default: "config.json" in directory of `veolia-idf-domoticz.py`)
  config_file: /config/veolia-idf/config.json
  # optional (Default: "<REALMODULESCRIPTPATH>/veolia-idf-domoticz.py")
  # script: /config/veolia-idf/veolia-idf-domoticz.py
  # optional (Default: false) - add --keep_output option
  keep_output: true
  # optional (Default:  false) - add --debug option
  #debug: true
  #DISPLAY: "10.33.2.69:0"
  # optional (Default: None) - Set file for stdout of script call
  outfile: /config/appdaemon/apps/testv2.log
  # optional (Default: None) - Set extra options for script call
  errfile: /config/appdaemon/apps/testv2err.log

J’attire l’attention sur ces deux lignes:

  event_name: call_veolia2
  extra_opts: [--screenshot,--veolia]

La première c’est pour déclencher MetersToHA sur l’événement call_veolia2 . Comme j’ai les deux configs en place, il faut éviter de lancer les 2 en même temps.

Puis « extra_opts » comporte « –veolia » que seul les données veolia sont obtenus et non grdf. En principe l’absence de configuration GRDF fans le fichier JSON est suffisant - mais j’ai les deux configs, et je récupére GRDF et Veolia à des heures différentes.

Je ne peux pas garantir que cela fonctionnera mieux, mais au moins le passage des options est amélioré, et le fichier « chromedriver.log » devrait aussi faire son apparence.

Bonjour le_top,
J’ai basculé en MetersToHA, mais exactement la même erreur. Aucun problème en mode DEBUG çà fonctionne mais en mode normal même erreur, avec ceci:
Traceback (most recent call last):
File « /config/appdaemon/apps/MetersToHA/meters_to_ha.py », line 2935, in doWork
crawler.init()
File « /config/appdaemon/apps/MetersToHA/meters_to_ha.py », line 489, in init
raise Exception(« No browser could be started with selenium »)
Exception: No browser could be started with selenium

ceci étant dans mon service.log j’ai ceci:
2023-03-17 09:36:46,998 : WW : « geckodriver » not found in config file, using default value
2023-03-17 09:36:46,998 : OK : « geckodriver » = « /config/appdaemon/apps/MetersToHA/geckodriver »
2023-03-17 09:36:46,998 : WW : « firefox » not found in config file, using default value
2023-03-17 09:36:46,998 : OK : « firefox » = « /config/appdaemon/apps/MetersToHA/firefox »
2023-03-17 09:36:46,998 : WW : « chromium » not found in config file, using default value
2023-03-17 09:36:46,998 : OK : « chromium » = « /usr/bin/chromium-browser »
2023-03-17 09:36:46,998 : WW : « chromedriver » not found in config file, using default value
2023-03-17 09:36:46,998 : OK : « chromedriver » = « /usr/bin/chromedriver »
2023-03-17 09:36:46,998 : OK : « chrome_version » = « None »

Sachant que j’utilise un PC qui se connecte à mon NAS Synology où homeassistant est installé en VM. Peut être faut il indiquer quelque part où le fichier firefox.exe sur mon PC se trouve?

Merci bcp!

En rajoutant le chemin de firefox.exe, çà se connecte au site Veolia, mais le problème persiste pour le timeout:

Traceback (most recent call last):
File « /config/appdaemon/apps/MetersToHA/meters_to_ha.py », line 2968, in doWork
veolia_idf_file = crawler.get_veolia_idf_file()
File « /config/appdaemon/apps/MetersToHA/meters_to_ha.py », line 1367, in get_veolia_idf_file
raise RuntimeError(« File download timeout »)
RuntimeError: File download timeout

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File « /config/appdaemon/apps/MetersToHA/meters_to_ha.py », line 2979, in doWork
veolia_idf_file = crawler.get_veolia_idf_file()
File « /config/appdaemon/apps/MetersToHA/meters_to_ha.py », line 1215, in get_veolia_idf_file
el_password = self.__wait.until(
File « /usr/lib/python3.10/site-packages/selenium/webdriver/support/wait.py », line 95, in until
raise TimeoutException(message, screen, stacktrace)
selenium.common.exceptions.TimeoutException: Message: failed, page timeout (timeout=60)

Sauf erreur, ta configuration est:

Synology NAS < VM avec HAOS < AddOn AppDaemon (donc docker) avec tous les packets tel qu’indiqué dans la documentation < Configuration AppDaemon < Lancement par déclenchement d’événement .

En mode débogue, le processus va tenter d’ouvrir l’interface graphique du navigateur sur serveur X « externe » et non sur un serveur X avec écran virtuel « interne » (c.a.d. au sein du conteneur de AppDaemon). Le navigateur tourne toujours dans la VM HAOS, mais le PC (avec un serveur X actif) sert d’affichage. Puis, il y a un peu plus d’information de débogue.

Aucun navigateur du PC n’intervient dans ce processus là dans cette configuration.

Sous AppDaemon c’est chromium qui est utilisé car en principe il y ni firefox ni geckodriver. Avec MetersToHA il devrait y avoir un fichier chromedriver.log qqpart - pas sûr qu’il va nous éclairer, mais c’est possible. Avec le chemin « firefox », le processus s’arrête au moment ou il attend le champs du mot de passe.

Il est vrai qua dans mon fichier config.json j’ai "chromium": "/usr/bin/chromium-browser",, Dans le principe cela ne devrait pas être nécessaire, mais suite à test cela semble tout de même le cas.
Donc en attendant je suggère d’ajouter cette ligne et de mon côté je vais corriger la détection automatique du chemin pour chromium-browser.

Sinon, on est d’accord que le mode débogue qui fonctionne c’est toujours depuis AppDaemon, en ajoutant l’option --debug et en définissant le DISPLAY qui pointe vers l’IP du PC ou il y a un Serveur X qui tourne.

merci le_top. Ma configuration est bien celle indiquée.
J’ai bien trouvé le fichier chromedriver.log. Très long, mais je remarque notamment:
Au début:
[1679051909.813][INFO]: Starting ChromeDriver 110.0.5481.177 (f34f7ab2d4ca4ad498ef42aeba4f4eb2c1392d63-refs/branch-heads/5481@{#1239}) on port 54655

[1679051909.814][INFO]: Please see ChromeDriver - WebDriver for Chrome - Security Considerations for suggestions on keeping ChromeDriver safe.

[1679051909.824][SEVERE]: bind() failed: Address not available (99)

[1679051909.824][INFO]: listen on IPv6 failed with error ERR_ADDRESS_INVALID

et après apparemment plusieurs tentatives de ce type:

[1679052092.754][INFO]: Waiting for pending navigations…
[1679052092.754][INFO]: Done waiting for pending navigations. Status: ok
[1679052092.759][INFO]: Waiting for pending navigations…
[1679052092.760][INFO]: Done waiting for pending navigations. Status: ok
[1679052092.760][INFO]: [383ff1044de5b58bf41c2373d07477e3] RESPONSE FindElements [ ]
[1679052093.262][INFO]: [383ff1044de5b58bf41c2373d07477e3] COMMAND FindElements {
« using »: « css selector »,
« value »: « input[type="password"] »

Je partage ma trace par pastebin (login & mot de passe remplacé par x):

Cela permets peut-être de trouver une différence importante.

Nos versions de chromedriver (et chromium) sont différentes (vous: 110.xxx, moi: 109.xxx)- ce qui peut être un élément impactant. Je peux essayer de mettre à jour de mon côté en reinitialisant AppDaemon. Vous pouvez aussi installer le paquet « undetected-chromedriver » (à ajouter aux paquets python à installer pour AppDaemon, dans sa config, dans la liste python_packages). Cela a un effet dans MetersToHA.
Cela peut entrainer la nécessiter d’ajouter l’option --chrome-version et son argument aux options de lancement dans la config apps.yaml (110 pour vous à priori - c’est la version principale de chromium):
extra_opts: [–screenshot,–veolia,–chrome-version,« 110 »] .
(Je n’ai pas testé undetected-chromedriver sous AppDaemon, un des effets c’est que cela télécharge une version de chromdriver par lui-même sans utiliser celui installé).

L’erreur IPv6 je l’ai aussi car il n’y a pas de IPv6, mais il y a un port ouvert en IPV4.

Je vous suggère en priorité de comparer les traces chromedriver.log .

J’ai pu reproduire le problème initial.

Le fichier est bien téléchargé, mais je pense qu’il n’est pas enregistré à cause de nouveaux contraintes de sécurité.

Du coup j’ai vu qu’il était disponible autrement et j’ai pu concevoir une solution.

Avant cela j’ai réglé plusieurs autres points sensibles au délais et j’ai ajouté qqs attentes supplémentaires, une détection si l’utilisateur est déjà identifié, … .

Du coup, il faut effective passer à MetersToHA car je ne l’ai pas porté à veolia-idf.
(La partie du code qui règle le problème initial est à recopier avec quelque modifs dans le code veolia_idf)

Bravo le_top, bonne nouvelle que tu aies pu reproduire le problème, maintenant tout fonctionne parfaitement!
Je vais pouvoir maintenant tenter de mettre celà dans InfluxDB / Grafana.
Merci encore pour la correction.

1 « J'aime »