Alternative fiable pour récupérer les tarifs EDF Tempo

Bonjour,

J’utilise l’intégration « Tarifs EDF » pour récupérer les tarifs de mon abonnement Tempo, mais je rencontre des blocages fréquents.

Pour rétablir le service, je dois systématiquement redémarrer l’intégration ou Home Assistant afin que les données s’actualisent. Je ne peux pas préciser la fréquence exacte de ces plantages, car je ne m’en aperçois que lors des changements de tarifs. En consultant le GitHub du projet (GitHub · Where software is built), j’ai remarqué que les erreurs de tarifs et les instabilités sont malheureusement courantes.

Quelle méthode utilisez-vous de votre côté pour récupérer les tarifs EDF de manière fiable ?

Merci d’avance pour votre aide.

Ma configuration


Version core-2026.2.2
Type d’installation Home Assistant Container
Développement false
Supervisor false
Docker true
Architecture des conteneurs amd64
Utilisateur root
Environnement virtuel false
Version de Python 3.13.11
Famille du système d’exploitation Linux
Version du système d’exploitation 6.6.x
Architecture du processeur x86_64
Fuseau horaire Europe/Paris
Répertoire de configuration /config

Home Assistant Community Store

GitHub API ok
GitHub Content unreachable
GitHub Web ok
HACS Data ok
GitHub API Calls Remaining 4988
Installed Version 2.0.5
Stage running
Available Repositories 2839
Downloaded Repositories 25

Home Assistant Cloud

Connecté false
Accéder au serveur de certificats ok
Accéder au serveur d’authentification ok
Accéder à Home Assistant Cloud ok

Daikin Onecta

API server ok
OAuth2 server ok
Maximum minute 20
Maximum day 200
Remaining minute 19
Remaining day 169
Retry after 0
Rate limit reset 33
OAuth2 token valid true

Dashboards

Tableaux de bord 10
Ressources 15
Vues 13
Mode storage

Network Configuration

Adaptateurs lo (disabled), eth0 (enabled, default, auto), eth1 (disabled), wg0 (disabled), br-f4e7933d812c (disabled), br-5d09e1c1731d (disabled), br-8eda695a697e (disabled), docker0 (disabled), br-a25f294e3f11 (disabled), br-a73fa9b5e8ef (disabled), br-da74aeaf944e (disabled), tailscale0 (disabled)
Adresses IPv4 lo (127.0.0.1/8), eth0 (192.168.0.70/24), eth1 (192.168.0.71/24), wg0 (10.0.4.1/24), br-f4e7933d812c (172.18.0.1/16), br-5d09e1c1731d (172.21.0.1/16), br-8eda695a697e (172.23.0.1/16), docker0 (172.17.0.1/16), br-a25f294e3f11 (172.22.0.1/16), br-a73fa9b5e8ef (172.19.0.1/16), br-da74aeaf944e (172.20.0.1/16), tailscale0 (100.117.9.116/32)
Adresses IPv6 lo (), eth0 (), eth1 (), wg0 (), br-f4e7933d812c (), br-5d09e1c1731d (), br-8eda695a697e (), docker0 (), br-a25f294e3f11 (), br-a73fa9b5e8ef (), br-da74aeaf944e (), tailscale0 ()
Adresses annoncées 192.168.0.70

Recorder

Heure de démarrage de l’exécution la plus ancienne 28 février 2026 à 18:17
Heure de démarrage de l’exécution actuelle 13 mars 2026 à 08:42
Taille estimée de la base de données (en Mio) 861.13 MiB
Moteur de la base de données sqlite
Version de la base de données 3.49.2

Moi je les mets en fixe et je change quand ça change (environ une fois par an…)
Et au pire si j’oublie c’est pas bien grave, ça ne sera pas trop faux et pas trop longtemps…

J’ai peur que quelque soit la methode cloud, il risque d’y avoir soit des indisponibilité, soit des changements dans la maniere dont Edf organise les data et donc des indispo…

Bref, la méthode à l’ancienne est pas immédiate, mais au moins c’est toujours dispo.

Avantages:

  • données fiables et dispo 100% du temps
  • mise à jour manuelle => prise de conscience des augmentations et des changement de stratégie à apporter si nécessaire

Inconvénients :

  • si oubli, c’est pas à jour => la conso en KWh est juste, mais le cout en € est celui de l’ancien tarif, donc faux à quelques % près jusqu’à la mise à jour manuelle
  • faut le faire a la main, ça prend 5min…
  • faut y penser, être informé de l’augmentation… merci le forum, en général c’est ça mon trigger!
1 « J'aime »

