Intégration Enedis-Linky

Bonjour à tous,

J’aimerai vous présenter la nouvelle intégration sur laquelle je travaille enedis-linky.

Avant toute chose, sachez que @VonOx fait déjà un énorme travail sur la possibilité de connecter le compteur Linky à Gladys via zigbee et je ne peux que vous conseiller d’utiliser zigbee quand ce sera disponible (données locales, en direct… à suivre ici).

Mais je vois quand même quelques avantages à ce module enedis-linky. Le premier c’est pour les nouveaux arrivants en domotique, ça peut leur permettre de recevoir des données sans avoir à investir dès le début dans du matériel. Aujourd’hui beaucoup de logements sont équipés d’un compteur Linky et Enedis nous met à disposition une API pour récupérer nos données (sous quelques conditions) donc autant en profiter. Le deuxième avantage auquel je pense, c’est le cas où on a un Linky distant par rapport au raspberry (à la cave, à l’extérieur…) ou qu’on souhaite surveiller la consommation d’une autre maison (secondaire, proche âgée…).

À noter tout de même qu’il y a quelques inconvénients à passer par l’API Enedis plutôt que la solution local zigbee.

  • peu de type données : la conso journalière (1 valeur pour chaque jour complet), la puissance moyenne par demi-heure (48 valeurs par jour) et la puissance max de la journée (pas encore implémenté dans cette intégration pour l’instant)
  • les données ne sont pas en direct, Enedis ne les donne que le lendemain (en général dans la première partie de journée mais jamais à heure fixe). Sachant ça, cette intégration est utile surtout pour les graphes un peu moins pour les scènes (en tout cas compliqué de les utiliser en déclencheurs) puisque tous les relevés sont reçu en même temps

Si le Linky a un historique, la première synchronisation récupère les 3 derniers mois pour la consommation journalière et les 7 derniers jours pour la courbe de puissance. Puis chaque matin on a une tentative de récupération toutes les 30 minutes jusqu’à la récupération des données de la veille. Une fois récupérées, plus aucune requête n’est faite jusqu’au lendemain.

Pour l’équipe de dev, il y a plusieurs points sur lesquels j’aimerai que vous me disiez ce que vous en pensez. Ce sont surtout des problèmes dû au fait que ce sont les données de la veille qu’on reçoit.
Au niveau des états, j’ai ajouté la possibilité de surcharger le created_at lors de l’enregistrement mais j’ai laissé updated_at à l’heure de l’enregistrement.
J’avais également des problèmes pour les agrégations, puisque les last_monthly_aggregate, last_daily_aggregate, last_hourly_aggregate sont des dates potentiellement plus récentes que les « nouvelles » valeurs, donc les calculs des agrégations ne se faisaient pas. Lors du poll, je force la mise à jour des dates last_xyz_aggregate aux premières dates de la nouvelles vagues de données.
Dernier point, les valeurs de puissance est (il me semble) utile surtout pour le graphe 24 heures. Le problème c’est qu’en deuxième partie de journée on a pas encore les données du matin donc on a seulement une partie de l’intervalle, ça fait très vide.


Que penseriez vous d’afficher l’intervalle depuis la dernière valeur agrégée plutôt que depuis l’heure actuelle ? (c’est une proposition je n’ai pour l’instant fait aucun changement dans ce sens)

Sinon pour ceux que ça intéresse, l’intégration utilise le module linky de @bokub (merci à lui) qui est une implémentation JS de l’API d’Enedis.
Pour configurer l’intégration il faut récupérer les tokens d’authentification d’Enedis. Cela se fait sur la passerelle proposé par @bokub https://conso.vercel.app/ en cliquant en bas et accepter les conditions de partage Enedis, puis rendez vous sur la page de l’intégration dans Gladys pour ajouter les tokens récupérés précédemment. On doit passer par cette passerelle car officiellement seul des sociétés peuvent communiquer avec l’API d’Enedis. La passerelle permet de générer les tokens au nom de Bokub Linky mais seul vous avez réellement ces tokens. Tout est expliqué sur le site, et si vous voulez en être sûr le code de la passerelle est ici linky/server at master · bokub/linky · GitHub

J’en suis aux finitions mais l’essentiel est là, j’espère que ça vous plaira

8 Likes

Hello @bertrandda ! Génial ce développement :slight_smile:

