bonjour,
est ce que quelqu’un, qui utilise le plugin « edf tempo » a aussi des erreurs APICall
[2026-04-05 11:05:14] ERROR API callApi(colors) erreur HTTP 0 : Operation timed out after 10000 milliseconds with 0 out of 0 bytes received
[2026-04-05 11:06:20] ERROR API callApi(colors) erreur HTTP 0 : Resolving timed out after 10000 milliseconds
je log uniquement les erreurs et celle là, je ne la comprends pas.
page santé
Salut,
Je n’utilise pas ce plugin et donc ne peut pas t’aider.
Cependant il serait interessant de publier la page santé de ton jeedom pour toute question : le souci vient peut être de la version de jeedom ou de l’OS que tu utilises et ces derniers sont présents dessus.
j’utilise le plugin depuis 2 ans je pense, quasiment depuis le début que j’utilise ma Luna
Bonjour,
Depuis environ 3 semaines, le plugin n’utilise plus le site EDF mais ai-beauvaisis.fr
Quand vous avez ces erreurs, ce serveur ne répond plus aux requêtes dans les 10 secondes.
Le code de l’appel :
@ido ai-beauvaisis.fr fait quoi de la hardwareKey du Jeedom des utilisateurs du plugin?
Hello @jpty , le hardwareKey sert a authentifier sur mon serveur que la demande est faite depuis un système Jeedom et à mettre en cache la data pour éviter de fracasser ma base de donnée.
La mécanique actuel c’est que j’ai un cron sur mon site qui va récupérer la data sur EDF en émulant les headers de navigateurs (un peu comme l’ancienne version) sauf que là au lieu de faire plusieurs centaines de requêtes chez EDF (tous les plugins en même temps 2 fois par jours) au risque de tout cassé, j’ai passé la route sur mon serveur.
Et j’en ai profité pour stocké les couleurs des jours passé jusqu’à 2024, et maintenant on a un calendrier qui fait un get pour récupérer les couleurs et dates.
Le hardwareKey n’est une mince protection pour éviter que mon serveur soit un hub à quiconque veux faire une app sans à avoir a s’authentifier sur les serveurs d’edf.
Pour ce qui est de l’erreur @vincent_ayala est-ce que ca le fait tous les jours depuis la mise à jour ou ce n’est que le 5 avril dernier ?
(je crois qu’hier matin j’ai bossé sur mon serveur et j’ai dû le faire reboot dans la matinée, ca se trouve c’était entre 11h et 11h10 …)
Ca ne vous pose aucun problème de capturer des données privées de tous les utilisateurs de votre plugin sans leur consentement ni même les informer? Vous ne trouvez pas ca problématique?
Cette subtilité ne se trouve ni dans la documentation ni dans le changelog…
C’est vrais que j’ai pas pensé à ca. j’avais focus l’attention sur le fait qu’un plugin sur Home Assistant puisse use mon endpoint, et comme c’est pas le projet je me suis appuyé sur une variable local de Jeedom.
Est-ce qu’il y a autre chose plus anonyme que je pourrais utiliser en lieu et place ? Ou je dois mettre au point une autre méthode pour authentifier l’origine de la requête ?
Je viens de push une MAJ du plugin pour générer un UUID sans se baser sur la HardwareKey .
Après de mon côté je n’ai pas stocké les datas de hardwarekey, mais un hash de l’ensemble avec un timestamp et un id plugin, donc de mon côté rien de privée. mais pour ne pas avoir de soucis j’ai généré ce nouvel ID unique et mis une mentions dans le changelog avec un mots d’excuse sur l’utilisation de la variable.
J’espère que ca ira côté legit 
restera toujours l’ip… et tout ca sans information… bref
je peux croire que c’était sans mauvaise intention mais ca reste un problème à mon humble avis
y a un trou dans la raquette qlq part
Je n’utilise pas l’IP … là honnêtement j’ai viré un hash qui était basé sur une data privée, pour un autre hash générer sur un ID unique aussi. Mais pour ce qui est de la requête curl derrière que ca soit fait sur mon serveur ou le serveur d’EDF cela ne change rien au plugin 
ou alors il y a quelque chose qui m’échappe, et si c’est le cas je veux bien avoir ton point de vue pour que je fixe ca
Sujet chaud déjà abordé ici:
Merci pour ton retour. il y a un monde entre la collecte de datas à but de statistiques et d’amélioration de plugin, et une requête pour récupérer la data sans quoi le plugin ne pourrait pas fonctionner … N’importe quelle plugin qui récupère des informations sur des serveur web externe fait une requête vers un site internet, propriété ou non du développeur. Donc concrètement couper les requêtes vers le monde extérieur rendrais obsolète la quasi totalité des plugins du market.
A moins que Jeedom fasse l’interface et que toutes les datas soient collectés par Jeedom puis retransmises à chaque installation. Ce qui voudrais dire que c’est à Jeedom de développer cette interface, ces base de données et d’en assurer la maintenance … cela n’as aucun sens.
Je ne suis pas certains que les équipe de Jeedom aient envie de se mettre ca sur le dos, ils leur est déjà difficile de mettre en version stable 2 de mes plugins poussé depuis plusieurs semaines, je doutent fortement que gérer une nouvelle infra soient dans leurs priorités.
Après @Mips j’aimerais bien avoir ton ressentis et ton point de vue sur le sujet car honnêtement je ne comprend pas trop le problème qu’un plugin fasse appel à un endpoint extérieur.
C’est pas n’importe quel endpoint extérieur!
Le description du plugin dit que les données sont récupérées depuis edf.
Donc on sait qu’un appel vers le site edf sera fait.
Sauf que c’est faux! C’est vers un site privé qui t’appartient.
Rien que ca c’est tromper les utilisateurs.
Et sans le savoir tu récoltes des données privées, ne fût-ce que l’adresse ip.
Il n’y a pas beaucoup de différence entre ton usage et la récolte de statistique.
Qui est responsable? Quel usage est fait de ces données? Combien de temps sont-elles conservées? Comment est ce sécurisé? Comment les données sont-elles nettoyés? Comment contrôles-tu les accès (connus ou à ton insu) ? Quelle procédure en cas de découverte de brèche? Etc
Il y a des dizaines d’autres questions…
Donc oui il y a une différence entre une personne privée qui fait ca en mode diy dans un monde de bisounours et une société qui en principe gère tous ces points (je suis pas naif, il peut aussi y avoir des failles mais au moins elle est responsable)
Et surtout ici l’utilisateur n’est pas informé.
Encore une fois tu n’as probablement pas voulu mal faire mais il faut être conscient que ca reste un problème sérieux qui pourrait devenir catastrophique.
Mais ca ne doit pas être le seul plugin dans ce cas… j’ai bien des idées sur d’autres
@ido , oui le pb existe que depuis la mise à jour. mais pas celle du 5 avril, ca le faisait avant, mais j’étais en déplacement et je n’ai pas eu le temps de m’en occuper. j’espérais que la mise à jour du 5 avril corrige le pb
pour rebondir le reste de la discussion, je comprends le sens des évolutions que tu as faites mais aussi la remarque de @Mips
je pense que mettre à jour la doc ne serait pas un mal pour faire toute la transparence sur le fonctionnement du systeme (a court terme).
question totalement bête sur l’évolution envisageable:
OK je comprends la problématique, en fait si je résume le principale reproche n’est pas tant qu’il y ait un appel externe, mais le fait qu’il n’ai jamais été mentionné que ca soit à l’époque où j’utilisais les serveurs d’edf que par rapport à la dernière mises à jour.
Donc effectivement je suis d’accord avec toi et je peux facilement corriger le tire en mettant dans la description qu’une requête HTTP est faite pour récupérer les données depuis l’extérieur, et que potentiellement leurs adresses IP publique pourrais être visible. mais qu’en aucun cas les datas sont stockés et réutilisées.
Sachant que sur mon serveur je ne stocke pas les IP, ne collecte aucune donnée nominative, je ne fais pas de tracking et que le hash de l’UUID est non réversible. L’unique objectif ici est de filtrer l’origine des requêtes (pour éviter un usage abusif de l’endpoint) et mettre en cache les datas pour par fracasser une base de données avec plusieurs centaines de requêtes simultanés. Donc on est sur un usage purement fonctionnel sans exploitation de données.
Pour ce qui est de l’exposition de l’adresse IP effectivement une requête HTTP expose une IP côté serveur, mais à aucun moment je la stock, ne l’utilise ou la traite. A ce titre mon fonctionnement n’est pas différent de n’importe quel service web contacté par un plugin (météo, api divers etc …) donc sur ce point tous ces plugins sont soumis à la même contrainte technique liées aux requêtes HTTP.
Concernant le risque catastrophique il me semble limité dans le contexte actuel. Dans le cas présent même si je me fais poutrer ma base de donnée, les données ne sont pas exploitable en l’état vu que je travail avec un hash non réversible et en plus je n’ai aucune corrélation entre l’identité réelle de l’utilisateur et le hash. Aucune donnée généré ne permets le contrôle du Jeedom de l’utilisateur final donc je suis à des années lumières d’une fuite de données sensible.
Concernant l’abandon de l’endpoint direct d’EDF pour passer par mon serveur, c’est vraiment pour éviter qu’EDF ne flag les centaines de requêtes simultanées et ne les bloques vu que je passais par une méthode sans authentifications pour récupérer les données (genre scrapping)
Et surtout pour rajouter des fonctions au plugins, à savoir l’historiques des couleurs des jours et surtout la mise à jour automatique des prix. ce n’est pas un changement caché pour collecter des données, mais bien un changement pour améliorer la stabilité et les fonctionnalités.
En conclusion je vais modifier la description du plugin et le readme sur github. Si vous voyez d’autre choses que je doivent mettre à jour je suis dispo 
Pour ce qui est des heures de synchronisations mon serveur tente de récupérer la data pendant 30min entre 11h et 11h30, EDF ne mets pas forcément à jour la data à 11h pile, en ce moment c’est plus autour de 11h06. Normalement le plugin dans Jeedom fait des requêtes entre 11h et 11h30 au serveur. J’ai recommandé dans le plugin de mettre les scenario autour de 11h10 pour être sûr que la data soient bien récupéré par le plugin.
Concernant ton erreur c’est un erreur de site inaccessible… je ne sais pas trop ce qui a causer cette erreur. Est-ce qu’hier et aujourd’hui tu as encore eu l’erreur ? Est-ce que d’autres utilisateur ont le même soucis ?
