Wrong vehicle location reported after 1st trip of the day

[jstammi]

I noticed that sometimes the location stayed the same in the monitor.csv though the car was moved, the ODO changed and the log reported a forced update (as I have set the flag; running in infinite mode).

Today I noticed in the api sources (v3.49.0), that the forced update logic within check_and_force_update_vehicles only really forces a status update, if the vehicle's last update time is known, else it is read only the cached state from the server (see VehicleManager line 122 with the related else in line 133). And this is not true after having created a new VehicleManager instance. And such is done at the moment on start-up (obviously), but also each day at midnight and after each 4th consecutive iteration ending with an error (whenever login is set to True on calling handle_vehicles in monitor.py).

This leads to wrong location reporting whenever

• the monitor is newly started and the vehicle location differs from the known one in the cache (e.g. moved since last usage)
• the 1st moving of the car per day
  before the 2nd iteration

What is the reason for creating a new VehicleManager instance each night? Most problems related to this issue would be solved with just keeping the one once created.
Else one could use force_refresh_all_vehicles_states instead, which really always forces a state update - afais this is exactly what is wanted and expected ... ?

The only remaining potential problem would be then imho on a start with no lines existing in monitor.csv, yet.

[jstammi]

I guess the above is only a minor issue and valid within a short time interval (until 2nd iteration). There must be some additional problem somewhere as I notice changed ODO without accordingly updated location in the monitor.csv. And vice versa btw.

I am running now a version that is logging additionally all requests towards the servers and their responses. Maybe this helps me to understand this better.

[ZuinigeRijder]

I create a new VehicleManager instance to be sure the VehicleManager instance is not somehow corrupted and there is a login once a day. Indeed this can have the side effect that the location workaround is not working when first called or after consecutive errors. But this is a workaround for the location problem, which should not have been there in the first place.

Bluelink helpdesk keeps trying (since Mai 2025) to convince me this is a problem of my car and I need to reset Bluelink. I have also seen that after a forced update, the next time the Bluelink server sends again the old location. So there are more problems at the Bluelink server.

I did not specifically told that this is a problem with the API, but that it is also a problem with the Bluelink App.

This is what I did send to Bluelink help desk:

Location of car is not updated anymore when the car is powered off

Recently I see a change in behavior in the location of my car (IONIQ 5). Previously, when the car is powered off, the location of the car is updated too. But now not anymore. When I go to the map in the Bluelink App, the location of the car is not updated to the current location. Only when I disable the location of the car icon and enable it again, the location is updated to the current location.

This is very annoying. Also others report the same problem.
Is this a software bug?

Thereafter, they keep trying to look like it is a problem of my car (several same sort of replies to my emails, again and again):

Dear Bluelink customer,

Thank you for your message.
In most cases, resetting the infotainment system will help restore full functionality of Bluelink services.
Start the connection with a soft reset. Your data will not be affected, as this is only a restart.
To do this, take a pen, go to your car, find the small hidden button in the infotainment frame and press it with the pen.
We would like to hear from you whether this has resolved your problem.

Would be good that a lot of people complain about this location update problem, so they will see a pattern in the complains.

[jstammi]

Yes, it should not be there.

For the workaround: I do not see a reason, not to call force_refresh_all_vehicles_states instead of check_and_force_update_vehicles as the only diff is, that the check method tests against the supplied minimum time since last upadate first, which is 0 in our case, making the check irrelevant ;-).

[ZuinigeRijder]

force_refresh_all_vehicles_states does always update the location, while the other method did not (always) update the location, when testing the workaround.

[jstammi]

Those are related lines 122ff of current VehicleManager for the check_and_force_update_vehicles method:

        if vehicle.last_updated_at is not None:
            _LOGGER.debug(
                f"{DOMAIN} - Time differential in seconds: {(started_at_utc - vehicle.last_updated_at).total_seconds()}"  # noqa
            )
            if (
                started_at_utc - vehicle.last_updated_at
            ).total_seconds() > force_refresh_interval:
                self.force_refresh_vehicle_state(vehicle_id)
            else:
                self.update_vehicle_with_cached_state(vehicle_id)
        else:
            self.update_vehicle_with_cached_state(vehicle_id)