Pour l’histoire de la passerelle, je suis un peu frileux à l’idée d’utiliser une entreprise tierce pour ce genre de développement:

  1. Qu’est-ce qui nous dit que cette plateforme va rester pérenne dans le temps ? En cas de downtime/mise à jour d’API, qu’est-ce qui nous dit que le dev va investir du temps pour maintenir cette plateforme?
  2. En terme de sécurité des données, certes le site dit que rien n’est stocké, mais bon c’est à nous de faire confiance !
  3. L’API d’Enedis possède un rate-limit par entreprise qui est assez faible. Le fait de ne rien faire transiter côté serveur (et que le client fasse ce qu’il veut, ce qui me semble d’ailleurs limite!) fait qu’on ne peut pas implémenter de queuing des requêtes. Je pense qu’assez vite on va avoir des problèmes de synchros avec des erreurs 429…
  4. Je trouve ça assez bizarre niveau sécu que les tokens soient donnés au client, sur les autres passerelles que j’ai vu (https://enedisgateway.tech est un autre par exemple), la passerelle fait office de passe plat et ne donne pas les tokens Enedis au client. ça permet notamment de faire du rate limiting, et de queue les requêtes en cas de fort traffic.

Dans l’idéal, je serais plutôt pour utiliser la structure juridique du projet et de faire passer ça par Gladys Plus, ça ferait plus sens et ça serait plus pérenne ^^

On en avait déjà parlé :

Après, pour le coup ça sera disponible via Gladys Plus, donc en payant… Je veux pas que ça soit vu comme un putsch aha ^^ Mais bon ça me fait un peu peur ces plateformes gratuites, on a aucune garantie et nous on veut que ce service soit disponible pour les 10 prochaines années.

Qu’en pensez-vous ?

1 Like

Au sujet du choix de ce module npm et de cette passerelle, j’ai choisi cette façon de faire parce qu’il me semblait pratique, c’est vraiment l’implémentation de l’API d’Enedis. Alors certes si Enedis modifie son API il faudra répercuter ces changements côté module js mais même si on développe notre propre passerelle qu’on utilise ou non ce module faudra faire un changement quelque part et on peut faire nous même la modification côté module il n’est pas bien compliqué. Le fait de passer les secrets à l’utilisateur permet justement d’éviter d’avoir à passer par une passerelle tierce à chaque appel API Enedis (et donc de faire transiter les données utilisateurs par un service tier). Une fois que tu a tes tokens, Gladys demande directement à Enedis, même si la passerelle est supprimée/ne fonctionne plus l’intégration continuera de fonctionner chez ceux qui l’ont déjà paramétrée.
Mais je comprend bien l’utilité d’avoir un serveur tampon pour réduire les erreurs, je ne pense pas que ce soit un réel problème aujourd’hui (j’ai regardé la limite est à 5 req/s), et de notre côté si on a une erreur ça retente une récupération des données 30minutes plus tard (déjà qu’on a 1/2 journée de retard sur les données à cause de l’API d’Enedis, ça ne devrait pas être trop impactant d’attendre quelques minutes de plus). Après s’il y a juste ça qui pose problème je peux passer par enedisgateway.tech
Plus globalement à propos de cette intégration Enedis-Linky et de Gladys Plus, je suis carrément pour ajouter des services qui peuvent compléter l’offre G+, c’est ça qui fait et permettra de faire vivre le projet sur le long terme. Mais autant Alexa, Google, Owntrack… le passage par G+ est nécessaire car il y a besoin d’une URL public parce que c’est l’extérieur qui initie la connexion, autant là c’est quelque chose qui fonctionne chez chacun. Je suis même prêt à développer un truc en plus côté G+ avec un contrat Enedis spécifique à la structure Gladys pour plus de stabilité pour les utilisateurs G+ mais c’est vrai que je voyais cette intégration comme une nouvelle motivation d’avoir des utilisateurs basiques (qui amènera forcément une partie à des utilisateurs Gladys Plus). C’est le genre de module que tu peux configurer sans aucun achats supplémentaires comme la météo, le calendrier, telegram… pour quelqu’un qui veut tester Gladys quelques semaines ça ne peut être que bénéfique.

On peut en rediscuter, je ne pense pas que ce soit une intégration très pressée à sortir. À voir aussi ce qu’en pensent les autres.

4 Likes

Justement je ne suis pas sûr que ce soit une bonne pratique ! Ces tokens sont destinés à être utilisée par l’entreprise partenaire, pas l’utilisateur final, non ?

Pour la partie commerciale, je suis ouvert ! Ca peut-être en dehors de Gladys Plus, ça peut-être une option séparée, tout est possible :slight_smile:

Je me permetde repondre a ce sujet, ne men voulez pas :smiley:

Dans ce cas (si je suis ton raisonnement) pourquoi l’intégration meteo ne fait elle pas partie de loffre gladys plus ? Une installation sans token ne serait elle pas plus facile ?

En fait je penses que c’est plus dans le sens « conditions d’utilisation » de l’api enedis qui est destinée à des entreprises uniquement.

1 Like

Ouai ouai ja ais bien compris
je sors xD

@bertrandda si je dis pas de bêtises les tokens sont valables 1 an. T’as un retour de l’api avec la date d’expiration ?

Effectivement je plussoie @VonOx, l’intégration météo l’utilisateur créé son compte lui même, et est en relation direct avec OpenWeather

Dans le cas de l’API Enedis, il faut un prestataire entreprise qui signe un contrat avec Enedis (c’est une demande d’Enedis, pour le coup ce serait plus simple si c’était comme OpenWeather!)

Je ne suis pas certain (à vérifier) que les tokens soient à destination de l’utilisateur final, pour des raisons 1) de sécurité informatique 2) contractuelle :slight_smile:

Pour faire un parallèle, selon moi l’intégration avec Enedis est beaucoup plus proche de l’intégration Alexa/Google Home que de l’intégration OpenWeather, et côté Google Home/Alexa l’utilisateur final n’a pas accès aux tokens, ce serait grave :smiley:

