Tu peux tout à faite mettre plusieurs trigger. Par contre c’est dommage de le faire 2 fois à 16s d’écart.
Assure toi que le mode de l’automatisation est bien « QUEUE »
La meilleure optimisation c’est de modifier le trigger HP/HC pour ne traiter que les cas de 22H (from on to off ou l’inverse) et de conserver le trigger de la couleur pour le calcul de 6H
Du coup, je déclenche quand le changement de couleur s’opère et à 22h et 10 secondes.
En théorie, le switch HC/HP qui lui a lieu l’heure exacte sera déjà activé le matin à 6h et à 22h00
Une autre technique, c’est de stocker la veille la couleur du jour à venir et de se baser sur le switch HC/HP.
J’irai sur cette voie si cette technique ne fonctionne pas.
alias: Borne > Sélection tarif applicable
description: >-
Le compteur de service public 'prix_des_charges_journalieres' a 6 tarifs
(Tempo)
On utilise l'interrupteur HC/HP géré par une autre automation.
On utilise l'heure (22h) et le changement d'état de "couleur du jour" pour modifier les tarifs
Quand celui-ci change d'état, on vérifie si on est passé en HC ou en HP. (1er
"Si")
En fonction du résultat, on va vérifier l'état de "couleur du jour" fourni par
Tempo (les 3 "Si" suivants).
On affecte à l'input tarif actuel la valeur correspondant aux inputs Tarifs
Tempo.
trigger:
- platform: state
entity_id:
- sensor.rte_tempo_couleur_actuelle
- platform: time
at: "22:00:10"
condition: []
action:
- if:
- condition: state
entity_id: input_boolean.status_hp_hc
state: "off"
then:
- if:
- condition: state
entity_id: sensor.rte_tempo_couleur_actuelle
state: Bleu
then:
- service: input_number.set_value
data_template:
entity_id: input_number.tarif_electricite_actuel
value: "{{ states('input_number.tarif_tempo_bleu_hp') }}"
- if:
- condition: state
entity_id: sensor.rte_tempo_couleur_actuelle
state: Blanc
then:
- service: input_number.set_value
data_template:
entity_id: input_number.tarif_electricite_actuel
value: "{{ states('input_number.tarif_tempo_blanc_hp') }}"
- if:
- condition: state
entity_id: sensor.rte_tempo_couleur_actuelle
state: Rouge
then:
- service: input_number.set_value
data_template:
entity_id: input_number.tarif_electricite_actuel
value: "{{ states('input_number.tarif_tempo_rouge_hp') }}"
else:
- if:
- condition: state
entity_id: sensor.rte_tempo_couleur_actuelle
state: Bleu
then:
- service: input_number.set_value
data_template:
entity_id: input_number.tarif_electricite_actuel
value: "{{ states('input_number.tarif_tempo_bleu_hc') }}"
- if:
- condition: state
entity_id: sensor.rte_tempo_couleur_actuelle
state: Blanc
then:
- service: input_number.set_value
data_template:
entity_id: input_number.tarif_electricite_actuel
value: "{{ states('input_number.tarif_tempo_blanc_hc') }}"
- if:
- condition: state
entity_id: sensor.rte_tempo_couleur_actuelle
state: Rouge
then:
- service: input_number.set_value
data_template:
entity_id: input_number.tarif_electricite_actuel
value: "{{ states('input_number.tarif_tempo_rouge_hc') }}"
mode: queued
max: 10
Oui mais c’est pas idéal.
Si par un malheureux hasard, ton HA ne fonctionne pas à 22H00 ET 10s, tu rates un tour.
Préfères ce genre trigger
trigger:
- platform: state
entity_id:
- input_boolean.status_hp_hc
from: "off"
to: "on"
Tu as raison, vu que mon automatisation sur le HC/HP est bien faite (elle se lance aussi au démarrage de HA et vérifier dans quelle amplitude horaire on est.
Donc le changement de on à off est bien plus pertinent pour le passage à 22h !
Mon truc commence donc par :
trigger:
- platform: state
entity_id:
- sensor.rte_tempo_couleur_actuelle
- platform: state
entity_id:
- input_boolean.status_hp_hc
to: "on"
(status_hp_hc est sur on quand on est en HC. Son nom littéral est « HC en cours ».)
Ce qui couvre tous les cas et évite les lancements successifs de l’automation.
Allez, une automatisation à économiser, et pas de prise de tête pour savoir quand on est dans la plage ou pas, y compris après un reboot
C’est génial, ca, comme intégration !!
Question subsidiaire : je crois que j’ai configuré mon utility meter avec un reset toutes les heures.
Ca a une importance ?
Je ne trouve pas comment modifier cette option…
Il y a des milliers de trucs qui existent déjà sous HA, ça vaut vraiment le coup de passer 5 minutes à chercher avant de réinventer la roue. Bon après ça permet de progresser
Carrement, si ta charge est plus longue que 1h, ça sera mal calculé !
Prends un truc trés long (année) pour être tranquille.
Le reset/cycle c’est toi qui le gère
En mode ui, destruction et recréation avec le même nom
Encore mieux tu as raison
Bon, j’ai mis une charge à 22h.
On verra ce que ca donne.
Pour le fun, j’ai ajouté une automation pour remplir mon agenda quand une charge se remplit.
Comme ca j’ai mon historique 
alias: Charge EV > Log les charges dans le calendrier
description: >-
utilise input_datetime.debut_de_la_charge quand la borne ne tire plius (- de
5W), la charge est réputée terminé. On remet à 0 le utilit meter. On inscrit
un événément dans le calendrier -recharge ev- avec heure de debut heure de fin
et conso. A AJOUTER : calcul du tarif de la charge (récupérer tarif en cours
et kw tirés chaque heure ? comment ?
trigger:
- platform: numeric_state
entity_id:
- sensor.borne_de_recharge_puissance
below: 5
condition: []
action:
- service: calendar.create_event
target:
entity_id: calendar.recharges_ev
data:
summary: Recharge
description: "{{ states('sensor.kwh_consommes_par_la_borne_ev') }} Watts consommés"
start_date_time: "{{ states('input_datetime.debut_de_la_charge') }}"
end_date_time: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
- service: utility_meter.calibrate
data:
value: "0"
target:
entity_id: sensor.kwh_consommes_par_la_borne_ev
mode: single
Bon, le truc dans l’agenda, c’est pas optimal
Sinon, j’arrive à récupérer à la grosse via la « consommation de gaz » le cout de mes charges de voiture, mais la granoliosité n’est pas bonne. C’est bon au mois, mais pas charge par charge, vu qu’elle coule sur 2 jours (de 22h à 6h le lendemain).
Cela dit, j’ai maintenant un truc pour obtenir le bon tarif au bon moment, et un capteur pour remonter le débit de la borne.
Il va falloir que je bidouille un truc pour stocker heure par heure la conso de la borne (1), puis faire un calcul en fonction du prix applicable à cette heure-là, stocker le résultat dans une variable (2) et faire un total lorsqu’on détecte la fin de la charge.
1 => a moins qu’on ne puisse utiliser un historique du compteur de la borne ? Jamais trop fouillé la dedans, mais on peut récupérer la conso des X dernières heures ?
2 => ca existe les variables ? On avait ca sous jeedom, c’était pas mal. Je veux stocker la conso dedans et l’effacer une fois mon calcul fait. Ca existe ?
Question con : pourquoi HA ne permet pas de faire ca nativement alors que c’est le cas dans le tableau énergie ??
En fait tout ce qui est à cheval entre jour/semaine/mois/année doit poser un souci
C’est vrai que coté dashboard énergie, tu ne peux pas fixer une fenêtre en fonction des heures.
Par contre, tu dois pouvoir faire un truc (ton idée 1)
Les variables ce sont les entités dans HA, mais il ne faut pas toujours appliquer les principes de jeedom là dessus (effacement etc)
C’est une bonne question. Le tableau énergie est assez récent comparé à HA et il y a pas mal d’évolution en ce moment. J’imagine que pour l’instant il n’y a pas assez de demande pour compléter les fonctions directement dans le core. As-tu regardé du coté du forum US pour voir si le sujet a été évoqué ?
Je dois être complètement débile, mais t’aurais pas un tuto quelque part ?
Je m’en sors pas 
Hello,
Tu as quoi comme valeur ‹ conso › ?
Une valeur instantanée ? Cumul ?
Parce que niveau syntaxe, ça rentre dans n’importe quel template
Salut et bonne année
Merci aussi pour ton aide depuis le début de ma galère.
La conso de la borne est remontée par un Shelly EM3 :
et je ne sais plus comment j’ai fait, mais j’ai un truc qui m’aggrège le tirage des 3 phases de la borne sur une seule entité :
Je n’ai plus aucune idée de comment j’ai créé ce truc
Limite, il serait peut être plus simple de repartir des data brutes du shelly, quitte à faire 3 fois le calcul ?
Salut et meilleurs voeux également
Regarde dans ton fichier sensor.yaml par exemple (ou configuration.yaml en fonction de l’organisation chez toi) … Tu dois bien retrouver le nom.
J’ai retrouvé un truc dans « package/borne_de_recharge.yaml » :
template:
- sensor:
- name: "Borne de recharge Energie totale"
unique_id: borne_recharge_total_energie
state: >-
{{
[ states('sensor.compteur_borne_de_recharge_phase_1_energy'),
states('sensor.compteur_borne_de_recharge_phase_2_energy'),
states('sensor.compteur_borne_de_recharge_phase_3_energy'),
] | map('float') | sum
}}
availability: >-
{{
[ states('sensor.compteur_borne_de_recharge_phase_1_energy'),
states('sensor.compteur_borne_de_recharge_phase_2_energy'),
states('sensor.compteur_borne_de_recharge_phase_3_energy'),
] | map('is_number') | min
}}
unit_of_measurement: kWh
device_class: energy
state_class: total_increasing
- name: "Borne de recharge Puissance totale"
unique_id: borne_recharge_total_puissance
state: >-
{{
[ states('sensor.compteur_borne_de_recharge_phase_1_puissance'),
states('sensor.compteur_borne_de_recharge_phase_2_puissance'),
states('sensor.compteur_borne_de_recharge_phase_3_puissance'),
] | map('float') | sum
}}
availability: >-
{{
[ states('sensor.compteur_borne_de_recharge_phase_1_puissance'),
states('sensor.compteur_borne_de_recharge_phase_2_puissance'),
states('sensor.compteur_borne_de_recharge_phase_3_puissance'),
] | map('is_number') | min
}}
unit_of_measurement: W
device_class: power
state_class: measurement
Et je n’ai absolument aucun souvenir d’avoir créé ce fichier 