Charge level set is not a device created by the plug-in. Probably Some other device from hvdw to control his/her chargermvveelen wrote: ↑Friday 04 July 2025 20:25 Below are the devices mentioned, in the Text device you posted. I think this is a nice way of showing these devices in one place.
I think that if I know where to start, I can manage myself to add/adjust or remove devices/lines.
"Charge level actual" is called "VolvoEX30 Batterij level" in my set up
I think "Volvo-evccConnectedStatus" (value B) is the "Plug connected"?
"Expected range" is probably "Volvo-fullRange"
"Current range" is "VolvoEX30 range"
"Charging to 90%" is in my setup "VolvoEX30 laadtijd tot vol" and I think I'd better translate. Dutch is "ugly" for these kinds of devices
I can't find the "Charge level set" yet.
Python Plugin: Volvo EV
Moderator: leecollings
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
-
mvveelen
- Posts: 697
- Joined: Friday 31 October 2014 10:22
- Target OS: NAS (Synology & others)
- Domoticz version: Beta
- Location: Hoorn, The Netherlands
- Contact:
Re: Python Plugin: Volvo EV
Ah,
clear. Thanks.
I'm facing another issue at the moment. The sensors aren't updating, although the car is charging. When I go to the CLI and do the 'trick' with "python3 authorize.py", then - after restarting Domoticz - all devices are updated. I see no errors in the Log, so it's kind of strange right? I haven't changed anything and since yesterday evening 21:30 (the last time I used python3 authorize.py) the values of the devices haven't changed.
Any ideas?
clear. Thanks.
I'm facing another issue at the moment. The sensors aren't updating, although the car is charging. When I go to the CLI and do the 'trick' with "python3 authorize.py", then - after restarting Domoticz - all devices are updated. I see no errors in the Log, so it's kind of strange right? I haven't changed anything and since yesterday evening 21:30 (the last time I used python3 authorize.py) the values of the devices haven't changed.
Any ideas?
RPi3b+/RFXCOM rfxtrx433E/Shelly/Xiaomi Gateway/Philips HUE Lights/Atag Zone One/2 SunnyBoy inverters/AirconWithMe/P1 smartmeter/Domoticz latest Beta
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
Looks like a serverside issue with the refresh token. I have the same issue. I have the same issue. Will try to troubleshoot later this weekend
-
mvveelen
- Posts: 697
- Joined: Friday 31 October 2014 10:22
- Target OS: NAS (Synology & others)
- Domoticz version: Beta
- Location: Hoorn, The Netherlands
- Contact:
Re: Python Plugin: Volvo EV
I just switched Debug on and see:
Code: Select all
2025-07-05 12:56:50.101 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:56:50.101 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:56:50.101 Volvo: DEBUG: Heartbeat() called
2025-07-05 12:56:50.101 Volvo: DEBUG: Not logged in, retrying in 500.0034408569336 seconds
2025-07-05 12:56:50.101 Volvo: DEBUG: No vin, do nothing
2025-07-05 12:56:50.101 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:00.032 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 12:57:00.082 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 12:57:00.083 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:00.086 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:57:00.086 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:57:00.086 Volvo: DEBUG: Heartbeat() called
2025-07-05 12:57:00.086 Volvo: DEBUG: Not logged in, retrying in 490.0183963775635 seconds
2025-07-05 12:57:00.086 Volvo: DEBUG: No vin, do nothing
2025-07-05 12:57:00.086 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:10.028 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 12:57:10.079 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 12:57:10.079 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:10.079 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:57:10.079 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:57:10.079 Volvo: DEBUG: Heartbeat() called
2025-07-05 12:57:10.079 Volvo: DEBUG: Not logged in, retrying in 480.02522706985474 seconds
2025-07-05 12:57:10.080 Volvo: DEBUG: No vin, do nothing
2025-07-05 12:57:10.080 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:20.025 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 12:57:20.075 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 12:57:20.075 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:20.075 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:57:20.075 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:57:20.075 Volvo: DEBUG: Heartbeat() called
RPi3b+/RFXCOM rfxtrx433E/Shelly/Xiaomi Gateway/Philips HUE Lights/Atag Zone One/2 SunnyBoy inverters/AirconWithMe/P1 smartmeter/Domoticz latest Beta
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
I just switched Debug on and see:
[/quote]
This is after the failure: the plug-in has no vin, cause the token refresh fails. I suspect after running authorize.py, you have a connection with Volvo for about 30 mins, and then you loose the connection, cause the connection token needs to be refreshed, but there is Some error with the refresh_token. If you can generate debug logging of that moment, that would be really helpful
EDIT: I just made a small change, hopefully this works around the issue. Found the cause: There is no nuew refresh_token in the the output when you refresh an access_token, which is very weird. I change the code that if there is no refresh_token, it will use the previous refresh_token to get a new access_token. It works for now. But not sure if this will last long.
You can test it too, i pushed the fix upstream, so if do a git pull you will have it.
if you have the no vin error, you need to run authorize.py to get a connection again... It will then work for at least an hour (i noticed this is the new expiration time for an access token, used to be half an hour).
I would be surprised if it continues to work this way, cause that lowers the security of the API. Basically would mean this when you have gathered someone's refresh token, you can alway regenerate a new access token and take over someone else's account... So make sure no one has access to you token.ini file!
Code: Select all
2025-07-05 12:56:50.101 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:56:50.101 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:56:50.101 Volvo: DEBUG: Heartbeat() called
2025-07-05 12:56:50.101 Volvo: DEBUG: Not logged in, retrying in 500.0034408569336 seconds
2025-07-05 12:56:50.101 Volvo: DEBUG: No vin, do nothing
2025-07-05 12:56:50.101 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:00.032 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 12:57:00.082 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 12:57:00.083 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:00.086 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:57:00.086 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:57:00.086 Volvo: DEBUG: Heartbeat() called
2025-07-05 12:57:00.086 Volvo: DEBUG: Not logged in, retrying in 490.0183963775635 seconds
2025-07-05 12:57:00.086 Volvo: DEBUG: No vin, do nothing
2025-07-05 12:57:00.086 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:10.028 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 12:57:10.079 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 12:57:10.079 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:10.079 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:57:10.079 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:57:10.079 Volvo: DEBUG: Heartbeat() called
2025-07-05 12:57:10.079 Volvo: DEBUG: Not logged in, retrying in 480.02522706985474 seconds
2025-07-05 12:57:10.080 Volvo: DEBUG: No vin, do nothing
2025-07-05 12:57:10.080 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:20.025 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 12:57:20.075 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 12:57:20.075 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 12:57:20.075 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 12:57:20.075 Volvo: DEBUG: onHeartbeat called
2025-07-05 12:57:20.075 Volvo: DEBUG: Heartbeat() called
This is after the failure: the plug-in has no vin, cause the token refresh fails. I suspect after running authorize.py, you have a connection with Volvo for about 30 mins, and then you loose the connection, cause the connection token needs to be refreshed, but there is Some error with the refresh_token. If you can generate debug logging of that moment, that would be really helpful
EDIT: I just made a small change, hopefully this works around the issue. Found the cause: There is no nuew refresh_token in the the output when you refresh an access_token, which is very weird. I change the code that if there is no refresh_token, it will use the previous refresh_token to get a new access_token. It works for now. But not sure if this will last long.
You can test it too, i pushed the fix upstream, so if do a git pull you will have it.
if you have the no vin error, you need to run authorize.py to get a connection again... It will then work for at least an hour (i noticed this is the new expiration time for an access token, used to be half an hour).
I would be surprised if it continues to work this way, cause that lowers the security of the API. Basically would mean this when you have gathered someone's refresh token, you can alway regenerate a new access token and take over someone else's account... So make sure no one has access to you token.ini file!
-
mvveelen
- Posts: 697
- Joined: Friday 31 October 2014 10:22
- Target OS: NAS (Synology & others)
- Domoticz version: Beta
- Location: Hoorn, The Netherlands
- Contact:
Re: Python Plugin: Volvo EV
What do you mean with this ?
"So make sure no one has access to you token.ini file!"
Did I forget something?
Did the update, the authorization and restarted Domoticz. This is what I have now (I deleted my VIN):
"So make sure no one has access to you token.ini file!"
Did I forget something?
Did the update, the authorization and restarted Domoticz. This is what I have now (I deleted my VIN):
Code: Select all
2025-07-05 14:32:46.455 Volvo: DEBUG: {"data": {"frontLeft": {"value": "NO_WARNING", "timestamp": "2025-07-05T12:32:36.778Z"}, "frontRight": {"value": "NO_WARNING", "timestamp": "2025-07-05T12:32:36.778Z"}, "rearLeft": {"value": "NO_WARNING", "timestamp": "2025-07-05T12:32:36.778Z"}, "rearRight": {"value": "NO_WARNING", "timestamp": "2025-07-05T12:32:36.778Z"}}}
2025-07-05 14:32:46.470 Volvo: TextSensor (Volvo-FrontRightTyrePressure)
2025-07-05 14:32:46.484 Volvo: TextSensor (Volvo-FrontLeftTyrePressure)
2025-07-05 14:32:46.499 Volvo: TextSensor (Volvo-RearRightTyrePressure)
2025-07-05 14:32:46.513 Volvo: TextSensor (Volvo-RearLeftTyrePressure)
2025-07-05 14:32:46.514 Volvo: DEBUG: GetDiagnostics() called
2025-07-05 14:32:46.514 Volvo: DEBUG: VolvoAPI(https://api.volvocars.com/connected-vehicle/v2/vehicles/-verwijderd-/diagnostics,application/json) called
2025-07-05 14:32:46.999 Volvo: DEBUG:
2025-07-05 14:32:47.000 Volvo: DEBUG: <Response [200]>
2025-07-05 14:32:47.000 Volvo: DEBUG: Result took 0:00:00.485362
2025-07-05 14:32:47.001 Volvo: DEBUG:
2025-07-05 14:32:47.002 Volvo: DEBUG: {
2025-07-05 14:32:47.002 Volvo: DEBUG: {"data": {"serviceWarning": {"value": "NO_WARNING", "timestamp": "2025-07-05T12:32:36.778Z"}, "engineHoursToService": {"value": 500, "unit": "h", "timestamp": "2025-07-05T12:32:36.778Z"}, "distanceToService": {"value": 16706, "unit": "km", "timestamp": "2025-07-05T12:32:36.778Z"}, "washerFluidLevelWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "timeToService": {"value": 9, "unit": "months", "timestamp": "2025-07-05T12:32:36.778Z"}}}
2025-07-05 14:32:47.016 Volvo: TextSensor (Volvo-WasherFluidLevel)
2025-07-05 14:32:47.017 Volvo: DEBUG: SafeUpdateSensor(-verwijderd-,29,EngineHoursToService,243,31,{'data': {'serviceWarning': {'value': 'NO_WARNING', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'engineHoursToService': {'value': 500, 'unit': 'h', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'distanceToService': {'value': 16706, 'unit': 'km', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'washerFluidLevelWarning': {'value': 'UNSPECIFIED', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'timeToService': {'value': 9, 'unit': 'months', 'timestamp': '2025-07-05T12:32:36.778Z'}}},engineHoursToService
2025-07-05 14:32:47.017 Volvo: DEBUG: Changing from + 500,500.0 to 500,500.0
2025-07-05 14:32:47.033 Volvo: General/Custom Sensor (Volvo-EngineHoursToService)
2025-07-05 14:32:47.033 Volvo: DEBUG: SafeUpdateSensor(-verwijderd-,30,KmToService,243,31,{'data': {'serviceWarning': {'value': 'NO_WARNING', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'engineHoursToService': {'value': 500, 'unit': 'h', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'distanceToService': {'value': 16706, 'unit': 'km', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'washerFluidLevelWarning': {'value': 'UNSPECIFIED', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'timeToService': {'value': 9, 'unit': 'months', 'timestamp': '2025-07-05T12:32:36.778Z'}}},distanceToService
2025-07-05 14:32:47.034 Volvo: DEBUG: Changing from + 16712,16712.0 to 16706,16706.0
2025-07-05 14:32:47.047 Volvo: General/Custom Sensor (Volvo-KmToService)
2025-07-05 14:32:47.048 Volvo: DEBUG: SafeUpdateSensor(-verwijderd-,31,MonthsToService,243,31,{'data': {'serviceWarning': {'value': 'NO_WARNING', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'engineHoursToService': {'value': 500, 'unit': 'h', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'distanceToService': {'value': 16706, 'unit': 'km', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'washerFluidLevelWarning': {'value': 'UNSPECIFIED', 'timestamp': '2025-07-05T12:32:36.778Z'}, 'timeToService': {'value': 9, 'unit': 'months', 'timestamp': '2025-07-05T12:32:36.778Z'}}},timeToService
2025-07-05 14:32:47.048 Volvo: DEBUG: Changing from + 9,9.0 to 9,9.0
2025-07-05 14:32:47.062 Volvo: General/Custom Sensor (Volvo-MonthsToService)
2025-07-05 14:32:47.076 Volvo: TextSensor (Volvo-ServiceStatus)
2025-07-05 14:32:47.076 Volvo: DEBUG: GetEngineStatus() called
2025-07-05 14:32:47.076 Volvo: DEBUG: VolvoAPI(https://api.volvocars.com/connected-vehicle/v2/vehicles/-verwijderd-/engine-status,application/json) called
2025-07-05 14:32:47.569 Volvo: DEBUG:
2025-07-05 14:32:47.569 Volvo: DEBUG: <Response [200]>
2025-07-05 14:32:47.570 Volvo: DEBUG: Result took 0:00:00.492462
2025-07-05 14:32:47.571 Volvo: DEBUG:
2025-07-05 14:32:47.571 Volvo: DEBUG: {
2025-07-05 14:32:47.572 Volvo: DEBUG: {"data": {"engineStatus": {"value": "STOPPED", "timestamp": "2025-07-05T12:32:36.778Z"}}}
2025-07-05 14:32:47.572 Volvo: DEBUG: UpdateSwitch(-verwijderd-,37,engineStatus,0,Off called
2025-07-05 14:32:47.572 Volvo: DEBUG: Switch status unchanged, not updating Volvo-engineStatus
2025-07-05 14:32:47.572 Volvo: DEBUG: GetEngine() called
2025-07-05 14:32:47.573 Volvo: DEBUG: VolvoAPI(https://api.volvocars.com/connected-vehicle/v2/vehicles/-verwijderd-/engine,application/json) called
2025-07-05 14:32:48.027 Volvo: DEBUG:
2025-07-05 14:32:48.027 Volvo: DEBUG: <Response [200]>
2025-07-05 14:32:48.027 Volvo: DEBUG: Result took 0:00:00.453828
2025-07-05 14:32:48.029 Volvo: DEBUG:
2025-07-05 14:32:48.030 Volvo: DEBUG: {
2025-07-05 14:32:48.030 Volvo: DEBUG: {"data": {"oilLevelWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "engineCoolantLevelWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}}}
2025-07-05 14:32:48.046 Volvo: TextSensor (Volvo-engineCoolantLevel)
2025-07-05 14:32:48.061 Volvo: TextSensor (Volvo-oilLevel)
2025-07-05 14:32:48.061 Volvo: DEBUG: GetWarningStatus() called
2025-07-05 14:32:48.061 Volvo: DEBUG: VolvoAPI(https://api.volvocars.com/connected-vehicle/v2/vehicles/-verwijderd-/warnings,application/json) called
2025-07-05 14:32:48.562 Volvo: DEBUG:
2025-07-05 14:32:48.562 Volvo: DEBUG: <Response [200]>
2025-07-05 14:32:48.563 Volvo: DEBUG: Result took 0:00:00.500221
2025-07-05 14:32:48.566 Volvo: DEBUG:
2025-07-05 14:32:48.568 Volvo: DEBUG: {
2025-07-05 14:32:48.569 Volvo: DEBUG: {"data": {"brakeLightCenterWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "brakeLightLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "brakeLightRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "fogLightFrontWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "fogLightRearWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "positionLightFrontLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "positionLightFrontRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "positionLightRearLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "positionLightRearRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "highBeamLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "highBeamRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "lowBeamLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "lowBeamRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "daytimeRunningLightLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "daytimeRunningLightRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "turnIndicationFrontLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "turnIndicationFrontRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "turnIndicationRearLeftWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "turnIndicationRearRightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "registrationPlateLightWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "sideMarkLightsWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "hazardLightsWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}, "reverseLightsWarning": {"value": "UNSPECIFIED", "timestamp": "2025-07-05T12:32:36.778Z"}}}
2025-07-05 14:32:48.585 Volvo: TextSensor (Volvo-BrakeLightCenterWarning)
2025-07-05 14:32:48.600 Volvo: TextSensor (Volvo-BrakeLightLeftWarning)
2025-07-05 14:32:48.613 Volvo: TextSensor (Volvo-BrakeLightRightWarning)
2025-07-05 14:32:48.626 Volvo: TextSensor (Volvo-fogLightFrontWarning)
2025-07-05 14:32:48.643 Volvo: TextSensor (Volvo-fogLightRearWarning)
2025-07-05 14:32:48.664 Volvo: TextSensor (Volvo-positionLightFrontLeftWarning)
2025-07-05 14:32:48.679 Volvo: TextSensor (Volvo-positionLightFrontRightWarning)
2025-07-05 14:32:48.693 Volvo: TextSensor (Volvo-positionLightRearLeftWarning)
2025-07-05 14:32:48.709 Volvo: TextSensor (Volvo-positionLightRearRightWarning)
2025-07-05 14:32:48.724 Volvo: TextSensor (Volvo-highBeamLeftWarning)
2025-07-05 14:32:48.739 Volvo: TextSensor (Volvo-highBeamRightWarning)
2025-07-05 14:32:48.752 Volvo: TextSensor (Volvo-lowBeamLeftWarning)
2025-07-05 14:32:48.766 Volvo: TextSensor (Volvo-lowBeamRightWarning)
2025-07-05 14:32:48.783 Volvo: TextSensor (Volvo-daytimeRunningLightLeftWarning)
2025-07-05 14:32:48.798 Volvo: TextSensor (Volvo-daytimeRunningLightRightWarning)
2025-07-05 14:32:48.813 Volvo: TextSensor (Volvo-turnIndicationFrontLeftWarning)
2025-07-05 14:32:48.829 Volvo: TextSensor (Volvo-turnIndicationFrontRightWarning)
2025-07-05 14:32:48.843 Volvo: TextSensor (Volvo-turnIndicationRearLeftWarning)
2025-07-05 14:32:48.858 Volvo: TextSensor (Volvo-turnIndicationRearRightWarning)
2025-07-05 14:32:48.872 Volvo: TextSensor (Volvo-registrationPlateLightWarning)
2025-07-05 14:32:48.887 Volvo: TextSensor (Volvo-sideMarkLightsWarning)
2025-07-05 14:32:48.899 Volvo: TextSensor (Volvo-hazardMarkLightsWarning)
2025-07-05 14:32:48.912 Volvo: TextSensor (Volvo-reverseMarkLightsWarning)
2025-07-05 14:32:48.912 Volvo: DEBUG: UpdateLastKnownLocation() called
2025-07-05 14:32:48.912 Volvo: DEBUG: LastKnownLocation present, checking if we have to update and / or record a trip
2025-07-05 14:32:48.913 Volvo: DEBUG: Car moved, calculate difference and write to triplog.csv
2025-07-05 14:32:48.913 Volvo: DEBUG: UpdateSwitch(-verwijderd-,84,Car is moving or moved,0,Off called
2025-07-05 14:32:48.913 Volvo: DEBUG: Changing from + 1,On to 0,Off
2025-07-05 14:32:48.928 Volvo: On/Off Switch (Volvo-Car is moving or moved)
2025-07-05 14:32:48.929 Volvo: DEBUG: 52.64897138888889;5.101028888888889;52.64897138888889,5.101028888888889;13308;149768.9051431204;83
2025-07-05 14:32:48.943 Volvo: TextSensor (Volvo-Last Known Location)
2025-07-05 14:32:48.957 Volvo: TextSensor (Volvo-Current Location)
2025-07-05 14:32:48.957 Volvo: DEBUG: existing file, append line
2025-07-05 14:32:48.971 Volvo: TextSensor (Volvo-Last Trip)
2025-07-05 14:32:48.971 Volvo: DEBUG: No ABRP token and/or apikey or no EV features detected, ignoring
2025-07-05 14:32:48.972 Volvo: Acquiring GIL for 'onStartCallback'
2025-07-05 14:32:49.022 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 14:32:49.072 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 14:32:49.073 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 14:32:49.073 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 14:32:49.073 Volvo: DEBUG: onHeartbeat called
2025-07-05 14:32:49.073 Volvo: DEBUG: Heartbeat() called
2025-07-05 14:32:49.073 Volvo: DEBUG: Not refreshing token, expires in 1732.6971080303192 seconds
2025-07-05 14:32:49.073 Volvo: DEBUG: We already have a vin
2025-07-05 14:32:49.073 Volvo: DEBUG: CreatePushButton(-verwijderd-,76,Flash) called
2025-07-05 14:32:49.073 Volvo: DEBUG: CreatePushButton(-verwijderd-,75,Honk) called
2025-07-05 14:32:49.073 Volvo: DEBUG: CreatePushButton(-verwijderd-,77,Honk and Flash) called
2025-07-05 14:32:49.074 Volvo: DEBUG: CreatePushButton(-verwijderd-,78,Lock with Reduced Guard) called
2025-07-05 14:32:49.074 Volvo: DEBUG: CreatePushButton(-verwijderd-,82,Force Update) called
2025-07-05 14:32:49.074 Volvo: DEBUG: Already exists
2025-07-05 14:32:49.074 Volvo: DEBUG: Climatization switched off, do nothing
2025-07-05 14:32:49.074 Volvo: DEBUG: Not updating, 893.1454837322235 to update
2025-07-05 14:32:49.074 Volvo: DEBUG: No ABRP token and/or apikey or no EV features detected, ignoring
2025-07-05 14:32:49.074 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 14:32:59.008 Volvo: Pushing 'onHeartbeatCallback' on to queue
2025-07-05 14:32:59.059 Volvo: Processing 'onHeartbeatCallback' message
2025-07-05 14:32:59.059 Volvo: Acquiring GIL for 'onHeartbeatCallback'
2025-07-05 14:32:59.059 Volvo: Calling message handler 'onHeartbeat' on 'module' type object.
2025-07-05 14:32:59.059 Volvo: DEBUG: onHeartbeat called
2025-07-05 14:32:59.059 Volvo: DEBUG: Heartbeat() called
2025-07-05 14:32:59.059 Volvo: DEBUG: Not refreshing token, expires in 1722.7107319831848 seconds
2025-07-05 14:32:59.060 Volvo: DEBUG: We already have a vin
2025-07-05 14:32:59.060 Volvo: DEBUG: CreatePushButton(-verwijderd-,76,Flash) called
2025-07-05 14:32:59.060 Volvo: DEBUG: CreatePushButton(-verwijderd-,75,Honk) called
2025-07-05 14:32:59.060 Volvo: DEBUG: CreatePushButton(-verwijderd-,77,Honk and Flash) called
2025-07-05 14:32:59.060 Volvo: DEBUG: CreatePushButton(-verwijderd-,78,Lock with Reduced Guard) called
2025-07-05 14:32:59.060 Volvo: DEBUG: CreatePushButton(-verwijderd-,82,Force Update) called
2025-07-05 14:32:59.060 Volvo: DEBUG: Already exists
2025-07-05 14:32:59.060 Volvo: DEBUG: Climatization switched off, do nothing
2025-07-05 14:32:59.060 Volvo: DEBUG: Not updating, 883.1591591835022 to update
2025-07-05 14:32:59.060 Volvo: DEBUG: No ABRP token and/or apikey or no EV features detected, ignoring
2025-07-05 14:32:59.061 Volvo: Acquiring GIL for 'onHeartbeatCallback'
RPi3b+/RFXCOM rfxtrx433E/Shelly/Xiaomi Gateway/Philips HUE Lights/Atag Zone One/2 SunnyBoy inverters/AirconWithMe/P1 smartmeter/Domoticz latest Beta
-
FireWizard
- Posts: 1905
- Joined: Tuesday 25 December 2018 12:11
- Target OS: Raspberry Pi / ODroid
- Domoticz version: Beta
- Location: Voorthuizen (NL)
- Contact:
Re: Python Plugin: Volvo EV
Hello @akamming,
I see similar issues with the authorization. It started yesterday.
I noticed the following.
I restarted my flows (in Node-RED) this morning and everything started and continues to function for 1 (!) hour.
This is rather strange, as that would mean, that it was able to refresh 1 time. But looking further, I understand.
I noticed a successful refresh after 1789 seconds, as expected. I refresh 10 seconds before expiration.
Also I noticed that previously the authorization returns an object with the following parameters in the response body: "access_token", 'refresh_token", "token_type" and "expires_in". See https://developer.volvocars.com/apis/do ... orisation/
However I saw a new parameter: "id_token".
After a refresh of the token, after as expected in maximum 1799 seconds, the new object does not contain a new "refresh_token", but only
"access_token", "id_token", "token_type" and "expires_in". So a new "refresh_token" is missing.
Is that an error at Volvo side or done intentionally?
Obviously Volvo is working on "something" new, which is currently undocumented.
The documentation lags behind the practical situation.
I think something went wrong, while they were changing the authorization process.
I monitor it, what is really happening.
I will try to use that "id_token" instead of the refresh_token and see if this solves the authorization issue.
I'll keep you informed
Regards
I see similar issues with the authorization. It started yesterday.
I noticed the following.
I restarted my flows (in Node-RED) this morning and everything started and continues to function for 1 (!) hour.
This is rather strange, as that would mean, that it was able to refresh 1 time. But looking further, I understand.
I noticed a successful refresh after 1789 seconds, as expected. I refresh 10 seconds before expiration.
Also I noticed that previously the authorization returns an object with the following parameters in the response body: "access_token", 'refresh_token", "token_type" and "expires_in". See https://developer.volvocars.com/apis/do ... orisation/
However I saw a new parameter: "id_token".
After a refresh of the token, after as expected in maximum 1799 seconds, the new object does not contain a new "refresh_token", but only
"access_token", "id_token", "token_type" and "expires_in". So a new "refresh_token" is missing.
Is that an error at Volvo side or done intentionally?
Obviously Volvo is working on "something" new, which is currently undocumented.
The documentation lags behind the practical situation.
I think something went wrong, while they were changing the authorization process.
I monitor it, what is really happening.
I will try to use that "id_token" instead of the refresh_token and see if this solves the authorization issue.
I'll keep you informed
Regards
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
tx. i now made a workaround to not try to update the refresh token if it's not in the output. It is valid for 7 days, si it is running agina. I hope Volvo fixes before this before 7 days expire, otherwise i'm forced to do 2FA every week. I am very interested in your test results. Hopefully you can update the refresh_token somehow the new id_token.FireWizard wrote: ↑Saturday 05 July 2025 14:56 Hello @akamming,
I see similar issues with the authorization. It started yesterday.
I noticed the following.
I restarted my flows (in Node-RED) this morning and everything started and continues to function for 1 (!) hour.
This is rather strange, as that would mean, that it was able to refresh 1 time. But looking further, I understand.
I noticed a successful refresh after 1789 seconds, as expected. I refresh 10 seconds before expiration.
Also I noticed that previously the authorization returns an object with the following parameters in the response body: "access_token", 'refresh_token", "token_type" and "expires_in". See https://developer.volvocars.com/apis/do ... orisation/
However I saw a new parameter: "id_token".
After a refresh of the token, after as expected in maximum 1799 seconds, the new object does not contain a new "refresh_token", but only
"access_token", "id_token", "token_type" and "expires_in". So a new "refresh_token" is missing.
Is that an error at Volvo side or done intentionally?
Obviously Volvo is working on "something" new, which is currently undocumented.
The documentation lags behind the practical situation.
I think something went wrong, while they were changing the authorization process.
I monitor it, what is really happening.
I will try to use that "id_token" instead of the refresh_token and see if this solves the authorization issue.
I'll keep you informed
Regards
-
FireWizard
- Posts: 1905
- Joined: Tuesday 25 December 2018 12:11
- Target OS: Raspberry Pi / ODroid
- Domoticz version: Beta
- Location: Voorthuizen (NL)
- Contact:
Re: Python Plugin: Volvo EV
Hi @akamming,
Instead of sending the "refresh_token" as the refresh token, I sent the "id_token" as refresh token.
That did not work and was not excepted. I understand, as the grant_type=refresh_token was still in the URL.
But I do not know, what Volvo's intention is, with that new id_token.
I think I have to do the same trick and then re-authorize, if the authorization stops.
Regards
Unfortunately, it did not work.tx. i now made a workaround to not try to update the refresh token if it's not in the output. It is valid for 7 days, si it is running agina. I hope Volvo fixes before this before 7 days expire, otherwise i'm forced to do 2FA every week. I am very interested in your test results. Hopefully you can update the refresh_token somehow the new id_token.
Instead of sending the "refresh_token" as the refresh token, I sent the "id_token" as refresh token.
That did not work and was not excepted. I understand, as the grant_type=refresh_token was still in the URL.
But I do not know, what Volvo's intention is, with that new id_token.
I think I have to do the same trick and then re-authorize, if the authorization stops.
Regards
-
mvveelen
- Posts: 697
- Joined: Friday 31 October 2014 10:22
- Target OS: NAS (Synology & others)
- Domoticz version: Beta
- Location: Hoorn, The Netherlands
- Contact:
Re: Python Plugin: Volvo EV
So, the setup I have is OK and I must wait for a solution because everyone is having the same issues since yesterday?
Edit: meanwhile I managed to get some info into 1 Text device with the help of ChatGPT. At least I can fiddle with it to get the info in it I want.
Edit: meanwhile I managed to get some info into 1 Text device with the help of ChatGPT. At least I can fiddle with it to get the info in it I want.
- Screenshot 2025-07-05 at 18.09.08.png (57.46 KiB) Viewed 919 times
RPi3b+/RFXCOM rfxtrx433E/Shelly/Xiaomi Gateway/Philips HUE Lights/Atag Zone One/2 SunnyBoy inverters/AirconWithMe/P1 smartmeter/Domoticz latest Beta
-
HvdW
- Posts: 617
- Joined: Sunday 01 November 2015 22:45
- Target OS: Raspberry Pi / ODroid
- Domoticz version: 2023.2
- Location: Twente
- Contact:
Re: Python Plugin: Volvo EV
Well done!
If you have a text device with more that 4 lines you can use this function for alignment.
Code: Select all
-- Helper functions
local function spaces(count)
return (" "):rep(count)
end
Code: Select all
local text = string.format(
'Expected range %s%s km\n' ..
'Current range %s%s km\n' ..
'EV consumption %s kWh/100km \n\n'..
'Charging from %s%% to %s%% \n'..
spaces(15)..'will take %s,\n' ..
spaces(15)..'ready %s\n',
spaces(8), expectedRange,
spaces(11), currentRange,
CALCULATED_EV_CONSUMPTION,
currentLevel, targetLevel,
chargingTimeText,
completionDate
)
Bugs bug me.
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
Yep. I noticed the refresh token is valid for 7 days. So hopefully Volvo fixes it before a week has passedFireWizard wrote: ↑Saturday 05 July 2025 15:28 Hi @akamming,
Unfortunately, it did not work.tx. i now made a workaround to not try to update the refresh token if it's not in the output. It is valid for 7 days, si it is running agina. I hope Volvo fixes before this before 7 days expire, otherwise i'm forced to do 2FA every week. I am very interested in your test results. Hopefully you can update the refresh_token somehow the new id_token.
Instead of sending the "refresh_token" as the refresh token, I sent the "id_token" as refresh token.
That did not work and was not excepted. I understand, as the grant_type=refresh_token was still in the URL.
But I do not know, what Volvo's intention is, with that new id_token.
I think I have to do the same trick and then re-authorize, if the authorization stops.
Regards
-
mvveelen
- Posts: 697
- Joined: Friday 31 October 2014 10:22
- Target OS: NAS (Synology & others)
- Domoticz version: Beta
- Location: Hoorn, The Netherlands
- Contact:
Re: Python Plugin: Volvo EV
With the latest update (did the git pull), it seems to be updating the devices again.
One thing: I changed the update interval from 900 to 60 seconds to be able to see the changes faster than after 900 seconds. 60 seconds is probably a too low amount, what is the lowest one can use without getting errors? And, can this be added to a new update, so nobody can change it to a too low value? Or add a warning to best use XX seconds after testing?
Trying to figure out the status of "evccConnectedStatus"
I'm charging now and the status is now "C". When the cable is connected, but charging is stopped, the status is "B". When no cable is connected, the status is "A", so I can use this to add that info to the Dummy text device.
One thing: I changed the update interval from 900 to 60 seconds to be able to see the changes faster than after 900 seconds. 60 seconds is probably a too low amount, what is the lowest one can use without getting errors? And, can this be added to a new update, so nobody can change it to a too low value? Or add a warning to best use XX seconds after testing?
Trying to figure out the status of "evccConnectedStatus"
I'm charging now and the status is now "C". When the cable is connected, but charging is stopped, the status is "B". When no cable is connected, the status is "A", so I can use this to add that info to the Dummy text device.
- Screenshot 2025-07-05 at 21.25.10.png (62.29 KiB) Viewed 883 times
RPi3b+/RFXCOM rfxtrx433E/Shelly/Xiaomi Gateway/Philips HUE Lights/Atag Zone One/2 SunnyBoy inverters/AirconWithMe/P1 smartmeter/Domoticz latest Beta
-
FireWizard
- Posts: 1905
- Joined: Tuesday 25 December 2018 12:11
- Target OS: Raspberry Pi / ODroid
- Domoticz version: Beta
- Location: Voorthuizen (NL)
- Contact:
Re: Python Plugin: Volvo EV
@akamming
I saw, that ThomasDDN tried to persuade you to move to HA.
I think, you had a serious question and to be honest, I think that developers should co-operate instead of competing.
In particular in case of companies like Volvo, which are not developer friendly, regarding communication or answering emails, etc.
I have searched on the Internet, regarding id_token and Volvo API, but did not find anything usefull.
I have no idea yet, what will be the intended use, but let's hope that they fix the refresh_token issue, this week.
I used the same workaround for now.
I check, if a refresh_token exist. If so, I use it, If not, I use the old one.
If they do not fix the issue, I will count the number of days and as soon as the counter reaches 6, I will re-authorize automatically.
Will keep you informed.
Regards
I saw, that ThomasDDN tried to persuade you to move to HA.
I think, you had a serious question and to be honest, I think that developers should co-operate instead of competing.
In particular in case of companies like Volvo, which are not developer friendly, regarding communication or answering emails, etc.
I have searched on the Internet, regarding id_token and Volvo API, but did not find anything usefull.
I have no idea yet, what will be the intended use, but let's hope that they fix the refresh_token issue, this week.
I used the same workaround for now.
I check, if a refresh_token exist. If so, I use it, If not, I use the old one.
If they do not fix the issue, I will count the number of days and as soon as the counter reaches 6, I will re-authorize automatically.
Will keep you informed.
Regards
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
How do you automatically reauthorize? It’s an 2fa solution…FireWizard wrote: ↑Saturday 05 July 2025 21:27 @akamming
I saw, that ThomasDDN tried to persuade you to move to HA.
I think, you had a serious question and to be honest, I think that developers should co-operate instead of competing.
In particular in case of companies like Volvo, which are not developer friendly, regarding communication or answering emails, etc.
I have searched on the Internet, regarding id_token and Volvo API, but did not find anything usefull.
I have no idea yet, what will be the intended use, but let's hope that they fix the refresh_token issue, this week.
I used the same workaround for now.
I check, if a refresh_token exist. If so, I use it, If not, I use the old one.
If they do not fix the issue, I will count the number of days and as soon as the counter reaches 6, I will re-authorize automatically.
Will keep you informed.
Regards
-
FireWizard
- Posts: 1905
- Joined: Tuesday 25 December 2018 12:11
- Target OS: Raspberry Pi / ODroid
- Domoticz version: Beta
- Location: Voorthuizen (NL)
- Contact:
Re: Python Plugin: Volvo EV
Hello @akamming
You asked:
In my opinion it is the ideal combination and that is probably the reason that it has been integrated in HA.
So here it is.
The simple answer.
Let your program act as a human being.
The more complex answer.
The "Authorization" is automatically started, when Node RED is started.
You know, we have several steps
USERNAME_PASSWORD_REQUIRED
OTP_REQUIRED
OTP_VERIFIED
COMPLETED
After COMPLETED, you will receive the access_token, refresh_token, etc.
If the response from Volvo authentication server is "OTP_REQUIRED", it sends at the same time an OTP to your mailbox. It is also possible with SMS.
A node in the flow reads only that email filtered on exactly the topic: "Your Volvo ID Verification code". I delay the flow for approx 10 seconds.
It proves that that is enough, in order to receive the email. Then I do some string handling on the payload (= body text in the mail) to parse the 6 digit number and store it in a variable. That variable is inserted in the next step of the flow.
Of course the node deletes the Volvo email, after it has read. So we keep the INBOX clean regarding this type of Volvo's mails.
But instead of an automatic start in the beginning, I can repeat that with a specific interval.
The refresh_token is valid for 7 days, unless rotated, then the old one will be made invalid.
I can set an interval of, let's say 6.5 days x 24 hours = 156 hours, so that it will authenticate again after 6.5 days.
I know that Python can also read mailboxes, but I made it for myself using an IMAP Mailbox.
The problem is that you made it for others as well, and they use maybe other types of mail, like Gmail, Outlook, Exchange, POP3 or even webmail, etc.
I think you have also received an email in March this year, that Volvo told you the the old (legacy) API is discontinued.
In that mail, you could have read:
I think that they are creating "something" for car owners, using home automation systems, like Domoticz, HA or OpenHab.
It could be that the new id_token is intended for that new project.
Let's keep an eye on it.
I have sent an email about that to Volvo. Let's wait, if they answer.
I'll keep you updated.
I hope, I have given you some insight on how I did it. If you have more questions, contact me.
Regards
You asked:
I said before:How do you automatically reauthorize? It’s an 2fa solution…
Keep in mind, that I use Node-RED and not Python or DzVents or Lua.I think that developers should co-operate instead of competing.
In my opinion it is the ideal combination and that is probably the reason that it has been integrated in HA.
So here it is.
The simple answer.
Let your program act as a human being.
The more complex answer.
The "Authorization" is automatically started, when Node RED is started.
You know, we have several steps
USERNAME_PASSWORD_REQUIRED
OTP_REQUIRED
OTP_VERIFIED
COMPLETED
After COMPLETED, you will receive the access_token, refresh_token, etc.
If the response from Volvo authentication server is "OTP_REQUIRED", it sends at the same time an OTP to your mailbox. It is also possible with SMS.
A node in the flow reads only that email filtered on exactly the topic: "Your Volvo ID Verification code". I delay the flow for approx 10 seconds.
It proves that that is enough, in order to receive the email. Then I do some string handling on the payload (= body text in the mail) to parse the 6 digit number and store it in a variable. That variable is inserted in the next step of the flow.
Of course the node deletes the Volvo email, after it has read. So we keep the INBOX clean regarding this type of Volvo's mails.
But instead of an automatic start in the beginning, I can repeat that with a specific interval.
The refresh_token is valid for 7 days, unless rotated, then the old one will be made invalid.
I can set an interval of, let's say 6.5 days x 24 hours = 156 hours, so that it will authenticate again after 6.5 days.
I know that Python can also read mailboxes, but I made it for myself using an IMAP Mailbox.
The problem is that you made it for others as well, and they use maybe other types of mail, like Gmail, Outlook, Exchange, POP3 or even webmail, etc.
I think you have also received an email in March this year, that Volvo told you the the old (legacy) API is discontinued.
In that mail, you could have read:
Currently we are developing a new API as a replacement.We ontwikkelen momenteel een nieuwe API ter vervanging. Houd onze website in de gaten om op de hoogte te blijven.
I think that they are creating "something" for car owners, using home automation systems, like Domoticz, HA or OpenHab.
It could be that the new id_token is intended for that new project.
Let's keep an eye on it.
I have sent an email about that to Volvo. Let's wait, if they answer.
I'll keep you updated.
I hope, I have given you some insight on how I did it. If you have more questions, contact me.
Regards
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
I googled. Id token is a know thing in oauth:FireWizard wrote: ↑Sunday 06 July 2025 15:02 Hello @akamming
You asked:
I said before:How do you automatically reauthorize? It’s an 2fa solution…
Keep in mind, that I use Node-RED and not Python or DzVents or Lua.I think that developers should co-operate instead of competing.
In my opinion it is the ideal combination and that is probably the reason that it has been integrated in HA.
So here it is.
The simple answer.
Let your program act as a human being.
The more complex answer.
The "Authorization" is automatically started, when Node RED is started.
You know, we have several steps
USERNAME_PASSWORD_REQUIRED
OTP_REQUIRED
OTP_VERIFIED
COMPLETED
After COMPLETED, you will receive the access_token, refresh_token, etc.
If the response from Volvo authentication server is "OTP_REQUIRED", it sends at the same time an OTP to your mailbox. It is also possible with SMS.
A node in the flow reads only that email filtered on exactly the topic: "Your Volvo ID Verification code". I delay the flow for approx 10 seconds.
It proves that that is enough, in order to receive the email. Then I do some string handling on the payload (= body text in the mail) to parse the 6 digit number and store it in a variable. That variable is inserted in the next step of the flow.
Of course the node deletes the Volvo email, after it has read. So we keep the INBOX clean regarding this type of Volvo's mails.
But instead of an automatic start in the beginning, I can repeat that with a specific interval.
The refresh_token is valid for 7 days, unless rotated, then the old one will be made invalid.
I can set an interval of, let's say 6.5 days x 24 hours = 156 hours, so that it will authenticate again after 6.5 days.
I know that Python can also read mailboxes, but I made it for myself using an IMAP Mailbox.
The problem is that you made it for others as well, and they use maybe other types of mail, like Gmail, Outlook, Exchange, POP3 or even webmail, etc.
I think you have also received an email in March this year, that Volvo told you the the old (legacy) API is discontinued.
In that mail, you could have read:
Currently we are developing a new API as a replacement.We ontwikkelen momenteel een nieuwe API ter vervanging. Houd onze website in de gaten om op de hoogte te blijven.
I think that they are creating "something" for car owners, using home automation systems, like Domoticz, HA or OpenHab.
It could be that the new id_token is intended for that new project.
Let's keep an eye on it.
I have sent an email about that to Volvo. Let's wait, if they answer.
I'll keep you updated.
I hope, I have given you some insight on how I did it. If you have more questions, contact me.
Regards
I did not get that emailIn essence: Access tokens are used for accessing resources, refresh tokens are used to get new access tokens, and ID tokens are used to verify user identity. They work together to provide a secure and seamless user experience
And cool what you did with node red!
-
FireWizard
- Posts: 1905
- Joined: Tuesday 25 December 2018 12:11
- Target OS: Raspberry Pi / ODroid
- Domoticz version: Beta
- Location: Voorthuizen (NL)
- Contact:
Re: Python Plugin: Volvo EV
Hello @akamming,
I think that Volvo's security is okay, with oauth2.0 and in addition pkce.
So, what would they do more?
When I started to integrate my Volvo, in 2018/19, I used the, in that time, HA Python integration .
See: https://github.com/molobrakos/volvooncall.
This Python script published the data over MQTT as well. I used that to Domoticz.
Later on, I abandoned that Python script and made a full Node-RED application.
It gave me more endpoints, than the script did.
The full text of the email (in English), see below:
So this has been the reason, they sent me that email.
But if you never used that API, your email address, has never been registered. So there was no reason to send you an email.
I have thought about how to solve this issue with the refresh_token.
I think, I will do it as follows.
1. Check if the returned object contains a key with the name "refresh_token"
2. If so, I will use that refresh_token which is valid for 1799 seconds (at least 1 time)
3. If not, I will continue to use the existing "refresh_token", which is valid for 7 days.
4. Only in case of 3, I will trigger the authorization after 6.5 days (156 hours)
Regards
I know, but I like to know, what Volvo's intention isI googled. Id token is a know thing in oauth:
I think that Volvo's security is okay, with oauth2.0 and in addition pkce.
So, what would they do more?
Probably, you never used the old (now deprecated) API.I did not get that email
When I started to integrate my Volvo, in 2018/19, I used the, in that time, HA Python integration .
See: https://github.com/molobrakos/volvooncall.
This Python script published the data over MQTT as well. I used that to Domoticz.
Later on, I abandoned that Python script and made a full Node-RED application.
It gave me more endpoints, than the script did.
The full text of the email (in English), see below:
It ends with a Read More button which curiously links directly to the Home Assistant Volvo on Call integration page.The API you are using to communicate with your Volvo vehicle seems to be outdated. It could be that you run it through home automation technology or similar.
Unfortunately, this API will be discontinued. At Volvo Cars we are actively developing a new API specifically designed for this issue. Please check our website to keep up to date with the upcoming API and timeline.
Thank you for your understanding.
So this has been the reason, they sent me that email.
But if you never used that API, your email address, has never been registered. So there was no reason to send you an email.
I have thought about how to solve this issue with the refresh_token.
I think, I will do it as follows.
1. Check if the returned object contains a key with the name "refresh_token"
2. If so, I will use that refresh_token which is valid for 1799 seconds (at least 1 time)
3. If not, I will continue to use the existing "refresh_token", which is valid for 7 days.
4. Only in case of 3, I will trigger the authorization after 6.5 days (156 hours)
Regards
-
akamming
- Posts: 386
- Joined: Friday 17 August 2018 14:03
- Target OS: Raspberry Pi / ODroid
- Domoticz version:
- Contact:
Re: Python Plugin: Volvo EV
The refresh token under 2 is (or was, since it’s no langer there) langer valid dan 1800s. I’ve Done tests with a refresh token of more than 2 days old and could still obtain a new tokenFireWizard wrote: ↑Monday 07 July 2025 13:55 Hello @akamming,
I know, but I like to know, what Volvo's intention isI googled. Id token is a know thing in oauth:
I think that Volvo's security is okay, with oauth2.0 and in addition pkce.
So, what would they do more?
Probably, you never used the old (now deprecated) API.I did not get that email
When I started to integrate my Volvo, in 2018/19, I used the, in that time, HA Python integration .
See: https://github.com/molobrakos/volvooncall.
This Python script published the data over MQTT as well. I used that to Domoticz.
Later on, I abandoned that Python script and made a full Node-RED application.
It gave me more endpoints, than the script did.
The full text of the email (in English), see below:
It ends with a Read More button which curiously links directly to the Home Assistant Volvo on Call integration page.The API you are using to communicate with your Volvo vehicle seems to be outdated. It could be that you run it through home automation technology or similar.
Unfortunately, this API will be discontinued. At Volvo Cars we are actively developing a new API specifically designed for this issue. Please check our website to keep up to date with the upcoming API and timeline.
Thank you for your understanding.
So this has been the reason, they sent me that email.
But if you never used that API, your email address, has never been registered. So there was no reason to send you an email.
I have thought about how to solve this issue with the refresh_token.
I think, I will do it as follows.
1. Check if the returned object contains a key with the name "refresh_token"
2. If so, I will use that refresh_token which is valid for 1799 seconds (at least 1 time)
3. If not, I will continue to use the existing "refresh_token", which is valid for 7 days.
4. Only in case of 3, I will trigger the authorization after 6.5 days (156 hours)
Regards
There 7 days was communicated bu thomasddn (author of the ha integration). But I don’t see that validity it in the response when i get the first access token. It licht be valid for a jonger time
About your fix: I did the same (except for step 4, that’s not possible from within a domoticz plugin)
-
FireWizard
- Posts: 1905
- Joined: Tuesday 25 December 2018 12:11
- Target OS: Raspberry Pi / ODroid
- Domoticz version: Beta
- Location: Voorthuizen (NL)
- Contact:
Re: Python Plugin: Volvo EV
Hi @akamming,
I don't think you can re-use an old "refresh_token" later on
I'm reading currently the Volvo Developer API and I see something, I did not see before.
The 7 days is not only the vision of Thomasddn, it is also stated on the Volvo developer page:
Regards
I think, you are correct, but if you rotate the refresh_token, the old one will become invalid and will be "replaced" by the new one.The refresh token under 2 is (or was, since it’s no langer there) langer valid dan 1800s. I’ve Done tests with a refresh token of more than 2 days old and could still obtain a new token
I don't think you can re-use an old "refresh_token" later on
I'm reading currently the Volvo Developer API and I see something, I did not see before.
Have you seen that before?You are also able to retrieve a complete list of any commands that you have sent.
Would that "id_token" be related to control the limitation instead of the current 10.000 calls/day?This API is Rate Limited to prevent malicious activity or accidents that cause service disruptions. The limit is set to 100 request per minute for a combination of the user's Volvo ID and the Client ID sending the request. A given user will have 100 requests per minute per application it uses. Should this limit be exceeded, the API will respond with HTTP code 429.
The invocation methods are more strictly limited to 10 requests per minute. This limit is also set using a combination of Volvo ID and Client ID. This stricter limitation is due to the underlying system's capacity.
The 7 days is not only the vision of Thomasddn, it is also stated on the Volvo developer page:
That is what I know and I used that for my flow specification.The access_token has a short lifespan. To create a seamless end-user experience, you will need to refresh the access token before it expires.
By default, refresh token rotation is enabled. Each time you call the Refresh endpoint, a new refresh token is created, and the old token is invalidated. If not rotated, the refresh_token is valid for 7 days. After that, the user has to re-authenticate.
Regards
Who is online
Users browsing this forum: No registered users and 1 guest