1 Like

En effet j’aurai surement dû un peu plus étudier l’API d’Enedis, on est pas sensé accéder directement aux données.

Je pense essayer dans un premier temps de passer par la passerelle enedisgateway.tech vu qu’elle est déjà en place. Je vais tenté de faire ça de façon « modulaire » on pourra peut être changer dynamiquement la passerelle si l’utilisateur est abonné G+ ou non. Voir même passer uniquement sur la passerelle G+ si on sent que la passerelle enedisgateway.tech ne tient pas. Quand penses tu, ça serai mieux ?

Dans l’idée je serais plutôt pour passer par Gladys Plus qui est un intermédiaire de confiance pour les utilisateurs Gladys, et surtout j’ai un peu peur du rate-limite qui est imposé par partenaire à 5 requêtes / secondes de manière globale à une application (tout client confondu).

Commercialement, d’un côté je n’ai pas envie de fournir une feature qui soit « payante only », mais d’un autre côté, est-ce que si on fournit la passerelle enedisgateway.tech « gratuite » en plus de Gladys Plus (je mets entre guillemet parce qu’au final enedisgateway.tech demande aussi des dons pour soutenir les coûts d’infrastructures) ce serait pas se tirer une balle dans le pied pour l’adoption de Gladys Plus, sachant que j’ai déjà beaucoup de mal à être rentable :sweat_smile:

De mon côté je peux te fournir assez rapidement des routes d’API Enedis sur Gladys Plus si tu veux, c’est de l’Oauth c’est pas une intégration énorme :slight_smile:

J’ai fais la demande à Enedis !

Visiblement j’ai déjà accès au bac à sable :slight_smile:

1 Like

Bon, ça va très vite, j’ai déjà reçu une réponse d’Enedis, ils ont besoin d’informations complémentaires mais j’ai déjà une 1ère version du contrat d’API :slight_smile:

De mon côté j’ai testé l’API sur le bac à sable, et j’ai commencé à implémenter des routes côté Gladys Plus pour gérer l’authentification (c’était rapide) + des routes passes-plats avec queuing pour respecter le rate-limite !

2 Likes

Ok bonnes nouvelles, je te laisse me dire quand tu as une première version des routes en question côté Gladys Plus, que je change la récupération des données côté intégration.

Il y aura un environnement de test Gladys Plus ? une preprod ou autre, ou je lance également G+ en local ?

Yes ! Je vais continuer dessus aujourd’hui, ça va aller assez vite je pense :slight_smile:

Non, comme je bosse seul sur Gladys Plus je travaille entièrement en local :slight_smile:

Dès que la feature est terminée, et bien testée, je déploierais sur l’environnement de production, et je te donnerais toutes les informations pour taper dedans.

Je peux déjà te donner le format des réponses de l’API, car ça matchera le format Enedis (je fais que passe-plat, je modifie rien)

Déjà les routes dispos côté Enedis que je vais fournir:

Exemple de paramètres/réponses sur la route /v4/metering_data/consumption_load_curve:

Query:

{
    usage_point_id: 16401220101758,
    start: '2022-08-01',
    end: '2022-08-03',
}

Réponse:

{
  "meter_reading": {
    "usage_point_id": "16401220101758",
    "start": "2019-05-06",
    "end": "2019-05-12",
    "quality": "BRUT",
    "reading_type": {
      "measurement_kind": "power",
      "unit": "W",
      "aggregate": "average"
    },
    "interval_reading": [
      {
        "value": "540",
        "date": "2019-05-06 03:00:00",
        "interval_length": "PT30M",
        "measure_type": "B"
      }
    ]
  }
}

Mais bon j’imagine que tu avais déjà fais ça avec l’intégration actuelle, donc là dessus tu n’auras pas grand chose à modifier ?

J’ai bien bossé aujourd’hui, j’ai finis la plupart des routes backend côté Gladys Plus.

L’authentification côté Gladys Plus fonctionne bien:

(C’est un premier poc, je vais améliorer)

Côté Gladys, dans ton intégration Enedis ça sera super simple, tu auras accès à des fonctions JS qui te renverront la donnée, pour l’instant j’ai codé 3 fonctions:

const data = await gladys.gateway.enedisGetConsumptionLoadCurve({
  usage_point_id: '22516914714270',
  start: '2021-09-01',
  end: '2021-09-05',
});
const data = await gladys.gateway.enedisGetDailyConsumptionMaxPower({
  usage_point_id: '22516914714270',
  start: '2021-09-01',
  end: '2021-09-05',
});
const data = await gladys.gateway.enedisGetDailyConsumption({
  usage_point_id: '22516914714270',
  start: '2021-09-01',
  end: '2021-09-05',
});

Ces fonctions renvoient la même data que l’API Enedis.

1 Like

@bertrandda J’ai une 1ère version de l’API de prête pour toi !

Je t’ai envoyé en MP toutes les informations pour utiliser l’API :slight_smile:

Hésite pas à me répondre là bas si tu as des questions !

1 Like

Tu as été rapide !

Je regarde ça merci

1 Like