Ritbeheertools voor Hyundai Bluelink of Kia UV Connect

[BenAW]

Met de nieuwe api 3.43.4 in mijn "oude" monitor 4.3.0 werkt alles weer als vanouds.voor mijn KIA Sportage HEV.
Moest alleen geopy en cloudscraper er bij installeren.

Fantastisch werk van de GitHub gemeenschap.

Nu de laatste monitor 4.5.3 aanpassen voor mijn Sportage en uittesten.

[ocaj]

[b]ZuinigeRijder in "Ritbeheertools voor Hyundai Bluelink of Kia UV Connect"ZuinigeRijder schreef op zaterdag 2 augustus 2025 @i.Stijn
Je kunt kijken of het nu werkt met (in hyundai_kia_connect_monitor directory):

code:

python debug.py

Dat debug-commando was ik vergeten. Dat hielp

Voordat ik ontdekte dat het een api-probleem was had ik van de week al zowel de monitor-software als de api geupdate. Daarbij had ik kennelijk een merge-foutje gemaakt van de default-config en mijn config, want brand stond nog op de default 2 en niet op 1 voor mijn Kia.
De debug-versie was daar wel behulpzaam bij, want daarin zag ik dat hij naar hyundai ging verbinden.

Maar goed, het werkt dus weer!

p.s. Bij het updaten eerder deze week moest ik zowel geopy als cloudscraper nog extra installeren.

[ Voor 6% gewijzigd door ocaj op 02-08-2025 10:15 ]

[BenAW]

In de nieuwe versie van de monitor 4.5.3 zijn de waardes voor charging en plugged nu automatisch false voor mijn HEV.

Nice

[CeesTax]

Ik heb nog steeds een 'login failed'. 'Sleeping a minute'.
heeft iemand daar ook last van?

[CeesTax]

Is inmiddels opgelost.

[Stefannn]

Nou,
Het werkt weer:
- hyundai_kia_connect_api-3.43.4 gedownload en "untarred"
- modules moeten installeren:
>> geopy-2.4.1
en die installed ook nog geographiclib-2.0
>> cloudscraper-1.2.71
en die installeerde ook nog pyparsing-3.2.3
en requests-toolbelt-1.0.0
NB: mijn vorige app was van maart-2025 dus ik had wat updates gemist

En hij doet het weer.
Ik roep de app met eigen python script aan aangezien in enkel de SOC en range wil hebben, dan is het ritbeheer tool enorme overkill.

Het werkt nu als "test". Ik moet het nog netjes maken.
Dat is wat extra werk.
Ik draai namelijk op een extreem simpele 1core, 500MHz "Via Eden" processor vergelijkbaar met 586. Traag, maar slechts 1watt.
Dat draait op "tinycore linux".
Heel prettige distributie want die draait geheel in RAM hetgeen de snelheid weer wat opkrikt EN geen diskwrites heeft dus geen disk-corruptie.
Maar goed... ik moet de "pip Install packages" wel naar een temp folder schrijven en er zogenaamde tcz packages van maken die bij een herstart worden ingelezen.
Dat doe ik ergens komende week. Nu even niet echt tijd.
Het werkt in ieder geval en dat is super.

[Stefannn]

Yesss....
Alles geüpdate
En het werkt allemaal weer.
Toppy

[ZuinigeRijder]

Sinds vanmorgen om 3:55 stopte de integratie met foutmeldingen met hyundai_kia_connect_api v3.43.3. Blijkbaar alleen voor Hyundai. Nadat ik terugging naar hyundai_kia_connect_api v3.43.0. werkte het weer.

Hebben ze de nieuwe authenticatiemethode voor Hyundai dan ingetrokken? Omdat Kia nog steeds werkt?

Zie dit issue op github.

[Stefannn]

ZuinigeRijder schreef op donderdag 7 augustus 2025 @ 14:45:
Sinds vanmorgen om 3:55 stopte de integratie met foutmeldingen met hyundai_kia_connect_api v3.43.3. Blijkbaar alleen voor Hyundai. Nadat ik terugging naar hyundai_kia_connect_api v3.43.0. werkte het weer.

Hebben ze de nieuwe authenticatiemethode voor Hyundai dan ingetrokken? Omdat Kia nog steeds werkt?

Zie dit issue op github.

Non de pi….
Laatste sync inderdaad vanmorgen 3:48
Lekker onhandig…. Hij staat te Solar-laden en mijn software stopt dat op 90%.
Net via de bluelink app gecheckt en hij is inderdaad doorgeladen tot 99%.
Mhh… ik moet daar iets van een backup op maken (dat hij ook intern bijhoudt hoeveel geladen is en de bluelink syncs enkel als error correctie gebruikt).
Maar goed…
Weer stuk dus.
Ik kijk even aan hoe GitHub hierop reageert.
Wellicht een 2-try authenticatie?

Dank voor de heads-up!!

[Stefannn]

Ik heb toch de oude api maar terug gezet. Dat was wel extreem weinig werk want de oude folder stond nog als hyundai_kia_connect_api.old op de correcte locatie. Met 2 moves was het geregeld. En het werkt weer.
Ik gok zo dat we binnenkort weer overgaan.
Zou me niet verbazen dat het een roll-back betreft omdat ze problemen met de app hebben en dat ze weer terug gaan als die zijn opgelost.
In de gaten houden dus.

[tpors]

Met mijn Kia gaat het vanaf vandaag ook weer fout. Ik had de v3.43.4 en dat ging tot gisteren prima.
Nu met 3.43.5 alles weer ok.

[ Voor 13% gewijzigd door tpors op 08-08-2025 13:11 ]

[Stefannn]

