Avoir les données "historiques" en attribut de l'un des sensors

[r-jean-pierre]

Liste de contrôle

• Cette demande ne contient qu'une seule demande de fonctionnalité (si vous avez plusieurs demandes, ouvrez une demande pour chaque fonctionnalité).
• Cette demande n'est pas un doublon de demandes précédentes.

Votre demande de fonctionnalité est-elle liée à un problème ? Veuillez décrire.

Hello! Merci d'avoir fait revivre l'intégration véolia pour ceux qui ont du basculer sur la nouvelle adresse il y a maintenant un bon bout de temps.
Je me demandais s'il était possible de récupérer par l'un des sensors (au hasard veolia_consumption_index) l'historique le plus long coté Véolia qu'il est possible d'avoir au niveau du jour et au niveau du mois
En effet c'est typiquement un capteur qui lorsqu'il envoie une donnée a temps T, c'est en fait une télé-relève de plusieurs heures pour pas dire plusieurs jours dans le passé, avec un tempo qui n'est même pas régulier (donc impossible de recaler les consommations sur les bons jours avec un delta_time)

Décrivez la solution que vous souhaitez

Un peu comme les autres intégration véolia ou bien alors par exemple linky, perdu pour perdu, c'est tout de même pratique d'avoir un attribut qui donne les dates, et un autre les consommations en forme de liste:

Au moins pour le passé, les consommations coincides avec les dates, et parfois même les trous de données sont un jour ou l'autre corrigés du coté fournisseur, alors que garder soi-même l'historique du capteur temps réel est quasiment inutile (ou moins pire agrégé au niveau du mois on devrait être proche de la réalité, et encore...)
Ca permet au moins de refaire les beaux graphiques comme ceux du site véolia

Contexte supplémentaire

J'aurais bien voulu montrer ce que j'vais fait à l'époque pour véolia, mais il est mort depuis 1 an. J'ai un bout de code commenté dans mon lovelace qui était:

- type: custom:plotly-graph
    entities:
    - entity: sensor.veolia_daily_consumption
      filters:
        - fn: |-
            ({ meta }) => ({
              xs: meta.historyConsumption.map(([date, value]) => new Date(date)-3600*1000),
              ys: meta.historyConsumption.map(([date, value]) => value)
            })

Tout porte à croire qu’il y avait un attribut historyConsumption qui devait stocker des couples (date, conso) , et vu le titre de mon graphe certainement sur 3 mois (donc une quasi centaine de couples (date, conso))
Je pense que le même attribut historyConsumption était dans veolia_monthly_consumption, ce qui permettait d'avoir 12 couples (nom du mois, conso du mois)

[Jezza34000]

Bonjour,
Je vais regarder ça dans la journée dès que j'ai un peu de temps :-)

[Jezza34000]

Hello alors effectivement apres investigation il semble que ca soit un point problématique dans HomeAssistant, il n'est pas concu pour travailler avec des données dans le passé.
La bonne solution consiste à attendre que les jours passent et l'historique va se créer.
La solution cité ci dessus provient d'un moyen de contournement qui consiste à copier de manière brut en attribut toutes les données et les lires avec une carte qui génère des graphique, mais cette solution n'est pas hyper propre d'un point de vue technique.
Les autres solution qui consiste à insérer "à postériori"les données dans la base (donc l'historique) semble aussi très complexe à mettre en oeuvre.
Je vais voir ce qui est faisaible au mieux et propre

[MB901]

Bonjour,
https://github.com/vingerha/gazpar_2_mqtt
Peut-être que ça pourrait donner des pistes ? C'est sous forme de addons, mais pour la question de mettre l'historique dans la base de donnée ça peut aider peut-être.
En tout cas merci pour le job !

[r-jean-pierre]

Hello alors effectivement apres investigation il semble que ca soit un point problématique dans HomeAssistant, il n'est pas concu pour travailler avec des données dans le passé. La bonne solution consiste à attendre que les jours passent et l'historique va se créer. La solution cité ci dessus provient d'un moyen de contournement qui consiste à copier de manière brut en attribut toutes les données et les lires avec une carte qui génère des graphique, mais cette solution n'est pas hyper propre d'un point de vue technique. Les autres solution qui consiste à insérer "à postériori"les données dans la base (donc l'historique) semble aussi très complexe à mettre en oeuvre. Je vais voir ce qui est faisaible au mieux et propre

Ouais je sais mais je vois bien que les créateurs de sensors par dépit font ça, et j'avais même échangé avec le créateur de graph-plotly, on tourne en rond. Je sais pas si c'est franco-francais, mais véolia et enedis, franchement.... entre extraire les données de leurs sites/api et ensuite recaler tout ça....

[r-jean-pierre]

Bonjour, https://github.com/vingerha/gazpar_2_mqtt Peut-être que ça pourrait donner des pistes ? C'est sous forme de addons, mais pour la question de mettre l'historique dans la base de donnée ça peut aider peut-être. En tout cas merci pour le job !

Alors à première vue, c'est identique à "Enedis Gateway API to send data in your MQTT Broker" que j'utilise pour enedis , mais ca résous pas le problème

