tempo QuickApp - Suivi Abonnement TEMPO (EDF)

**fredokl** · le 20 janvier

Sinon l'idée un RGBW serait vraiment pas mal.

**mprinfo** · le 20 janvier

Je sais de quel côté ton cœur balance

Envoyé de mon BLA-L29 en utilisant Tapatalk

**fredokl** · le 21 janvier

Vas-y balance!

**Sakkhho** · le 22 janvier

Hausse sur tempo sensiblement plus importante que sur les autres tarif ?
A regarder de près quand les montants seront publiés.

Envoyé de mon iPhone en utilisant Tapatalk

**Lazer** · le 22 janvier

Oui c'est la première crainte que j'ai eu en lisant la synthèse du discours du maire de France... les 3% restants sont probablement les abonnés Tempo / EJP.

Ce matin j'ai lu un autre article sur Selectra qui craint la même chose...

Wait & see... on sera fixé dans une semaine à 10 jours.

Une seule chose est sûre, quelque soit l'abonnement, ces 10% d'augmentation supplémentaire vont encore relancer une vague d'achats de panneaux photovoltaïques comme à chaque fois.
Pour les intéresses, dépêchez vous, il semblerait que la situation en mer rouge et le détournement des bateaux par l'Afrique va avoir une inflience sur les prix qui vont repartir à la hausse, alors qu'ils n'ont jamais été aussi bas que cet hiver (-50% en 6 mois, si on se reprend +50% dans l'autre sens c'est dommage...)

**mprinfo** · le 23 janvier

Petit aperçu pour voir les couleurs tempo
Avec le bouton d'ouverture de la porte de garage
Uniquement disponible avec mon QA

Envoyé de mon BLA-L29 en utilisant Tapatalk

**Lazer** · le 23 janvier

Tout ça pour nous montrer que tu as un beau Linky :2:

Et j'adore le "Uniquement disponible avec mon QA", un vrai pro du marketing :lol:

**mprinfo** · le 23 janvier

Mdr
Moi je fais pas de spam pour faire de la pub

J'ai installé tu QA il fonctionne bien aussi

Pourquoi tu le relis à ton QA edrt2 ?
Ne serait il pas plus judicieux d'interroger directement edrt2 à 6h et 22h ?

Si j'ai bien compris tu changes la couleur de ton QA à 0h ?

Perso je préfère faire cela à 6h

Envoyé de mon BLA-L29 en utilisant Tapatalk

**Lazer** · le 23 janvier

il y a 5 minutes, mprinfo a dit :

Pourquoi tu le relis à ton QA edrt2 ?

Parce que le QA EDRT2 va déjà chercher les infos de la téléinformation, qui sont des infos locales, indépendantes du cloud.
Je l'ai expliqué dans mon tuto, ça permet de continuer à fonctionner même en cas de panne des 2 serveurs (EDF et RTE) et/ou d'Internet.

Car il ne s'agirait pas que les scénarios domotiques se plantent un jour rouge, la blague peut vite couter très cher...

**mprinfo** · le 23 janvier

Ma question était

Pourquoi tu le relis à ton QA edrt2 ?

Ne serait il pas plus judicieux d'interroger

directement edrt2 à 6h et 22h ?

Envoyé de mon BLA-L29 en utilisant Tapatalk

**Lazer** · le 23 janvier

Je vais te retourner la question, et même 2 : pourquoi réinventer la roue d'une part, et faire 2 fois le travail d'autre part ?

J'ai déjà un QA qui fonctionne, en exploitant pleinement l'API proposée par GCE.

Donc mon QA Tempo va juste relire le contenu de la Variable globale alimentée par le QA GCE.

Simple et efficace.

D'ailleurs dans ma nouvelle version, je peux maintenant récupérer la couleur du lendemain depuis la téléinfo, à partir de 20h (stocké dans une autre VG), donc ça fait encore une sécurité supplémentaire.

**mprinfo** · le 23 janvier

En passant par ton QA edrt2 tu as un intermédiaire qui peut être planté
Ou on peut aussi imaginer que l'on utilise pas le qa edrt2
Ma réflexion était juste pour rendre indépendant le QA ce n'était pas une critique

Envoyé de mon BLA-L29 en utilisant Tapatalk

**Lazer** · le 23 janvier

Si le QA EDRT2 plante, alors le QA Tempo plantera également si j'inclue ma librairie GCE dedans, puisque ça sera le même code, donc les mêmes bugs !

Et même pire, puisque ça utilisera double de ressources CPU + RAM sur la HC3, et aussi sur l'EDRT2 lui-même qui sera doublement interrogé, on n'est pas à l'abri d'effet de bords qui fassent apparaitre de nouveaux bugs qui ne seraient pas apparus avec un seul QA qui interroger l'EDRT2.