ZuinigeRijder schreef op donderdag 7 augustus 2025 @ 14:45:
Sinds vanmorgen om 3:55 stopte de integratie met foutmeldingen met hyundai_kia_connect_api v3.43.3. Blijkbaar alleen voor Hyundai. Nadat ik terugging naar hyundai_kia_connect_api v3.43.0. werkte het weer.

Hebben ze de nieuwe authenticatiemethode voor Hyundai dan ingetrokken? Omdat Kia nog steeds werkt?

Zie dit issue op github.

Kleine (waarschijnlijk onnodige) aanvulling:
- je geeft aan dat 3.43.3 er mee op hield.
- ik had 3.43.4 >> die hield er ook mee op.
3.43.5 heb ik niet getest maar daar zit alleen US content in als ik GitHub zo lees.

[BenAW]

Lijkt dat KIA weer de login procedure verandert heeft.
Login geeft weer foutmeldingen.

Nu ook melding op GitHub:
https://github.com/Hyundai-Kia-Connect/kia_uvo/issues/1260

Login in de KIA app heeft een (nieuw?!) reCaptcha "Ik ben geen robot"
Mogelijk is dit de oorzaak?

[ Voor 55% gewijzigd door BenAW op 21-08-2025 14:48 . Reden: extra info ]

[Stefannn]

BenAW schreef op donderdag 21 augustus 2025 @ 13:18:
Lijkt dat KIA weer de login procedure verandert heeft.
Login geeft weer foutmeldingen.

Mijn Hyundai loopt nog.
Maar bedankt voor de heads-up. Ik zal frequent checken.

[BenAW]

Er is een aangepaste file voor de Hyndai-Kia api, waardoor de reCaptcha vermeden kan worden.
monitor.py lijkt weer goed te werken.

De aanpassing laat de Hyundai api ongemoeid. Zal aangepast moeten worden als Hyndai zijn login verandert.

[Stefannn]

BenAW schreef op zondag 24 augustus 2025 @ 10:08:
Er is een aangepaste file voor de Hyndai-Kia api, waardoor de reCaptcha vermeden kan worden.
monitor.py lijkt weer goed te werken.

De aanpassing laat de Hyundai api ongemoeid. Zal aangepast moeten worden als Hyndai zijn login verandert.

Mijn Hyundai monitor loopt inderdaad nog

[ZuinigeRijder]

BenAW schreef op zondag 24 augustus 2025 @ 10:08:
Er is een aangepaste file voor de Hyndai-Kia api, waardoor de reCaptcha vermeden kan worden.
monitor.py lijkt weer goed te werken.

De aanpassing laat de Hyundai api ongemoeid. Zal aangepast moeten worden als Hyndai zijn login verandert.

Kun je iets meer vertellen, hoe je dit voor Kia voor elkaar gekregen hebt? En wat je moet doen?

[BenAW]

ZuinigeRijder schreef op zondag 24 augustus 2025 @ 12:36:
[...]


Kun je iets meer vertellen, hoe je dit voor Kia voor elkaar gekregen hebt? En wat je moet doen?

Natuurlijk. KIA EU heeft 22? aug de login voor de KIA app verandert door er een reCaptcha aan toe te voegen. Hierdoor was automatisch inloggen met username en password niet meer mogelijk.
Hyundai was/is nog niet aangepast..
Op GitHub kwamen er snel oplossingsrichtingen, waarmee 2 tokens konden worden afgevangen, waarvan er een manual in een script gezet moest worden. Niet erg praktisch maar het werkte.
Kort daarna kwam er een volautomatisch oplossing, waarbij één file aangepast was, die je handmatig kon overschrijven in de api.
Sinds een paar uur is er al een nieuwe api 3.44.5
https://github.com/Hyunda..._kia_connect_api/releases

Ook de HomeAssistant integratie is al aangepast:

[BenAW]

Met de nieuwe api werken monitor.py en kml.py nog als vanouds.

Debug.py heeft last van de nieuwe inlogprocedure, werkt wel, maar de output is rommelig.

Misschien toeval, maar ik zie nog geen dubbele regels voor dezelfe positie met een andere km stand.
Zou KIA het probleem opgelost hebben ?!?!

[ Voor 32% gewijzigd door BenAW op 25-08-2025 19:41 ]

[BenAW]

Vanmorgen weer problemen met de login naar KIA.
Zowel monitor.py als de HomeAssistant integration werken niet meer.
Op Github lijkt een oplossing al weer in de maak te zijn.

[ZuinigeRijder]

@BenAW Inderdaad, ik neem aan dat je deze post bedoelt.

[BenAW]

ZuinigeRijder schreef op dinsdag 26 augustus 2025 @ 11:50:
@BenAW Inderdaad, ik neem aan dat je deze post bedoelt.

Correct. Maar rustig afwachten tot er een oplossing is, en of Hyundai dezelfde route gaat als KIA.

[ZuinigeRijder]

@BenAW Er is een tijdelijke workaround voor Kia Europa gebruikers. Ik kan het niet testen, want heb geen Kia. Details in deze post. Helaas wel (nog) handmatige stappen nodig.

[BenAW]

ZuinigeRijder schreef op woensdag 27 augustus 2025 @ 10:31:
@BenAW Er is een tijdelijke workaround voor Kia Europa gebruikers. Ik kan het niet testen, want heb geen Kia. Details in deze post. Helaas wel (nog) handmatige stappen nodig.

Ik volg die discussie ook een beetje. Lijkt dat KIA EU bezig is zijn servers aan te passen / over te zetten.
Als de rust wat terug is ga ik die manual procedure proberen.
Momenteel is er geen werkende oplossing voorhanden.

EDIT: As of now, and until @marvinwankersteen says otherwise, the script is not working as Kia have changed something in the auth flow. Please don't bother trying the workaround for now.

