How often does this plugin query the polestar API?

[nthbooth]

I am assuming.that there is a cost on power usage on the polestar each time you query the API (as I assume it will wake up the polestar to get the latest data). Has anyone seen any impact on this and how often does it query?

Is there a way to reduce the query frequency to maybe once an hour or something like that?

Nick

[leeyuentuen]

not sure

i think the polestar keep sending data to the server.
i'm only getting the data from the server and not from the car directly i think (correct me if i'm wrong)

[loebse]

My guess is that it does not affect the car. I am using the integration since the beginning and cannot see any difference. Also, there is no update of the data when the car is locked for e.g. several days.

Most likely the car will send updates to the polestar servers and then the integration polls the polestar servers but there is no connection from the servers to the car to wake it up.

[nthbooth]

I have a bad feeling they it queues the car everyone you query the API. Why do I think this Things like position and battery, location and locked I have entered the app it has loaded and given one reading a couple of times it has provided the wrong information before on the next refresh providing the correct up-to-date information. Hence having a way to reduce the frequency that (probably manual input with a sensible default as everyone's use case will be different) might be worth while. Also from an use point of view if we are hitting it too often then polestar is more likely to put up captures or similar things. So if a default was 15 minutes for the majority of people that may be often enough. Anyway just my thoughts. As a side note: On the other car I have I have had to remove the integration as I can see the battery going down thanks to the API usage (it has a much smaller battery hence is noticeable)

…

On Wed, 27 Dec 2023, 22:39 Tuen Lee, ***@***.***> wrote: not sure i think the polestar keep sending data to the server. i'm only getting the data from the server and not from the car directly i think (correct me if i'm wrong) — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBFDR4BZASYLH26R5WZXC3YLSPR5AVCNFSM6AAAAABBER5GRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGY3TAMJVGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dgomes]

I agree with @nthbooth we have seen this happen with the BMW API, it now limits calls to 1/hour to avoid running into their API limits that were put in place meanwhile. Lets try to avoid polestar blocking the API altogether ....

[loebse]

Well, we don't know what we don't know.

As the API is not officially supported by Polestar nor documented, they can basically decide whenever they want to shut it down. Is it more likely that they do not shut it down if we query less frequently? Maybe yes, maybe no...

I would disagree with @nthbooth when it comes to querying the car itself. The app is definitely using a different API than the one we are using here. When you use the app, you can also send commands to the car (lock, unlock, start climate, etc.) which is not possible with this API that is also being used by the polestar.com website.

When you use the app (iOS or Android), it always takes multiple seconds to make any request because (I guess) it is actually waking up the car itself. When you use this API here it is a GraphQL query that returns instant results from the Polestar servers.

• Is there a risk that Polestar will shutdown this API (again, like the previous one)? Yes.
• Is there a risk that you empty the battery of your car? Probably not.
• Is it still a good idea to make the polling interval configurable? Probably yes.

[dgomes]

let me clear out my answer:

• I agree with @nthbooth about not querying the API too often
• I really don't think the API we are using queries the car, we are most likely querying a "Digital Twin" of the car, and therefore has no impact in the battery or data communication.

[leeyuentuen]

let me clear out my answer:

• I agree with @nthbooth about not querying the API too often
• I really don't think the API we are using queries the car, we are most likely querying a "Digital Twin" of the car, and therefore has no impact in the battery or data communication.

i'm maybe think something like: if the car is not moving update every 5min. otherwise update every 15sec

[nthbooth]

I think the MVP here would be to make it configurable. I would probably set it at an hour for example, as I don't feel I need more granularity. And I don't see a use case for me to have it ever more than once every 15 minutes. (again to be clear this is my use case others may have other use cases.)

I would also like to know if you need to query it every 15 seconds. What is the use case for that level of granulation on the querying? It would also be useful to add some randomisation into it as well in the query period to ensure we don't end up doing a DDOS against the API with all the home assistance instances hitting the Polestar API at the same moment every 15 seconds.. (this is something I have seen multiple times before)..