The force_refresh_interval is a fundtion paramater that the monitor fixed provides as 0. The inner if will evaluate always to True leading to call the force method from there.
The only difference is to calling the force method directly is the outer if. At this is exactly the one raising the issue. As within the workaround we exactly know, that an forced update is required (due to change of ODO), therefore not doing so due to no vehicle.last_updated_at being available is IMHO wrong.

I changed this in my installation already. But unfortunately due to other problems (sry, will raise more tickets) I cannot validate any effect by today already (once again request limit exceeded :-().

I should be able to provide feedback on this tomorrow.

[jstammi]

I have also seen that after a forced update, the next time the Bluelink server sends again the old location

Yes, I see this in my monitor.csv, too. But I never noticed in the Bluelink App up to now.

This is why I implemented yesterday a tracing all https requests/responses out of the api impl to be able to see what data is incoming due to which requests. As with at least 2 layers of abstraction in between (api impl and VehicleManager) this could be also some wrong handling there.

[jstammi]

I should be able to provide feedback on this tomorrow.

As expected, switching the called method works. Whenever a new position was assumed due to ODO change within the last 2 days, the forced update then really triggered api calls and the position detected then (not before - for me the forced update is definitely required!) made totally sense.

One related hint: with the VehicleManager failing while initializing for fetching the vihicles, after having successfully fetched a token, then this instance will never again fetch any data, see Hyundai-Kia-Connect/hyundai_kia_connect_api#939.

[ZuinigeRijder]

I have added a bit better error handling. See R4.13.0

[jstammi]

After some time of driving now with recording to the monitoring.csv plus in background capturing the http request/response data *) this bases on, there are some new findings related from a day with a lot of short and long stops between a mix of some short (<15m) and medium (<45 minutes) trips within a day.

In the json data received using the api for the status, there are 3 major blocks that I currently consider relevant:

• location status, containing lat, lon and time (plus some more)
• vehicle status, containing time, elapsedTime, engine, sleepModeCheck (plus some more)
• odometer

At the moment one does either trigger a "forced update" always on odometer change, or never, depending on the setting in the config. For my analysis, the "forced update" option was enabled and I fetched infinitely every 20 minutes.

My observation for this is that

• sometimes this is needed, as the odometer changed but location did not: this seams related to an updated vehicleStatus record with containing sleepModeCheck=true, which seems to relate to a elapsedTime**) short above 3 minutes. As then the odometer change and an updated vehicleStatus is received, but locationStatus remains unchanged (yet?) and updates after a "forced update" to a location that seems correct then.
• sometimes it is not, as odometer changed and the location is updated accordingly already (but the vehiclStatus is not updated in this case btw): seen once with fetching shortly after having closed/powered-off the car and the update by the car was not related to a sleepModeCheck. As this was recorded after one of the "longer" trips, I guess the car is maintaining the states while in motion regularly, too
• and sometimes the "forced sync" makes things even worse as the result is no longer correct: when odometer and location having been updated by the car both already (same as before, incl the not updated vehicleStatus) - but still being in motion. The forced update then fetches a new location, and that seems also valid for that point of time. But the "forced update" does not result in an updated odometer. Leading to a record in the monitor.csv showing then a mix of the time and odometer as fetched initially, plus the location of the "forced update", that one did not receive a new odometer for, nor the related timestamp being used in the monitor.csv

AFAIS the logic for a "forced sync" (in fact this seems to update the location and the vehicle status only, but not the odometer should be changed to be triggered only if the odometer changed without location update in parallel. I will update my version accordingly for further testing and analysis within the next days.

*) possible by using my modified versions of api and monitor and setting monitor_trace_requests = True in the monitor.cfg

**) the elapsedTime seems to indicate the time of having closed or power-off (not yet sure about this) the car, relative to the vehicleStatus time

[ZuinigeRijder]

I am also testing a local patch, where the location is only updated, when the location date/time is newer than the previous location date/time. You need to patch Vehicle.py with the attached version in hyundai_kia_connect_api.

Vehicle.py.txt

[jstammi]

According to my recorded data this should not change anything for you. As the location time changes always whenever something changes at all - not only with a new location record, as one could/would expect. And with this changing always, especially for all 3 cases above, I would expect this to never apply and prevent from a "forced update". I would be surprised if you observe different behavious, sry to say.