Donc au final, ça ne sera pas plus fiable, et statistiquement parlant, d'un point de vue calcul de probabilité, c'est des maths, il y a même plus de chance que ça plante... donc bon... non vraiment je préfère conserver une architecture simple et efficace, où chaque QA a sont job à faire.

PS : c'est comme les disques en RAID cette histoire, tu as plus de chance d'avoir un problème avec plusieurs disques regroupés dans une grappe RAID qu'avec des disques indépendants... simple calcul de probabilités de niveau lycée.

C'est pas pour rien que le RAID 5 a été abandonné il y a pas mal d'année et remplacé par le RAID 6, qui lui même est en passe d'être abandonné et remplacé par de nouveaux algorithmes (Erasure Coding, etc). Dit autrement : on intègre le fait qu'on va avoir X pannes simultanées en ajoutant des protections de partout pour se prémunir contre ces pannes, à la fin on a une sorte d'usine à gaz.

Si tu as 1 chance sur 1 million que 1 disque tombe en panne, alors tu as 1 chance sur 500'000 seulement d'avoir une panne avec 2 disques... plus tu en mets, plus ça a de chance de planter.
ça c'est pour le calcul mathématique.
Ensuite tu ajoutes les effets de bords (vibrations des disques qui entrent en résonance, différence de latence entre 2 disques, etc) qui font que le risque de panne augmente encore beaucoup plus rapidement que le simple calcul de probabilité.

La comparaison est peut être un peu exagérée, mais imagine 2 QA qui font la même chose, c'est un peu comme les disques, 2 fois plus de chance de plantage.
Et comme ces 2 QA interrogent le même appareil, la similarité, au lieu d'avoir des disques qui entrent en résonance et se gênent mutuellement, c'est un EDRT de l'autre coté qui n'arrive plus à répondre aux requêtes simultanée des 2 QA. Au mieux un ralentissement, au pire un plantage, le serveur Web embarqué dans l'Ecodevice est très léger et dispose de très peu de ressources...

**Lazer** · le 23 janvier

il y a 57 minutes, mprinfo a dit :

En passant par ton QA edrt2 tu as un intermédiaire qui peut être planté

Et de toute façon, même si le QA EDRT2 plante, ce n'est pas un souci, puisque je le répète pour la Nième fois, mon QA Tempo est prévu pour gérer le cas de plantage : indisponibilité des serveurs EDF, RTE, téléinformation (donc indirectement Enedis)

ça fait déjà 3 sources d'informations.
Plus on lui ajoute de source d'info, plus ça va le rendre fiable.
En effet, on ne peut pas appliquer le calcul de probabilité exposé précédemment, puisque pour fonctionner, mon QA Tempo a besoin d'une seule source minimum.

Pas des 3 simultanément.
Et ça, ça change tout.
Au leu de devenir de moins en moins fiable à mesure qu'on lui ajoute des sources, au contraire, il va devenir de plus en plus fiable.

Je le redis, je l'ai conçu de telle sorte à ce qu'il soit le plus robuste possible, car là on commence à parler pognon.
Entre une journée rouge optimisée à 15 kWh, et une autre sans optimisation à 45 kWh, ça fait 33 - 11 = 22 € de différence, je trouve ça assez significatif.
Surtout si la blague du bug se répète plusieurs jours d'affilée...

Donc s'agirait pas que GEA fasse n'importe quoi avec les conditions à sa disposition.

Tiens, d'ailleurs, dis donc... GEA il dépend de tous les autres QA pour fonctionner ?
Et pourtant, on ne va pas inclure le code LUA de tous les autres QA du forum dans GEA, ça n'aurait aucun sens

Modifié le 23 janvier par Lazer

**mprinfo** · le 23 janvier

Je n'utilise pas GEA
Merci pour ces explications

Envoyé de mon BLA-L29 en utilisant Tapatalk

**henri-allauch** · le 29 août

Depuis hier au soir :

https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=2024-08-29

Réponse :

RESTEASY003210: Could not find resource for full path: https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=2024-08-29

Problème provisoire ou modification du site ???

Modifié le 29 août par henri-allauch

**Sakkhho** · le 29 août

En effet , idem chez moi.

Envoyé de mon iPhone en utilisant Tapatalk

**Lazer** · le 29 août

Je confirme....

Je ne sais pas si c'est temporaire ou définitif, mais.... API publique, ça devait arriver un jour.... comme tout service cloud !

Du coup ça donne tout l'intérêt de mon QuickApp qui est plus résilient car il prend en compte 2 sources, dont l'API de chez RTE qui est parfaitement documentée.

Et à venir avant cet hiver, avant que la saison des jours rouges ne revienne, une nouvelle version qui prendra une 3ème source, en local : en effet j'ai réussi à décoder la couleur du lendemain depuis la trame Téléinformation (à utiliser conjointement avec le QA GCE pour EDRT2).

