Peaqev can't stop charger

[kirilldem]

Hello,

For the second night in a row peaqev has broken my peak - it seems that it can't stop my easee charger for some reason. Could the fallback be to instead request the lowest amps available when this happens.

I am on the latest HA, peaqev integration and latest easee integration.

Here is the error message, please let me know if I can provide some more info.

This error originated from a custom integration.

Logger: custom_components.peaqev.peaqservice.util.extensionmethods
Source: custom_components/peaqev/peaqservice/util/extensionmethods.py:28
integration: peaqev ev-charging (documentation, issues)
First occurred: August 25, 2024 at 2:58:51 PM (7 occurrences)
Last logged: 2:59:45 AM

Fail when trying to stop connected charger. Retrying stop-attempt...

[kirilldem]

It doesn't seem to take advantage of the higher peak either :)

[elden1337]

Looks like it either eventually stopped or your are charging very very low?
My assumption is unfortunately that there was fuzz with the easee api, since the gothenburg model would otherwise allow that very peak for the rest of the day (and by that i mean that i dont think it could change amps either).

Or, if easee has made changes perhaps? Its happened before but i dont have one so i dont keep up to date there without being prompted.

[kirilldem]

I think there is some sort of a problem - I had similar in July too. It was able to control the charger later on:

I have also noticed that peaqev doesn't always take advantage of the Gothenburg peak model (more often not than using the day peak).

There were no issues reported with easee APIs https://status.easee.com/

Can I provide better logs?

[elden1337]

If you havent rebooted since i would like the full logs for peaqev from the night.

The "unable to stop charger" should just keep trying, i also get that sometimes if chargeamps api is not fast enough.

The thing with interim day peak foe gothenburg model should work, but in this case it looks off yes. Question is if it managed to raise it in the earlier attempts of the hour after the peak breach, cos very late in the hour increasing is not allwed anyway since the risk of breach is too high.

I still think it sounds like a non response from easee cloud, but let's see the log to see what my code has done during.

[elden1337]

for ref this test is passing (and has been since way back) and is checking that increased peaks for Gothenburg are making them allowed during the same day. https://github.com/elden1337/peaqev-core/blob/aa9033e3562974d36e40fc0d34cb241045cb0406/peaqevcore/tests/test_localetypes.py#L428

So for that part to not be an issue with cloud calling i will require more cases or logs.

[elden1337]

did a few changes, mostly pedagogical to not log that directly which I did for some reason. But I also changed now so that if one attempt has been made and it is more than 20s since it will log. i also swapped order of calling the charger for pause and checking this, plus added a clause that if there was an unsuccessful attempt it did not have to wait 60s before calling charger again .

I want to have this running here for a bit since it's a core part functionality and can seriously screw things, but if there has been no cloud issue and we cannot prove that this could potentially make it more solid.

[kirilldem]

Sadly nothing else in the logs. I think peaqev was on debug already:

  logs:
    custom_components.peaqev: debug

Here is what my usage used for the last couple of days

[elden1337]

Not supposed to be closed. Bad commit msg