Bonjour,
Tu as ce tuto, en utilisant le PDF de chez EDF pour les tarifs :

ou par Kelwatt :

2 « J'aime »

Merci pour vos suggestions. Celle de BBE semble effectivement la plus simple.

Cependant, l’intégration « Tarif EDF » présentait l’avantage de fournir nativement le tarif en temps réel. L’entité sensor.tarif_actuel_tempo_9kva_ttc s’actualise automatiquement selon les heures et les jours pour suivre l’évolution de la tarification.

Même si l’on récupère les tarifs à jour, il reste à concevoir une automatisation pour extraire la bonne valeur au bon moment. Quitte à devoir passer par un script, je me demande s’il ne serait pas plus simple d’en créer un qui redémarre l’intégration « Tarif EDF » toutes les 24 heures.

En gros les tarifs changent deux fois par an, en février et en août en général (du moins ces dernières années).
Donc pourquoi vérifier les tarifs toutes les 24 h ?
Les tutos que je t’ai fournis, actualise les tarifs les 5 premiers jours de février et aout, avec une automatisation.

2 « J'aime »

Bonjour
Sachant que les tarifs changent une fois par an, je le fais manuellement, cela me prend 10 minutes et au moins c’est sûr et si fiable

J’ai conçu un petit module LCD qui affiche ma consommation solaire ainsi que ma consommation EDF. Il calcule en temps réel le coût du kilowattheure (kWh) en fonction de la production solaire et du tarif en vigueur à l’instant T. C’est précisément pour cette raison que j’ai besoin d’un tarif actuel fiable qui s’actualise au fil de la journée et reste parfaitement à jour.

Bonjour,

C’est sûr, et fiable, mais nécessite une action humaine.
Si j’ai créé ces tutos, c’est justement parce que je veux que ce soit sûr, fiable ET automatique.
Après, à chacun de faire comme bon lui semble. :wink:

Bonjour,

Il te suffit de créer un sensor template qui appelle tel ou tel tarif en fonction de l’heure et de la couleur, en cours.

Pour la couleur, tu peux la récupérer avec l’intégration RTE TEMPO, ou sinon en utilisant Scrape pour aller chercher l’info sur le site d’EDF là encore : Connaître les Prochains Jours Tempo - EDF Particulier

1 « J'aime »

Un simple template permet de récupérer le tarif courant ?
J’ai déjà RTE tempo

un template, une automatisation, suivant ce avec quoi tu es le plus à l’aise…

  • Tu connais le tarif de chaque couleur (quelle que soit la façon dont tu l’as récupéré, en manuel ou en automatique).

  • Tu sais la couleur du jour

  • Tu sais si tu es en HP ou HC

=> tu sais choisir quel est le tarif actuel

C’est du if then else assez classique…

2 « J'aime »

Bien sûr, c’est à toi de le créer pour lui indiquer ce que tu veux.
Par exemple :

  • Si heure entre 6h et 22h et si couleur = rouge/blanc/bleu, alors utiliser le tarif correspondant récupéré par PDF Scrape
  • Si heure entre 22h et 6h et si couleur = rouge/blanc/bleu, alors utiliser le tarif correspondant récupéré par PDF Scrape

Tu peux te baser sur ce code, à adapter :

{% set couleur = states('sensor.rte_tempo_couleur_actuelle') | lower %}
  {% set heures_creuses = is_state('binary_sensor.rte_tempo_heures_creuses', 'off') %}

  {% set prix_pleine = states('input_number.heure_' ~ couleur ~ '_pleine_kwh') %}
  {% set prix_creuse = states('input_number.heure_' ~ couleur ~ '_creuse_kwh') %}

  {% if couleur in ['rouge', 'bleu', 'blanc'] %}
    {% if heures_creuses %}
      {% if prix_pleine in ['unknown', 'unavailable', None, ''] %}
        0.0
      {% else %}
        {{ prix_pleine | float(0) }}
      {% endif %}
    {% else %}
      {% if prix_creuse in ['unknown', 'unavailable', None, ''] %}
        0.0
      {% else %}
        {{ prix_creuse | float(0) }}
      {% endif %}
    {% endif %}
  {% else %}
    0.0
  {% endif %}

Il se base sur des capteurs qui ont comme noms :

  • input_number.heure_’ ~ couleur ~ '_pleine_kwh
  • input_number.heure_’ ~ couleur ~ '_creuse_kwh

Donc soit tu appelles tes capteurs créés avec l’un des deux tutos donné plus tôt de la même manière, soit tu modifies ce code pour utiliser les capteurs que t’as créé.

1 « J'aime »

