Ritbeheertools voor Hyundai Bluelink of Kia UV Connect

[ZuinigeRijder]

@CeesTax Ik neem aan dat je een token gegenereerd hebt en dat gebruikt heb in plaats van wachtwoord? Kun je de foutmelding/stacktrace hier posten?

[CeesTax]

Ik had het token niet in het config bestand gezet. Na deze correctie werkte het weer. Dank voor de snelle reactie.

[Stefannn]

Stefannn schreef op vrijdag 17 oktober 2025 @ 12:09:
Het werkt allemaal weer hier.
Ik heb een "custom fixed" split-off van 3.45.1 gemaakt want 3.48.1 werkt niet met mijn python3.9.18
Zelfs de ") -> datetime.timezone | None:" fix is onvoldoende om het aan de praat te krijgen. Met mijn 3.9.18 kreeg ik ook allemaal "onbekende timezones".
Om het aan de praat te krijgen heb ik de fixes in KiaUvoApiEU.py handmatig doorgevoerd. Dat was vrij weinig werk.
Upgraden van python zal nog niet zo simpel zijn. Een hogere versie bestaat nu niet voor mijn "Tiny Core Linux" dus die zou ik zelf moeten compileren. Nog niet geprobeerd maar vaak geeft dat weer andere dependancies.
Voorlopig happy. Ik heb geen extra functies nodig.

Ter info,
In bovenstaande quote kreeg ik hyundai_kia_connect_api niet aan de praat op python3.9 een zag mezelf genoodzaakt tot het handmatig updaten van de 3.45 files.

Inmiddels heb ik het WEL op python3.9 aan de praat.
Probleem is/was dit issue, dwz "je moet een correcte tzdata package op python hebben".
Dat is echt vele malen simpeler dan een hogere python versie installeren.

Kortom.. "tip in geval je er tegenaanloop op python3.9"

[ZuinigeRijder]

@Stefannn Ik heb een andere aanpassing gedaan in hyundai_kia_connect_api, zodat deze compatible is met 3.9.

Change python 3.10 typing construct to one compatible with 3.9

Dat zit in deze release (samen met tzdata requirement): 3.49.0

[Stefannn]

ZuinigeRijder schreef op donderdag 23 oktober 2025 @ 10:41:
@Stefannn Ik heb een andere aanpassing gedaan in hyundai_kia_connect_api, zodat deze compatible is met 3.9.

Change python 3.10 typing construct to one compatible with 3.9

Dat zit in deze release (samen met tzdata requirement): 3.49.0

yep, die had ik ook gezien. Ik heb het inderdaad op 3.49 aan de praat.
Die construct had ik tijdens het troubleshooten van de login ook al handmatig gefixt. Toen liep ik echter tegen het timezone probleem op en dat kreeg ik niet gefixt.

[DJN]

Hyundai in home Assistant. Dit werkte bij mij makkelijk:

https://github.com/Hyunda...ia_connect_api/issues/925

Moest eerst wel Python installeren via https://www.python.org/downloads/

[ocaj]

Een paar weken terug heb ik een update van mijn auto (Kia) geïnstalleerd. Sindsdien heb ik er ook af en toe last van dat de locatie niet goed ge-update wordt.

Je heb daarvoor een paar maanden terug de "monitor_force_sync_when_odometer_different_location_workaround"-parameter geïntroduceerd, dus die heb ik nu aangezet.
Het werkt enigszins/soms, maar gisteren had ik wat vreemd gedrag:

2025-11-07 10:41:23+01:00, , 40745, , ; Woonadres waar ik 's morgens vertrokken was
2025-11-07 10:41:23+01:00, , 40745, , ; Locatie waar ik rond 10:41 de auto neergezet heb
2025-11-07 12:30:16+01:00, , 40753.7, ; Woonadres (klopt)
2025-11-07 12:33:53+01:00, , 40753.7, ; Adres waar ik rond 10:41 de auto neergezet had
2025-11-07 19:40:21+01:00, , 40790.8, ; Woonadres (en geen forced-sync van de locatie waar ik om 19:40 parkeerde)
2025-11-07 22:14:10+01:00, , 40827.8, ; Woonadres
2025-11-07 22:17:20+01:00, , 40827.8, ; Adres waar ik om 19:40 parkeerder (en dus niet mijn woonadres waar hij vóór de forced-sync nog wel het goede adres wist)

Als ik zoek op "Forced" in de logs zie ik:
20251107 10:45:07: INFO: Forced sync, new odometer=[40745], old_odometer=[40736.3]
20251107 19:45:07: INFO: Forced sync, new odometer=[40790.8], old_odometer=[40753.7]
20251107 22:15:07: INFO: Forced sync, new odometer=[40827.8], old_odometer=[40790.8]

