Update on request

[psteinrueck]

My homebrew Home Energy Management System now relies on Car_Connectivity. It works very well with my Volkswagen ID.7, but unfortunately not with our e‑Golf. Volkswagen applies extremely restrictive request‑quota limits for this vehicle type. With the default 180 s update interval, the quota is exceeded after only a few hours. To maintain 24‑hour access, I had to increase the interval to 1800 s.

Such a slow reaction time makes any meaningful control strategy impossible.

Unfortunately, the Car_Connectivity “update” command sent via the paho‑mqtt client

self.client.publish("carconnectivity/0/commands/update_writetopic","update")

does not trigger an immediate refresh. The next update still occurs only at the scheduled interval (which may be up to 1800 s later).

I would kindly like to ask the author to consider implementing an on‑demand, near‑real‑time update mechanism to support responsive energy‑management use cases

[tillsteinbach]

Have you set the max_age config parameter in the connector?
"max_age": 300, //Cache requests to the server vor MAX_AGE seconds
if not I would recommend trying to lower it

[psteinrueck]

does this help solving my problem: What I need is a requested update, e.g: not exceed the request quota the mqtt client becomes updated only every half hour, However when my system recognizes a car being plugged to the wallbox, the system should find out what car has been connected by retrieving the connection information via carconnectivity. To do so my system issues an update command and expects an answer on short notice. Also the SOC information is required within seconds.

[tillsteinbach]

The problem you are probably facing is that your update is getting data from the cache. If you set the cache time (max_age) low, it will request new data from the server and not take the cache.

[psteinrueck]

Thanks, have trialed setting max_age down even to 60, no success -
on update I still receive data from the past until the next interval has been completed. (the debug log shows immediate action on sending the update request, however it yields a copy of data pulled at the most recent periodic update:

Here is an example of the debug log: last periodic update at UTC 6:51; time of update request: UTC 7:05 (MEZ 8:05): (response starts at second line of facsimilie, first lien: final statement of a previous update request))

> 2026-01-29T08:03:19+0100:carconnectivity.plugins.mqtt:DEBUG:mqtt_client:Successfully set value
> 2026-01-29T08:05:24+0100:urllib3.connectionpool:DEBUG:connectionpool:Resetting dropped connection: emea.bff.cariad.digital
> 2026-01-29T08:05:25+0100:urllib3.connectionpool:DEBUG:connectionpool:https://emea.bff.cariad.digital:443 "GET /vehicle/v1/vehicles HTTP/11" 200 None
> 2026-01-29T08:05:26+0100:urllib3.connectionpool:DEBUG:connectionpool:https://emea.bff.cariad.digital:443 "GET /media/v2/vehicle-images/WVWZZZAUZL8904033?resolution=2x HTTP/11" 200 None
> 2026-01-29T08:05:29+0100:urllib3.connectionpool:DEBUG:connectionpool:https://emea.bff.cariad.digital:443 "GET /vehicle/v1/vehicles/WVWZZZAUZL8904033/selectivestatus?jobs=access,automation,charging,climatisation,fuelStatus,vehicleLights,vehicleHealthInspection,vehicleHealthWarnings,measurements HTTP/11" 207 None
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Implicitly converting value to float: 68
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Value from the past: level: 2026-01-29 06:51:57.419280+00:00 > 2026-01-29 00:24:19+00:00
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Implicitly converting value to float: 114
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Value from the past: range: 2026-01-29 06:51:57.419686+00:00 > 2026-01-29 00:24:19+00:00
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Implicitly converting value to float: 114
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Value from the past: total_range: 2026-01-29 06:51:57.420189+00:00 > 2026-01-29 00:24:19+00:00
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Implicitly converting value to float: 68
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Value from the past: level: 2026-01-29 06:51:57.419280+00:00 > 2026-01-29 00:24:19+00:00
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Implicitly converting value to float: 114
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Value from the past: range: 2026-01-29 06:51:57.419686+00:00 > 2026-01-29 00:24:19+00:00
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Implicitly converting value to float: 114
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Value from the past: total_range: 2026-01-29 06:51:57.420189+00:00 > 2026-01-29 00:24:19+00:00
> 2026-01-29T08:05:29+0100:carconnectivity:DEBUG:attributes:Implicitly converting value to float: 42172
> 2026-01-29T08:05:29+0100:car 

[tillsteinbach]

The warning of the value from the past should not really be a problem here. The server responds with data from 00:24:19 although the last data from the server has a timestamp of 06:51:57. As both is in the past I would expect that the data is still the same.

[psteinrueck]

Thanks - the root cause of the problem seems to lie in the unfavorable 12V battery management of the e-Golf. In contrast to the MEB platform the e_golf battery management does not recharge the 12V battery automatically. Too many requests freeze the communication with the Carriad servers. Thus any periodic update may stall the communication. When I tried the max_age parameter, obviously the low battery voltage already has already shut down communication with the Carriad server. I will try the update command again, with a fresh loaded battery, a rather long update interval and a low max-age parameter.

[tillsteinbach]

Yes, that sounds good.