[linky] Fixes for change in Enedis API on 2024 December 20 #17945

lo92fr · 2024-12-21T11:07:36Z

Fixes for Linky Enedis December web site change

This pull request is about fixing the linky addon after the change that was made on Enedis side to the Web Site.
This is linked to issue:
#17936

Description

Mainly, changes are :
- URL for data is now mes-mesures-prm and not mes-mesures.
- Dto format have changed : mainly merge data & date, field renaming, and moving.
- Some changes on date format.

lolodomo · 2024-12-21T11:30:10Z

Thank you @lo92fr , I will review and test.

lolodomo · 2024-12-21T11:37:15Z

I still have Java 17 and Java 21 on my dev PC so it should be easy to build a JAR for Java 17.
But in case I would have only Java 21, do you know what is the maven command to execute to build a JAR compatible with Java 17 / OH 4.3 ?
@holgerfriedrich I am sure you know ;)

holgerfriedrich · 2024-12-21T12:02:06Z

@lolodomo Hopefully it is just:

mvn install -Pj17 -Dohc.version=4.3.0

https://community.openhab.org/t/openhab-5-x-snapshot-requires-java-21/160890/5

lolodomo · 2024-12-21T12:29:36Z

@lo92fr : does not work for me => Error requesting 'https://alex.microapplications.enedis.fr/mes-mesures-prm/api/private/v1/personnes/xxxxx/prms/yyyyy/donnees-energetiques?mesuresTypeCode=ENERGIE&mesuresCorrigees=false&typeDonnees=CONS&dateDebut=2023-01-01': {"message":"Internal server error. Please try again","code":"INTERNAL_SERVER_ERROR"}

Will see if it work in next tries (next hours).

lo92fr · 2024-12-21T13:35:10Z

