Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poll frequency #7

Closed
zulu-bravo opened this issue Feb 3, 2023 · 10 comments
Closed

Poll frequency #7

zulu-bravo opened this issue Feb 3, 2023 · 10 comments

Comments

@zulu-bravo
Copy link

Hello,
Merci pour votre travail. Cette intégration est géniale.
Pourriez-vous indiquer à quelle fréquence sont faits les appels API à RTE?
En effet, la mise à jour de la couleur du lendemain se fait de manière assez aléatoire et je souhaite en savoir plus.
Aussi, est-il possible de faire une mise à jour forcée ?
Merci !

@hekmon
Copy link
Owner

hekmon commented Feb 3, 2023

Bonjour,

Merci pour le retour tout d'abord !

Effectivement la mise à jour est un petit peu spéciale... Je voulais éviter que l'extension ne devienne un "client gênant" pour RTE dans le cas où beaucoup de personnes commenceraient à l'utiliser.

Commençons par les cycles standards:

  • Après une requête exécutée avec succès, si la couleur du lendemain est connue, l'extension se met en sommeil jusqu'au lendemain 6h (car elle n'apprendra rien de nouveau avant)
  • Si la couleur du lendemain n'est pas (encore) connue, elle essaye toutes les 30min (de ce que j'ai lu ici et là sur les forums avant de développer l'extension, essayer plus souvent sur une journée entière risquerait de faire bannir temporairement votre application RTE)
  • Si la requête rencontre une erreur (erreur réseau ou API) elle réessaye au bout de 10min (cet état est sensé être temporaire donc j'ai choisi un compromis entre vitesse et risque de bannissement si le problème dure quelque peu)
  • Il y a d'autres valeurs dans d'autres cas particuliers mais ils ne devraient quasiment jamais arriver.

Tous ces délais sont théoriques dans le sens où ils représentent une valeur de base à attendre. Mais pour éviter que tous les utilisateurs viennent tous demander en même temps tous les jours à 6h du matin l'information (et donc générer un pic de charge potentiel sur les serveurs de RTE) tous ces délais sont en suite légèrement modifié aléatoirement pour distribuer les connections sur le temps d'un point de vue des serveurs de RTE.

Les valeurs de modification aléatoires dépendent des cas ci dessus mais vous pouvez voir le détails dans la fonction _compute_wait_time() du controller d'API ici.

Il n'est actuellement pas possible d'effectuer une mise à jour forcée mais cela ne devrait (normalement) pas être nécessaire. Avez-vous un cas d'utilisation particulier pour penser à cette solution ?

@zulu-bravo
Copy link
Author

Bonjour
Merci pour votre réponse détaillée.
En fait, je vous pose la question car j'observe que la couleur J+1 n'est pas mise à jour dans la journée, jusqu'à tard dans l'après midi. Si un appel est fait toutes les 30', ça ne devrait pas arriver car je vois la couleur sur le site EDF.
C'était le cas il ya 2 jours et aujorud'hui aussi.
Dans les 2 cas, j'ai observé qu'il y avait une mise à jour de l'intégration en attente. Dès que je l'ai installée, le problème s'est résolu.
Est-ce possible que les appels api ne se font pas s'il ya une mise à jour non installée?
Merci

@hekmon
Copy link
Owner

hekmon commented Feb 3, 2023

Non je pense que vous rencontriez vous aussi le problème découvert dans #3 et dont la correction a nécessité plusieurs itérations (#4 et #6).

En fait il y a bien un moyen de forcer une update: redémarrer Home Assistant ! Installer une mise à jour redémarre Home Assistant et donc corrigeait votre problème... temporairement.

Assurez-vous de bien avoir la v1.2.2 et dites moi si le problème se représente, je laisse l'issue ouverte en attendant.

@zulu-bravo
Copy link
Author

Ah super, merci ! J'ai bien la v1.2.2.
Je vous tiens au courant si le problème se représente demain, sinon vous pouvez clôturer.
Merci !

@hekmon
Copy link
Owner

hekmon commented Feb 5, 2023

Puis je conclure après ces 2 jours que tout se passe bien avec la v1.2.2 ?

@zulu-bravo
Copy link
Author

Oui, aucun problème depuis la v1.2.2
Merci!

@hekmon hekmon closed this as completed Feb 5, 2023
@rtorrente
Copy link

rtorrente commented Feb 12, 2023

Hello @hekmon,

Merci pour ce plugin qui marche bien depuis 1 semaine chez moi !

Je me permet de réagir à cette issue car une info sur le site de RTE remet peut être en question la mise en sommeil jusqu'au lendemain quand une couleur est dispo.

En effet, on peut voir sur le site ici : https://www.services-rte.com/fr/visualisez-les-donnees-publiees-par-rte/calendrier-des-offres-de-fourniture-de-type-tempo.html

Conformément à la Délibération de la Commission de régulation de l’énergie du 30 octobre 2014 portant décision sur les missions des gestionnaires de réseaux d’électricité relative aux tarifs à effacement de type Tempo, la seule information de référence relative à la couleur des jours de type Tempo ayant un caractère engageant pour RTE est celle publiée en J-1 à 10h30 sur la présente page. Lorsque les informations à sa disposition le permettent, RTE diffuse un pré-signalement à titre purement informatif entre 8h et 10h30. L'information pré-signalée ne présage pas de l'information définitive et n'engage pas RTE

On peut donc avoir un risque (très peu probable je pense) d'avoir une mauvaise couleur si il y a un changement après la première couleur jusqu'à 10h30.

Peut être rajouter un check vers 11h même si on a déjà une couleur pour la confirmer ?

Qu'en pensez vous ?
Merci !

@hekmon
Copy link
Owner

hekmon commented Feb 12, 2023

Hello @rtorrente !

Ravi que l'intégration vous plaise.

Effectivement le point que vous soulevez mérite attention. Et la solution que vous proposez me semble parfaitement convenir. En visant 11h à plus ou moins 15min pour le délai variable, cela permettrait d'avoir une confirmation (silencieuse) ou une correction en fin de matinée dans le cas d'un changement improbable... mais possible !

Merci d'avoir repéré cette petite faille.

Je réouvre cette issue comme base de discussion jusqu'à la correction :)

@hekmon hekmon reopened this Feb 12, 2023
@hekmon
Copy link
Owner

hekmon commented Feb 23, 2023

Feb 23 06:02:21 nucsrv docker[160024]: 2023-02-23 06:02:21.876 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Calling https://digital.iservices.rte-france.com/open_api/tempo_like_supply_contract/v1/tempo_like_calendars with start_date as '2022-02-24T00:00:00+0100' and end_date as '2023-02-25T00:00:00+0100'
Feb 23 06:02:21 nucsrv docker[160024]: 2023-02-23 06:02:21.876 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Requesting access token
Feb 23 06:02:22 nucsrv docker[160024]: 2023-02-23 06:02:22.078 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Computing wait time based on data_end(2023-02-24 00:00:00+01:00) - today(2023-02-23 06:02:21.875773+01:00) = diff(1 day, 0:00:00)
Feb 23 06:02:22 nucsrv docker[160024]: 2023-02-23 06:02:22.078 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] We do not have next day color yet and hour of change (6h) is already past, retrying soon (wait time is 0:29:56)
Feb 23 06:32:18 nucsrv docker[160024]: 2023-02-23 06:32:18.079 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Calling https://digital.iservices.rte-france.com/open_api/tempo_like_supply_contract/v1/tempo_like_calendars with start_date as '2022-02-24T00:00:00+0100' and end_date as '2023-02-25T00:00:00+0100'
Feb 23 06:32:18 nucsrv docker[160024]: 2023-02-23 06:32:18.250 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Computing wait time based on data_end(2023-02-25 00:00:00+01:00) - today(2023-02-23 06:32:18.078968+01:00) = diff(2 days, 0:00:00)
Feb 23 06:32:18 nucsrv docker[160024]: 2023-02-23 06:32:18.250 INFO (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] We got next day color but we it is too early to be sure: waiting until confirmation hour to get futur next day color (wait time is 4:29:55)
[...]
Feb 23 11:02:13 nucsrv docker[160024]: 2023-02-23 11:02:13.251 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Calling https://digital.iservices.rte-france.com/open_api/tempo_like_supply_contract/v1/tempo_like_calendars with start_date as '2022-02-24T00:00:00+0100' and end_date as '2023-02-25T00:00:00+0100'
Feb 23 11:02:13 nucsrv docker[160024]: 2023-02-23 11:02:13.251 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Requesting access token
Feb 23 11:02:13 nucsrv docker[160024]: 2023-02-23 11:02:13.974 DEBUG (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] Computing wait time based on data_end(2023-02-25 00:00:00+01:00) - today(2023-02-23 11:02:13.251004+01:00) = diff(2 days, 0:00:00)
Feb 23 11:02:13 nucsrv docker[160024]: 2023-02-23 11:02:13.974 INFO (RTE Tempo API Worker) [custom_components.rtetempo.api_worker] We got next day color, waiting until tomorrow to get futur next day color (wait time is 19:00:53)

lgtm !

Ca sera dans l'upcoming v1.3.0 :)

@hekmon
Copy link
Owner

hekmon commented Feb 23, 2023

Je clos suite à la publication de la v1.3.0. Merci encore @rtorrente !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants