En quoi ça ne fonctionne pas bien ? C’est la méthode la plus officielle.
Alors, je ne suis pas sur que le principe soit bien meilleur, surtout avec des fonctions qui n’existent pas.
Ce que tu peux faire c’est :
Déclencher ton action à 23H59 ou 0H00 (et pas 23H59 et 59s) : HA fait son calcul à la minute (en réalité qq secondes après la minute).
Prendre la valeur (fonction states()) au moment de l’exécution de l’automatisation. La différence entre la valeur à heure fixe ou la valeur à heure fixe + 59s est négligeable. C’est en plus probablement pas une valeur instantanée
Voici le post que j’ai fait ou j’explique ce qui ne fonctionne pas :
Concernant la valeur dans le passé, plutot que de compter toute la journée des valeurs qui s’incrémentent, je me dis que c’est plus simple de simplement calculer le delta entre la valeur absolue actuelle et la valeur absolue d’hier à la meme heure. cela fait moins de calculs que de faire le compte a chaque evennement. Du coup je ne vois pas comment faire
Perso je ne vois pas vraiment en quoi la valeur est aberrante : je vois une reset tous les jours et une valeur croissante sur la journée. C’est à mon avis plus un problème de conversion W /kW voire de kVA
Donc le principe est le même à 23H59 tu fais le calcul entre ta valeur actuelle et ton entité. Et tu remets ça dans ton entité.
Le fait de le faire à 23H59 permet de t’assurer que l’entité porte bien la date d’hier dès 0h00
Merci je viens de comprendre pour mon entité a 23h59!
Pour le compteur avec les valeurs aberrantes ca semble fonctionner et effectivement j’ai bien un reset tous les jours mais je ne comprends pas pourquoi certains jours ca me donne des valeurs correctes autour de 20kwh et des jours ca va donner des valeurs de l’ordre de 20 000 kwh je ne comprends pas pourquoi. Et mes donnees viennent du TIC donc avec un checksum donc normalement pas possible d’avoir des mauvaises donnees. Il se comporte comme si au lieu de faire valeur actuelle - valeur d’avant il faisait valeur actuelle - 0 et mes donnees montent d’un coup.
Je maintiens mon idée, tu as facteur 1000 (très, trop proche de la différence entre KW et W pour être une coïncidence ) Et comme tu as à priori l’option tempo, je parie qu’un des jours est mal calculé ou a la mauvaise unité.
Donc d’un coté tu fais 20000W que tu convertis en 20kW. Et l’autre jour tu n’a pas la conversion et tu mets 20000W directement en 20000kW
Non je suis encore en hc hp ( je vais bientot prendre tempo) du coup toutes mes heures creuses sont calculees de la meme facon et des jours ca marche et d’autres pas du tout comme je l’ai montre sur la capture d’avant. Et j’ai exactement le meme pb avec les heures pleines
On peut exclure une erreur sur le linky au début.
Et un utility meter c’est juste un compteur (ça ne manipule pas l’entité), en fin de traitement.
Donc si tu as des valeurs bizarres, c’est forcement à cause d’un truc entre les 2
Bonjour,
quand ta de mauvaise donnée, tu n’aurais pas redémarrer HA avant ?
Si c’est bien le cas, faut ajouter l’option availability: dans ton template sensor, pour eviter de mauvais calcul au rédémarrage de HA et ou les entités sont encore indisponible le temps du chargement.
- name: box_metering_PC_PB_PE_sum
unit_of_measurement: "Wh"
device_class: energy
state_class: total_increasing
state: >-
{% set PC = states('sensor.0x54ef4410004ea988_energy')|float(default=0)*1000 %}
{% set PB = states('sensor.0x54ef4410005647e8_energy')|float(default=0)*1000 %}
{% set PE = states('sensor.0xa4c138b1bfb7f7ef_energy')|float(default=0)*1000 %}
{{ PC + PB + PE | int(default=0) |round(0) }}
availability: "{{ states('sensor.0x54ef4410004ea988_energy')|is_number and states('sensor.0x54ef4410005647e8_energy')|is_number and states('sensor.0xa4c138b1bfb7f7ef_energy')|is_number }}"
- name: Bluetooth Proxy 854638 Uptime Readable
state: >-
{% set uptime = states.sensor.bluetooth_proxy_854638_ble_proxy_uptime.state | int(0) %}
{% set jours = (uptime / 86400) | int(0) %}
{%- if jours > 0 -%}
{{ jours }} jours, {{ (uptime - (jours * 86400)) | int(0) | timestamp_custom('%H:%M:%S', false) }}
{%- else -%}
{{ uptime | int(0) | timestamp_custom('%H:%M:%S', false) }}
{%- endif -%}
unique_id: bluetooth_proxy_854638_uptime_readable
availability: "{{ states('sensor.bluetooth_proxy_854638_ble_proxy_uptime') not in ['unknown', 'unavailable', 'none'] }}"
alors non je n’ai pas redémarré HA juste avant mais je ne connaissais pas cette balise.
J’aurai bien voulu l’utiliser dans mon compteur mais je ne pense pas que cette balise soit disponible dans un compteur de services publique
Je suis tout à fait d’accord et le truc le plus étrange c’est que cela se produit pas systématiquement ! Par exemple aujourd’hui cela a fonctionné nickel !
Je n’ai pas de piste mais tu peux essayer de faire la liste des entités qui servent à la composition (perso ça semble bien nébuleux avec des trucs prêts mais pas encore actifs) de tes sensors et voir comparer les valeurs dans un même graph.
Tu dois être en mesure de savoir lequel déconne en 1er
EDIT: Vu, tu viens de faire l’exercice.
A mon avis, il faut plutot se pencher sur le cas de l’esp … Il n’a pas à renvoyer 0, c’est un souci de code à mon avis
