selectable features and adaptive refresh interval

[tmsch13]

Problem

I was wondering today, that a drive after 19:00 was not recorded via volvo2mqtt. So I checked the log an saw: WARNING: VCCAPIKEY <REDACTED> is extended and will be reusable at: 16.09.2024, 02:00:10 Also the Volvo developer portal showed that I used 10.003 out of 10.000 requests today.

My updateInterval is set to 60s so i thought that would be 60 x 24 = 1440 requests per day, so I greped the log for GET Requests an got:

Sep 15 19:01:24 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/energy/v1/vehicles/{0}/recharge-status Sep 15 19:01:24 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0} Sep 15 19:01:25 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/energy/v1/vehicles/{0}/recharge-status Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0}/odometer Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0}/windows Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0}/doors Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/location/v1/vehicles/{0}/location Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0}/tyres Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0}/engine-status Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0}/statistics Sep 15 19:01:26 volvo2mqtt [24359] - DEBUG: Starting GET call against https://api.volvocars.com/connected-vehicle/v2/vehicles/{0}/diagnostics

So there are 11 Requests per Interval, so 10.000 / 11 = 909 possible Intervals. So when Interval = 60s aka 1 minute thats 909 Minutes or 909/60 = 15,15 hours.

Intervall is reset at 2:00, so I run out of Requests at around 17:00

Ideal Solution

Perfectly the interval and the amount of features that are updated would adapt to the status of the car. When the car is moving location and odometer is updated more frequent, when the car is charging, the location has obvious not to be updated but charging specific features like SoC, connection status etc. should be updated more frequent.

When engine state is off, and car is not charging, it would be sufficient to skip all other features and maybe even pause the requests for a while.

Slow changing features like diagnostics (time to service, distance to service) could be refreshed only once a day.

All in all, that would allow more frequent data requests when its relevant while also reducing the total requests per day.

alternative or additionally (small) solution

Alternatively or additionally It would be nice to just be able to easily adjust the requested datapoints. So i could exclude for example windows, doors and tyres, so there would be 3 request less per interval which would give at least an extra of 3 x 60 x 24 = 4320 Requests per day.

[Dielee]

Just add a second vcc API key and your problem is gone.

[github-actions[bot]]

This issue is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.