Suite à une question posée en 2023, cette dépêche propose un état des lieux des sources librement accessibles (sans imposer un jeton pour accéder aux API pour obtenir de manière structurée l’information) permettant de suivre les jours en tensions pris en compte dans l’option tarifaire TEMPO chez EDF. Cette option tarifaire consiste à payer moins cher l’électricité à condition de la payer 3 fois plus cher 22 jours dans l’année : les jours en tensions, généralement durant l’hiver.
Cette option permet de lisser la charge sur le réseau de transport de l’électricité. Pour faire bon usage de cette option, il faut surveiller la couleur du jour pour déterminer s’il vaut mieux réduire le chauffage électrique et les autres sources de consommations électriques. L’information est affichée le jour même sur le compteur électrique, mais il peut être utile d’être prévenu. On peut consulter le site de EDF, mais il peut être plus intéressant de disposer d’une API pour récupérer cette information, et ainsi pouvoir l’intégrer dans un système domotique, par exemple.
Sommaire
Les anciennes APIs ne fonctionnent plus
En effet, les forums domotiques attestent que c’était pourtant très utilisé, depuis le 29/08/2024 (avant-veille du changement de saison Tempo) les URL concernées (resp. couleur du jour+lendemain et compteurs saison en cours) répondent en erreur:
Couleurs jour/lendemain
Totaux en cours
À la recherche d’une solution de remplacement
On voit une autre URL apparaître ces derniers jours sur les forums, mais elle ne donne pas spécifiquement les couleurs jour/lendemain mais des compteurs: nombre de jours bleus, rouges et blancs depuis le début de l’année. Il faudrait donc déduire la couleur du jour en fonction de ce qui change d’un jour à l’autre! On a vu plus simple, mais comme ça marche pas on ne risque pas de l’utiliser:
URL nouvelle
{
“errors”: [],
“content”: [
{
“typeJourEff”: « TEMPO_BLANC »,
“libelle”: « TEMPO BLANC 2024 2025 »,
“nombreJours”: 43,
“premierJour”: « 2024-09-01 »,
“dernierJour”: « 2025-08-31 »,
“premierJourExclu”: null,
“dernierJourExclu”: null,
“nombreJoursTires”: 0,
“etat”: “OUVERTE”
},
{
“typeJourEff”: « TEMPO_BLEU »,
“libelle”: « TEMPO BLEU 2024 2025 »,
“nombreJours”: 300,
“premierJour”: « 2024-09-01 »,
“dernierJour”: « 2025-08-31 »,
“premierJourExclu”: null,
“dernierJourExclu”: null,
“nombreJoursTires”: 12,
“etat”: “OUVERTE”
},
{
“typeJourEff”: « TEMPO_ROUGE »,
“libelle”: « TEMPO ROUGE 2024 2025 »,
“nombreJours”: 22,
“premierJour”: « 2024-11-01 »,
“dernierJour”: « 2025-03-31 »,
“premierJourExclu”: null,
“dernierJourExclu”: null,
“nombreJoursTires”: 0,
“etat”: « NON_COMMENCEE »
}
]
}Le site d’EDF utilise une API interne indiquant la couleur, jour par jour, pour une plage de dates donnée. Il faut remplir quelques en-têtes HTTP pour que la requête soit acceptée :
curl \
'https://api-commerce.edf.fr/commerce/activet/v1/calendrier-jours-effacement?option=TEMPO&dateApplicationBorneInf=2023-9-12&dateApplicationBorneSup=2023-9-15&identifiantConsommateur=src' \
-H 'accept: application/json, text/plain, */*' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json'Exemple de réponse:
{
“errors”: [],
“content”: {
“dateApplicationBorneInf”: « 2023-09-12 »,
“dateApplicationBorneSup”: « 2023-09-16 »,
“dateHeureTraitementActivET”: « 2024-09-11T11:19:26Z »,
“options”: [
{
“option”: “TEMPO”,
“calendrier”: [
{
“dateApplication”: « 2023-09-12 »,
“statut”: « TEMPO_BLEU »
},
{
“dateApplication”: « 2023-09-13 »,
“statut”: « TEMPO_BLEU »
},
{
“dateApplication”: « 2023-09-14 »,
“statut”: « TEMPO_BLEU »
},
{
“dateApplication”: « 2023-09-15 »,
“statut”: « TEMPO_BLEU »
}
]
}
]
}
}Ces APIs semblent répondre en erreur « La syntaxe de la requête est erronée » aléatoirement lorsqu’on y accède avec curl. Une requête peut fonctionner une fois puis subitement cesser de répondre. S’agit-il d’une limitation du nombre de requêtes venant de la même IP? D’une authentification à effectuer pour avoir le droit de faire des requêtes? Ou juste d’un système complètement buggé qui plante une fois sur 10?
Pour ceux, que j’imagine nombreux, a qui cela va poser problème et qui ne veulent (ou peuvent) obtenir l’info via un module téléinfo à monter sur son compteur, il y a une URL dont je n’ai pas trouvé référence sur le site de RTE (qui ne propose que des API à jetons) qui se trouve en regardant le github source d’un site tiers donnant également l’info:
Source tierce
L’info délivrée par le compteur arrive en prime bien plus tardivement: En début de soirée au lieu de fin de matinée. C’est parce qu’elle transite par Enedis, une autre entreprise qui se charge de la distribution de l’électricité (les lignes à basse tension et les compteurs électriques).
On peut donc utiliser cette indirection ou regarder les sources afin de trouver l’URL en question, pour laquelle on a une info hélas bien plus verbeuse où il faut faire son marché : on récupère un JSON de tous les jours écoulés depuis le début de la saison en cours, et il faut :
— extraire l’info aux bonnes dates,
— refaire ses compteurs de jours bleu/blanc/rouge pour savoir s’il reste des jours rouges ou blancs prévus avant la fin de l’hiver,
— traiter le flag “fallback” qui, selon la documentation, indique un mode dégradé, mais ce flag ne semble jamais être mis à “true” dans l’historique des données disponibles, et son rôle exact n’est pas clair.
Conclusion
Il est au final navrant qu’EDF remplace un truc simple qui marchait très bien par un machin alambiqué qui tombe en marche une fois sur 10…
Je ne donne pas l’URL librement accessible, mais non documentée, de RTE car je n’aimerais pas qu’elle croule sous les demandes: Ceux qui sont capables de l’utiliser de manière raisonnée sans exploser des quotas sauront bien la trouver avec les infos données!
(RTE, Réseau de Transport de l’Électricité est l’entreprise qui s’occupe du réseau électrique à haute tension en France. Ce sont eux qui déterminent les jours où le réseau va être très chargé, et c’est ça qui détermine le prix de l’électricité).
Un avantage à l’utiliser, c’est que l’info est disponible encore plus tôt qu’elle ne l’était chez EDF (c’était généralement MAJ peu après 11h00), permettant d’anticiper encore un peu plus un jour rouge, sachant qu’ils sont souvent en série, si on a quelques lessives à lancer…
S’il y a des suggestions d’alternatives (sans jetons d’API) non citées, merci de les indiquer en commentaires.
# Catalogue API RTE
Posté par Haughtgard . Évalué à 1 (+2/-1).
Bonjour,
RTE possèdent des API accessibles et documentées.
Pour les jour Tempo Tempo Like Supply Contract.
Un compte est nécessaire pour utiliser les API de ce site.
[^] # Re: Catalogue API RTE
Posté par lym . Évalué à 1 (+0/-0).
Hello,
En effet, c'est la possibilité toute fléchée!
Maintenant, la question, c'est pourquoi imposer un compte pour obtenir une info ouverte?
Si on regarde un site très utilisé en domotique et faisant indirection (https://www.api-couleur-tempo.fr/) il utilise aussi en source l'URL libre d'accès de RTE et à regarder ses sources sur Github, un commentaire évoque qu'en plus de demander un compte ces API seraient moins stables que l'URL sans prise de tête qui alimente le site donnant l'info mise en forme (https://www.services-rte.com/fr/visualisez-les-donnees-publiees-par-rte/calendrier-des-offres-de-fourniture-de-type-tempo.html)!
[^] # Re: Catalogue API RTE
Posté par Haughtgard . Évalué à 1 (+1/-0).
Je suis d'accord si c'est une info publique ça devrait être juste accessible directement.
Dans Home Assistant j'utilise le HACS rte-ecowatt depuis un moment et je n'ai pas de soucis de stabilité de l'API.
Mais c'est pareil ce genre d'info ne devrait pas nécessité de compte.
# Ouf!
Posté par lym . Évalué à 4 (+5/-2).
Je l'avais oublié cette news! Faut dire que j'avais proposé un truc écrit un peu rapidement puis reçu des demandes de modifs à un moment ou je n'étais pas chez moi en septembre dernier… puis cela m'était un peu sorti de la tête.
Merci à ceux qui ont édité/complété, cela peut sans doute toujours servir à ceux qui n'auraient pas déjà trouvé une source d'info alternative qui leur convienne. Pour celle-ci, je peux donner un bilan de l'automne/hiver qui est très positif.
Cette API cachée s'est révélée très fiable, avec une (pré-)info couleur du lendemain généralement donnée entre 6h00 et 6h15 (mon script teste à partir de 6h et tous les 1/4 d'heures si info lendemain présente): L'intérêt est d'être informé d'un jour rouge avant même de partir au boulot la veille et de lancer un gros consommateur type machine à laver de manière anticipée, sachant que si on est lundi RTE peut possiblement enquiller la semaine derrière si les prévisions de conso sont élevées et ne s'est pas privé de le faire cette année.
Il y a eu quelques exceptions plus tardives, mais elles sont restées rares et toujours bien plus tôt que les 10h30 spécifiées engager RTE, sans parler de toute autre source qui en dépends.
Je n'ai pas pu clarifier le rôle du champ fallback: Jamais constaté de remise en cause de l'info, classiquement prise dès publication chez moi, après 10h30… Mais il peut aussi y avoir des saisons tempo entières sans que cette possibilité soit utilisée et possiblement plusieurs saisons d'observation requises pour en avoir le coeur net.
Je ne pourrais sans doute pas le faire: Probable que j'abandonne Tempo en novembre prochain avant les premiers jours rouges, car les évolutions tarifaires du kWh se sont un peu foutues de ceux qui font des efforts et la CRE a d'ors et déjà annoncée vouloir persister à rendre Tempo moins intéressant car même sans changer ses habitudes les jours rouges cela restait un abonnement rentable!
OK, mais dans ce cas pourquoi avoir conservé des tarifs kWh bleu/blanc stables et baissé surtout les HP rouges quand les autres offres réglementées on baissées généralement de plus de 15% en février dernier? Ceux qui jouaient le jeu sur ces périodes de tarifs élevés ne verront aucune baisse (ne consommant quasiment rien en HP/rouge) tandis que cela va profiter en réalité à ceux qui ne changeaient rien! Cette évolution tarifaire est donc à 180° du problème soulevé par la CRE: Il eu fallu baisser bleu/blanc quitte à monter fortement les HP/rouge!
Cette année, début février le quota de jours rouges était passé donc aucun intérêt à sortir immédiatement de Tempo. Mais sur la saison suivante je pense partir sur une stratégie inverse: Passer d'un 9kVA Tempo à un 6kVA tarif fixe (car le 9kVA fixe est passé en extinction en février dernier, imposant le HP/HC qui n'est plus jamais rentable à lui seul, cf la suite) et étaler sur 24h ce que je me faisais chier à concentrer sur 8h HC, en particulier les jours rouges.
Je paierais pour le moment plus cher, mais sans la contrainte Tempo qui était forte quand on est tout électrique: Jouer avec son télétravail pour pouvoir approvisionner son insert en quasi continu, se retrouver avec 1 semaine de lessives à passer sur le WE suivant 5j consécutifs (certes, je pourrais lancer des LL en HC rouge de nuit, mais il faudrait me relever au milieu de la nuit pour tout mettre dans le sèche linge inévitable en hiver) etc… En résumé, je veux bien m'emmerder mais il faut que le jeu en vaille clairement la chandelle. Et j'ai en prime horreur qu'on se moque de moi, ce qui est à mon sens ici le cas: On a attiré le chaland en 2022 quand RTE ne pensait pas faire l'hiver sans risquer le black-out, ça va mieux, au revoir et même pas merci!
Niveau évolution, cela a piégé aussi ceux qui étaient resté sur les tarifs EJP en extinction depuis des lustres: Tous les tarifs Tempo étaient passé sous ceux EJP, beaucoup ont donc viré EJP et ne pourront y revenir alors que ce tarif est désormais redevenu plus intéressant que Tempo!
Et l’extinction du tarif fixe en 9kVA est d'ors et déjà prévue pour les 6kVA!
A ce sujet petit calcul de rentabilité HP/HC:
Si F est le tarif kWh fixe et P/C respectivement ceux d'un tarif HP/HC, à considérer les consos équivalentes Nf et Np/Nc nous avons:
Nf.F=Np.P+Nc.C pour l'équilibre tarifaire des 2 types de contrats fixe et HP/HC.
Nf=Np+Nc avec la même conso globale.
La résolution est triviale et donne un équilibre tarifaire pour un ratio de conso HC/HP de:
Nc/Np=(F-C)/(P-F)
Avec les tarifs actuels donnés ici:
https://particulier.edf.fr/content/dam/2-Actifs/Documents/Offres/Grille_prix_Tarif_Bleu.pdf
Nc/Np=(20.16-16.96)/(21.46-20.16)=2.46
C'est à dire que pour rentabiliser un HP/HC au tarif réglementé actuel, il faut désormais consommer à minima presque 2.5 fois plus en HC (1/3 d'une journée, généralement de nuit) qu'en HP (2/3 restants de la journée)!!! Intégrer les différences tarifaires des différents abonnements ne change ce constat qu'à la marge.
Autant dire qu'il est désormais impossible de rentabiliser un HP/HC classique (non Tempo): La mise en extinction des tarifs fixes est donc une augmentation qui ne dit pas son nom et va toucher tous les nouveaux contrats ou les changements…
Il faut en effet voir qu'il y a 25 ans, un tarif HP était équivalent au tarif fixe et les HC n'étaient que du bonus. On est depuis longtemps passé à un malus aux HP hélas jusqu'à en arriver à la situation présente: Se faire flouer! Et passer à Tempo n'est désormais plus forcément une option.
=> Retour au fixe en soignant les délestages car désormais ce sera baisser vers un 6kVA: Ce sera une conso plus plate, non pilotable à la consommation pour les producteurs qui si tout le monde fait pareil vont donc devoir se démerder pour produire! Mais il faut à un moment arrêter de prendre les gens pour des ânes…
[^] # Re: Ouf!
Posté par Florent Fourcot . Évalué à 3 (+1/-0).
Le calcul de ratio pour rendre les heures creuses me semble faux.
Si je consomme 1kWh, ça coûte 20,16 en tarif classique. Si je fais la moitié en HC et la moitié en HP, j'arrive à (21.46 + 16.96) / 2 = 19,21
Ce calcul simple permet de voir qu'un contrat avec 50% en HC est gagnant. Bien loin de ton calcul avec un ratio de 2.46, ou alors je n'ai pas compris un truc.
La bonne résolution du ratio pour moi, avec R le pourcentage d'HC :
16.96 x R + (1 - R) x 21.46 = 20.16
[^] # Re: Ouf!
Posté par lym . Évalué à 0 (+0/-1).
Le calcul est juste. Pour une conso totale égale il faut une consommation digne d'un boulanger faisant tourner ses fours en nocturne et la vitrine le jour désormais.
# La couleur du jour dans son terminal
Posté par Tania (Mastodon) . Évalué à 2 (+2/-0).
Chaque matin, pour connaitre la couleur du jour et du lendemain, j’utilise un petit script bash qui fonctionne plutôt bien. La personne qui le maintient a effectivement modifié la façon de se connecter à l’API en 2024. Ça semble plus compliqué qu’avant.
[^] # Re: La couleur du jour dans son terminal
Posté par lym . Évalué à 1 (+0/-0).
EDF, je n'avait pas pigé comment cela fonctionnait au moment du changement.
RTE, c'était assez simple en fait… Il suffit de regarder (F12->Réseau->Recharger la page sous Firefox par exemple) ce qu'appelle la page RTE grand public citée dans mon autre commentaire (en maintenance à l'instant ou j'écris, cependant).
On y voit une URL appelée par cette page front-end avec en paramètre les années de la saison Tempo en cours (on peut récupérer également les saisons passées complètes de manière analogue, d'ailleurs) qui retourne un JSON récapitulant tout le calendrier depuis le 1er septembre du début de saison Tempo avec les couleurs. On en tire la dispo de l'info lendemain et par simple somme les totaux par couleur de l'année en cours.
Ce que j'ai est un peu spécifique niveau langage (Lua), car ma solution domotique a une intégration Lua native (c'est un langage fait spécifiquement pour s'intégrer ainsi à d'autres programmes, même si un interpréteur classique existe, avec tout ce qu'il faut quand le cœur est en C/C++, il est d'ailleurs utilisé dans certains jeux pour scripter des actions). Mais récupérer un JSON ouvert et le parser en Python par exemple c'est simple (possible en Bash aussi, mais c'est moins évident/lisible à mon sens, son avantage est surtout d'être là de base sur presque sur tout Unice).
L'autre avantage est d'avoir 99% du temps l'info dès 6h15 (ça a parfois tardé jusqu'à 9h30 des jours ou cela a semblé hésiter et à chaque fois c'était pas du bleu le lendemain) au lieu de 11h passé chez EDF.
# projet perso tempo
Posté par DarkChyper . Évalué à 5 (+5/-0).
Bonjour la communauté,
Je m'appelle Simon Lhoir.
J'apprends grâce à cet article qu'il y avait une API ouverte pour tempo. Depuis toujours j'utilise l'API de RTE qui nécessite un token.
Vu que je trouvais ça naze et que j'avais besoin d'une excuse pour développer un projet, j'ai créé un outil qui relaie l'information de RTE via différents canaux (RSS, API, ics…) et cela en respectant la vie privée de tous.
Les sources sont ici : https://gitlab.com/dark-open/tempo
Le site est disponible ici : https://tempo.lhoir.me
Le projet est sous licence Créative Commons BY.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.