Just a comment and a call for volunteers… the Linky binding suffers of unstability because it parses the HTTP website endpoint, not the API, so it depends on parsing the presentation layer that changes frequently, and on some cookies for authentication that are not done for API calls. A non-sense for maintainability .
If a motivated developer wants to use the real API (endpoints that send raw data and where we authenticate in OAuth), it is here and some examples are here
+1, I would like to see a complete rewrite of this plugin.
We have two possible way to do this:
1/ As you mention, the DataConnect API from enedis is a possible way.
Using this API directly would require to register against Enedis to etablish a contract.
This registration is only available for business entity, or for association.
So if we want to go this way, we will need to creation A french law 1901 association, like they do for Home Assistant (Association HACF).
2/ Another possible way is to use the MyElectricalData gateway (https://www.myelectricaldata.fr/).
This gateway is a front end to Enedis Dataconnect API.
MyElectricalData is already registered against Enedis, so we wouldn’t need to register ourselves.
Pro and Cons of the solution:
Solution 1:
Direct solution connect to Enedis
Administration registration task to be done.
Solution 2:
Easier to start, no administrative task to be done.
Add an intermediate tiers between the plugin and Openhab.
If MyElectrical stop to work, will need to rewrite plugin to go to solution 1.
For me, solution 1 seems better.
What do you thing about it ?
I will check, but I’m not sure it will work.
Conso API is quite the same as MyElectricalData I was talking about yesterday.
"Enedis propose également des APIs, mais celles-ci ne sont ouvertes qu’aux entreprises ayant signé un contrat chez eux. Conso API fait donc office d’entreprise intermédiaire afin de vous donner accès aux API “Token V3” et “Metering Data V5” d’Enedis.
To get an authorization code against enedis, we will need to have a client_id / client_secret to do an OAuth2 request, and get the token. We will have this client_id / client_secret only if we register with enedis.
I hope you’re doing well. I see that you are the original contributor of the Linky addon.
We would like to rewrite it to use the official Enedis Dataconnect API instead of the private API that is currently in use in the addon.
This would have many benefits:
Authentification procedure will be more stable and far more easy for end user.
We will have more information available like 30mn consomptions, production informations, and also tempo day informations.
We’ve start discussion about what is the best way to do it (see above) :
- Directly from official Enedis Api.
or
- Using an intermediate API like :
Myelectricaldata (https://www.myelectricaldata.fr/)
ConsoApi (https://conso.boris.sh/).
As you’re the original contributors, I would like to have your advice, and also check if it’s ok for you if I start the modifcation to propose a pull request for this modifications.
@lo92fr : thanks for pinging me on this proposal that would be beneficial to the binding as currently the configuration elements are not really easy to gather, and as you said, is quite subject to brake (this already happened).
You’re more than welcome to propose such an evolution and I’ll do my best to help you with code reviews.
I do not have that much time for openHab currently, so I’m very happy to see this.
Sorry, I thought that Client id / secret was the one of boris.sh, and on his behalf, everyone Can get its own token. Then I thought this one was sufficient for enedis api calls, no need of the client / secret of Boris anymore. But you are right, Boris publishes his own api because the client / secret of the app id required for enedis api calls.
Too Bad… Once again, thingdms are done for monetizing and not for endusers…
.