Below the analysis for our trips on 6.11. (sry, I do not want to expose my location, so I removed all lat/lon).
Color scheme:

• white data unchanged and considered correct
• yellow: data item changed compared to previous one
• green: data changed and considered valid
• red: unchanged but invalid due to pending expected change (for monitor.csv: changed but invalid, or for empty cells missing; for request time: data already valid, request not needed)
• grey: not applicable for this endpoint (sry, G10:I10 is wrong wrt, should be green for lat/lon, yellow for location time)

And for completeness: this is how the data for within a response for a .../status/latest endpoint request looks like:

GET https://prd.eu-ccapi.hyundai.com:8080/api/v1/spa/vehicles/xxxxxxx/status/latest: 200 OK
response: {"retCode":"S","resCode":"0000","resMsg":{"vehicleStatusInfo":{"vehicleLocation":{"coord":{"lat":xx.xxxxxx,"lon":x.xxxxxx,"alt":0,"type":0},"head":0,"speed":{"value":0,"unit":0},"accuracy":{"hdop":0,"pdop":0},"time":"20251105212346"},"vehicleStatus":{"airCtrlOn":false,"engine":false,"doorLock":true,"doorOpen":{"frontLeft":0,"frontRight":0,"backLeft":0,"backRight":0},"trunkOpen":false,"airTemp":{"value":"02H","unit":0,"hvacTempType":1},"defrost":false,"acc":false,"evStatus":{"batteryCharge":false,"batteryStatus":67,"batteryPlugin":0,"remainTime2":{"etc1":{"value":24,"unit":1},"etc2":{"value":750,"unit":1},"etc3":{"value":185,"unit":1},"atc":{"value":185,"unit":1}},"drvDistance":[{"rangeByFuel":{"evModeRange":{"value":330,"unit":1},"totalAvailableRange":{"value":330,"unit":1}},"type":2}],"reservChargeInfos":{"reservChargeInfo":{"reservChargeInfoDetail":{"reservInfo":{"day":[1,2,4,5],"time":{"time":"0740","timeSection":0}},"reservChargeSet":true,"reservFatcSet":{"defrost":true,"airTemp":{"value":"0CH","unit":0,"hvacTempType":1},"airCtrl":0,"heating1":0}}},"offpeakPowerInfo":{"offPeakPowerTime1":{"starttime":{"time":"1200","timeSection":0},"endtime":{"time":"1200","timeSection":0}},"offPeakPowerFlag":0},"reserveChargeInfo2":{"reservChargeInfoDetail":{"reservInfo":{"day":[6],"time":{"time":"0900","timeSection":0}},"reservChargeSet":true,"reservFatcSet":{"defrost":false,"airTemp":{"value":"00H","unit":0,"hvacTempType":0},"airCtrl":0,"heating1":0}}},"reservFlag":0,"ect":{"start":{"day":9,"time":{"time":"1959","timeSection":1}},"end":{"day":9,"time":{"time":"1959","timeSection":1}}},"targetSOClist":[{"targetSOClevel":80,"dte":{"rangeByFuel":{"evModeRange":{"value":330,"unit":1},"totalAvailableRange":{"value":330,"unit":1}},"type":2},"plugType":0},{"targetSOClevel":100,"dte":{"rangeByFuel":{"evModeRange":{"value":330,"unit":1},"totalAvailableRange":{"value":330,"unit":1}},"type":2},"plugType":1}]}},"ign3":true,"hoodOpen":false,"transCond":true,"steerWheelHeat":2,"sideBackWindowHeat":0,"tirePressureLamp":{"tirePressureLampAll":0,"tirePressureLampFL":0,"tirePressureLampFR":0,"tirePressureLampRL":0,"tirePressureLampRR":0},"battery":{"batSoc":83,"batState":0},"sleepModeCheck":false,"time":"20251105212345","remoteWaitingTimeAlert":{"remoteControlAvailable":1,"remoteControlWaitingTime":168,"elapsedTime":"00:09:12"},"systemCutOffAlert":0,"tailLampStatus":0,"hazardStatus":0},"odometer":{"value":120322.7,"unit":1}}},"msgId":"xxxxxx"}

And for a forced update, endpoint .../status:

