API status code sensor stuck at "Internal Server Error"

[olalid]

Now and then I see the API status code sensor displaying status "Internal Server Error".
The other sensors seem to keep updating in this state, so it sort of seems like it is only the API status code sensor that is affected.
Restarting the integration removes the problem usually.
Not sure what to look for in the log files, but if you have any ideas what to search for...

[leeyuentuen]

i saw this issue also recently, but need to find the reason why (maybe 2fa issue or bad mobile signal)
but the quick fix could be temp use this this automation from 3shirts
#110 (comment)

[olalid]

I think changing this line from BASE_URL to BASE_URL_V2 might fix it:

self._set_latest_call_code(BASE_URL, 500)

[leeyuentuen]

I think changing this line from BASE_URL to BASE_URL_V2 might fix it:

self._set_latest_call_code(BASE_URL, 500)

you should be right. because the 2 api calls has been changed to v2

can you open a MR? then i can merge them to dev to test

[olalid]

I have ran my fix over night without seeing the internal server error, so looks promising.

#124

[olalid]

Well, it was not enough, there is one more place that needs to be fixed:

#125

[olalid]

@leeyuentuen what is your idea about the separate lastest_call_code (i.e. lastest_call_code and lastest_call_code_2).
Is that necessary to keep like that? Could we store the call code in the same place independent of the version of API called?

The current setup makes fixing this completely very complex since we do not know if a v1 or v2 API caused the error in the component code, so I would have to somehow convey that information over.
My fixes above seems to mostly just decrease the likelihood of the the internal server error getting stuck, so would be good to make a bigger effort to fix it completely...

[leeyuentuen]

@leeyuentuen what is your idea about the separate lastest_call_code (i.e. lastest_call_code and lastest_call_code_2). Is that necessary to keep like that? Could we store the call code in the same place independent of the version of API called?

The current setup makes fixing this completely very complex since we do not know if a v1 or v2 API caused the error in the component code, so I would have to somehow convey that information over. My fixes above seems to mostly just decrease the likelihood of the the internal server error getting stuck, so would be good to make a bigger effort to fix it completely...

the idea of v1 en v2 is that there are 2 different api call.
the one is for the authentication and basic car information. the v2 is getting the battery and odo meter data

normally if v1 failed, then the authentication also failed, so the v2 will also failed.

but if only v2 failed, the v1 should keep working

fyi: the statuscode is just an information. it doesn't changes the other entities value, just only know the the other entity is getting information

[leeyuentuen]

i'm not sure, but the more issue with the api, could be related with 2FA of polestar.

[olalid]

I think what we are seeing is just random fails due to server being too busy or packet loss or whatever.
And if the fail happens during a V1 call then it potentially sticks for a very long time since it is not called very often and therefore not cleared with a new V1 call code.

But again, do you feel it is important to keep the call codes separate?
I.e. would a pull request where I consolidate so that the call code is stored in the same place for both API versions be rejected?

[leeyuentuen]

i use that call code more for debugging and see if there are issue due make that call.

you can always created a MR and if improve it could always been merged

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.