Là il est 22:25, le sensor dit 22.93kw, mais en fait c'est la valeur totale de hier de 00:00 à 23:59
C'est d'ailleurs pour ça que dans les attributs à Day1, qui est aujourd’hui y'a 0, demain, dans day 2, j'ai la valeur qu'on voit à 22.93 (si elle n'est pas recorrigée, parfois ça arrive), mais la nouvelle valeur du sensor qui arrivera à 2h00 du matin ou 15:35 (on sait jamais quand elle tombe) sera pas la bonne (ni en valeur ni encore moins en temps dans la base HA)
On s'en sortira jamais
Et c'est hors les trous de données sur plusieurs jours
Et pour se reconcentrer sur véolia, au moins ces derniers temps le décalage enedis est environ de 3h avec une certaine régularité (mais ça n'a pas tj été le cas), mais de mes souvenirs chez véolia, c'était entre 12h et 3j....
Pour enfoncer le clou: deux valeurs qui se suivent dans la BD au timestamp 2024/11/22T22:30 et 2024/11/22T23:00 sont peut être en fait dans la réalité vraie la conso du 2024/11/18 et 2024/11/21. Avec toutes les joies que ca apporte par exemple sur une agrégation à la journée où on se trouve avec la somme de deux valeurs en litres....

C'est vraiment dommage car les développeurs d'addons font vraiment un travail de fou, le problème est d'un coté HA, et de l'autre les boites privées qui sont pas 100% enjouées de donner gratos leurs api/iots, etc. et veulent qu'on passe par leurs appli bourrées de pub

[Jezza34000]

C'est bon j'ai trouvé comment insérer de l'historique en natif dans HomeAssistant.
Je finalise mon code je vérifie que tout soit ok et je publie

[r-jean-pierre]

C'est bon j'ai trouvé comment insérer de l'historique en natif dans HomeAssistant. Je finalise mon code je vérifie que tout soit ok et je publie

Merci! Incroyable ce que tu fais pour la communauté!

[Jezza34000]

Hello c'est mis à jour

https://github.com/Jezza34000/home-assistant-veolia/releases/tag/v1.4.4

J'ai ajouté tous les détails de comment fonctionne l'historique sur le README

[r-jean-pierre]

Cool! Ca semble fonctionner avec le le dashboard par défaut et le composant graph stats, j'ai exactement les mêmes chiffres que sur le site véolia.

J'ai p'être une question: le sensor "sensor.veolia_conso_journaliere" n'apparait pas comme tous les autres, j'ai tenté de l'utiliser avec custom:apexcharts-card et custom:plotly-graph, le premier dit qu'il le trouve pas, le second fait un graph vide

Y'a une astuce avec ce type de capteur? (j’avoue c'est la première fois que je vois ça)

[Jezza34000]

Hello, je n'utilise pas ces cartes donc je ne sais pas vous répondre sur ce sujet.

[r-jean-pierre]

Bon je sais pas trop ce que j'ai fait (normalement rien) mais le sensor.veolia_consommation_journaliere a disparu. (en fait il s'appelait sensor.veolia_conso_journaliere hier quand je l'avais trouvé).
C'est p'etre suite à l'udpate et reboot (core_2024.11.2)

J' ai tenté de comprendre le code etc. mais ça va au delà de mes compétences
J'ai uniquement peut être vu qqc:

custom_components/veolia/manifest.json,
ligne 12,
version -> 1.4.4 (non?)

[Jezza34000]

Oui c'est du au renommage de l'entité
Le terme "Consommation" était trop long pour un affichage complet, j'ai réduit a "Conso" dans la nouvelle version.

[r-jean-pierre]

En fait les deux étaient "perdus", j'ai relancé ma machine et au retour de HA, j'ai au moins de nouveau sensor.veolia_conso_journaliere, c'est déjà ça de pris!

[r-jean-pierre]

Du coup j'ai 3 questions qui trainent:

• la première est: ta technique d'avoir ce fameux capteur qui écrit dans le recorder de homeassistant permettra de "conserver" l'historique? si je comprend le truc, au 1décembre, comme les données par exemple journalières de novembre n’auraient pas du apparaitre dans un sensor mal programmé, dans ta version, certes décembre va couler dans le sensor, mais on gardera tout ce qu'il a vu jusqu'alors?
• si la réponse est oui à celle d'avant, on peut alors imaginer la même chose sur les mois? vu que veolia donne à partir de janvier du mois en cours, y'aurait du coup aucun calcul à faire et le volume de données serait très faible à conserver dans la BD, y'a plus qu'à tracer des barcharts sur 10 ans avec la possibilité d'une granularité au jour et au mois, c'est double victoire, non? (-> contrairement aux sensors qui stockent toutes les secondes une valeur qui change finalement au max 1 fois par jour)
• dernière question: aurais-tu prévu de remonter encore plus d'info? j'imagine l'api donne des données clients, voire des stats (je fais un // avec les api enedis qui comparent jour à jour, mois à mois de l'année d'avant, etc.). Je sais que tout se recalcul, et que souvent l'intéret est limité, mais si déjà offert par le fournisseur...

Pour info: je pense récréer qqc inspiré de ceci avec enedis:

Mais pour véolia, grace à ton intégration magique :)

[Jezza34000]

Hello,

• Oui, l'historique "classique" tel qu'il fonctionne sous Home Assitant ne change en rien
• Oui il est possible de récupérer à postériori la conso des mois/années passées, mais l'intégration ne le fais pas actuellement
• L'API de Véolia fournit effectivement une grande quantité d'informations. Cependant, les données de comparaison ne sont pas directement fournies par l'API. À l'image de ce que font Enedis ou Véolia, ces comparaisons sont calculées directement sur le navigateur. De ce fait, l'intégration Home Assistant n'a pas vocation à effectuer ces calculs. Son rôle est de transmettre les données brutes, tandis que les statistiques doivent être générées à l'aide d'automations et/ou de cartes personnalisées.

[r-jean-pierre]

Merci pour les précisions!

[r-jean-pierre]

Je crois que j'ai remarqué qqc, je fais un autre ticket pour pas polluer celui ci