[jkkataja]

When the car is moving a more granular does make sense, especially if we start getting coordinates (haven't installed this addon yet and the picture did not include GPS coordinates) to add car and have it move around map in HA. Also, when the car is charging more frequent update is nice.

Nissan Leaf integration (https://www.home-assistant.io/integrations/nissan_leaf/) has 3 different levels, might be a good idea to borrow the idea and adjust accordingly:

update_interval time (optional, default: 1 hour)
The interval between updates if the climate control is off and the car is not charging. Set in any time unit (e.g., minutes, hours, days!). Providing a low interval will cause the service to refresh more frequently and can negatively impact your 12V battery.

update_interval_charging time (optional, default: 15)
The interval in minutes between updates if charging.

update_interval_climate time (optional, default: 5)
The interval in minutes between updates if climate control on.

[loebse]

Providing a low interval will cause the service to refresh more frequently and can negatively impact your 12V battery.

Again, there is no evidence atm that this GraphQL query is affecting the car itself in any shape or form. I am using the API with the high frequency for quite a while now and it does not have any effect on the 12V battery as using the API only queries the polestar servers but not the car.

However, making the interval configurable will allow everyone to use the integration as personally required.

[jkkataja]

It’s from the Leaf integration from where I copy&pasted the interval examples from. I figured the context made it clear that it is referring the Leaf integration and not this one. But if there was any uncertainty it’s good that you elaborated that.

[dgomes]

If this integration is to make it into HA core, update_interval must be fixed and sensible (not too often), so any "smart updates" should be left out to automations that can make use of https://www.home-assistant.io/integrations/homeassistant/#service-homeassistantupdate_entity

[leeyuentuen]

If this integration is to make it into HA core, update_interval must be fixed and sensible (not too often), so any "smart updates" should be left out to automations that can make use of https://www.home-assistant.io/integrations/homeassistant/#service-homeassistantupdate_entity

the best way is get update from polestar side that there is an update of the value. but that way is not possible. so the current way is update every 15sec, but this will make issue on their server.

if someone got some idea, just shoot. i can't tell too much in detail before polestar will block this again.

and i will see what we can do after my holiday

[dgomes]

15 seconds is way too often, based on my experience with BMW API's we should go for at most 15min (BMW actually throttles to 1/hour)

Now with few users everything is OK, until there are many users and their API get overloaded and they block/throttle

If you want to have very frequent updates, I recommend you go in for https://github.com/Ixam97/CarStatsViewer which will not rely on Polestar backend

[nthbooth]

Also it might be worth considering backoff for when the API is down otherwise you end up slowing down recovery. If a lot of people use this plugin (which my guess is they will with time) then if there was an outage on the polestar side it could mean that every single home assistant tries to retry every couple of seconds hence sustaining the outage. there should probably be some sort of backoff is possible to protect polestar.
something like first retry after 15 seconds + a couple of second randomisor then 30 seconds then 1 minute then 2 minutes 4.. doubling till you get to 1 hour.

Again trying to suggest things here that mean we that the API won't get blocked. if we behave responsibly as a community on the whole then I feel polestar would accept rather than block our usage.

[dgomes]

If we use https://developers.home-assistant.io/docs/integration_fetching_data/ then backoff gets handled by HA core

[leeyuentuen]

I think about it, in the Volvo API, each user can have 10.000 requests a day (should be possible for each request every 15 seconds).
there is on the API a small DDoS issue where it keeps retrying when it fails to update the async_update, so I've changed it so that we will delay there for 30 seconds before doing the next update (on failed). Also, there was a small issue on the unauthorized (token expired) issue, so let me see if this could remain stable before big changes.
I think that the server on the Polestar side should use caching method, so if they see that there is no changes on e.g. battery data, they will just return the same value back as the cached one.

on the other side, IF "Polestar engineer" of "people from Polestar" can give me more information, they can always contact me to collaborate

let take a look at the latest beta (1.2.7), hope I can release this beta to prod, because the main branch is behind a lot