Dus rond half 1 krijg ik 2 updates, ook zonder de forced-sync: eerst een goede, daarna een foute
Om kwart voor 8 probeert hij wel een forced-sync, maar die werkte niet?
En om kwart over 10 doet hij een forced-sync die me terug bij het vorige adres brengt?

Is dit iets bekend of iets nieuws?

Ik zit trouwens nog op monitor-versie R4.5.3 en op API 3.44.5 (met wat handmatige aanpassingen voor het autorisatieprobleem). Ik gebruik geen HomeAssistent, maar de kale monitor-scripts met wat eigen scripts eromheen die de data naar database en dashboards sturen.

Omdat er wel data door lijkt te komen heb ik de neiging om niet te veel te veranderen, maar als je zegt: ga eerst maar updaten naar laatste versies dan zal ik daar even voor gaan zitten.

[ZuinigeRijder]

@ocaj Ik heb ook soms dat de server bij een forced sync de goede locatie terugstuurt, maar daarna dus soms weer de oude locatie. Dit is een probleem van de server. Mijn vermoeden is dat de er meerdere servers zijn en dat deze servers (nog) niet goed gesynchroniseerd zijn. Het heeft voor jou nog geen zin om een nieuwere versie te installeren.

Lokaal ben ik wel een wijziging aan het testen, om te proberen of ik dit probleem kan ondervangen. Daarvoor heb ik Vehicle.py gepatched (dus van hyundai_kia_connect_api, niet van mijn tool), inclusief extra logging. Maar het probleem van de server is nog niet opgetreden, zover ik kan zien in de toegevoegde logging. Maar ben pas kort aan het testen met nog maar weinig ritten.

Wat ik probeer in de patch: de _location_last_set_time wordt alleen geupdate (inclusief de coördinaten):
- wanneer de datum/tijd nieuwer is
- er wordt ook geprobeerd de tijd te corrigeren (alweer een server bug), net zoals in ._last_updated_at, maar wordt alleen overgenomen wanneer de datum/tijd niet nieuwer is dan de huidige datum/tijd. <-- EDIT: blijkt dat dit zij effecten geeft, dus nieuwe lokale patch zonder dit.

Wanneer je deze kleine wijziging ook wil testen, stuur me dan een PM.

[ Voor 3% gewijzigd door ZuinigeRijder op 10-11-2025 07:55 ]

[ocaj]

Bedankt voor de snelle reactie en mooi dat je al aan een workaround werkt. Zie verder PM

[Stefannn]

@ocaj ,
Ten overvloede…
Voor mijn ioniq5,
In ieder geval sinds gister (omdat ik het gebruikte) maar wellicht al eerder is het “locatie klopt soms niet” bij mij over gegaan in “locatie klopt vrijwel nooit”.
Forced sync via het Python script loste het op maar dat heb Ik maar 1x getest.
Als het inderdaad zo is dat het issue van sporadisch naar vrijwel altijd is gegaan dan valt een “niet werkende forced sync” natuurlijk ook eerder op.

[ZuinigeRijder]

Oké, vandaag weer de situatie gehad, dat er een oude locatie binnenkwam, na een geforceerde locatie, die wel het goede adres gaf. Het blijkt dat de datum/tijd dan óók ouder is dan de vorige locatie datum/tijd (die van de geforceerde). Het corrigeren van de locatie update tijd had echter het zij effect dat deze toch overgenomen werd, dus zal die correctie uit het algoritme moeten halen. Zal weer een tijdje de locale patch laten draaien.

[ZuinigeRijder]

Het lijkt erop dat ik géén workaround kan maken voor het locatie probleem, na een forced update komt de goede locatie, maar de volgende cached update kan er weer een oude locatie komen met een nieuwere tijdstempel.

Daarnaast is het probleem van verkeerde datum/tijd stempel óók aanwezig bij de locatie, net zoals bij last_updated_at. Dus ook die wijziging is noodzakelijk bij location update die had ik er net uit gehaald om zij effecten te voorkomen

monitor.csv

code:

datetime, longitude, latitude, engineOn, 12V%, odometer, SOC%, charging, plugged, address, EV range
2025-11-09 17:10:19+01:00, lat1, lon1, False, 92, 53519.8, 56, False, 0, adres1
2025-11-10 13:11:35+01:00, lat2, lon2, False, 98, 53523.4, 52, False, 0, adres2
2025-11-10 13:37:28+01:00, lat1, lon1, False, 97, 53527, 51, False, 0, adres1
-> fout locatie 2025-11-10 13:40:37+01:00, lat2, lon2, False, 97, 53527, 51, False, 0, adres2