if it work in next tries (next

It still work on my side, strange.
Does the xxx in URL correctly formatted with something like MPSxxxYYY ?

Laurent.

lolodomo · 2024-12-21T13:50:29Z

Does the xxx in URL correctly formatted with something like MPSxxxYYY ?

3 letters then 3 numbers and then 3 letters.
Starts by N in my case.
If I correctly remember, it is the reference of my counter?

lo92fr · 2024-12-21T14:23:22Z

If it's still does not work, can you please:

check that you have the new version of the website. Look like this:
When you load the page, take a look on the browser debugger, new URL appears at the bottom of the list.
Is it the same and does it works correctly in your browser session ?

Thks,
Laurent.

lolodomo · 2024-12-21T16:53:32Z

Yes, I have the same page on their website.
The requests are similar, the binding request just has an additional parameter "dateDebut".
When I run in my browser session while I am logged to the website, the binding URL works well!

lolodomo · 2024-12-21T16:58:13Z

Now the binding is working! Even after I disconnect from the website in my browser.
Maybe you need to connect at least one time to the new website version ?

lolodomo · 2024-12-21T17:18:11Z

...hab.binding.linky/src/main/java/org/openhab/binding/linky/internal/handler/LinkyHandler.java

+                updateState(PEAK_TIMESTAMP, new DateTimeType(
+                        days.datas.get(days.datas.size() - 1).dateDebut.atZone(this.timeZoneProvider.getTimeZone())));


This was changed very recently, just before releasing 4.3. We don't need to pass a ZonedDateTipe; DateTimeType just needs an Instant as parameter. So you do not need TimeZoneProvider .

Hello @lolodomo,

I'm not sure to understant. Do you say to use the DateTimeType constructor that take an instant, something like this.
updateState(PEAK_TIMESTAMP,
new DateTimeType(days.datas.get(days.datas.size() - 1).dateDebut.toInstant(zoneOffset)));

The matter is that I still need to find a zoneOffset in this case.
The Enedis API return a LocalDateTime at offset of the current zone.
The DateTimeType if I undestand correctly want a universal time.

So somewhere we need to convert from local to universal using a timezone ?

Laurent.

@jlaur is our specialist with date. Please advice.

If days.datas.get(days.datas.size() - 1).dateDebut is a LocalDateTime, the implementation is already correct. If it is an Instant there is no need to convert to ZonedDateTime.

the implementation is already correct

@jlaur : you mean @lo92fr proposed code is correct ?
I am a little lost, why should we consider the timezone setup in server ?
Imagine that for a strange reason I setup timezone in OH server to UTC+5. I am convinced Enedis provides dates in France timezone, that is UTC+1.

Hello @jlaur,

No there is no way to configure the home location / time-zone in the eneids account.
I think this is a hidden fixed value that is link to your PDL (Point of Delivery) that is linked to your postal address.

So I think the best is to assume that the api just return a local Datetime, and that the openhab server is on the same timezone.

The only scenario I can see that can be bad is someone having two different house : let say one in France, and one in another timezone like Guadeloupe, and that at the same time will use only one openhab instance for the two house.
In this case, result can be wrong.

Laurent.

Couldn't the timezone be a configuration setting of the PDL thing ? Defaulted to France/Paris ?

Hello @clinique,

Yes, this a solution.
Like this we will be able to handle specific case.

Laurent.

Probably the default should then be openHAB time-zone rather than France/Paris, given what @lo92fr wrote about the service probably using time-zone of PDL. But since it's not documented or proven, I guess it doesn't matter much, as long as it can be overridden by configuration.

@clinique, @jlaur,

I've implements the config for timezone in this commit.
Let me know if it's ok for you.
4281d5e

Laurent.

lolodomo · 2024-12-25T11:15:44Z

The fix fails for me.
It worked just one time apparently because.i previously opened a session on the website but the next days it failed.

lolodomo · 2024-12-31T09:22:19Z

While I installed 4.3.1, I updated again the linky bundle and it seems to work well yesterday and also today!
So maybe in my previous test, I did not take care and the previous jar was reloaded...

jlaur

Minor comments related to the time-zone commit. The I18 properties file should also be regenerated.

...hab.binding.linky/src/main/java/org/openhab/binding/linky/internal/handler/LinkyHandler.java

bundles/org.openhab.binding.linky/src/main/resources/OH-INF/thing/thing-types.xml

lo92fr · 2025-01-15T11:06:30Z

Hello @jlaur, Hello @lolodomo,

Any news on this ?

Thanks,
Laurent. @

jlaur · 2025-01-15T11:18:45Z

Any news on this ?

My comments are resolved, but I have not reviewed this PR, so @lolodomo will be needed for finalizing the review and merging the PR.

lolodomo · 2025-01-15T12:09:15Z

The major problem is that unfortunately this fix does not work well !
It can work one day after a fresh OH install and then does not work anymore. This is probably a problem of cookie or similar.
I remember that we had exactly the same issue with the previous fix ... until @lo92fr fixed something more.

Am I alone with this PR not working more than one day ?

lo92fr · 2025-01-15T16:37:47Z

The major problem is that unfortunately this fix does not work well ! It can work one day after a fresh OH install and then does not work anymore. This is probably a problem of cookie or similar. I remember that we had exactly the same issue with the previous fix ... until @lo92fr fixed something more.

Am I alone with this PR not working more than one day ?

Have to said that I'm not totally sure myself if the fix is ok or not.
I'm working on my production server with the linkyv2 branch, and have disconnection every 24 hours.
I was thinking it was because of the workflow change that i've maded on linkyv2 branch (linky v2 keep the connection opened, but main branch disconnect / reconnect at every 24 hours refresh), but finally perhaps not.

@lolodomo : what error do you have after one day, an http 500 Internal Error ?
Anything in the log ?

What I try so far if to make the refresh more frequent, I see that if I change the refresh frequence from 24h to 3h, I can trigger the error as weel after only 3 hours.

I've also try in this case to clear all cookie, and redo the connectionInit phase, but this don't seem sufficient to fix the error.
But in v2, when I hit the error, If i stop the thing, and restart it, the connection restart to work correctly.

So I thing there is something that expire after some session time, and stay in memory, and that is not reinitialized correctly.

I will continue to narrow done this issue in the next few days, and will tell you if I find something.

Laurent.

lolodomo · 2025-01-16T07:08:03Z

what error do you have after one day, an http 500 Internal Error ?

{"message":"Internal server error. Please try again","code":"INTERNAL_SERVER_ERROR"}

lo92fr · 2025-01-26T08:40:36Z

what error do you have after one day, an http 500 Internal Error ?

{"message":"Internal server error. Please try again","code":"INTERNAL_SERVER_ERROR"}

Hello all, @lolodomo

Perhaps find a fix on this new error.
It seems that we need to call the getPrmInfo each time we update the data.
Today, we only do it when initializing the handler.

My assomption is that the new website implementation keep some state data, and invalidate them after a few hours.
This state data is certainly initialize when we call this getPrmInfo endpoint.

I've doned some test on v2 branch, seems to fix the problems on my side.
Will need to be tested also on this fix branch to be sure.

Laurent.

lolodomo · 2025-02-01T17:48:54Z

@lo92fr : can you please rebase your branch so that we can compile it again ?

- URL for data is now mes-mesures-prm and not mes-mesures. - Dto format have changed : mainly merge data & date, field renaming, and moving. - Some changes on date format. Signed-off-by: Laurent ARNAL <[email protected]>

Signed-off-by: Laurent ARNAL <[email protected]>

lo92fr · 2025-02-02T13:22:26Z

do it when initializing the handler.

My assomption

Helo @lolodomo,

Done the rebasing just right now.
But note that my fix from last week is not sufficient to totally fix our issues.
I've done some more modifications on the linkyv2 branch that seems to be promising.
I will try to backport them to fix branch this afternoon, or somewhere laster this week if I don't find time today.

Laurent.

lolodomo · 2025-02-02T13:50:22Z

I just build and deploy the last jar and yes you're right, it still does not work, always the same internal server error.

lo92fr requested review from clinique and lolodomo as code owners December 21, 2024 11:07

lo92fr mentioned this pull request Dec 21, 2024

New version of Enedis website, #17936

Open

wborn linked an issue Dec 21, 2024 that may be closed by this pull request

New version of Enedis website, #17936

Open

jlaur changed the title ~~Linky : Fixes for change in Enedis API on 2024 December 20 !~~ [linky] Fixes for change in Enedis API on 2024 December 20 Dec 21, 2024

lolodomo added the bug An unexpected problem or unintended behavior of an add-on label Dec 21, 2024

lolodomo reviewed Dec 21, 2024

View reviewed changes

jlaur reviewed Jan 8, 2025

View reviewed changes

clinique approved these changes Jan 8, 2025

View reviewed changes

lo92fr added 3 commits February 2, 2025 14:13

fixes for change in Enedis API on 2024 December 20 !

f21e715

- URL for data is now mes-mesures-prm and not mes-mesures. - Dto format have changed : mainly merge data & date, field renaming, and moving. - Some changes on date format. Signed-off-by: Laurent ARNAL <[email protected]>

add timezone to thing config to allow overriding default timezone

2dc10c3

Signed-off-by: Laurent ARNAL <[email protected]>

spotless:apply

45c1e3c

Signed-off-by: Laurent ARNAL <[email protected]>

lo92fr added 2 commits February 2, 2025 14:13

fixes for Jacob review

b26ba9a

Signed-off-by: Laurent ARNAL <[email protected]>

add possible fix for 500 Internal Server Error

f1dba4f

Signed-off-by: Laurent ARNAL <[email protected]>

lo92fr force-pushed the linky-fix-202412 branch from cd8015d to f1dba4f Compare February 2, 2025 13:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[linky] Fixes for change in Enedis API on 2024 December 20 #17945

[linky] Fixes for change in Enedis API on 2024 December 20 #17945

lo92fr commented Dec 21, 2024

lolodomo commented Dec 21, 2024

lolodomo commented Dec 21, 2024

holgerfriedrich commented Dec 21, 2024

lolodomo commented Dec 21, 2024

lo92fr commented Dec 21, 2024

lolodomo commented Dec 21, 2024 •

edited

Loading

lo92fr commented Dec 21, 2024

lolodomo commented Dec 21, 2024 •

edited

Loading

lolodomo commented Dec 21, 2024

lolodomo Dec 21, 2024

lo92fr Dec 25, 2024

lolodomo Dec 25, 2024

jlaur Dec 25, 2024

lolodomo Dec 31, 2024

lo92fr Jan 8, 2025

clinique Jan 8, 2025

lo92fr Jan 8, 2025

jlaur Jan 8, 2025

lo92fr Jan 8, 2025

lolodomo commented Dec 25, 2024

lolodomo commented Dec 31, 2024

jlaur left a comment

lo92fr commented Jan 15, 2025

jlaur commented Jan 15, 2025

lolodomo commented Jan 15, 2025

lo92fr commented Jan 15, 2025

lolodomo commented Jan 16, 2025

lo92fr commented Jan 26, 2025

lolodomo commented Feb 1, 2025

lo92fr commented Feb 2, 2025

lolodomo commented Feb 2, 2025

		updateState(PEAK_TIMESTAMP, new DateTimeType(
		days.datas.get(days.datas.size() - 1).dateDebut.atZone(this.timeZoneProvider.getTimeZone())));

[linky] Fixes for change in Enedis API on 2024 December 20 #17945

Are you sure you want to change the base?

[linky] Fixes for change in Enedis API on 2024 December 20 #17945

Conversation

lo92fr commented Dec 21, 2024

Fixes for Linky Enedis December web site change

Description

lolodomo commented Dec 21, 2024

lolodomo commented Dec 21, 2024

holgerfriedrich commented Dec 21, 2024

lolodomo commented Dec 21, 2024

lo92fr commented Dec 21, 2024

lolodomo commented Dec 21, 2024 • edited Loading

lo92fr commented Dec 21, 2024

lolodomo commented Dec 21, 2024 • edited Loading

lolodomo commented Dec 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lolodomo commented Dec 25, 2024

lolodomo commented Dec 31, 2024

jlaur left a comment

Choose a reason for hiding this comment

lo92fr commented Jan 15, 2025

jlaur commented Jan 15, 2025

lolodomo commented Jan 15, 2025

lo92fr commented Jan 15, 2025

lolodomo commented Jan 16, 2025

lo92fr commented Jan 26, 2025

lolodomo commented Feb 1, 2025

lo92fr commented Feb 2, 2025

lolodomo commented Feb 2, 2025

lolodomo commented Dec 21, 2024 •

edited

Loading

lolodomo commented Dec 21, 2024 •

edited

Loading