Je pense que je vais me diriger vers cela.
Je vais faire aider par mon Gemini :wink:
Il m’a déjà pondu ce script : Il me semble juste qu’il n’ait pas à jour au niveau des prix :upside_down_face:

template:
  - sensor:
      - name: "Prix Electricité Actuel"
        unit_of_measurement: "€/kWh"
        state: >
          {% set couleur = states('sensor.rte_tempo_couleur_actuelle') %}
          {% set heure = now().hour %}
          {% set is_hc = heure < 6 or heure >= 22 %}
          
          {% if couleur == 'Bleu' %}
            {{ 0.1296 if is_hc else 0.1609 }}
          {% elif couleur == 'Blanc' %}
            {{ 0.1486 if is_hc else 0.1894 }}
          {% elif couleur == 'Rouge' %}
            {{ 0.1568 if is_hc else 0.7562 }}
          {% else %}
            0.1609
          {% endif %}
1 « J'aime »

Oui, voilà, c’est un bon début.
Après, faudra bien penser à venir changer les valeurs à chaque fois que les prix changeront.
C’est la contrainte de mettre les prix en dur au lieu d’aller les récupérer sur le net. :wink:

1 « J'aime »

Pour ça il suffit d’utiliser un helper/entrée plutôt qu’une valeur en dur.

Ainsi quand tu changes le helper, ça change partout où tu l’utilises…
Dans le panel Energie / dans ton calcul du cout courant, et n’importe où ailleurs…

Effectivement, toujours avoir un seul endroit à modifier, c’est la base pour pas oublier de la faire à un endroit.

Après, le « problème » reste toutefois le même : devoir le faire au moins une fois manuellement.

100% d’accord.

Alimenter un helper permet d’avoir un truc fiable qui reste disponible.

Après le faire en automatique ou manuel, il y a des avantages et des inconvénients dans les deux cas…

La mise à jour auto c’est un plus. Mais je ne suis pas 100% sûr de la pérennité d’un scrape. C’est tellement dépendant de la manière dont l’info est présentée sur le site sur lequel on va la chercher…

C’est le genre de truc qui va marcher 3 ans Nickel, juste le temps qu’on l’oublie puis tomber et on n’y fera pas attention avant de se rendre compte que les tarifs n’ont pas été mis à jour depuis 6 mois parce que le site a changé sa présentation.

Et s’il faut se mettre un reminder pour vérifier que Scrape a marché… autant se le faire à la main…

2 « J'aime »

C’est désormais réglé et parfaitement fonctionnel !

J’ai finalement désinstallé l’intégration « Tarif EDF » pour la remplacer par un capteur template. J’ai conservé exactement le même identifiant d’entité (sensor.tarif_actuel_tempo_9kva_ttc) afin que mes autres automatisations et mon module LCD reprennent le relais sans aucune modification.

Les futures mises à jour des prix se feront directement dans mon fichier template.yaml. La structure est suffisamment claire et lisible pour que la maintenance soit très simple.

Merci à tous pour votre aide et votre participation !

- sensor:
    - name: "Tarif Actuel Tempo 9kVA TTC"
      unique_id: tarif_actuel_tempo_9kva_ttc
      unit_of_measurement: "€/kWh"
      state_class: measurement
      state: >
        {% set couleur = states('sensor.rte_tempo_couleur_actuelle') | capitalize %}
        {% set heure = now().hour %}
        {% set is_hc = heure < 6 or heure >= 22 %}
        
        {% if couleur == 'Bleu' %}
          {{ 0.1325 if is_hc else 0.1612 }}
        {% elif couleur == 'Blanc' %}
          {{ 0.1499 if is_hc else 0.1871 }}
        {% elif couleur == 'Rouge' %}
          {{ 0.1575 if is_hc else 0.7060 }}
        {% else %}
          {# Valeur de secours : Bleu HP #}
          0.1612
        {% endif %}
      attributes:
        friendly_name: "Prix électricité temps réel"
        source: "Calcul interne (Tableau utilisateur)"
2 « J'aime »

Et tu utilises quel tarif dans ton panel energie ?

Là aussi il faut mettre à jour tous les 6 mois ou tu a cablé ton sensor.tarif_actuel_tempo_9kva_ttc comme cout sur chaque index ?

C’est amusant, je me posais justement la question il y a quelques instants. En réalité, je ne consulte pratiquement jamais le tableau de bord « Énergie » natif.
Il est sans doute resté avec la configuration par défaut, et je ne suis même pas certain qu’il prenne les tarifs en compte.
Je me suis fait un tableau de bord personnalisé pour l’énergie.