[ Voor 14% gewijzigd door BenAW op 27-08-2025 16:34 ]

[BenAW]

Heb de tijdelijke workaround uitgetest en lijkt goed te werken.
Het is geen oplossing voor iedereen en voor altijd.
Geen idee hoe lang het token geldig blijft.

Zag tevens dat de auto positie in de app telkens op de plaats is waar de vorige stop was.

[ZuinigeRijder]

Na het wijzigen van de login procedure voor Kia gebruikers een tijdje terug, is nu de Hyundai login stuk sinds vandaag. Dus moeten we wachten totdat er een fix komt van de hyundai_kia_connect_api. Zie dit issue.

Misschien dat Hyundai hetzelfde heeft gedaan als KIA een tijdje geleden: een captcha toegevoegd aan hun inloggegevens?

[ Voor 6% gewijzigd door ZuinigeRijder op 14-10-2025 16:14 ]

[ZuinigeRijder]

Voor (Hyundai en eerder al voor Kia) gebruikers in Europa is er een oplossing. Zie deze post van dit issue.

Google translate:
Voor Kia-gebruikers:
Kia-Europe-Login-Flow
https://github.com/Hyunda...iki/Kia-Europe-Login-Flow

Voor Hyundai-gebruikers geldt dezelfde aanpak als voor Kia-Europe-Login-Flow:

Download het Python-script voor Hyundai:
https://gist.github.com/M...8fb06937da18482ddf35171ac
-> RAW-modus inschakelen
-> kopiëren/plakken in bestand: HyundaiFetchApiTokens.py

Hoe ik het in Windows deed:
Zorg ervoor dat je het Python-pakket hebt geïnstalleerd: selenium
bijv.:
python -m pip install selenium

Doe dan het volgende:

- Voer uit: python HyundaiFetchApiTokens.py

- Er wordt een Chrome-venster geopend met de juiste mobiele user-agent die Hyundai nodig heeft.

- Accepteer cookies en log in (gebruik niet 'maak een account aan') op uw Hyundai-account en los de reCAPTCHA op.

- Op de nieuwe pagina: sta toegang tot cookies toe en sta toegang tot Click2By toe.

- Zodra het inloggen slaagt, voltooit het script de OAuth-flow en print het:
Vernieuwingstoken: gebruik dit als uw "wachtwoord" in monitor.cfg
Toegangstoken: (meestal niet nodig voor clients)

- Bewaar de vernieuwingstoken op een veilige plaats (bijv. in een wachtwoordbeheerder of monitor.cfg). Plaats of deel deze niet.

- Download hyundai_kia_connect_api v3.48.1 of nieuwer: https://github.com/Hyunda..._api/releases/tag/v3.48.1

- Vervang de submap hyundai_kia_connect_api onder hyundai_kia_connect_monitor door de submap hyundai_kia_connect_api onder hyundai_kia_connect_api-3.48.1

Omdat ik een oudere Python-versie op Windows gebruikte (Python 3.9.13), moest ik in hyundai_kia_connect_api/utils.py de volgende regel 101 wijzigen:
) -> datetime.timezone | None:
naar:
) -> datetime.timezone:

Waarschijnlijk moet ik upgraden naar een latere Python-versie op Windows.
Op een Linux-versie heb ik Python 3.11.2 gebruikt, daar werkt het zonder deze wijziging in utils.py.

Overweeg daarom om de Python-versie te upgraden, want dit lijkt een functie te zijn van een nieuwere Python-versie.

[BenAW]

Is even wat "gedoe" om het token te verkrijgen, is niet voor iedereen even makkelijk denk ik.
Heb de mijne sinds begin september voor de KIA site en werkt tot nu toe probleemloos, zowel in de Ritbeheertools als in HomeAssistant.

[Stefannn]

Pfew...
Ik heb er ook een standalone script voor gefabriekt: hier
Dat was voor mij nodig omdat ik een headless systeem heb
Ook geen selenium nodig

[ Voor 5% gewijzigd door Stefannn op 16-10-2025 13:50 ]

[Stefannn]

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.

[ZuinigeRijder]

R4.10.0: Bugfix: schrijven als windows-1252 veroorzaakt een decode-exceptie

Lost dit probleem op
Wijziging naar schrijven als windows-1252 veroorzaakt een decode-uitzondering voor bestaande gegevens en veroorzaakt "Overschrijdt aantal verzoeken" in oneindige modus #84

Er zat een subtiele bug in het van achter naar voren lezen van een bestand in de binaire modus.
In plaats van:

code:

yield buffer[::-1].decode()

Werd het volgende gedaan:

code:

yield buffer.decode()[::-1]

Dit betekent dat de buffer eerst als UTF-8 werd gedecodeerd en vervolgens werd omgedraaid. Maar de buffer moet eerst worden omgedraaid voordat deze correct als UTF-8 kan worden gedecodeerd.

Ook de verkeerde tijdelijke oplossing voor het gebruik van de codering windows-1252 teruggedraaid

[ZuinigeRijder]

R4.11.0: Minder Python pakket afhankelijkheden en verbeterde README.md

hyundai_kia_connect_api heeft onlangs afhankelijkheden verwijderd EN het geopy-pakket optioneel gemaakt.

Omdat niet iedereen de Google Sheet-optie en/of MQTT zal gebruiken, heb ik ook twee pakketten optioneel gemaakt:
- gspread
- paho_mqtt

Let op: als u Google Sheets en MQTT gebruikt, moet u deze pakketten nog steeds installeren

De volgende afhankelijkheden werden verwijderd:
- cloudscraper
- geopy (alleen nodig bij gebruik van Google-adresopzoeking in plaats van openstreetmap)
- python_dateutil
- pytz

