401 Unauthorized error

[MalcolmSpencer]

Problem
I am intermittently (4-6 times a day) getting an error 'Error fetching myenergi data:' turning on debug it seems to be coming from the call
GET /api/AccountAccess/LibbiMode?serialNo=xxxxxx https://myaccount.myenergi.com/api/AccountAccess/LibbiMode?serialNo=xxxxxx

I am not sure but could this be a Token Expiration problem?
Is anyone else seeing this?

Configuration
Installation method
Home Assistant OS Core 2026.3.3
Supervisor 2026.03.2
Operating System 17.1
Frontend 20260312.0
My Energi Version 0.2.0

Debug Logs
2026-03-23 16:09:44.621 DEBUG (MainThread) [custom_components.myenergi] Refresh history local start of day in UTC 2026-03-23 00:00:00+00:00 UTC
2026-03-23 16:09:44.624 DEBUG (MainThread) [pymyenergi.client] Refreshing data for all myenergi devices
2026-03-23 16:09:44.624 DEBUG (MainThread) [pymyenergi.connection] GET /cgi-jstatus-* https://s18.myenergi.net/cgi-jstatus-*
2026-03-23 16:09:45.082 INFO (MainThread) [httpx] HTTP Request: GET https://s18.myenergi.net/cgi-jstatus-* "HTTP/1.1 200 OK"
2026-03-23 16:09:45.085 DEBUG (MainThread) [pymyenergi.connection] GET status 200
2026-03-23 16:09:45.086 DEBUG (MainThread) [pymyenergi.client] Updating eddi eddi-xxxxxx
2026-03-23 16:09:45.087 DEBUG (MainThread) [pymyenergi.client] Updating libbi libbi-xxxxx
2026-03-23 16:09:45.087 DEBUG (MainThread) [pymyenergi.connection] GET /api/AccountAccess/LibbiMode?serialNo=xxxxxx https://myaccount.myenergi.com/api/AccountAccess/LibbiMode?serialNo=xxxxxx
2026-03-23 16:09:45.224 INFO (MainThread) [httpx] HTTP Request: GET https://myaccount.myenergi.com/api/AccountAccess/LibbiMode?serialNo=xxxxx "HTTP/1.1 401 Unauthorized"
2026-03-23 16:09:45.227 DEBUG (MainThread) [pymyenergi.connection] GET status 401
2026-03-23 16:09:45.227 DEBUG (MainThread) [custom_components.myenergi]
2026-03-23 16:09:45.228 ERROR (MainThread) [custom_components.myenergi] Error fetching myenergi data:
2026-03-23 16:09:45.228 DEBUG (MainThread) [custom_components.myenergi] Full error:
Traceback (most recent call last):
File "/config/custom_components/myenergi/init.py", line 110, in _async_update_data
await self.client.refresh()
File "/usr/local/lib/python3.14/site-packages/pymyenergi/client.py", line 266, in refresh
await existing_device.refresh_extra()
File "/usr/local/lib/python3.14/site-packages/pymyenergi/libbi.py", line 102, in refresh_extra
chargeFromGrid = await self._connection.get(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<2 lines>...
)
^
File "/usr/local/lib/python3.14/site-packages/pymyenergi/connection.py", line 161, in get
return await self.send("GET", url, data, oauth)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/pymyenergi/connection.py", line 110, in send
raise WrongCredentials()
pymyenergi.exceptions.WrongCredentials
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 426, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/myenergi/init.py", line 114, in _async_update_data
raise UpdateFailed() from exception
homeassistant.helpers.update_coordinator.UpdateFailed
2026-03-23 16:09:45.244 DEBUG (MainThread) [custom_components.myenergi] Finished fetching myenergi data in 0.623 seconds (success: False)

[G6EJD]

This is not an issue with the integration.

The error occurs when an attempt to access a Libbi is being made - do you have a Libbi?

There are many instances of phantom devices appearing in MyEnergi systems so its existence needs to be established?

If you do have a Libbi, then is this a new or existing installation that is now exhibiting this error?

What has changed?

[MalcolmSpencer]

Yes I have a Libbi and I have been getting these errors since the integration was enhanced to use the email and password to access the libbi grid charging functions, etc. The error causes the Libbi entities to become 'unavailable' for a period of time.
This was originally discussed under CJNE/ha-myenergi#576 but i have now tracked down the specific error in the debug logs

[G6EJD]

The question has to be asked - why aren't others reporting an error on accessing data? You appear to be the only one.

