As view last week with Gael (@glhopital), this is a rewrite of the linky binding that use the official DataConnect Enedis API.
The use of this API will provide simpler authentification for the end user, as well as new functionnality like more granular data.
Description
This new binding version should offer right now the same functionnality that the old one.
Please note that we don’t use directly the Enedis API because of legal registration issue, but the myelectricaldata API which is a mirror gateway to the official API.
This is WIP, will need on my side :
To fix compilation warning and code violation.
Do more in depth testing.
Would like to add more functionnality like :
New channel to expose Tarification, tempo Day,
Expose more granular data provide by this new API.
Importing historical value to persistance to enable graphing.
Add documentation on change between the old/new binding.
The evolution of linky binding was discuss as said with Gael in the following thread:
I’m afraid using myelectricaldata won’t be scalable (I mean considering all the openhab users and all the myelectricaldata users), just because of Enedis that won’t allow such proxies :
Enedis limite à 5 appels par seconde et vous n’êtes pas seul à vouloir utiliser mes services !
5 calls per second for the whole myelectricaldata service !
For more scalability, I suggest to make configuration items in this plugin in order to have the end user able
to change the URL root of the API (i.e. not to need a plugin version for changing from myelectricaldata provide to another one)
to add optional custom client & secret IDs
It means letting people having their own local association registered to enedis use the plugin directly with enedis. Having a local association is not complicated to register (we all now local associations of 20 or 50 members) and this will be the only scalable method to bypass the enedis limitation of 5 calls per second per registered clientID (so per association)
If client and secret IDs are not filled : the binding will assume that the proxy service does not require it (just like myelectricaldata does, injecting its own on the server side before calling enedis API). If client and secret IDS are filled : the request can be directly addressed to the enedis API.
Such a design would allow more flexibility of the plugin to adapt to new proxy service creators (as soon as they just mimic the enedis API) and to spread the global load that would increase too quickly if we only bet on myelectricaldata, and would make myelectricaldata owner himself unconfortable and limiting his service.