Ook README.md verbeterd.

[ZuinigeRijder]

Voor diegene die voor Kia of Hyundai een nieuw token moeten aanmaken, hier is een README welke voor beide zou moeten werken, met uitleg voor Linux/MacOS en Windows.

Alternatieve methode voor alleen Hyundai gebruikers:
Stefannn in "Het grote Hyundai Ioniq 5 topic"

[CeesTax]

Geüpdatet naar R4.11.0 en 3.48.1 van de api, Readme.md gevolgd en succesvol afgesloten en toch een 'unexpected statuscode' ontvangen bij uitvoeren van het monitor.py script. Enig idee waar ik het zou kunnen zoeken? Dank.

[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

[Stefannn]

for info,
ik heb mijn token voor Hyundai moeten refreshen.
ging zonder nieuwe problemen

[ZuinigeRijder]

@Stefannn Ja, ik heb deze ook moeten vernieuwen. Zie ook deze post op goingelectric.de.

Mijn token is na 180 dagen verlopen.

Dit waren de soorten foutmeldingen.

code:

20260417 07:56:51: WARNING: Exception: Received unexpected statusCode
20260417 07:56:51: INFO: Sleeping a minute

En:

code:

20260417 08:32:46: INFO: Login using VehicleManager
20260417 08:32:48: WARNING: Exception: Received unexpected statusCode
20260417 08:32:48: INFO: Sleeping a minute

Ik moest het token opnieuw genereren, ik heb dit script gebruikt onder Windows 11, waarna het weer werkte.

[Hippe Lip]

ZuinigeRijder schreef op zondag 19 april 2026 @ 09:35:
Mijn token is na 180 dagen verlopen.

Moeten we voortaan 2x per jaar dat token vernieuwen?
<zucht>

[ZuinigeRijder]

@Hippe Lip Ja, helaas wel

[hemertje]

@ZuinigeRijder

Energieleverancier Tibber ziet geen mogelijkheden meer om onze EV Hyundai's uit te lezen en aan te sturen (start/stop laden) sinds de laatste software aanpassingen van Hyundai

Ken jij mogelijkheden die dat (weer) mogelijk maken en waar we Tibber mee op weg kunnen helpen?

ik dacht aan jouw tools en die van https://github.com/ZuinigeRijder/hyundai_kia_connect_monitor

[ Voor 14% gewijzigd door hemertje op 20-04-2026 10:55 ]

[ZuinigeRijder]

@hemertje Ik denk dat het probleem is dat er overgestapt is van email + wachtwoord naar email + token, terwijl dat token iedere 180 dagen vernieuwd moet worden. In plaats van het wachtwoord moet dus iedere 180 dagen een nieuw token (door de gebruiker) gegenereerd worden (python benodigd, niet voor een eenvoudige eindgebruiker) en in plaats van het wachtwoord het gegenereerde token invullen.

Dan moet Tibber dus mogelijk maken om het wachtwoord iedere keer te laten veranderen. Kan me voorstellen dat ze voor een eenvoudige eindgebruiker dit niet kunnen verwachten?

Óf Tibber moet zelf om de 180 dagen een nieuw token genereren met het email adres en wachtwoord Maar daar zit dus nog een handmatige stap in, inloggen op site, kopiëren token en invullen als wachtwoord

[ Voor 7% gewijzigd door ZuinigeRijder op 20-04-2026 11:00 ]

[hemertje]

deze tool dus gebruiken als ik het goed begrijp:

https://www.goingelectric...ic.php?p=2412639#p2412639

[ZuinigeRijder]

@hemertje Ja, klopt.

[jouwheld]

Hmm lijkt alsof Hyundai de url die wordt gebruikt om token te halen, heeft geblocked.
Zowel via script op goingelectric maar ook deze https://github.com/Hyunda...ee/master/KiaHyundaiToken

[ERROR] OAuth error. Redirect URL: https://idpconnect-eu.hyu...oginUrl=&ui_locales=en-US

[ZuinigeRijder]

@jouwheld Heb je die van 2 posts terug geprobeerd? Bij mij lukte dit een week geleden.

[ZuinigeRijder]

Voor diegene die een auto hebben met ccNC infotainment systeem, het kan zijn dat de locatie niet meer goed bijgewerkt wordt. Je moet dan upgraden naar een nieuwere versie van de hyundai_kia_connect_api 4.10.2

Let op, wanneer je naar deze nieuwere versie gaat:
- de hyundai_kia_connect_monitor is hiervoor NIET aangepast
- deze hyundai_kia_connect_api versie is NIET meer compatible met Python 3.9.x, dus je moet dan naar een nieuwere versie van Python, bijvoorbeeld 3.12

[jouwheld]

ZuinigeRijder schreef op dinsdag 21 april 2026 @ 17:40:
@jouwheld Heb je die van 2 posts terug geprobeerd? Bij mij lukte dit een week geleden.

Ja die had ik als eerste geprobeerd.

edit: Vandaag werkt het wel, het tweede script van github iig.

[ Voor 12% gewijzigd door jouwheld op 22-04-2026 17:09 ]

[ZuinigeRijder]

Hier nog een manier om het token te vernieuwen, voor diegene die ook Home Assistent hebben.

DJN schreef op woensdag 29 april 2026 @ 17:09:
Voor de Hyundai / Kia Connect app gebruikers in Home Assistant. Token om in te loggen is blijkbaar maar 180 dagen geldig. Ik vond een handige home assistant app die de token direct via home assistant kan vernieuwen: https://github.com/TMA84/bluelink-refresh-token

[Hippe Lip]

ZuinigeRijder schreef op donderdag 30 april 2026 @ 07:47:
Hier nog een manier om het token te vernieuwen, voor diegene die ook Home Assistent hebben.


[...]

Ik heb ‘m geïnstalleerd, maar het lijkt erop dat je die wel elk halfjaar handmatig moet bedienen.
Maar tis wel een heel stuk eenvoudiger dan de hele procedure van voorheen.

[ZuinigeRijder]

Release R4.15.0: De hyundai_kia_connect_api genereert nu intern een token in de EU.

Sinds enige tijd moest er in de EU een token worden gegenereerd (eenmaal per 180 dagen) die in plaats van het wachtwoord werd gebruikt. Inmiddels gebruikt hyundai_kia_connect_api intern de token generatie als onderdeel van het inlogproces. De nieuwste versies van hyundai_kia_connect_api voor de EU vereisen daarom weer het echte wachtwoord.

De inloglogica voor Hyundai en Kia in Europa is gebaseerd op het bluelink-refresh-token- project. Inloggen met gebruikersnaam en wachtwoord wordt direct ondersteund voor Kia, Hyundai en Genesis (EU) - er is geen browser of handmatige token extractie nodig. Het pycryptodome-pakket (afhankelijkheid) wordt gebruikt voor RSA-wachtwoordversleuteling tijdens het inlogproces in de EU. Python 3.12 of nieuwer is vereist om dit pakket te gebruiken.

Ik heb van een gebruiker begrepen dat de oude manier van token generatie niet meer werkt. Dus als het token is verlopen, moet je hyundai_kia_connect_api upgraden naar versie 4.23.1 of hoger.

Belangrijke opmerking:
hyundai_kia_connect_api is nu afhankelijk van Python 3.12 en voor het intern genereren van tokens heb je het pycryptodome-pakket nodig.

[BenAW]

Wat zijn de ervaringen met de nieuwe login voor KIA in mijn geval?
Mijn oude setup met Token werkte niet meer.
Voor de Hyundai/KIA connect integratie in Home Assistant kwam vrij snel een update. Logt nu automatisch in met usernaam en paswoord. (Api versie 4.26.5 zover ik kan nagaan)

Vanwege de requirement voor Python 3.12 of hoger heb ik een nieuwe container aangemaakt op mijn Proxmox servertje, => Python 3.13.5. De required packages erbij, Ritbeheertools 4.15.0 er op, Hyundai-Kia-Connect api 4.27.2 er bij en draaien maar.
Helaas een waslijst met error meldingen.

Een aantal heb ik kunnen wegwerken. Bijv. in de Api staat een file KiaUvoApiCA.py waar in iets met tijdzones in Canada moet gebeuren. Canada staat niet (meer?) in de lijst met tijdzones uit TZDATA, dus dit werkt niet. Regels uit gecomment, gaf al veel minder ellende.
In KiaUvoApiEU.py staan 2 regels met Crypto.cypher en Crypto.Publickey.
Pakket Crypto is onbekend. Crypto vervangen door Cryptodome gaf ook weer wat verlichting.

Momenteel kan ik geen verbinding krijgen met https://prd.eu-ccapi.kia.com/
Server onderhoud of wat dan ook. Iig niet werken.
Lijkt dat de problemen hoofdzakelijk van de Api komen, maar dat is meer een gevoel.
De Api in HA werkt wel goed.

Benieuwd naar ervaringen en naar wat wel werkt.

[Lawrentz]

BenAW schreef op zondag 30 augustus 2026 @ 15:54:
Wat zijn de ervaringen met de nieuwe login voor KIA in mijn geval?
Mijn oude setup met Token werkte niet meer.
Voor de Hyundai/KIA connect integratie in Home Assistant kwam vrij snel een update. Logt nu automatisch in met usernaam en paswoord. (Api versie 4.26.5 zover ik kan nagaan)

Vanwege de requirement voor Python 3.12 of hoger heb ik een nieuwe container aangemaakt op mijn Proxmox servertje, => Python 3.13.5. De required packages erbij, Ritbeheertools 4.15.0 er op, Hyundai-Kia-Connect api 4.27.2 er bij en draaien maar.
Helaas een waslijst met error meldingen.

Een aantal heb ik kunnen wegwerken. Bijv. in de Api staat een file KiaUvoApiCA.py waar in iets met tijdzones in Canada moet gebeuren. Canada staat niet (meer?) in de lijst met tijdzones uit TZDATA, dus dit werkt niet. Regels uit gecomment, gaf al veel minder ellende.
In KiaUvoApiEU.py staan 2 regels met Crypto.cypher en Crypto.Publickey.
Pakket Crypto is onbekend. Crypto vervangen door Cryptodome gaf ook weer wat verlichting.

Momenteel kan ik geen verbinding krijgen met https://prd.eu-ccapi.kia.com/
Server onderhoud of wat dan ook. Iig niet werken.
Lijkt dat de problemen hoofdzakelijk van de Api komen, maar dat is meer een gevoel.
De Api in HA werkt wel goed.

Benieuwd naar ervaringen en naar wat wel werkt.

Ik maak van bluelink.py op v4.27.1 zonder errors.
Crypto is hier ook vervangen door Cryptodome en heb Canada ook moeten uitremmen.
De aansturing staat bij mij in een shell script dat ik handmatig of vanuit Domoticz kan aansturen.

[ZuinigeRijder]

@BenAW Ik heb een nieuwe DietPi versie geinstalleerd, welke Python 3.13 bevat.
Daar moest ik onder andere het volgende dingen doen.

1. Gebruik van "apt install" i.p.v. pip install of python -m pip install
2. Bij gebruik van Debian 13 of hoger kunnen de pakketnamen enigszins afwijken. Voorbeelden voor gebruik met sudo apt install:

beautifulsoup4 → python3-bs4
paho-mqtt → python3-paho-mqtt
gspread → python3-gspread
geopy → python3-geopy
python-dateutil → python3-dateutil
requests → python3-requests


3. Na installatie van pycryptodome moest ik een link leggen van Crypto naar CryptoDome.

code:

sudo ln -s /usr/lib/python3/dist-packages/Cryptodome /usr/lib/python3/dist-packages/Crypto

4. Het probleem van Canada met tzdata had ik ook.
DietPi 12.9 maakt gebruik van een oudere Debian-basis (zoals Debian 12 Bookworm). Destijds stopte Debian alle tijdzones — inclusief de verouderde links zoals Canada/* — in één groot tzdata-pakket.Vanaf nieuwere Debian-versies (zoals Debian 13 Trixie, de basis voor DietPi 13.x) hebben de pakketbeheerders het tzdata-pakket opgesplitst:tzdata: Bevat alleen nog de actuele, actieve geografische zones (zoals America/St_Johns).tzdata-legacy: Een nieuw, los pakket waarin alle oude symbolische links (zoals de Canada/-mappen) zijn geplaatst om systemen slank te houden.

code:

sudo apt update && sudo apt install tzdata-legacy -y

[BenAW]

1- Ook ik heb apt install moeten gebruiken
2- Zelfde ervaring, even zoeken naar de correcte syntax
3- Die link is een betere oplossing. Hoef je niets aan te passen met een nieuwe versie van de api.
Ik kwam ook een nieuwere library tegen: pycryptodomeX
Heb er nog niets mee gedaan.
4- Ook tzdata-legacy lijkt me een bestendiger oplossing.

Bedankt voor de reactie.

[ocaj]

Aha, liep hier ook al de hele dag te klooien en snapte niet wat ik fout deed. Blijk ik niet de enige te zijn.
Thanks, hij doet het hier weer. Mooi dat hij nu weer écht inlogged en we niet 2 keer per jaar een nieuw token hoeven te regelen

[Lawrentz]

Omdat het responsebericht van bluelink.py (bij mij) geen json of xml is maar een mengeling van platte text en json verspreid over meerdere regels, de inhoud van de geocode in het responsebericht regelmatig varieert/verspringt is het lastig de data uit elkaar te trekken en te kunnen verwerken.

Gisteren ben ik de gehele avond bezig geweest om alle errors en de variërende/verspringende selecties te verwijderen en alles te tunen. Hiervoor heb ik de frequentie van de http requests tijdelijk verhoogd ivm een hoop trial & error.

Lijkt alles eindelijk te werken krijg ik vanochtend een nieuwe errormelding.

raise error_code_mapping[response["resCode"]](response["resMsg"])
hyundai_kia_connect_api.exceptions.RateLimitingError: Exceeds number of requests - Exceeds Number of Requests.

Zucht ...
Ben benieuwd wanneer ik weer van het strafbankje af mag.

Btw, het lijkt dat 200 http requests per dag het maximum is, dus <= 8.3 http requests per uur.

[ZuinigeRijder]

@Lawrentz Vanaf vannacht 00:00 uur mag je van het strafbankje af. Bluelink.py is een eigen brouwsel?

[Lawrentz]

ZuinigeRijder schreef op woensdag 2 september 2026 @ 22:42:
@Lawrentz Vanaf vannacht 00:00 uur mag je van het strafbankje af. Bluelink.py is een eigen brouwsel?

Ah, fijn.

bluelink.py is afkomstig van https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api.
Omdat bluelink vermeld staat in de titel van dit draadje ging ik er automatisch van uit dat dit bekend is.
Nog sterker, door op het forum te zoeken naar bluelink kwam ik een paar maanden geleden in dit draadje terecht.

[ZuinigeRijder]

@Lawrentz Misschien kijk ik erover heen, maar ik zie geen bluelink.py source code binnen hyundai_kia_connect_api. Er is wel een verwijzing naar bluelinky.

[Lawrentz]

ZuinigeRijder schreef op donderdag 3 september 2026 @ 08:28:
@Lawrentz Misschien kijk ik erover heen, maar ik zie geen bluelink.py source code binnen hyundai_kia_connect_api. Er is wel een verwijzing naar bluelinky.

@ZuinigeRijder
Deze bedoel ik.
https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/blob/master/hyundai_kia_connect_api/bluelink.py

Aansturing

sudo /home/pi/.venv/bin/python /usr/local/src/hyundai_kia_connect_api/hyundai_kia_connect_api/bluelink.py --region <my-region>  --brand <my-brand> --username <"my-uid"> --password <"my-pwd"> --pin <my-pin> info --json infos.json

[ Voor 19% gewijzigd door Lawrentz op 03-09-2026 08:49 ]

[Lawrentz]

ZuinigeRijder schreef op woensdag 2 september 2026 @ 22:42:
@Lawrentz Vanaf vannacht 00:00 uur mag je van het strafbankje af. Bluelink.py is een eigen brouwsel?

@ZuinigeRijder
Ja ik ben idd sinds middernacht van het strafbankje af.
Dit nog even ter bevestiging.

[ZuinigeRijder]

Lawrentz schreef op donderdag 3 september 2026 @ 08:41:
[...]

@ZuinigeRijder
Deze bedoel ik.
https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/blob/master/hyundai_kia_connect_api/bluelink.py

Aansturing

sudo /home/pi/.venv/bin/python /usr/local/src/hyundai_kia_connect_api/hyundai_kia_connect_api/bluelink.py --region <my-region>  --brand <my-brand> --username <"my-uid"> --password <"my-pwd"> --pin <my-pin> info --json infos.json

Oké, maar deze print gewoon de informatie die in vehicle.* zit. In hyundai_kia_connect_monitor heb ik ook een debug.py zitten, die heel vehicle inhoud print (plus debug logging).

Maar waarom log je niet in via de hyundai_kia_connect_api en haal je de gewenste vehicle.* vanuit Python op, in plaats van parsen van de output van bluelink.py?
Je kunt bluelink.py als basis pakken en dit voor jezelf aanpassen naar gewenste informatie?

[ Voor 4% gewijzigd door ZuinigeRijder op 03-09-2026 10:09 ]

[Lawrentz]

ZuinigeRijder schreef op donderdag 3 september 2026 @ 10:06:
[...]


Oké, maar deze print gewoon de informatie die in vehicle.* zit. In hyundai_kia_connect_monitor heb ik ook een debug.py zitten, die heel vehicle inhoud print (plus debug logging).

Maar waarom log je niet in via de hyundai_kia_connect_api en haal je de gewenste vehicle.* vanuit Python op, in plaats van parsen van de output van bluelink.py?
Je kunt bluelink.py als basis pakken en dit voor jezelf aanpassen naar gewenste informatie?

@ZuinigeRijder
Dat was me nog niet gelukt door gebrek aan tijd enige tijd geleden.
De bluelink.py kreeg ik aan de praat en ben daar vooralsnog op verder gegaan.
Daarna was mijn account voor 3-4 weken om een duistere reden geblokkeerd.
En nadat aanloggen weer lukte kreeg ik de errors op geocode.

Wat jij beschrijft is mijn volgende stap.
Wellicht dat wat jij beschrijft me achteraf gezien minder tijd gekost zou hebben.

[Stefannn]

ZuinigeRijder schreef op donderdag 3 september 2026 @ 10:06:
[...]


Oké, maar deze print gewoon de informatie die in vehicle.* zit. In hyundai_kia_connect_monitor heb ik ook een debug.py zitten, die heel vehicle inhoud print (plus debug logging).

Maar waarom log je niet in via de hyundai_kia_connect_api en haal je de gewenste vehicle.* vanuit Python op, in plaats van parsen van de output van bluelink.py?
Je kunt bluelink.py als basis pakken en dit voor jezelf aanpassen naar gewenste informatie?

Dat is exact wat ik nu doe.
Ik heb de bluelink.py als basis gepakt waarmee de communicatie met de auto in ieder geval opgelost is. Vervolgens heb ik die aangepast zodat die enkel de voor mij interessante data naar een text file stuurt.
De monitor tooling van @ZuinigeRijder is voor mij overkill. Ik wil enkel soc en resterende km weten zodat ik mijn laadpaal kan besturen.

Nb… ik ben nog niet over naar de nieuwe versie. Ik zit nog op Python 3.9 en het gaat nog wat kruim kosten om dat geupgrade te krijgen op mijn 18 jaar oude 500MHz single core 32bit cpu. Uiteindelijk gaat me dat wel lukken. Kost wat tijd.

[ZuinigeRijder]

Stefannn schreef op donderdag 3 september 2026 @ 10:27:
[...]

Nb… ik ben nog niet over naar de nieuwe versie. Ik zit nog op Python 3.9 en het gaat nog wat kruim kosten om dat geupgrade te krijgen op mijn 18 jaar oude 500MHz single core 32bit cpu. Uiteindelijk gaat me dat wel lukken. Kost wat tijd.

Ja, voor mij was het upgraden van Python 3.9 naar Python 3.13 even een struggle. Ik heb het voordeel dat ik het een en ander op Proxmox heb draaien, op een Intel Mini PC (Intel NUC 5 i3 RYK mini 16GB 256GB Nvme, tweedehands gekocht voor 75 euro op marktplaats). Hierop heb ik 2 virtuele machines draaien, één met Home Assistant (HAOS) en één met DietPI OS (waarop hyundai_kia_connect_monitor draait).

In plaats van DietPI OS VM te upgraden, heb ik gewoon een verse laatste versie van DietPI VM ernaast gezet en hyundai_kia_connect_monitor daarna gekopieerd vanuit de oude VM. Het installeren van de nodige Python pakketten was ook nog even uitzoeken. Toen alles goed draaide, kon ik de oude DietPI VM weggooien. P.S. De DietPI OS draait met 1 GB geheugen, maar gebruikt maar iets van 300 MB.

Bij Proxmox zat ik nog op versie 8.3, deze heb ik gisteren geupgrade naar Proxmox 9.2.

[ Voor 7% gewijzigd door ZuinigeRijder op 03-09-2026 10:46 ]

[Stefannn]

ZuinigeRijder schreef op donderdag 3 september 2026 @ 10:37:
[...]


Ja, voor mij was het upgraden van Python 3.9 naar Python 3.13 even een struggle. Ik heb het voordeel dat ik het een en ander op Proxmox heb draaien, op een Intel Mini PC (Intel NUC 5 i3 RYK mini 16GB 256GB Nvme). Hierop heb ik 2 virtuele machines draaien, één met Home Assistant (HAOS) en één met DietPI OS.

In plaats van DietPI OS VM te upgraden, heb ik gewoon een verse laatste versie van DietPI VM ernaast gezet en hyundai_kia_connect_monitor daarna gekopieerd vanuit de oude VM. Het installeren van de nodige Python pakketten was ook nog even uitzoeken. Toen alles goed draaide, kon ik de oude DietPI VM weggooien. P.S. De DietPI OS draait met 1 GB geheugen, maar gebruikt maar iets van 300 MB.

Bij Proxmox zat ik nog op versie 8.3, deze heb ik gisteren geupgrade naar Proxmox 9.2.

Ha…
Ik ben nog een flink eind minimaler .
Via eden ulv 500MHz 1core 32bit processor met 1 watt tpd.
Het draait met 1G ram. Daarvan gebruik ik 600MHz maar wel met het complete OS in ram, op een ramdisk dus.
Om flash slijtage te voorkomen doe ik slechts 1 diskwrite per dag. Dat zal je met HA niet lukken.
Ik draai op tinycore Linux.
Maar goed.. dit ding heb ik 18 jaar geleden aangeschaft. Toen was er nog geen raspberry pi en ook nog geen HA.

[Bob Popcorn]

Super gaaf dit! En ook redelijk complex voor de leek. Is er al eens iemand geweest die gekeken heeft of dit te hosten valt met een beetje een front end?

[Stefannn]

Bob Popcorn schreef op donderdag 3 september 2026 @ 11:25:
Super gaaf dit! En ook redelijk complex voor de leek. Is er al eens iemand geweest die gekeken heeft of dit te hosten valt met een beetje een front end?

De hyundai server host de data al.
De standaard Hyundai host dit al "met een beetje frontend".
Dit betreft lokale software die het geautomatiseerd van de hosts af kan plukken.

[BenAW]

De ververste monitor.py met de nieuwe login draait weer als vanouds.
Probleem met de km standen was dat soms de oude km stand waarde bij een nieuwe update terecht kwam.
Wat ik nu zie is dat het vorige adres (straat etc.) bij de volgende update staat, terwijl de gps coördinaten wel ge-update zijn.
Ben ik de enige of zijn er meer van dit soort bemerkingen?

[ZuinigeRijder]

@BenAW Dat is bij mij al heeeel lang zo. De enige manier bij mij is om de volgende optie te activeren:

ZuinigeRijder in "Ritbeheertools voor Hyundai Bluelink of Kia UV Connect"

Of had je die al aanstaan?

[BenAW]

Die optie staat al op True.
Bij mij WAS het de kmstand die "bleef hangen" naar de volgende update.
Nu lijkt het juist andersom, de kmstand is correct, maar de omschrijving van de positie blijft gelijk, terwijl de gps coördinaten wel veranderd zijn.

[ZuinigeRijder]

@BenAW Dan zou het een probleem moeten zijn van hyundai_kia_connect_api, want die geeft namelijk het adres terug én de GPS coördinaten. Ik neem aan dat je ook de volgende settings hebt aanstaan?

code:

use_geocode = True
use_geocode_email = True
geocode_provider = 1

Ik weet niet of het probleem van de verkeerde locatie nu misschien opgelost is en dat je monitor_force_sync_when_odometer_different_location_workaround = False moet zetten? Alhoewel bij mij het nog niet opgevallen is dat het adres verkeerd is.

[BenAW]

Voor alle duidelijkheid, ik zie dit na de "grote" update van vorige week.
Ik zie dit in monitor.kml na draaien van kml.py.

Tot nu toe 2 duidelijke gevallen met een positie na een langere stop, en daarna een wat langere rit (15 en 24km) en vervolgens de nieuwe positie.

De workaround kijkt alleen naar de kmstand tussen 2 opeenvolgende posities begrijp ik?

[ZuinigeRijder]

@BenAW Ik gebruik momenteel versie hyundai_kia_connect_api 4.23.1.
De workaround kijkt of de kilometerstand veranderd is en doet dan een force refresh. Wanneer de kilometerstand hetzelfde blijft, wordt de locatie en adres teruggezet van meteen na de refresh.

Welke versie gebruik jij?
Ik zie wel dat er aan de versies na 4.23.1 gesleuteld is aan o.a. de location én location time. Kan zomaar zijn dat er iets niet meer goed is in hyundai_kia_connect_api.

[BenAW]

Ik gebruik 4.27.2
De workaround op False geeft geen zichtbaar verschil in monitor.kml
Zal dit voorlopig in de gaten houden.

Ik zie uiteraard hetzelfde in monitor.csv ;-)

[ Voor 16% gewijzigd door BenAW op 12-09-2026 14:23 ]

[ZuinigeRijder]

@BenAW Dan stel ik voor dat je hyundai_kia_connect_api 4.23.1 installeert met workaround op True. Wanneer dan het probleem zich daar niet voordoet, weten we dat het probleem later geïntroduceerd is.

[BenAW]

Goed plan, ga ik doen.

[BenAW]

4.23.1 geeft een login error, terug naar 4.27.2 en alles draait weer.

[ZuinigeRijder]

@BenAW Ah, ok, mijn fout. Ik heb versie hyundai_kia_connect_api-4.27.1 draaien. Met die versie zie ik jouw probleem niet. Maar jij hebt ook en Kia Sportage HEV volgens mij. Weet niet of dat een CCS2 auto is of niet. Maar je zou ook nog v4.27.1 kunnen proberen, alhoewel ik niet verwacht dat het probleem daarna geïntroduceerd is.

[BenAW]

Dat verklaart de login error. Ik blijf even op 4.27.2 met de workaround op True en rapporteer weer hier als ik iets te melden heb.
Mijn Sportage is nog een Gen5W.

[BenAW]

Vanmiddag een wat langere rit, met een langere stop, en met de workaround op True geeft dit
op de thuis positie (gps) alle data goed behalve het adres, dit is het adres van de stop.

Ga nu kijken wat er met de workaround op False gebeurt.
Mijn voorzichtige conclusie is dat KIA het probleem met de kmstand op hun server heeft opgelost, en dat de workaround daar nu een probleem mee heeft.

[BenAW]

Uurtje getennist, beide ritten daar naar toe staan nu correct in monitor.csv met de workaround op False.
Maar ja, sample size 1 .....
Lijkt er op dat KIA het kmstand probleem gefixet heeft.