In situations like this it nearly almost always points to a local
problem, either your system's inability to reliably get access to the servers; a setup issue with the Libbi; an issue with HA implementation of your automations.

You could run a simple Python access test on the Libbi data, to see if it responds to the API key or password or both.

As the python runs through the access attempts it clearly stops at the Libbi stage. So the question must be what are MyEnergi using to access API data for the Libbi and why would they choose a password instead of the common API key method.

'Someone' is going to have to do the research on this topic to find out what the correct API call is and what authentication is required and in what form.

[MalcolmSpencer]

As mentioned this is an intermittent error, yesterday (23/3) the entities went unavailable 3 times and today 5 times so far. They usually recover to the correct value on the next poll which is minute later. You don't notice this unless you have an automation using the entities and even then you can code the automation to ignore an 'unavailable' value. It was mentioned as having been seen by others in the #576 discussion.

I'll do some more digging and happy investigate. I work in the IT industry but i am not a software engineer so might need some guidance.

[G6EJD]

What is your update rate?

You will probably be aware that MyEnergi has changed its access rate to be a much slower; although unknown rate, and although others have asked, no definitive answer has been provided.

The consensus seems to be every 5-mins to avoid access errors, which won't be a problem for anyone really.

I suggest you slow your access rate down to see if this change is part of your problem.

[MalcolmSpencer]

As mentioned i am not a SW developer but after investigating and with a lot of help from AI the suggestion is that Oauth token is expiring. The reason seems to be that the code to check and refresh the token has been defined in connection.py, row 75

def checkAndUpdateToken(self):
    # check if we have oauth credentials
    if self.app_email and self.app_password:
        # check if we have to renew out token
        self.oauth.check_token()
        self.oauth_headers = {"Authorization": f"Bearer {self.oauth.access_token}"}

However as far as i can see this is never called and therefore the token will expire, and the next update will fail. Once this happens the next update will get a new token and normal updates will occur again until the next time the token expires. The suggestion is that checkAndUpdateToken needs to be called just before the API is accessed at about row 87

async def send(self, method, url, json=None, oauth=False):
    # Use OAuth for myaccount.myenergi.com
    if oauth:
        # check if we have oauth credentials
        if self.app_email and self.app_password:
            
            # --- INSERT THE FIX HERE ---
            self.checkAndUpdateToken()
            # ---------------------------

            theUrl = self.oauth_base_url + url

The logic seems sound to me from my understanding of the code but sorry if this is completely wrong.

@trizmark I think you created this change so you probably understand it best.

[G6EJD]

Yes, I agree this is exactly why the MyEnergi server is rejecting the Libbi request, and the sequencing of the error occurring supports that too.

So the Digest authentication expiration is set by the MyEnergi server, but we don't know for how long it is valid. But we know when the Nonce expires the server will return a 401 Unauthorised status, albeit with stale=true, so a browser can re-initiate with new credentials to get a new nonce, usually without prompting the user.

However, with the way the server is called now that stale=true will be missed.

The solution seems to be to separate the Libbi call to be in effect an independent process and not relying on the Nonce lifetime.

I have studied the Libbi request or the volume of data returned, but the solution could be as simple as to refine the Libbi request code to remove any undo delays and restructure any processing within the calling code that is extending the time inside of the nonce lifetime.

Over to the author of the Libbi access code.

I also note there has been a recent change by MyEnergi to their access requirements such as rate limiting, so this could be part of any changes that are now becoming apparent.

[trizmark]

While the LLM is correct and that part of the code is not called, if it was down to the access token, the you wouldn't be able to recover from the issue without reloading the integration.
I have an old dev instance of HA with ha-myenergi running for nearly 12 months and it's still happily fetching the libbi data every minute without any issues.
If the issue were down to rate limiting, then the error would be 429 rather than 401.

I'll submit a PR to include the check token in the send, but as it stands that's not the root cause of your issue.

[G6EJD]

What happened to the change of credentials from API key to password, or vice-versa for the Libbi access, is that a factor?

[trizmark]

Some API endpoints are accessible via API key/secret (old auth method). This info is static and does not change from session to session.
Some endpoints (some libbi-related ones and stuff to do with site/energy plan config) use app email/password to get an access token via OAuth. During connection there's a bearer token generated using the email/password. Still looking at this, but based on AWS Cognito docs, the default validity for the token is 30 days.

If the issue would be with the token expiry (and the lack of refresh) then it would impact everybody and you would not be able to get any data without reloading the integration.

I'll prep a PR later to fix the missing refresh, but I don't believe that's the source of the issue.