**Sakkhho** · le 30 août

d'ailleurs ECODEVICE 3 il est tjs pas sorti ?

**Lazer** · le 30 août

Non, le dev a pris un peu de retard...

**chrisalex** · le 3 septembre

Hello,
voici la nouvelle url pour l'api :
https://api-commerce.edf.fr/commerce/activet/v1/saisons/search?option=TEMPO&dateReference=2024-09-03

bien mettre la date du jour souhaitée à la fin bien sûr

**henri-allauch** · le 3 septembre

Pour moi, Le lien que tu cite ci-dessus répond -> {"errors":[{"code":"ATM_HTTP_400","description":"La syntaxe de la requête est erronée.","severity":"ERROR","type":"TECHNICAL"}],"content":null}

Et parfois {"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":4,"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"}]}

Et https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=2024-09-03 repond ->

RESTEASY003210: Could not find resource for full path: https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=2024-09-03

Le QA Tempo EDF détecte Aussi l'erreur

Le QA Tempo RTE détecte Aussi l'erreur sur le site EDF et fonctionne sur le site RTE

[03.09.2024] [17:32:38] [DEBUG] [QA_TEMPO RTE_170]: Première requête
[03.09.2024] [17:32:40] [ERROR] [QA_TEMPO RTE_170]: Can't get EDF Tempo : Code de statut HTTP = 404
[03.09.2024] [17:32:41] [DEBUG] [QA_TEMPO RTE_170]: Nouvelle couleur RTE du jour : BLEU
[03.09.2024] [17:32:41] [DEBUG] [QA_TEMPO RTE_170]: Nouvelle couleur RTE de demain : BLEU
[03.09.2024] [17:32:41] [ERROR] [QA_TEMPO RTE_170]: Impossible d'obtenir le statut EDF Tempo
[03.09.2024] [17:32:41] [TRACE] [QA_TEMPO RTE_170]: Nouvelle couleur du jour : BLEU
[03.09.2024] [17:32:41] [TRACE] [QA_TEMPO RTE_170]: Notification : Couleur Tempo aujourd'hui : BLEU
[03.09.2024] [17:32:42] [TRACE] [QA_TEMPO RTE_170]: Nouvelle couleur de demain : BLEU
[03.09.2024] [17:33:42] [DEBUG] [QA_TEMPO RTE_170]: Interrogation EDF
[03.09.2024] [17:33:43] [ERROR] [QA_TEMPO RTE_170]: Can't get EDF Tempo : Code de statut HTTP = 404
[03.09.2024] [17:33:44] [ERROR] [QA_TEMPO RTE_170]: Impossible d'obtenir le statut EDF Tempo

A tout hasard j'ai essayé les liens sur un autre OS et un autre navigateur -> C'est pareil

SI cela fonctionne chez vous : @Lazer @chrisalex @Sakkhho c'est un problème de région ou mon IP qui est BlackListée ???

Modifié le 3 septembre par henri-allauch

**Lazer** · le 3 septembre

Depuis hier j'ai surtout l'impression que ça ne fonctionne qu'à certaines heures de la journée.... Donc selon le moment où tu l'as fait.... effectivement là tout de suite ça ne fonctionne plus alors que c'était OK vers midi.

Conclusion : il est urgent d'attendre que EDF stabilise tout ça...

**chrisalex** · le 3 septembre

@Lazer a raison ça ne marchait pas tout à l'heure et présentement cela refonctionne :

"{\"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\":4,\"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\"}]}"

**yves.guern** · le 3 septembre

Bonjour à tous,

Oui EDF a changé l'adresse et le contenu des info "tempo".

et, en prime, il y a eu un bug 'façon stagiaire' le 31 aout, toujours pas corrigé le 1er sept (pour cause konétè dimanche)? probablement lié au fait que c'est le 1er Sep que le calendrier Tempo change...

Maintenant c'est stable. Depuis 3 jours...

Pour la couleur du jour ou du lendemain: j'utilise une nouvelle adresse qui retourne le calendrier des jours 'en cours' ou plus exactement entre deux dates à fournir dans l'url.

Le code est le suivant:

    local curtime = os.time()
    local sDemain = os.date("%Y-%m-%d",curtime+86400)
    local sPremier = os.date("%Y-%m-%d",curtime-6*86400)
    URL = https://api-commerce.edf.fr/commerce/activet/v1/calendrier-jours-effacement?option=TEMPO&dateApplicationBorneInf="..sPremier.."&dateApplicationBorneSup="..sDemain.."&identifiantConsommateur=src

EDF retourne alors un tableau des couleurs qui va de sPremier (il y a 6 jours dans mon code), à sDemain.

Chaque élément du tableau retourné (dans json.decode(response.data).content.options[1].calendrier) contient un champ "dateApplication" qui est la date du jour en question (pour contrôle?) et sa couleur dans le champ "statut" sous la forme "TEMPO_XXXX", XXX étant la couleur du jour