GET https://prd.eu-ccapi.hyundai.com:8080/api/v1/spa/vehicles/xxxxxx/status: 200 OK
response: {"retCode":"S","resCode":"0000","resMsg":{"airCtrlOn":true,"engine":true,"doorLock":false,"doorOpen":{"frontLeft":0,"frontRight":0,"backLeft":0,"backRight":0},"trunkOpen":false,"airTemp":{"value":"0CH","unit":0,"hvacTempType":1},"defrost":false,"acc":true,"evStatus":{"batteryCharge":false,"batteryStatus":66,"batteryPlugin":0,"remainTime2":{"etc1":{"value":26,"unit":1},"etc2":{"value":770,"unit":1},"etc3":{"value":185,"unit":1},"atc":{"value":185,"unit":1}},"drvDistance":[{"rangeByFuel":{"evModeRange":{"value":313,"unit":1},"totalAvailableRange":{"value":313,"unit":1}},"type":2}],"reservChargeInfos":{"reservChargeInfo":{"reservChargeInfoDetail":{"reservInfo":{"day":[1,2,4,5],"time":{"time":"0740","timeSection":0}},"reservChargeSet":true,"reservFatcSet":{"defrost":true,"airTemp":{"value":"0CH","unit":0,"hvacTempType":1},"airCtrl":0,"heating1":0}}},"offpeakPowerInfo":{"offPeakPowerTime1":{"starttime":{"time":"1200","timeSection":0},"endtime":{"time":"1200","timeSection":0}},"offPeakPowerFlag":0},"reserveChargeInfo2":{"reservChargeInfoDetail":{"reservInfo":{"day":[6],"time":{"time":"0900","timeSection":0}},"reservChargeSet":true,"reservFatcSet":{"defrost":false,"airTemp":{"value":"00H","unit":0,"hvacTempType":0},"airCtrl":0,"heating1":0}}},"reservFlag":0,"ect":{"start":{"day":9,"time":{"time":"1959","timeSection":1}},"end":{"day":9,"time":{"time":"1959","timeSection":1}}},"targetSOClist":[{"targetSOClevel":80,"dte":{"rangeByFuel":{"evModeRange":{"value":313,"unit":1},"totalAvailableRange":{"value":313,"unit":1}},"type":2},"plugType":0},{"targetSOClevel":100,"dte":{"rangeByFuel":{"evModeRange":{"value":313,"unit":1},"totalAvailableRange":{"value":313,"unit":1}},"type":2},"plugType":1}]}},"ign3":true,"hoodOpen":false,"transCond":false,"steerWheelHeat":0,"sideBackWindowHeat":0,"tirePressureLamp":{"tirePressureLampAll":0,"tirePressureLampFL":0,"tirePressureLampFR":0,"tirePressureLampRL":0,"tirePressureLampRR":0},"battery":{"batSoc":82,"batState":0},"sleepModeCheck":false,"time":"20251106162328","remoteWaitingTimeAlert":{"remoteControlAvailable":1,"remoteControlWaitingTime":168,"elapsedTime":"00:00:00"},"systemCutOffAlert":0,"tailLampStatus":0,"hazardStatus":0},"msgId":"xxxxxx"}

[jstammi]

Maybe I should move this to a new ticket. As this is different from the initial observation and with a different cause. And with the title not matching to this.

[jstammi]

Update: reverting that finding - missed the log of the next day, that - unfortunately - confirms just your observation :-(, an old location is provided some time later again :-( :-(.

Just to let you know, even before I could fully analyze: I faced some days ago some montor.csv entries that seem to show a jump-back of the location to the previous one, at least the way that I understood it how you described it.

And as I was still logging all outgoing requests plus the responses from the servers, I still could check if the servers are causing this. And at least after some 15 minutes quick fetching the json responses: no. It must be somehow related to the handling afterwards. The servers consistently returned the correct new location, never again the previous one - contrary to the monitor.csv.

Though this might not feel really good - in fact it is. Because in this case we do not depend on Hyundai (or related) to get this fixed ;-).

Sorry, I run out of time just now, but I will come back later again.

Update: found some more occurrences in the log and still need to check for them in detail. And hopefully with some idea on how to circumvent wrong writing to the monitor.csv.