Oui cela fonctionne - je comprends aussi que c’est un peu complexe.
J’ai commencé à développer cela comme add-on, mais il y a encore du travail.
Pour le moment j’ai « juste » un add-on qui installe les paquets et dans lequel j’ai un début de création du fichier de configuration json à partir de la configuration de l’add-on.
Ensuite il reset à comprendre comment l’addon pourra réagir sur un trigger, comment communiquer avec HA en évitant de spécifier l’url et le token… .
Enfin, en attendant, le plus simple c’est de passer par appdaemon ou en lancant « docker compose … ».
C’est malheureusement trop complexe pour mon niveau débutant .
Je vais attendre soit un tuto qui soit plus détaillé et surtout plus adapté a mon niveau, soit un add-on ( un peu comme le add-on linky)
Il faut un peu de patience après ajout car la construction du add-on se fait actuellement localement.
J’ai testé la récupération de données Veolia.
Il y a encore des choses à finaliser, dont notament la documentation, la publication en bonne et du forme, la trace d’exécution de meters_to_ha.pl, etc.
La configuration réussi ressemble à ceci en yaml (on peut l’éditer en mode « graphique »):
veolia_login: mon@email.com
veolia_contract: 45646
veolia_password: mot de passe
veolia_event: call_veolia
logs_folder: /config
keep_output: true
local_config: false
skip_download: false
insecure: true
download_folder: /config
DISPLAY: ":0"
debug: false
trace: false
screenshot: true
log_level: info
timeout: "30"
type: ha
Dans home-assistant il faut ensuite déclencher l’événement défini (ici: call_veolia).
Après la synchro, On peut à priori visualiser qqs de ces fichiers sous « /config » :
Avec la bonne configuration il télécharge les données de Veolia (et/ou GRDF), et ce sur événement généré depuis Home Assistant.
Les traces sont envoyés dans le répertoire de votre choix.
Pour déclencher un événement c’est comme pour tout événement et donc comme pour Appdaemon.
Voir l’exemple dans la documentation .
Ce qui manque c’est l’évolution de la documentation/La documentation spécifique de l’Add-on. Les paramètres de configuration sont toutes décrites en français dans la configuration du Add-on.
Le script de base meters_to_ha.pl n’a pas changé et la plupart des paramètres sont celles du fichier de configuration json et les paramères du script.
Sinon, l’installation peut prendre un peu de temps - la génération des images publiques pour le Add-on n’est pas encore fait, donc l’Add-on est créé en local.
En tous cas l’Add-on évitera la complexité de la configuration d’Appdaemon, et la création du fichier json au bon format.
je vais m’empresser de tester tout ca. Pour les datas en temps réel du gaz j’ai utilisé un bouton RF433, connecté à la prise TIC du gazera, qui a chaque tic simule l’action du bouton.
chaque action = 10litre de gaz.
Pour l’eau je n’ai pas trouvé de solution sur le compteur.
Bonjour a tous, de mon coté j’ai une erreur :
Error: failed to import python required module : No module named ‹ colorama ›, alors que celui ci est bien satifait, dans la file de discution une personne a rencontrée le meme problème et la résolut mais ne donne pas la solution si quelqu’ un sais je suis preneur merci
Est-ce bien la même installation python qui est appellé (c.a.d., l’installation qui a colorama installée).
Il faut savoir que le « conteneur ssh » s’apparente en pratique à une installation d’OS différente que le conteneur qui exécute Home Assistant en soi, ou encore le conteneur AppDaemon, etc. Donc si colorama est installé dans le « conteneur ssh » cela n’implique pas que c’est installé dans le conteneur « Appdaemon ».
« Un conteneur » est en quelque sorte une machine « à part » sur votre machine et s’apparente à une machine virtuelle. Chaque conteneur a ainsi ses programmes dont les versions et configurations des programmes peuvent être différentes de cells des autres conteneurs, et en tous cas « isolés ».
C’est vrai aussi pour l’installation en mode ‹ add-on › (module complémentaire) qui s’exécute aussi dans son conteneur. Mais dans ce cas, l’installation de colorama est forcé par le add-on et ne nécessite pas de configuration de l’utilisateur.
A condition de pouvoir exécuter l’installation python visé:
Il est possible de forcer l’utilisation d’une installation python ou une autre en appelant ‹ meters_to_ha.py › directement par l’installation python en question. Exemple: /chemin/vers/python3 ./apps/meters_to_ha/meters_to_ha.py -c ./config.json --run --veolia.
Il est possible de vérifier si colorma est installé avec /chemin/vers/python3 -m colorama, ce qui donne en cas d’installation : /chemin/vers/python3: No module named colorama.__main__; 'colorama' is a package and cannot be directly executed, au lieu de: /chemin/vers/python3: No module named colorama dans le cas contraire (l’erreur ci-dessus confirme la présence de colorama comme un module, mais l’absence de la fonction __main__ ce qui est attendu).
Merci pour ton explication LeTop, j’ai résolut cette partie, en effet c’est dans la conf de Appdeamon qu’il manquait les libs. j’ai maintenant un autre pb, voir ci dessous
je c’est une installation via les modules dans HA, quand je lance le call_véolia j’ai cette erreur
Ma conf apps
veolia_idf:
module: meters_to_ha_appdaemon
class: MetersToHA
# optionnel - Par défaut "call_meters_to_ha".
# Permet de définir plusieurs lancements distincts, par exemple
# pour consulter Veolia à une certaine heure, et GRDF à une autre heure.
event_name: call_veolia
# optionnel - Par exemple --grdf pour ne faire que la requête auprès de GRDF
# --veolia pour ne faire la requête qu'auprès de Veolia
# --insecure pour accepter les certificats SSL non vérifiés
# (par exemple autosigné).
extra_opts: [--veolia]
# optionnel
log_folder: /config
# optionnel (Par défaut: "config.json" dans le répertoire de `meters_to_ha.py`)
config_file: /config/meters_to_ha.json
#config_file: /config/appdaemon/apps/veolia-idf/config.json
#config_file: /config/veolia-idf/config.json
# optionnel (Par défaut: "<REALMODULESCRIPTPATH>/meters_to_ha.py")
#script: /config/appdaemon/apps/veolia-idf/veolia-idf-domoticz.py
#script: /config/meters_to_ha/meters_to_ha.py
#script: /config/meters_to_ha/meters_to_ha.py
script: /config/appdaemon/apps/MetersToHA/meters_to_ha.py
# optionnel (Par défaut: false) - add --keep-output option
# conserver les csv
keep_csv: true
keep_output: false
# optionnel (Par défaut: false) - add --debug option - nécessite DISPLAY & serveur X!!
debug: True
# optionnel (Par défaut: None) - Set DISPLAY for GUI interface (when debug is true)
#DISPLAY: 192.1.0.52:0
#DISPLAY: 192.168.0.25:0
# optionnel (Par défaut: None) - Fichier pour la sortie STDOUT du script
outfile: /config/appdaemon/apps/meters_to_ha_script.log
# optionnel (Par défaut: None) - Fichier pour la sortie STDERR du script
errfile: /config/appdaemon/apps/meters_to_ha_err.log
Très étrange car cela ne devrait pas arriver - le code en protège. Je me demande s’il n’y a pas qqchse de supprimé/commenté. Sinon, il y a peut-être une évolution de python, mais je penses que mon Appdaemon est à jour.
Il y a une ligne qui comporte « Found chromium binary » - c’est suivi par " with undetected driver" ?
J’ai apporté ces évolutions:
Affichage de la version python utilisée:
J’ai: « /usr/bin/python3 Version 3.11.5 » (dans appdaemon)
Un contrôle supplémentaire par rapport à « undetected_chromedriver ».
Il convient donc de mettre à jour MetersToHa pour Appdaemon (via HACS).
C’est la bonne version s’il y a ce code à partir de la ligne 168:
try:
# Double check and logging because 'not defined' uc
# was observed despite this protected import.
import undetected_chromedriver as uc
LOGGER.debug("Undetected ChromeDriver import ok")
_uc_options_test = uc.ChromeOptions()
LOGGER.debug("Undetected ChromeDriver Options ok")
hasUndetectedDriver = True
except ImportError:
pass
Vous savez s’il est possible de faire un rattrapage des datas en cas de perte de donnée? surtout qu’elles sont disponible dans le fichier csv.
De façon plus large comment faire une injection des datas récupérées depuis le site vers homeassistant
Je n’ai pas encore essayé ce projet - je le surveille.
Je n’ai pas trop le temps pour le tester en ce moment.
Sinon l’autre méthode c’est de mettre à jour la base de données directement.
Voici un script avec lequel j’avais corrigé des erreurs dans la BDD suite à mon développement sous MetersToHA.
Je partage ce script comme éventuelle inspiration. Mais il faut comprendre comment cette table fonctionne!
#!/bin/bash
# 50, 51, 55
# Do update of gas_consumption_kwh
# metadata_id can be found in metadata table
#CREATE TABLE statistics_meta (
# id INTEGER NOT NULL,
# statistic_id VARCHAR(255),
# source VARCHAR(32),
# unit_of_measurement VARCHAR(255),
# has_mean BOOLEAN,
# has_sum BOOLEAN,
# name VARCHAR(255),
# PRIMARY KEY (id)
#)
#mean,min,max,sum
#10727509|2023-01-24 20:30:11.186135|2023-01-24 20:25:00.000000|28657.0|28657.0|28657.0||||50
#28657.0|28657.0|28657.0
#select * from statistics_meta where id=50 limit 1;
SENSOR="sensor.gas_consumption_kwh"
ID=$(sqlite3 home-assistant_v2.db <<EOSQL
select id from statistics_meta where statistic_id="$SENSOR";
EOSQL
)
echo $ID
if [ "$ID" == "" ] ; then
echo "Could not find ID for $SENSOR"
fi
#972726|2023-02-09 01:00:10.924994|50|2023-02-09 00:00:00.000000|||||31783.0|36878.0
#11306625|2023-02-08 09:43:12.253890|2023-02-08 09:30:00.000000|||||31106.0|36201.0|50
#11333082|2023-02-09 01:20:10.813158|2023-02-09 01:15:00.000000|||||31783.0|36878.0|50
#12409700|||||||35059.0|40154.0|50|1678206912.48971|1678206600.0|
SHORT_TERM_IDX=12409982
LONG_IDX=1062482
#ID=50
STATE=35059
SUM=40154
ECHO=echo
#ECHO=
#set mean=null,min=null,max=null,state=28657,sum=33752
$ECHO sqlite3 home-assistant_v2.db <<EOSQL
update "statistics_short_term"
set mean=null,min=null,max=null,state=$STATE,sum=$SUM
where metadata_id in ($ID)
AND id>=$SHORT_TERM_IDX
;
EOSQL
#AND state=$STATE
#11250958|2023-02-06 23:25:14.204596|2023-02-06 23:20:00.000000|||||30994.0|36089.0|50
#id|created|start|mean|min|max|last_reset|state|sum|metadata_id
#10694884|2023-01-24 00:50:17.716574|2023-01-24 00:45:00.000000|28657.0|28657.0|28657.0||||50
#10694745|2023-01-24 00:45:31.049645|2023-01-24 00:40:00.000000|||||28657.0|33752.0|50
#10726675|2023-01-24 20:00:11.205636|2023-01-24 19:55:00.000000|||||28657.0|33752.0|50
#922191|2023-01-24 20:00:11.472642|50|2023-01-24 19:00:00.000000|||||28657.0|33752.0
sqlite3 home-assistant_v2.db <<EOSQL
.headers on
SELECT *
FROM "statistics_short_term"
where metadata_id in ($ID)
AND id>=$SHORT_TERM_IDX-500
order by id desc;
EOSQL
#970490|2023-02-08 09:00:10.979432|50|2023-02-08 08:00:00.000000|||||31106.0|36201.0
#965860|2023-02-06 23:00:13.290641|50|2023-02-06 22:00:00.000000|||||30994.0|36089.0
#set mean=null,min=null,max=null,state=28657,sum=33752
$ECHO sqlite3 home-assistant_v2.db <<EOSQL
update "statistics"
set mean=null,min=null,max=null,state=$STATE,sum=$SUM
where metadata_id in ($ID)
AND id>=$LONG_IDX
;
EOSQL
#AND state=$STATE
sqlite3 home-assistant_v2.db <<EOSQL
.headers on
SELECT *
FROM "statistics"
where metadata_id in ($ID)
AND id>=$LONG_IDX-5000
order by id desc;
EOSQL
Merci je vais regarder cela. Je suis sous MariaDB et il y a bien une fonction import CSV. cependant comme tu le dis il faut vérifier le fonctionnement de la table statistics et potentiellement des dépendances qu’il peut y avoir avec les autres tables.
La seule dépendence c’est d’utiliser le bon id - que l’on trouve dans statistics_meta (voir requête dans l’exemple).
Sinon, le tout c’est de bien construire date, le min/max (à priori null), la valeur de la periode et l’accumulation. On peut prendre comme exemple l’historique récente.
C’est scriptable et pourrait être indépendant du type de base de données et généralisé si on le fait sous Python (avec SQLAlchemy je crois).
.
si quelqu’ un sais je suis preneur 