13:00-13:08 Vertrek van adres1 naar adres2.
13:31-13:37 Daarna van adres2 terug naar adres1.

speciale logging van lokale patch:

code:

20251110 13:23:13: INFO: 2025-11-09 17:18:45+01:00 != 2025-11-10 13:11:35+01:00 new
20251110 13:23:13: INFO: 2025-11-09 17:18:47+01:00 != 2025-11-10 13:11:34+01:00 new location time lon1, lat1
20251110 13:23:15: INFO: Forced sync, new odometer=[53523.4], old_odometer=[53519.8]
20251110 13:23:15: INFO: org=('adres1)
20251110 13:23:36: INFO: 2025-11-10 13:11:35+01:00 != 2025-11-10 13:23:33+01:00 new
20251110 13:23:36: INFO: 2025-11-10 13:11:34+01:00 != 2025-11-10 12:23:34+01:00 new location time lon2, lat2
-> tijstempel fout 20251110 13:23:36: INFO: 2025-11-10 12:23:34+01:00 < 2025-11-10 13:11:34+01:00 keep old location time lon2, lat2
20251110 13:23:37: INFO: 2025-11-10 13:11:34+01:00 != 2025-11-10 13:23:34+01:00 new location time lon2, lat2
20251110 13:23:38: INFO: upd=('adres2)
20251110 13:23:38: INFO: Writing monitor.csv line
20251110 13:23:38: INFO: curr=2025-11-10 13:11:35+01:00, lat2, lon2, False, 98, 53523.4, 52, False, 0, adres2
20251110 13:23:38: INFO: New data added or first run today or errors, running configured commands
20251110 13:38:10: INFO: 2025-11-10 13:23:34+01:00 != 2025-11-10 13:37:28+01:00 new location time lon1, lat1
20251110 13:38:13: INFO: Forced sync, new odometer=[53527], old_odometer=[53523.4]
20251110 13:38:13: INFO: org=('adres1)
20251110 13:38:23: INFO: 2025-11-10 13:23:33+01:00 != 2025-11-10 13:38:21+01:00 new
20251110 13:38:23: INFO: 2025-11-10 13:37:28+01:00 != 2025-11-10 12:38:22+01:00 new location time lon1, lat1
-> tijdstempel fout 20251110 13:38:23: INFO: 2025-11-10 12:38:22+01:00 < 2025-11-10 13:37:28+01:00 keep old location time lon1, lat1
-> goede locatie doorgegeven 20251110 13:38:24: INFO: 2025-11-10 13:37:28+01:00 != 2025-11-10 13:38:22+01:00 new location time lon1, lat1
20251110 13:38:25: INFO: upd=('adres1)
20251110 13:38:25: INFO: Writing monitor.csv line
20251110 13:38:25: INFO: curr=2025-11-10 13:37:28+01:00, lat1, lon1, False, 97, 53527, 51, False, 0, adres1
20251110 13:38:25: INFO: New data added or first run today or errors, running configured commands
20251110 13:53:10: INFO: 2025-11-10 13:38:21+01:00 != 2025-11-10 13:40:37+01:00 new
-> verkeerde locatie doorgegeven 20251110 13:53:10: INFO: 2025-11-10 13:38:22+01:00 != 2025-11-10 13:40:36+01:00 new location time lon2, lat2
20251110 13:53:13: INFO: Writing monitor.csv line
20251110 13:53:13: INFO: curr=2025-11-10 13:40:37+01:00, lat2, lon2, False, 97, 53527, 51, False, 0, adres1
20251110 13:53:13: INFO: New data added or first run today or errors, running configured commands

Let op het handmatig commentaar bij regels met -> ervoor, in de code hierboven.

[Stefannn]

ZuinigeRijder schreef op maandag 10 november 2025 @ 15:52:
Het lijkt erop dat ik géén workaround kan maken voor het locatie probleem, na een forced update komt de goede locatie, maar de volgende cached update kan er weer een oude locatie komen met een nieuwere tijdstempel.

Daarnaast is het probleem van verkeerde datum/tijd stempel óók aanwezig bij de locatie, net zoals bij last_updated_at. Dus ook die wijziging is noodzakelijk bij location update die had ik er net uit gehaald om zij effecten te voorkomen

monitor.csv

code:

datetime, longitude, latitude, engineOn, 12V%, odometer, SOC%, charging, plugged, address, EV range
2025-11-09 17:10:19+01:00, lat1, lon1, False, 92, 53519.8, 56, False, 0, adres1
2025-11-10 13:11:35+01:00, lat2, lon2, False, 98, 53523.4, 52, False, 0, adres2
2025-11-10 13:37:28+01:00, lat1, lon1, False, 97, 53527, 51, False, 0, adres1
-> fout locatie 2025-11-10 13:40:37+01:00, lat2, lon2, False, 97, 53527, 51, False, 0, adres2

13:00-13:08 Vertrek van adres1 naar adres2.
13:31-13:37 Daarna van adres2 terug naar adres1.

speciale logging van lokale patch:

code:

20251110 13:23:13: INFO: 2025-11-09 17:18:45+01:00 != 2025-11-10 13:11:35+01:00 new
20251110 13:23:13: INFO: 2025-11-09 17:18:47+01:00 != 2025-11-10 13:11:34+01:00 new location time lon1, lat1
20251110 13:23:15: INFO: Forced sync, new odometer=[53523.4], old_odometer=[53519.8]
20251110 13:23:15: INFO: org=('adres1)
20251110 13:23:36: INFO: 2025-11-10 13:11:35+01:00 != 2025-11-10 13:23:33+01:00 new
20251110 13:23:36: INFO: 2025-11-10 13:11:34+01:00 != 2025-11-10 12:23:34+01:00 new location time lon2, lat2
-> tijstempel fout 20251110 13:23:36: INFO: 2025-11-10 12:23:34+01:00 < 2025-11-10 13:11:34+01:00 keep old location time lon2, lat2
20251110 13:23:37: INFO: 2025-11-10 13:11:34+01:00 != 2025-11-10 13:23:34+01:00 new location time lon2, lat2
20251110 13:23:38: INFO: upd=('adres2)
20251110 13:23:38: INFO: Writing monitor.csv line
20251110 13:23:38: INFO: curr=2025-11-10 13:11:35+01:00, lat2, lon2, False, 98, 53523.4, 52, False, 0, adres2
20251110 13:23:38: INFO: New data added or first run today or errors, running configured commands
20251110 13:38:10: INFO: 2025-11-10 13:23:34+01:00 != 2025-11-10 13:37:28+01:00 new location time lon1, lat1
20251110 13:38:13: INFO: Forced sync, new odometer=[53527], old_odometer=[53523.4]
20251110 13:38:13: INFO: org=('adres1)
20251110 13:38:23: INFO: 2025-11-10 13:23:33+01:00 != 2025-11-10 13:38:21+01:00 new
20251110 13:38:23: INFO: 2025-11-10 13:37:28+01:00 != 2025-11-10 12:38:22+01:00 new location time lon1, lat1
-> tijdstempel fout 20251110 13:38:23: INFO: 2025-11-10 12:38:22+01:00 < 2025-11-10 13:37:28+01:00 keep old location time lon1, lat1
-> goede locatie doorgegeven 20251110 13:38:24: INFO: 2025-11-10 13:37:28+01:00 != 2025-11-10 13:38:22+01:00 new location time lon1, lat1
20251110 13:38:25: INFO: upd=('adres1)
20251110 13:38:25: INFO: Writing monitor.csv line
20251110 13:38:25: INFO: curr=2025-11-10 13:37:28+01:00, lat1, lon1, False, 97, 53527, 51, False, 0, adres1
20251110 13:38:25: INFO: New data added or first run today or errors, running configured commands
20251110 13:53:10: INFO: 2025-11-10 13:38:21+01:00 != 2025-11-10 13:40:37+01:00 new
-> verkeerde locatie doorgegeven 20251110 13:53:10: INFO: 2025-11-10 13:38:22+01:00 != 2025-11-10 13:40:36+01:00 new location time lon2, lat2
20251110 13:53:13: INFO: Writing monitor.csv line
20251110 13:53:13: INFO: curr=2025-11-10 13:40:37+01:00, lat2, lon2, False, 97, 53527, 51, False, 0, adres1
20251110 13:53:13: INFO: New data added or first run today or errors, running configured commands

Let op het handmatig commentaar bij regels met -> ervoor, in de code hierboven.

Tja...
Het "helpt niet", maar het sluit dus aan bij mijn post in het hyundai5 forum "dat locatie een groter probleem geworden is".
Met andere woorden: "je bent niet de enige.... ik heb het ook..."

Aangezien dit wel heel erg rommelig is........
zou het over een week of zo niet wat verbeteren???

[Stefannn]

ZuinigeRijder schreef op maandag 10 november 2025 @ 15:52:
.....na een forced update komt de goede locatie, maar de volgende cached update kan er weer een oude locatie komen met een nieuwere tijdstempel.

==> volgens mij heb ik exact dat afgelopen vrijdag ervaren, maar dan in de app, niet in de python-stuff.

De app gaf de auto op een plek die duidelijk verkeerd was
Maar gaf daar een heel recente tijdstempel bij

Anyway... "helpt ook niks "

[Hippe Lip]

ZuinigeRijder schreef op zondag 9 november 2025 @ 22:17:
Oké, vandaag weer de situatie gehad, dat er een oude locatie binnenkwam, na een geforceerde locatie, die wel het goede adres gaf. Het blijkt dat de datum/tijd dan óók ouder is dan de vorige locatie datum/tijd (die van de geforceerde).

@ZuinigeRijder Dan kun je daarop testen: nieuwe datum/tijd is ouder dan de laatst bekende (via een helper), dus ik negeer deze ‘nieuwe’ waarde?

[ZuinigeRijder]

Hippe Lip schreef op donderdag 13 november 2025 @ 23:00:
[...]

@ZuinigeRijder Dan kun je daarop testen: nieuwe datum/tijd is ouder dan de laatst bekende (via een helper), dus ik negeer deze ‘nieuwe’ waarde?

Helaas kom ik ook datum/tijd tegen die ouder is dan de laatst bekende, maar dan met de verkeerde coördinaten/adres

Maar ik heb een andere workaround gevonden. Wanneer je force update geconfigureerd heb, onthoud ik de coördinaten/adres/tijd na de force update en zet deze terug, zolang de km stand niet veranderd. Dat ben ik al een weekje aan het testen en dat lijkt nu goed te gaan. Zal binnenkort wel een nieuwe release maken.

[Hippe Lip]

ZuinigeRijder schreef op vrijdag 14 november 2025 @ 08:24:
Helaas kom ik ook datum/tijd tegen die ouder is dan de laatst bekende, maar dan met de verkeerde coördinaten/adres

@ZuinigeRijder
Wat ik bedoelde is dat je nieuwe info negeert als de datum-tijd-combinatie ouder is dan de laatst bekende.

Maar ik heb een andere workaround gevonden. Wanneer je force update geconfigureerd heb, onthoud ik de coördinaten/adres/tijd na de force update en zet deze terug, zolang de km stand niet veranderd. Dat ben ik al een weekje aan het testen en dat lijkt nu goed te gaan. Zal binnenkort wel een nieuwe release maken.

Zeg je nu niet net wat ik voorstelde? Alleen overschrijf jij iets en negeer ik juist die update als die ouder is (gooi ‘m weg).

[ZuinigeRijder]

Hippe Lip schreef op vrijdag 14 november 2025 @ 08:31:

Zeg je nu niet net wat ik voorstelde? Alleen overschrijf jij iets en negeer ik juist die update als die ouder is (gooi ‘m weg).

Niet helemaal, ik kijk alleen naar de kilometerstand, de datum/tijd doet er niet toe. En ik zet het terug in Vehicle, omdat ik de aanpassing in monitor.py gemaakt heb (dus de data in Vehicle is al aangepast) en niet in de API hyundai_kia_connect_api. De andere API calls werken dan gewoon met de juiste gecorrigeerde data.

[ Voor 3% gewijzigd door ZuinigeRijder op 14-11-2025 08:35 ]

[ZuinigeRijder]

Release R4.14.0: Verbeterde configureerbare oplossing voor locatie die niet up-to-date is

De volgende configureerbare oplossing is verbeterd: R4.5.2

Wanneer een geforceerde synchronisatie is gedaan, reageert de server soms, na het verkrijgen van de juiste locatie, met het retourneren van de verkeerde eerdere locatie. Wanneer een geforceerde synchronisatie is gedaan, wordt de geretourneerde locatie nu onthouden en gebruikt zolang de kilometertellerstand hetzelfde is.

Hoewel ik geen geforceerde synchronisatie wilde uitvoeren, is dit momenteel de tijdelijke oplossing voor mensen met dit probleem die een actuele locatie in monitor.csv en andere tools willen. Ik hoop dat dit aan de serverkant van Hyundai en Kia wordt opgelost (dit probleem doet zich in ieder geval in Europa voor bij beide merken), zodat de tijdelijke oplossing niet meer nodig is.

Deze geforceerde synchronisatie wordt alleen uitgevoerd wanneer de kilometertellerstand is gewijzigd en wanneer monitor.cfg is geconfigureerd als:

code:

monitor_infinite = True
monitor_force_sync_when_odometer_different_location_workaround = True