J’ai mis ces daux examples sous test/csv dans le projet et j’ai commencé un peit doc dous docs/Veolia.md .
Cela me semble intéressant de se faire une idée à quel heure le relevé de veolia eau services correspond. Si on prend le relevé physiquement à heures connues, la première approche c’est une règle de 3. Si on prend matin, midi et soir, minuit et lendemain matin cela devrait reserrer la plage.
Bonsoir à tous, petit problème de mon côté après, je crois, une MAJ de AppDaemon.
Maintenant j’ai dans le log ce qui suit: apparemment il ne trouve pas le secrets.yaml
Quelqu’un aurait une idée svp?
Merci bcp et bonne soirée.
s6-rc: info: service legacy-services successfully started
Traceback (most recent call last):
File « /usr/bin/appdaemon », line 8, in
ERROR Error loading secrets file: /config/secrets.yaml
sys.exit(main())
^^^^^^
File « /usr/lib/python3.11/site-packages/appdaemon/main.py », line 417, in main
admain.main()
File « /usr/lib/python3.11/site-packages/appdaemon/main.py », line 276, in main
if « appdaemon » not in config:
^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: argument of type ‹ NoneType › is not iterable
[20:26:32] INFO: Service AppDaemon exited with code 1 (by signal 0)
« Home Assistant » a changé le répertoire /config en /homeassistant et déplacé les configurations des add-on vers /addon_configs sans penser à un vrai plan d’évolution des installation à mon avis.
Du coup, je recommande:
Suite à (1) un bogue sur la plateforme de veolia et (2) un changement dans le nom du fichier de téléchargement, j’ai dû apporter quelques évolutions à MetersToHA.
Pour en profiter, il suffit de redémarrer le add-on, sinon il faut mettre à jour AppDaemon our tout autre action nécessaire selon la méthode d’installation.
Salut,
Merci pour ce service bien pratique.
Cependant j’ai toujours un bug et je n’ai plus de remontée depuis le 13/12, malgré mise à jour et redémarrage Appdaemon.
Dans les logs, il remonte une erreur pour accéder au bouton « Litres » … et effectivement je reproduis le problème en navigant sur le site dans mon espace client, la partie historique ne se charge pas : je dois d’abord aller dans un des onglets « Consommation facturée » ou « Alertes de consommation » pour enfin aller dans « Historique » pour que la page se charge correctement et que je puisse accéder aux boutons attendus …
Je suis le seul dans ce cas ?
Merci d’avance
@_fp J’ai publié la mise à jour il y a 5 jours. Il faut mettre à jour MetersToHA - j’ai implémenté ce contournement.
ah je viens de comprendre, les mises à jour MeterToHA arrivent dans l’ancien chemin /config/appdaemon/ et non pas dans le nouveau chemin addon_configs/a0d7b954_appdaemon , j’avais vraisemblablement corrigé le soucis de chemin un peu salement lorsque ça s’est produit, j’ai copié les fichiers au bon endroit et ça passe, je réinstallerais au propre cette partie quand j’aurais un peu de temps … Un grand merci !!
Bonjour, je continue donc ici plutôt que le fil GAZPAR, désolé.
Tout d’abord je tourne maintenant sur un N100, donc pas de problème de ressources a priori.
Pas de tag git configuré, et j’ai bien
Your branch is up to date with 'origin/meters-to-ha'.
MetersToHA Container version: dev.016 #1ffabca5cf27b9f8a46e57c1d056364e /run.sh
MetersToHA Python GIT version: 154f476 on Thu Dec 21 18:19:38 2023 +0100
Je continue à avoir la même erreur :
2023-12-24 07:43:05,105 : OK : Click on button Jours
2023-12-24 07:43:07,118 : OK : Wait for button Telechargement
2023-12-24 07:43:07,118 : ~~ : Wait before clicking (10.0s).
2023-12-24 07:43:17,159 : OK : Click on button Telechargement
2023-12-24 07:46:17,683 : WW : Wait for end of download to '/config/historique_jours_litres*.csv'Grab & Save '/config/error.png'. Traceback (most recent call last): - File "//MetersToHA/apps/meters_to_ha/meters_to_ha.py", line 3368, in doWork - veolia_idf_file = crawler.get_veolia_idf_file() - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - File "//MetersToHA/apps/meters_to_ha/meters_to_ha.py", line 1686, in get_veolia_idf_file - raise RuntimeError("File download timeout") - RuntimeError: File download timeout
2023-12-24 07:46:17,730 : WW : Grab & Save '/config/screen_on_exception1.png'. Encountered error -> Retrying once
2023-12-24 07:46:19,311 : OK : Connexion au site Veolia Eau Ile de France
2023-12-24 07:46:20,031 : EE : Grab & Save '/config/check_profile.png'. Remove temporary download file '/config/historique_jours_litres.csv'. Grab & Save '/config/screen_on_exception2.png'. Writing '/config/screen_on_exception2.png.html'. [Errno 2] No such file or directory: '/config/historique_jours_litres.csv'
2023-12-24 07:46:20,093 : OK : Close Browser
2023-12-24 07:46:20,095 : OK : Close Display
2023-12-24 07:46:20,095 : EE : Ended with error : // re-run the program with '--debug' option
Les png d’erreur ne donnent pas beaucoup d’infos :
error.png
Bonjour,
Pour GRDF dans le tab Energie, j’ai le capteur « sensor.grdf_xxxxxxx_daily_kwh » qui affiche « Les entités suivantes ont la classe « measurement » mais « last_reset » est manquant ». il semble que: The state class for “energy” entities should be “total_increasing” (energy consumed since the last reset).
Avez vous eu ce problème et comment le resoudre svp?
Bonnes fetes à tous.
Je « recommande » d’utiliser sensor.grdf_xxxxxxx_kwh qui représente le total des kWh avec la valeur ‹ total_increasing › defini, et non période par période (le ‹ daily_kWh › peut des fois regrouper plusieurs jours).
L’utilisation de last_reset a été déprécié .
Les ‹ daily_kWh › sont là pour des raisons historiques (car proposé par au moins une ancienne intégration) et cela peut faciliter l’affiche d’un historique « journalier » en dehors du panneau « Energie ».
Bonjour Mario 
J’ai un problème avec l’intégration. J’ai installé l’intégration meterstoHA, l’ai paramétré avec mes identifiants SEDIF et dans les logs, j’ai un message d’erreur:
Si tu peux m’aiguiller, merci beaucoup 
Je vois que la méthode d’installation est probablement le Add-On.
Avant ce message en question on devrait voir qqchse comme ceci:
Test access to Home Assistant API (should show '{"message":"API running."}')
curl -H 'Authorization: Bearer <ICI_IL_Y_LE_TOKEN_D_ACCESS>' -H 'Content-Type: application/json' http://supervisor/core/api/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 26 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 26 100 26 0 0 93 0 --:--:-- --:--:-- --:--:-- 93
{"message":"API running."}
Normalement on doit avoir {"message":"API running."} mais il y a peut-être autre chose qui indique le problème.
Quand le Add-On tourne au sein de HAOS, pas besoin d’ajouter des identifiant pour accéder à HA, sinon oui.
Donc généralement, ceci doit rester « vide »/non-renseigné:
Et quand c’est vide on voit un token généré sous Authorization: Bearer <ICI_IL_Y_LE_TOKEN_D_ACCESS>'
Donc, je te confirme que je tourne avec HAOS, de plus, j’utilise également un serveur mqtt. Est ce que je dois également le laisser vide?
Et j’ai bien le message en question:
[quote] % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0
100 26 100 26 0 0 3711 0 --:–:-- --:–:-- --:–:-- 4333
{« message »:« API running. »}
« ./haevent2exec.py » --config-json « /m2h_config.json » --external-program « /execEvent.sh » --log-level=« debug » call_veolia call_grdf [/quote]
Le fait qu’il soit renseigné ou non ne change rien tant qu’on ne l’a pas choisi comme type de serveur:
Si on choisi ‹ mqtt ›, ces informations sont nécessaires, sinon elles seront ignorées. Si le mode ‹ ha › ne fonctionne pas, ‹ mqtt › peut être une solution. Par contre, ‹ ha › devrait fonctionner…
L’erreur « 502 » - arrive à quel moment? J’imagine que cela peut éventuellement être lié au token et à ce moment là on peut tenter le redémarrage de l’add-on (un nouveau token sera générée).
Au début la connexion à l’api semble ok. Et la connexion est complètement ok quand on obtient ceci ensuite:
[2024/01/05 23:33:38] (haevent2exec.py) INFO Connected
[2024/01/05 23:33:38] (haevent2exec.py) INFO Result of subscription for 'call_veolia': None
[2024/01/05 23:33:38] (haevent2exec.py) INFO Result of subscription for 'call_grdf': None
[2024/01/05 23:33:38] (haevent2exec.py) INFO Result of subscription for 'homeassistant_started': None
[2024/01/05 23:33:38] (haevent2exec.py) INFO send_event_msg: Got id (4,)
[2024/01/05 23:33:38] (haevent2exec.py) INFO Subscribed, waiting for messages`
Ce qui confirme que haevent2exec.py a souscrit aux événements prévus.
Le déroulement normal (avec Niveau de débogue à « debug »):
[2024/01/06 01:45:00] (haevent2exec.py) INFO Received WSMessage(type=<WSMsgType.TEXT: 1>, data='{"type":"event","event":{"event_type":"call_veolia","data":{},"origin":"LOCAL","time_fired":"2024-01-06T00:45:00.168591+00:00","context":{"id":"01HKE3NWW1RY8WZ8NWQ3D8G1HH","parent_id":null,"user_id":null}},"id":1}', extra='')
[2024/01/06 01:45:00] (haevent2exec.py) INFO Received event: call_veolia
[2024/01/06 01:45:00] (haevent2exec.py) DEBUG Run_on_event: ha
[2024/01/06 01:45:00] (haevent2exec.py) INFO Start external program for call_veolia
[2024/01/06 01:45:00] (haevent2exec.py) DEBUG Run_on_event: kill
[2024/01/06 01:47:24] (haevent2exec.py) DEBUG Run_on_event: process_done
[2024/01/06 01:47:24] (haevent2exec.py) INFO send_event_msg: Got call_veolia ()
Cela indique le message reçu du web service, et à travers les messages divers étapes de son traitement (que je peux liés à des points dans le code).
Peut-être que cela mène déjà à d’autres indices.
J’ai donc relancé l’addon, j’ai changé le type de serveur et je suis passé à HA, voici le log:
Test access to Home Assistant API (should show '{"message":"API running."}')
curl -H 'Authorization: Bearer bcd5c5ca1db3390f135bde5923bf35a299966ecbcf3466621acec87b324c11d4ea0dbed54e1428dfa07ee866d1ec5dc36a6aa6e752acd8b2' -H 'Content-Type: application/json' http://supervisor/core/api/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 26 100 26 0 0 3138 0 --:--:-- --:--:-- --:--:-- 3250
{"message":"API running."}
"./haevent2exec.py" --config-json "/m2h_config.json" --external-program "/execEvent.sh" --log-level="debug" call_veolia call_grdf
[2024/01/08 17:19:54] (haevent2exec.py) INFO Received {'type': 'auth_required', 'ha_version': '2024.1.2'}
[2024/01/08 17:19:54] (haevent2exec.py) INFO Connected
[2024/01/08 17:19:54] (haevent2exec.py) INFO Result of subscription for 'call_veolia': None
[2024/01/08 17:19:54] (haevent2exec.py) INFO Result of subscription for 'call_grdf': None
[2024/01/08 17:19:54] (haevent2exec.py) INFO send_event_msg: Got id (3,)
[2024/01/08 17:19:54] (haevent2exec.py) INFO Subscribed, waiting for messages
[2024/01/08 17:19:54] (haevent2exec.py) INFO Received WSMessage(type=<WSMsgType.TEXT: 1>, data='{"id":1,"type":"result","success":true,"result":null}', extra='')
[2024/01/08 17:19:54] (haevent2exec.py) INFO Received WSMessage(type=<WSMsgType.TEXT: 1>, data='{"id":2,"type":"result","success":true,"result":null}', extra='')
Il semblerait que l’erreur 502 vienne quand je « call veolia »
Je vois que une chose qui manque est:
[2024/01/05 23:33:38] (haevent2exec.py) INFO Result of subscription for 'homeassistant_started': None
On n’est donc pas sur la même version.
Au passage je viens de mettre à jour l’OS de l’Add-On et j’ai passé la version de run à ‹ dev.17 › ce qui permettra de voir que le Add-On est à jour.
MetersToHA Container version: dev.017 #b8b932f7e0dd8fed68e4c6fbc846b372 /run.sh
MetersToHA Python GIT version: 4eb9df9 on Tue Jan 9 00:54:32 2024 +0100
La chaine « b8b932f7e0dd8fed68e4c6fbc846b372 » est le hash SHA1 de ‹ run.sh › .
La version du script meters_to_ha.py est 4eb9df9 - on peut vérifier si c’est la dernière dans cette liste.
Mais le problème ne semble pas lié à meters_to_ha.py, mais à l’échange des événements. C’est peut-être lié à la version…
Alors, je fais la mise à jour
Bonsoir,
J’essaye d’utiliser MetersToHA en MQTT. J’ai bien renseigné le serveur MQTT avec toutes les données, et la connection fonctionne. Par contre, après la connection au site Veolia ou GRDF, j’ai ce message - dans le service.log:
2024-01-09 22:11:15,714 : EE : ‹ <= › not supported between instances of ‹ str › and ‹ int ›
Et en regardant plus en détails, j’ai ceci, qui semble indiquer un problème dans la publication du msg mqtt:
python3 MetersToHA/apps/meters_to_ha/meters_to_ha.py -l /config -c "/m2h_config.json" --grdf -r
python3 MetersToHA/apps/meters_to_ha/meters_to_ha.py -l /config -c "/m2h_config.json" --veolia -r
Traceback (most recent call last):
File "//MetersToHA/apps/meters_to_ha/meters_to_ha.py", line 3388, in doWork
injector.update_veolia_device(veolia_idf_file)
File "//MetersToHA/apps/meters_to_ha/meters_to_ha.py", line 2872, in update_veolia_device
publish.single(
File "/usr/lib/python3.11/site-packages/paho/mqtt/publish.py", line 240, in single
multiple([msg], hostname, port, client_id, keepalive, will, auth, tls,
File "/usr/lib/python3.11/site-packages/paho/mqtt/publish.py", line 176, in multiple
client.connect(hostname, port, keepalive)
File "/usr/lib/python3.11/site-packages/paho/mqtt/client.py", line 912, in connect
self.connect_async(host, port, keepalive,
File "/usr/lib/python3.11/site-packages/paho/mqtt/client.py", line 979, in connect_async
if port <= 0:
^^^^^^^^^
TypeError: '<=' not supported between instances of 'str' and 'int'
Une idée du problème svp?
Bonne soirée à tous
Pour moi, c’est même pire, l’appel au service ne fonctionne plus 
J’ai implémenté & publié la solution.