EDIT (Pierre-Gilles): The Enedis-Linky integration is available!
Documentation:
9 Likes
Hello @bertrandda! Great development 
Regarding the gateway, I’m a bit wary of using a third-party company for this kind of development:
- What guarantees that this platform will remain sustainable over time? In case of downtime/API updates, what guarantees that the dev will invest time to maintain this platform?
- In terms of data security, sure the site says nothing is stored, but still it’s up to us to trust them!
- Enedis’ API has a rate limit per company that is quite low. The fact that nothing goes through the server (and that the client can do whatever it wants, which seems borderline to me!) means we can’t implement request queuing. I think pretty quickly we’ll have sync issues with 429 errors…
- I find it quite strange security-wise that tokens are given to the client; on other gateways I’ve seen (https://enedisgateway.tech is another example), the gateway acts as a relay and does not give Enedis tokens to the client. That notably allows rate limiting and queuing requests in case of heavy traffic.
Ideally, I’d rather use the project’s legal structure and route this through Gladys Plus, it would make more sense and be more sustainable ^^
We already talked about it:
Afterwards, for this it will be available via Gladys Plus, so paid… I don’t want this to be seen as a coup aha ^^ But well, these free platforms worry me a bit, we have no guarantees and we want this service to be available for the next 10 years.
What do you think?
1 Like
Regarding the choice of this npm module and this gateway, I chose this approach because it seemed convenient to me; it’s really the implementation of Enedis’s API. Of course, if Enedis modifies its API we will need to propagate those changes on the JS module side, but even if we develop our own gateway, whether we use this module or not a change will have to be made somewhere, and we can make the modification ourselves on the module side — it’s not very complicated. Passing the secrets to the user specifically avoids having to go through a third-party gateway for each Enedis API call (and therefore avoids routing users’ data through a third-party service). Once you have your tokens, Gladys queries Enedis directly; even if the gateway is removed/stops working the integration will continue to function for those who have already configured it.
But I understand the usefulness of having a buffer server to reduce errors; I don’t think it’s a real problem today (I checked — the limit is 5 req/s), and on our side if we get an error it retries fetching the data 30 minutes later (we already have half a day’s delay on the data because of Enedis’s API, so waiting a few more minutes shouldn’t be too impactful). If that’s the only issue, I can route through enedisgateway.tech
More broadly about this Enedis-Linky integration and Gladys Plus, I’m totally in favor of adding services that can complement the G+ offering; that’s what makes — and will keep — the project alive in the long term. While for Alexa, Google, Owntrack… routing through G+ is necessary because a public URL is needed since the external service initiates the connection, here it’s something that runs locally for each user. I’m even ready to develop something additional on the G+ side with an Enedis contract specific to the Gladys structure for more stability for G+ users, but it’s true that I saw this integration as a new incentive to attract basic users (which will inevitably convert some to Gladys Plus users). It’s the kind of module you can configure without any additional purchases, like weather, calendar, Telegram… for someone who wants to try Gladys for a few weeks it can only be beneficial.
We can discuss it again; I don’t think this is an integration that needs to be rushed out. Also let’s see what the others think.
4 Likes
Actually I’m not sure that’s good practice! These tokens are intended to be used by the partner company, not the end user, right?
For the commercial side, I’m open! It can be outside of Gladys Plus, it can be a separate option, anything is possible
Let me reply to this topic, don’t be mad at me 
In that case (if I’m following
Actually I think it’s more like the « terms of use » of the Enedis API, which are intended for businesses only.
1 Like
Yeah yeah I got it
I’m leaving xD
@bertrandda if I’m not mistaken the tokens are valid for 1 year. Have you got a response from the API with the expiration date?
Indeed I second @VonOx, for the weather integration the user creates their account themselves and is in direct relation with OpenWeather
In the case of the Enedis API, you need a corporate service provider who signs a contract with Enedis (that’s a request from Enedis; honestly it would be simpler if it were like OpenWeather!)
I’m not certain (to be checked) that the tokens are intended for the end user, for reasons 1) IT security 2) contractual
By way of comparison, in my opinion the integration with Enedis is much closer to the Alexa/Google Home integration than to the OpenWeather integration, and on the Google Home/Alexa side the end user does not have access to the tokens — that would be bad
1 Like
Indeed I probably should have studied the Enedis API a bit more; we’re not supposed to access the data directly.
I think I’ll try at first to go through the enedisgateway.tech gateway since it’s already in place. I’ll try to do that in a « modular » way — we might be able to change the gateway dynamically depending on whether the user is subscribed to G+ or not. Maybe even switch solely to the G+ gateway if we feel the enedisgateway.tech gateway doesn’t hold up. What do you think, would that be better?
In principle I’d be more in favor of going through Gladys Plus, which is a trusted intermediary for Gladys users, and above all I’m a bit worried about the rate limit that the partner imposes at 5 requests/second globally per application (all clients combined).
Commercially, on the one hand I don’t want to provide a feature that’s « paid-only », but on the other hand, wouldn’t offering the enedisgateway.tech « free » gateway in addition to Gladys Plus (I’m putting that in quotes because ultimately enedisgateway.tech also asks for donations to support infrastructure costs) be shooting ourselves in the foot for the adoption of Gladys Plus, given that I’m already struggling to be profitable 
On my side I can provide Enedis API routes on Gladys Plus fairly quickly if you want, it’s OAuth, it’s not a huge integration
Well, it’s moving very quickly, I’ve already received a response from Enedis, they need additional information but I already have a first version of the API contract
On my side I’ve tested the API in the sandbox, and I’ve started implementing routes on the Gladys Plus side to handle authentication (that was quick)
2 Likes
Ok, good news, I’ll let you tell me when you have a first version of the routes in question on the Gladys Plus side, so I can change the data retrieval on the integration side.
Will there be a Gladys Plus test environment? A preprod or something else, or should I also run G+ locally?
Yes! I’ll continue working on it today, it should go pretty quickly I think
No, since I’m working alone on Gladys Plus I work entirely locally
As soon as the feature is finished and well tested, I’ll deploy it to the production environment, and I’ll give you all the information to access it.
I can already give you the format of the API responses, because it will match the Enedis format (I’m just a passthrough, I don’t change anything)
Already the routes available on the Enedis side that I will provide:
Example of parameters/responses for the route /v4/metering_data/consumption_load_curve:
Query:
{
usage_point_id: 16401220101758,
start: '2022-08-01',
end: '2022-08-03',
}
Response:
{
"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"
}
]
}
}
But I imagine you already did this with the current integration, so you won’t have much to change on that, right?
I worked well today, I finished most of the backend routes on the Gladys Plus side.
Authentication on the Gladys Plus side works well:
(This is a first proof of concept (PoC), I will improve)
On the Gladys side, in your Enedis integration it will be super simple, you’ll have access to JS functions that will return the data to you, for now I’ve coded 3 functions:
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',
});
These functions return the same data as the Enedis API.
1 Like
@bertrandda I have a first version of the API ready for you!
I’ve sent you all the information to use the API in a DM
Don’t hesitate to reply there if you have any questions!
1 Like
You were quick !
I’ll take a look, thanks
1 Like
Hi everyone! Ultimately I’m the one moving this forward, and I’d like to present my various thoughts.
The connection/data retrieval part in Gladys is almost working, and I’d like to start in parallel the thinking about how to display this data in the interface.
Here are some mockups.
Connection with the Enedis API
Display of the different detected meters, and contract/tariff declaration
Dashboard display
I think it’s interesting to have boxes on the dashboard dedicated to electricity consumption so we can allow extensive customization on this topic.
I’m specifically thinking about calculating the cost of consumed electricity, computed from the data provided by the meters:
What do you think of this idea?
Is there any information missing?
3 Likes