RQ: Je ne demande qu'un nombre restreint de jours pour limiter la taille du message à recevoir/traiter, objectivement 6 c'est déjà trop, 2 suffiraient !!!
Et, quelque soit la valeur de sPremier, les données qui nous intéressent (aujourd'hui et Demain) sont les deux dernières valeurs du tableau retourné)

MAIS L'utilisation brutale de l'url ci dessus provoque le message d'erreur signalé plus haut:

{"errors":[{"code":"ATM_HTTP_400","description":"La syntaxe de la requête est erronée.","severity":"ERROR","type":"TECHNICAL"}],"content":null}

J'ai (donc) ajouté un header à la requête en recopiant (presque) celui vu sous firefox.

C'est une copie bête! L'ensemble des champs ne doit pas être utile mais cela fonctionne:

function QuickApp:onInit()

.../...
self.EDFoptions={checkCertificate=false,method='GET',timeout=5000,
                headers = {
        ["Host"] = 'api-commerce.edf.fr',
        ["User-Agent"] = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0',
        ["Accept"] = 'application/json, text/plain, */*',
        ["Accept-Language"] = 'fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3',
        --["Accept-Encoding"] = 'gzip, deflate, br, zstd',
        ["Referer"] = 'https://particulier.edf.fr/',
        ["content-type"] = 'application/json',
        ["Situation-Usage"] = 'Jours Effacement',
        ["X-Request-Id"] = tostring(curtime)..460,
        ["Application-Origine-Controlee"] = 'site_RC',
        ["Origin"] = 'https://particulier.edf.fr',
        ["Sec-Fetch-Dest"] = 'empty',
        ["Sec-Fetch-Mode"] = 'no-cors',
        ["Sec-Fetch-Site"] = 'same-site',
        ["Connection"] = 'keep-alive',
        ["TE"] = 'trailers',
        ["Priority"] = 'u=4',
        ["Pragma"] = 'no-cache',
        ["Cache-Control"] = 'no-cache'
            }}

  self.http = net.HTTPClient({timeout=20000})
.../...
end


function getEDFData(self)
    local sDemain = os.date("%Y-%m-%d",curtime+86400)
    local sPremier = os.date("%Y-%m-%d",curtime-6*86400)
    local url = "https://api-commerce.edf.fr/commerce/activet/v1/calendrier-jours-effacement?   option=TEMPO&dateApplicationBorneInf="..sPremier.."&dateApplicationBorneSup="..sDemain.."&identifiantConsommateur=src"

   
    self.EDFoptions.headers["X-Request-Id"] = tostring(curtime)..460
  
  self.http:request(url,{
        options = self.EDFoptions,
        success = function(response)
            self.webData = json.decode(response.data)
            self.tCalendar = self.webData.content.options[1].calendrier
           ..../.....
        error = function(response)
           ..../.....        
        })
end

J'ai commenté ["Accept-Encoding"] = 'gzip, deflate, br, zstd', car sinon le site EDF encode la réponse et, avec le lua de la HC3, je suis comme une poule avec un couteau, ce sera le sujet d'une autre question....

Notez le champ du header "X-Request-Id" qui n'est pas un champ fixe du header et qui doit(?) être mis à l'heure unix (en ms) à chaque appel

Avec cela j'ai retrouvé le fonctionnement normal que j'avais avec l'url d'avant:

local curtime = os.time()
url = "https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant="
self.http:request(url..(os.date("%Y-%m-%d",curtime)).."&_="..curtime.."542",{
        options={checkCertificate=false,method='GET',timeout=5000},
..../....

L'adresse https://api-commerce.edf.fr/commerce/activet/v1/saisons/search?option=TEMPO&dateReference=2024-09-03 donne le nombre de jour restant pour chaque couleur. Le retour est un Json:

    errors    []
      content
        0
          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"
        1
          typeJourEff    "TEMPO_BLEU"
          libelle    "TEMPO BLEU 2024 2025"
          nombreJours    300
          premierJour    "2024-09-01"
          dernierJour    "2025-08-31"
          premierJourExclu    null
          dernierJourExclu    null
          nombreJoursTires    4
          etat    "OUVERTE"
        2
          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"

Notez, si vous êtes pointilleux, qu’après 11h cela vous donne le nombre de jours 'consommés' en date du lendemain. C'est en fait la somme des jours "Tirés" par EDF à l'heure de l'interrogation.

Du coup je ne suis pas bien sûr de la signification de la date que l'on doit donner dans l'URL....

notez que 'utilise le même header mais qu'il n'est pas nécessaire.

Modifié le 3 septembre par yves.guern

tempo QuickApp - Suivi Abonnement TEMPO (EDF)

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

mprinfo

mprinfo

Barelle

Images postées