Ritbeheertools voor Hyundai Bluelink of Kia UV Connect

[ZuinigeRijder]

@CeesTax Heb je ook de een nieuwe versie van hyundai_kia_connect_api in de subdirectory van hyundai_kia_connect_monitor gezet? Want alleen een nieuwere versie van hyundai_kia_connect_api heeft die extra parameter.

- upgrade hyundai_kia_connect_api naar minimaal v3.33.3.

[ Voor 29% gewijzigd door ZuinigeRijder op 10-04-2025 08:31 ]

[CeesTax]

@ZuinigeRijder , nee, en dat was het probleem. Dank.

[ZuinigeRijder]

Ik heb al een tijdje dat de locatie niet meer actueel bijgewerkt wordt, bij het uitzetten van de auto. In de ritbeheertools is te zien dat vaak het adres nog het vorige bezoekadres is.

Kan zijn dat te maken heeft met de volgende service acties:

NE, CE Verbesserter Regellogik für Batteriekontrollsystem
Gültig bis: 05.06.2027
Kampagnencode: 40D240

NE CE ICCU aktualisieren und ggf. ICCU und Sicherung erneuen (3. Software)
Gültig bis: 17.06.2027
Kampagnencode: 40D236

Het zou zelfs door de nieuwe bluelink update kunnen komen, maar volgens mij was het probleem er al eerder?
In ieder geval geeft de server cache niet meer de laatste adres terug, na uitzetten van de IONIQ 5.

Zijn er meer mensen met dit probleem

[Stefannn]

ZuinigeRijder schreef op dinsdag 20 mei 2025 @ 08:46:
Ik heb al een tijdje dat de locatie niet meer actueel bijgewerkt wordt, bij het uitzetten van de auto. In de ritbeheertools is te zien dat vaak het adres nog het vorige bezoekadres is.

Kan zijn dat te maken heeft met de volgende service acties:

[...]


Het zou zelfs door de nieuwe bluelink update kunnen komen, maar volgens mij was het probleem er al eerder?
In ieder geval geeft de server cache niet meer de laatste adres terug, na uitzetten van de IONIQ 5.

Zijn er meer mensen met dit probleem

Zendt de auto überhaupt een bluelink update?
Ik bedoel…. Is het niet meer dat de “volledige data sync” bij uitzetten van de auto vaak niet meer gebeurt?
Zoals in ander forum aangegeven: ik heb zeer zeker ondervonden dat de batterij status veel minder vaak geactualiseerd wordt als vroeger. Dat is bij mij het geval na de laatste infotainment software update.
Kortom… kan je op de app zien dat de status refreshed was na uitzetten?

Nb…
Inmiddels roep ik de api direct aan. Jouw script was namelijk wel extreme overkill aangezien ik alleen de batterij en range wil weten voor mijn laadpaal. Daartoe moest ik wel python leren want dat kon ik nog niet maar dat is me ook gelukt .
Ik roep nu ook een “bluelink sync met auto” aan bij elke 5kWh laden. Dat maakt me onafhankelijk van de bluelink refresh grillen.

[ZuinigeRijder]

Stefannn schreef op dinsdag 20 mei 2025 @ 09:00:
[...]

Zendt de auto überhaupt een bluelink update?
Ik bedoel…. Is het niet meer dat de “volledige data sync” bij uitzetten van de auto vaak niet meer gebeurt?
Zoals in ander forum aangegeven: ik heb zeer zeker ondervonden dat de batterij status veel minder vaak geactualiseerd wordt als vroeger.
Kortom… kan je op de app zien dat de status refreshed was na uitzetten?

Ja, de eind kilometerstand en andere gegevens wordt teruggegeven van de server, alleen geen up-to-date locatie. Ook in de Bluelink App, wanneer je naar de kaart gaat, wordt daar de oude locatie aangegeven. De enige manier om de actuele locatie van de auto te krijgen, is de button van de auto-locatie uit te zetten en weer aan te zetten, waarnaar mijn vingerafdruk nodig is om de huidige locatie op te halen.

Nb…
Inmiddels roep ik de api direct aan. Jouw script was namelijk wel extreme overkill aangezien ik alleen de batterij en range wil weten voor mijn laadpaal. Daartoe moest ik wel python leren want dat kon ik nog niet maar dat is me ook gelukt .
Ik roep nu ook een “bluelink sync met auto” aan bij elke 5kWh laden. Dat maakt me onafhankelijk van de bluelink refresh grillen.

Och ja, ik kende ook geen Python, soms moet je er gewoon aan beginnen

[Stefannn]

ZuinigeRijder schreef op dinsdag 20 mei 2025 @ 09:05:

Ja, de eind kilometerstand en andere gegevens wordt teruggegeven van de server, alleen geen up-to-date locatie. Ook in de Bluelink App, wanneer je naar de kaart gaat, wordt daar de oude locatie aangegeven. De enige manier om de actuele locatie van de auto te krijgen, is de button van de auto-locatie uit te zetten en weer aan te zetten, waarnaar mijn vingerafdruk nodig is om de huidige locatie op te halen.

holy crap.... dat is veel "erger" dan alleen de api.
Defacto eigenlijk meer (of tevens) een concern voor het ioniq5 forum.
Dat betekent dus dat als ik de auto ergens in de stad heb geparkeerd ik hem zonder bovenstaande truc helemaal niet terug kan vinden.
En die truc is echt niet zo vanzelfsprekend. Totdat je bovenstaande schreef wist ik niet eens dat er een "auto locatie button" bestond.
Ik heb het net even getest en het werkt inderdaad exact zoals je beschrijft.

Ik vermoed overigens dat betreffende actie "vanuit de app een voertuig-sync" triggert (extern dus) en dat die dan dus wel compleet doorkomt.
De voertuigsync bij aankomst bestemming wordt vanuit de auto getriggert (intern) en is (dus?) incompleet.
NB: 12V accu status is ook niet compleet bij een een voertuig-trigger, dus "het past in iets van een symptoom"
(ik weet eigenlijk niet of die compleet is bij een geforceerde sync vanuit die app).

[ZuinigeRijder]

@Stefannn Ik heb afgelopen vrijdag een mail gestuurd naar [e-mail] maar nog geen antwoord terug.

Hi,

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?

Thanks,

[Stefannn]

ZuinigeRijder schreef op dinsdag 20 mei 2025 @ 10:31:
@Stefannn Ik heb afgelopen vrijdag een mail gestuurd naar [e-mail] maar nog geen antwoord terug.


[...]

Update,
mijn vrouw kwam net terug met de ioniq5,
Na parkeren werd de status ge-update en in de bluelink app op telefoon zie ik de locatie op de kaart wel recht voor de deur.
(ik heb status via api niet meer gecheckt maar jij had al geconstateerd dat de app op telefoon hetzelfde gedrag heeft)
gecheckt: ik had zelf geen update getriggered, dit was door de auto getriggered.
==> kortom.... ik heb jouw gedrag hier (nog) niet geconstateerd.

Ik houd het in de gaten komende tijd.

[ZuinigeRijder]

@Stefannn @pinquin21 heeft hetzelfde probleem:
pinquin21 in "Het grote Hyundai Ioniq 5 topic"

[TCroezing]

ZuinigeRijder schreef op dinsdag 20 mei 2025 @ 09:05:
Ja, de eind kilometerstand en andere gegevens wordt teruggegeven van de server, alleen geen up-to-date locatie. Ook in de Bluelink App, wanneer je naar de kaart gaat, wordt daar de oude locatie aangegeven. De enige manier om de actuele locatie van de auto te krijgen, is de button van de auto-locatie uit te zetten en weer aan te zetten, waarnaar mijn vingerafdruk nodig is om de huidige locatie op te halen.

Dat de locatie niet altijd correct was in de app was mij eerder al opgevallen. De auto wordt dan op een vorige of nóg oudere locatie weergegeven. Door iets later nogmaals te verversen in de app, wordt de locatie wel correct weergegeven.

[ZuinigeRijder]

@TCroezing Ja, maar dan is de locatie niet meer betrouwbaar via dit tool, want je wil helemaal niet verversen, maar alleen de server cache gebruiken. Voorheen werd de locatie bij uitzetten van de auto naar de server gestuurd en kreeg je de laatste locatie gewoon terug via de server API. Dat maakt het aspect ritbeheer heel lastig, moet je alsnog handmatig bijhouden waar je geweest bent, voor diegene die dit tool daarvoor gebruikt

[TCroezing]

ZuinigeRijder schreef op dinsdag 20 mei 2025 @ 21:06:
@TCroezing Ja, maar dan is de locatie niet meer betrouwbaar via dit tool, want je wil helemaal niet verversen, maar alleen de server cache gebruiken. Voorheen werd de locatie bij uitzetten van de auto naar de server gestuurd en kreeg je de laatste locatie gewoon terug via de server API. Dat maakt het aspect ritbeheer heel lastig, moet je alsnog handmatig bijhouden waar je geweest bent, voor diegene die dit tool daarvoor gebruikt

Eens.
Jammer jammer jammer

[ocaj]

Is dat dan een specifiek Ionic5-probleem?

Net even gekeken in de logs en van de afgelopen week of zo lijkt de locatie gewoon te kloppen en verstuurd te worden bij uitzetten van de auto (Kia Niro EV). Ik herken het probleem dus niet.

[ZuinigeRijder]

@ocaj zou kunnen. Kan ook te maken hebben met een service update of infotainment update.

[tpors]

Ik heb hetzelfde probleem met mijn Kia EV6, locatie blijft ook achterlopen.

[TCroezing]

Idem hier met een Kona

[fredkroket]

Idem hier met een Ioniq Electric.

[Stefannn]

curieus...
- ik ben naar de wasstraat gereden.
- na uitzetten van auto was de locatie op bluelink-app op telefoon wel ge-update
- maar bij status overzicht was laatste sync een half uur terug.

toen ik weer thuis kwam:
- na uitzetten van auto was de locatie op bluelink-app op telefoon opnieuw ge-update
- en bij status overzicht was laatste sync nu wel bijgewerkt.

Ik zal de monitor tool weer in een crontab zetten. Sinds ik de api zelf aanroep gebruik ik die niet meer maar als "onderzoek" geeft het wellicht wat bruikbare data.

[Stefannn]

Trouwens:
- weet je of enkel het adres niet klopt? of ook de Coordinaten?

Eerlijk gezegd vind ik het "raar" als de auto een sync doet met soms wel/geen actuele locatie.
Ik kan me echter wel goed voorstellen:
- dat de auto enkel de coordinaten doorgeeft
- dat de server daar een adres van maakt (en waarschijnlijk bij binnenkomst, dus niet later nog een retry)
- en dat de server (tijdelijk) een api-probleem met coordinaat>adres functie heeft

[ZuinigeRijder]

Stefannn schreef op donderdag 22 mei 2025 @ 11:48:
Trouwens:
- weet je of enkel het adres niet klopt? of ook de Coordinaten?

Eerlijk gezegd vind ik het "raar" als de auto een sync doet met soms wel/geen actuele locatie.
Ik kan me echter wel goed voorstellen:
- dat de auto enkel de coordinaten doorgeeft
- dat de server daar een adres van maakt (en waarschijnlijk bij binnenkomst, dus niet later nog een retry)
- en dat de server (tijdelijk) een api-probleem met coordinaat>adres functie heeft

Het adres gebeurt niet via de API, hyundai_kia_connect_api gebruikt openstreetmap of google maps om via de coördinaten het adres te bepalen. De Bluelink App laat via een andere weg de locatie zien, door via de coördinaten de positie op de kaart te tonen.

Aangezien we zien dat het niet specifiek voor de IONIQ 5 is (ook Kia EV6, Kona, Ioniq Electric, maar weer niet bij Kia Niro EV) denk ik dat wel de locatie gestuurd wordt van de auto naar de server, maar dat er een of andere manier de server software niet (altijd) de laatste locatie meestuurt.

[Stefannn]

Ervaring vandaag:
07:20: van huis gegaan met SOC=99, rit van 120km:
08:59: korte stop bij een winkel, app gecheckt: positie en andere gegevens zijn correct ge-update
09:05 opnieuw in auto en in 5 minuten naar eindbestemming
09:10 (ongeveer) aankomst eindbestemming, aldaar eerst met de aanwezigen bemoeid

9:52 check app
==>> in app staat de auto nog bij de winkel
==>> "sync tijd" in status update staat op 9:12 (dus heeft wel gesynced bij aankomst eind bestemming)
==>> op kaart "auto symbool 2x aangeklikt"
==>> auto staat nu wel op de correcte bestemming
Raar genoeg: "sync tijd" in status update onveranderd op 9:12

Ik heb thuis jouw de output van jouw monitor tool geraadpleegd (monitor.csv, wel een versie van vorig jaar zomer)
8:59: locatie nog bij mij thuis >> dat is raar want ik had ter plekke gecheckt en toen was de locatie wel ok. km-stand is 120km meer en SOC is 72 dus dat klopt.
9:12: locatie bij winkel >> ook raar want toen was ik al op de eindbestemming, km-stand is wel 1km meer dan om 8:59.
9:52: locatie eindbestemming >> dat klopt dus wel, dat is de handmatige sync vanuit de app. km-stand en SOC onveranderd.
12:44: locatie weer bij mij thuis, dat klopt want ik was weer naar huis gereden. echter.... battery SOC nog op 72, raar genoeg de km-stand wel 120km verder als 9:52
13:25:battery SOC correct op 50 en locatie klopt ook weer, de update is het gevolg van een update-push vanuit de auto op battery-tiental tijdens laden want hij hangt weer aan de lader, dat is dus ook "normaal"

Naast jouw monitor script lees ik de api tegenwoordig zelf uit.
==> ik kan ook zien dat ik tussen 12:44 en 13:25 meermalen "vanuit cash" SOC op de onjuiste 72 heb gelezen

NB,
de app-check om 8:59 reproduceer ik uit mijn hoofd maar ik begin aan mijn geheugen te twijfelen.
Om 9:52 had ik van alles screenshots gemaakt en weet ik dus heel zeker dat alles wat ik hier schrijf correct is.
Toen ik thuis kwam heb ik de app vergeten te raadplegen.

Ik concludeer een beetje dat bij een sync met de auto "enigszins random" sommige data niet doorkomt (andere verklaring welkom)
Dat de "last sync value" in de app display om 9:52 niet werd ge-update is denk ik gewoon een app-gui issue dat er los van staat.

Het is alles bij elkaar wel curieus.

[Stefannn]

En "voor wat het waard is"
Even terugkijkend in de monitor.csv output zie ik meer sequences waarbij de SOC onveranderd blijft terwijl er toch tripjes zijn gemaakt aangezien de km-stand wel verandert. En bij een volgende update (meestal bij mij thuis aan de lader want tijdens laden komt er van tijd tot tijd een geforceerde update langs) verandert de SOC wel terwijl de km-stand (terecht) gelijk blijft.
Soms zie ik de positie in monitor.csv veranderen bij een nieuwe regel met gelijke SOC maar andere km-stand.
Soms zie ik de positie in monitor.csv NIET veranderen bij een nieuwe regel met gelijke SOC maar andere km-stand.

[Stefannn]

Oh... dat opent wel de weg voor een "correctie" in het python-tool:

Na read from cash:
- check km-stand
- als km-stand veranderd is terwijl de locatie niet veranderd is --> forceer sync met auto

[ZuinigeRijder]

Stefannn schreef op vrijdag 23 mei 2025 @ 15:35:
Oh... dat opent wel de weg voor een "correctie" in het python-tool:

Na read from cash:
- check km-stand
- als km-stand veranderd is terwijl de locatie niet veranderd is --> forceer sync met auto

Een sync maakt de auto wakker en zie dan ook een dip in het 12 volt percentage m.b.v. BM2 monitor. Dus een geforceerde sync wil ik niet meer doen.

[Stefannn]

ZuinigeRijder schreef op vrijdag 23 mei 2025 @ 16:19:
[...]


Een sync maakt de auto wakker en zie dan ook een dip in het 12 volt percentage m.b.v. BM2 monitor. Dus een geforceerde sync wil ik niet meer doen.

Tja... het is maar 1 enkele sync extra. Een volgende sync zal alleen maar gebeuren als de km-stand verandert dus als je weer een stukje rijdt en dan wordt de 12V accu wel weer opgeladen lijkt me. Maar goed.... ik snap de aversie van 12V accu onnodig belasten wel. Ieder zijn keuze.

NB: Ik forceer sinds een week tijdens het laden elke 5kWh laden een sync.
Ik ging er een beetje vanuit dat de auto tijdens het laden sowieso wakker is en dat er dan geen 12V risico's zijn. Dat klopt toch wel hoop ik?

[hemertje]

Onder de 30% van de grote accu schijnt de 12V accu niet geladen te worden, tenminste dat bevestigd Hyundai NL me

[ZuinigeRijder]

@hemertje Dat moet 20% zijn, ergens in een plaatje staat 30%, maar dat klopt niet. Ik heb de 12 volt accu ook bijgeladen zien worden net boven 20%.

@Stefannn Inderdaad, wordt bij het laden, ook de 12 volt accu bijgeladen met 13.5 volt of hoger, afhankelijk hoe vol de 12 volt accu is. Ik kan het aantal keer dat ik een geforceerde sync doe natuurlijk beperken.

Echter ik denk dat Hyundai en Kia dit gewoon moeten (kunnen) oplossen. Ik heb zelf 2x een mail naar hyundai gestuurd:

16 mei 2025:

To: [e-mail]
Headline: 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?

Thanks,

En na 4 dagen een reminder:

Hi,

I did not receive an answer of the problem I asked 4 days ago. By the way, I live in the Netherlands.
See problem below....

Thanks,

Misschien is het goed als diegene die het probleem ook heeft, ook een mail stuurt naar [e-mail]


Misschien dat er dan serieuzer naar gekeken wordt, want nog steeds geen antwoord.

[Stefannn]

ZuinigeRijder schreef op vrijdag 23 mei 2025 @ 21:30:

Echter ik denk dat Hyundai en Kia dit gewoon moeten (kunnen) oplossen.

>> klopt. Als mijn laatste conclusie klopt is de oorzaak “drop-outs van datafields bij sync van auto naar cash”. Dat moeten ze aan de serverkant kunnen oplossen met een mooi protocol.
Nb, als er een fix in de auto nodig is dan zijn we in de aap gelogeerd want die software wordt maar 2x per jaar vernieuwd. Maar… zo’n protocol ding moeten ze in de server kunnen oplossen.

Ik heb zelf 2x een mail naar hyundai gestuurd

>> goed punt. Doe ik morgen..

[Stefannn]

Stefannn schreef op vrijdag 23 mei 2025 @ 22:04:
>> goed punt. Doe ik morgen..

done

[tpors]

ZuinigeRijder schreef op vrijdag 23 mei 2025 @ 21:30:

Misschien is het goed als diegene die het probleem ook heeft, ook een mail stuurt naar [e-mail]

Heb ook een mail gestuurd.

[Stefannn]

ik heb de extra monitoring uit gezet.
ik had nu namelijk 2 monitors draaien: jouw motor.py en mijn eigen monitor/control tool.
Ik wil dat niet constant aan hebben in verband met risico op interferentie.
Ik kan in ieder geval melden dat ik met regelmaat een veranderde km-stand zonder veranderd adres tegenkom. Ook vandaag nog.
Als er reden is om het weer te testen doe ik dat gaarne.

[ZuinigeRijder]

@Stefannn Bij mij loopt het adres vaak 1 adres achter. Bijvoorbeeld gisteren om 12:00 uur thuisgekomen en werd het vorige adres getoond. En zonder dat de auto gebruikt was of iets gebeurd was met de Bluelink App, was er 5 uur later een update om 17:11 met het goede adres en voor de rest precies dezelfde gegevens.

Vandaag loopt het ook 1 adres achter. Zelfs na een resfresh in de Bluelink App zorgde er niet voor dat het laatste adres werd opgehaald.

Nog curieuzer vandaag 27 mei:
09:26 aangekomen op adres 1, thuisadres wordt opgehaald (vorig adres)
11:21 refresh Bluelink Status ophalen in App, thuisadres wordt opgehaald (vorig adres).
12:29 aangekomen thuis, adres 1 wordt opgehaald (vorige adres)
13:57 aangekomen op adres 2, thuisadres wordt opgehaald (vorig adres)
14:12 aangekomen op adres 3, adres 2 wordt opgehaald (vorig adres)
15:18 thuis aangekomen, thuisadres wordt opgehaald (dus goede adres ), maar de SOC% is niet het SOC% van aankomst, maar van vertrek adres 3.
15:21 niets gedaan met de auto of Bluelink App, adres 2 wordt opgehaald (vorige adres) met het juiste SOC% van thuis en rijbereik, andere gegevens zijn hetzelfde als 15:18 (dus alles hetzelfde, behalve coördinaten, SOC%, adres en rijbereik).

P.S. Het lijkt erop dat initieel het goede adres opgehaald wordt met verkeerde SOC% en rijbereik, maar een paar minuten later overschreven met het vorige adres en juiste SOC% en rijbereik. Dus afhankelijk wanneer je de gegevens ophaalt, krijg je half goede en half foute gegevens. Ik haal om de 20 minuten op en blijkbaar bij 15:18 en 15:21 heb ik tweemaal de gegevens opgehaald, net na uitzetten auto en een paar minuten later.

Volgens mij was de foute SOC% altijd al zo en corrigeerde ik dat al in mijn andere scripts, maar het foute vorige adres is van iets recents.......

[ Voor 18% gewijzigd door ZuinigeRijder op 27-05-2025 21:01 ]

[CeesTax]

ZuinigeRijder schreef op dinsdag 20 mei 2025 @ 08:46:
Ik heb al een tijdje dat de locatie niet meer actueel bijgewerkt wordt, bij het uitzetten van de auto. In de ritbeheertools is te zien dat vaak het adres nog het vorige bezoekadres is.

Kan zijn dat te maken heeft met de volgende service acties:

[...]


Het zou zelfs door de nieuwe bluelink update kunnen komen, maar volgens mij was het probleem er al eerder?
In ieder geval geeft de server cache niet meer de laatste adres terug, na uitzetten van de IONIQ 5.

Zijn er meer mensen met dit probleem

Bij mij ook het geval, geen locatie gegevens van geparkeerde auto in csv bestand.

[Stefannn]

ZuinigeRijder schreef op dinsdag 27 mei 2025 @ 20:55:
@Stefannn Bij mij loopt het adres vaak 1 adres achter. Bijvoorbeeld gisteren om 12:00 uur thuisgekomen en werd het vorige adres getoond. En zonder dat de auto gebruikt was of iets gebeurd was met de Bluelink App, was er 5 uur later een update om 17:11 met het goede adres en voor de rest precies dezelfde gegevens.

Vandaag loopt het ook 1 adres achter. Zelfs na een resfresh in de Bluelink App zorgde er niet voor dat het laatste adres werd opgehaald.

Nog curieuzer vandaag 27 mei:
09:26 aangekomen op adres 1, thuisadres wordt opgehaald (vorig adres)
11:21 refresh Bluelink Status ophalen in App, thuisadres wordt opgehaald (vorig adres).
12:29 aangekomen thuis, adres 1 wordt opgehaald (vorige adres)
13:57 aangekomen op adres 2, thuisadres wordt opgehaald (vorig adres)
14:12 aangekomen op adres 3, adres 2 wordt opgehaald (vorig adres)
15:18 thuis aangekomen, thuisadres wordt opgehaald (dus goede adres ), maar de SOC% is niet het SOC% van aankomst, maar van vertrek adres 3.
15:21 niets gedaan met de auto of Bluelink App, adres 2 wordt opgehaald (vorige adres) met het juiste SOC% van thuis en rijbereik, andere gegevens zijn hetzelfde als 15:18 (dus alles hetzelfde, behalve coördinaten, SOC%, adres en rijbereik).

P.S. Het lijkt erop dat initieel het goede adres opgehaald wordt met verkeerde SOC% en rijbereik, maar een paar minuten later overschreven met het vorige adres en juiste SOC% en rijbereik. Dus afhankelijk wanneer je de gegevens ophaalt, krijg je half goede en half foute gegevens. Ik haal om de 20 minuten op en blijkbaar bij 15:18 en 15:21 heb ik tweemaal de gegevens opgehaald, net na uitzetten auto en een paar minuten later.

Volgens mij was de foute SOC% altijd al zo en corrigeerde ik dat al in mijn andere scripts, maar het foute vorige adres is van iets recents.......

OK.. ik heb de monitor.csv nog wat preciezer bekeken.
Conclusies:
1/ het gaat ook vaak goed. In ongeveer de helft van de gevallen zijn SOC en locatie correct ge-update na een stukje rijden.
2/ redelijk random wordt ofwel de locatie, danwel de SOC niet ge-update. Beiden tegelijk niet ge-update heb ik niet gezien maar daarvoor is het aantal samples ook te klein. SOC-update fails zijn sowieso minder goed te zien omdat de kleine ritjes naar de supermarkt geen SOC verandering geven.
3/ ik heb inderdaad ook gezien dat de positie ge-update werd naar "vorige locatie".
Dus:
- na een rit naar A geen locatie update
- na de volgende rit naar B locatie update naar "A"
- bij geforceerde update locatie B
4/ inderdaad in alle gevallen is SOC en locatie correct bij de volgende update. Ook hier is de sample grootte te klein om dat met zekerheid te weten. In ieder geval dus wel "heel vaak" en misschien wel "altijd"

Kwa "oplossing" is 1 geforceerde car-sync in geval van "km stand veranderd maar locatie niet" wel te doen. Daar zal de 12V accu niet van slijten. (het is ook niet anders dan dat je af en toe vanuit de app een refresh afdwingt).

Verder viel me nog iets op:
- Tot 1 April zat de 12V accu rond de 80%, minimaal 75%, maximaal 86%.
- Sinds 3 april zit de 12V accu steevast boven de 90%: minimaal 90%, maximaal 99%.
In beide gevallen was de monitor periode maar 1 a 2 weken aangezien ik jouw tool niet standaard gebruik. Het verschil is echter nogal opvallend groot. Vooral omdat het maximum tot 1 april lager is dan het minimum na 3 april. Ik kan me geen software update herinneren in die periode.

[ Voor 3% gewijzigd door Stefannn op 28-05-2025 08:15 ]

[ZuinigeRijder]

Stefannn schreef op woensdag 28 mei 2025 @ 08:11:
[...]

3/ ik heb inderdaad ook gezien dat de positie ge-update werd naar "vorige locatie".
Dus:
- na een rit naar A geen locatie update
- na de volgende rit naar B locatie update naar "A"
- bij geforceerde update locatie B

Bij een geforceerde status update via de Bluelink App, wordt bij mij de locatie NIET bijgewerkt naar de huidige locatie. Wel wanneer je via de Bluelink App -> Kaart -> AutoLocatie symbool uit en aanzetten.

4/ inderdaad in alle gevallen is SOC en locatie correct bij de volgende update. Ook hier is de sample grootte te klein om dat met zekerheid te weten. In ieder geval dus wel "heel vaak" en misschien wel "altijd"

Bij mij loopt de locatie echter wél achter en is niet correct. Bijvoorbeeld nu wordt nog steeds het vorige adres getoond na de laatste update van 15:21.

Kwa "oplossing" is 1 geforceerde car-sync in geval van "km stand veranderd maar locatie niet" wel te doen. Daar zal de 12V accu niet van slijten. (het is ook niet anders dan dat je af en toe vanuit de app een refresh afdwingt).

Ik heb via de hyundai_kia_connect_monitor een geforceerde sync gedaan:

code:

MANAGER.check_and_force_update_vehicles(0)

Dan komt inderdaad de huidige locatie terug. Blijkbaar in de Bluelink App alleen via de kaart AutoLocatie symbool uit en aanzetten.

Het geforceerd ophalen van huidige locatie, zou betekenen dat iedere rit er 1 geforceerde sync gaat gebeuren. Er zit ook een (andere?) limiet aan het aantal geforceerde syncs.

Maar nog steeds denk ik dat Hyundai/Kia dit aan de server kant moet oplossen. Alleen zij hebben nog steeds niet gereageerd op mijn 2 mailtjes

[Stefannn]

ZuinigeRijder schreef op woensdag 28 mei 2025 @ 09:29:

Bij een geforceerde status update via de Bluelink App, wordt bij mij de locatie NIET bijgewerkt naar de huidige locatie. Wel wanneer je via de Bluelink App -> Kaart -> AutoLocatie symbool uit en aanzetten.

Ah, daar ben ik denk ik onzorgvuldig en heb ik app/status, app/kaart en api_force_update over 1 kam geschoren:
- in ieder geval middels de api_force_update
- en in ieder geval middels app/kaart
- app/status weet ik niet zeker (ben ik ook gewoon vergeten)

wel een beetje bizar, ik zou zeggen dat de app de auto ook gewoon via de api aanroept.
Is er dan een aparte api voor met/zonder update?

Bij mij loopt de locatie echter wél achter en is niet correct. Bijvoorbeeld nu wordt nog steeds het vorige adres getoond na de laatste update van 15:21.

Misschien was ik niet duidelijk, wat ik bedoelde te zeggen is dat ALS de locatie incorrect is,..... in ALLE gevallen de locatie WEL correct is na 1 enkele api_force_update (geen retries nodig)
Ik geloof dat je hetzelfde zegt.

Maar nog steeds denk ik dat Hyundai/Kia dit aan de server kant moet oplossen. Alleen zij hebben nog steeds niet gereageerd op mijn 2 mailtjes

klopt, en ik heb ook nog geen reactie.

NB, als het een "cash probleem" aan de auto kant is in plaats van een communicatie error vrees ik dat hiervoor een auto-software-update nodig is. De infotainment update van dit voorjaar is net geweest dus dat zal nog wel even duren.
Aan de andere kant... als ze "nu" een ticket accepteren dan zal implementeren, testen, en release-acceptatie zeker een half jaar duren dus kan het de najaar update nog net halen. Alleen hadden we afgelopen herfst geen update.

[Stefannn]

NB,
wat code uit vehicle.py:

code:

@property
    def location_last_updated_at(self):
        """
        return last location datetime.
        last_updated_at and location_last_updated_at can be different.
        The newest of those 2 can be computed by the caller.
        """
        return self._location_last_set_time

    @location.setter
    def location(self, value):
        self._location_latitude = value[0]
        self._location_longitude = value[1]
        self._location_last_set_time = get_safe_local_datetime(value[2])

alarming: last_updated_at and location_last_updated_at can be different.

En uit HyundaiBlueLinkApiUSA.py:

code:

def _get_vehicle_location(self, token: Token, vehicle: Vehicle):
        """
        Get the location of the vehicle
        This logic only checks odometer move in the update.
        This call doesn't protect from overlimit as per:
        Only update the location if the odometer moved AND if the last location
        update was over an hour ago.
        Note that the "last updated" time is initially set to three hours ago.
        This will help to prevent too many calls to the API
        """
        url = self.API_URL + "rcs/rfc/findMyCar"
        headers = self._get_vehicle_headers(token, vehicle)
        try:
            response = self.sessions.get(url, headers=headers)
            response_json = response.json()
            _LOGGER.debug(f"{DOMAIN} - Get Vehicle Location {response_json}")
            if response_json.get("coord") is not None:
                return response_json
            else:
                if (
                    response_json.get("errorCode", 0) == 502
                    and response_json.get("errorSubCode", "") == "HT_534"
                ):
                    _LOGGER.warn(
                        f"{DOMAIN} - get vehicle location rate limit exceeded."
                    )
                else:
                    _LOGGER.warn(
                        f"{DOMAIN} - Unable to get vehicle location: {response_json}"
                    )

        except Exception as e:
            _LOGGER.warning(
                f"{DOMAIN} - Get vehicle location failed: {e}", exc_info=True
            )

        _LOGGER.debug(f"{DOMAIN} - Get Vehicle Location result is None")
        return None

alarming:
This logic only checks odometer move in the update.
This call doesn't protect from overlimit as per:
Only update the location if the odometer moved AND if the last location
update was over an hour ago.

Kortom: Ik heb het nog niet in detail bekeken maar ik heb toch het gevoel dat de api ook nog de nodige "error correctie" toevoegt die wellicht niet helemaal goed functioneert.

[ Voor 12% gewijzigd door Stefannn op 28-05-2025 11:37 ]

[Stefannn]

Sorry voor de wat flaky posting, maar ik kan ook niet weten wat je al gelezen hebt.

Wat me opvalt in HyundaiBlueLinkApiUSA.py:

def _get_vehicle_location(....
roept: url = self.API_URL + "rcs/rfc/findMyCar"

def _get_vehicle_status(...
roept: url = self.API_URL + "rcs/rvs/vehicleStatus"

Kortom: 2 verschillende url's voor status & locatie.
Dat zou verklaren waarom jij constateert dat app_update van status de locatie NIET update en app_update van kaart wel.

def _get_vehicle_location(....
mompelt dan ook nog wat over "aantal calls beperken" (hetgeen natuurlijk logisch is gezien de 12V accu)

Kortom: het zou best wel eens kunnen zijn dat de api de locatie-call teveel onderdrukt.

[ZuinigeRijder]

Stefannn schreef op woensdag 28 mei 2025 @ 11:35:
NB,
wat code uit vehicle.py:

code:

@property
    def location_last_updated_at(self):
        """
        return last location datetime.
        last_updated_at and location_last_updated_at can be different.
        The newest of those 2 can be computed by the caller.
        """
        return self._location_last_set_time

    @location.setter
    def location(self, value):
        self._location_latitude = value[0]
        self._location_longitude = value[1]
        self._location_last_set_time = get_safe_local_datetime(value[2])

alarming: last_updated_at and location_last_updated_at can be different.

Niet helemaal, deze location_last_updated_at is door mij toegevoegd
Er wordt volgens mij niets mee gedaan in de hyundai_kia_connect_api, wel in monitor.py om de laatste update datum/tijd in monitor.csv te zetten..

En uit HyundaiBlueLinkApiUSA.py:

code:

def _get_vehicle_location(self, token: Token, vehicle: Vehicle):
        """
        Get the location of the vehicle
        This logic only checks odometer move in the update.
        This call doesn't protect from overlimit as per:
        Only update the location if the odometer moved AND if the last location
        update was over an hour ago.
        Note that the "last updated" time is initially set to three hours ago.
        This will help to prevent too many calls to the API
        """
        url = self.API_URL + "rcs/rfc/findMyCar"
        headers = self._get_vehicle_headers(token, vehicle)
        try:
            response = self.sessions.get(url, headers=headers)
            response_json = response.json()
            _LOGGER.debug(f"{DOMAIN} - Get Vehicle Location {response_json}")
            if response_json.get("coord") is not None:
                return response_json
            else:
                if (
                    response_json.get("errorCode", 0) == 502
                    and response_json.get("errorSubCode", "") == "HT_534"
                ):
                    _LOGGER.warn(
                        f"{DOMAIN} - get vehicle location rate limit exceeded."
                    )
                else:
                    _LOGGER.warn(
                        f"{DOMAIN} - Unable to get vehicle location: {response_json}"
                    )

        except Exception as e:
            _LOGGER.warning(
                f"{DOMAIN} - Get vehicle location failed: {e}", exc_info=True
            )

        _LOGGER.debug(f"{DOMAIN} - Get Vehicle Location result is None")
        return None

alarming:
This logic only checks odometer move in the update.
This call doesn't protect from overlimit as per:
Only update the location if the odometer moved AND if the last location
update was over an hour ago.

Kortom: Ik heb het nog niet in detail bekeken maar ik heb toch het gevoel dat de api ook nog de nodige "error correctie" toevoegt die wellicht niet helemaal goed functioneert.

Deze code is niet de EU versie, maar de USA versie. Je moet in KiaUvoApiEU.py kijken
In die laatste wordt de locatie alleen opgehaald bij force refresh en anders wordt de laatste locatie uit de status gehaald, want bij EU staat daar de cache van de server gehaald.

[Stefannn]

ZuinigeRijder schreef op woensdag 28 mei 2025 @ 12:27:
Deze code is niet de EU versie, maar de USA versie. Je moet in KiaUvoApiEU.py kijken
In die laatste wordt de locatie alleen opgehaald bij force refresh en anders wordt de laatste locatie uit de status gehaald, want bij EU staat daar de cache van de server gehaald.

Ah… ik dacht dat dat enkel kia was .

[Stefannn]

Toch is er iets curieus...

Zoals jij zegt: voor europa is er slechts 1 status call waar de locatie ook in zit
==> ik zie dat inderdaad in KiaUvoApiEU.py

Maar:
- je had ook gevonden dat de locatie niet wordt geüpdatet als je in de app een "status update" doet.
- en ik had zelf gevonden dat als ik in de app via de kaart-button een update doe de "status refresh tijd" bij de status page niet verandert (heb ik nog niet gedubbelchecked)
==> dat suggereert dus dat er toch 2 calls zijn voor status & locatie.

Overigens maakt het feit dat de app na parkeren de verkeerde locatie toont wel dat dit een echt "must solve Hyundai probleem" is. Niet enkel iets voor hobby-api gebruikers.

[ZuinigeRijder]

Stefannn schreef op woensdag 28 mei 2025 @ 12:59:
Toch is er iets curieus...

Zoals jij zegt: voor europa is er slechts 1 status call waar de locatie ook in zit
==> ik zie dat inderdaad in KiaUvoApiEU.py

Maar:
- je had ook gevonden dat de locatie niet wordt geüpdatet als je in de app een "status update" doet.
- en ik had zelf gevonden dat als ik in de app via de kaart-button een update doe de "status refresh tijd" bij de status page niet verandert (heb ik nog niet gedubbelchecked)
==> dat suggereert dus dat er toch 2 calls zijn voor status & locatie.

De Bluelink App maakt geen gebruik van hyundai_kia_connect_monitor API (open source), dus hoe Hyundai het geïmplementeerd heeft in hun Bluelink App is onbekend.

[Stefannn]

En bij een "force refresh" worden state en location toch apart ge-update.

code:

def force_refresh_vehicle_state(self, token: Token, vehicle: Vehicle) -> None:
        state = self._get_forced_vehicle_state(token, vehicle)
        state["vehicleLocation"] = self._get_location(token, vehicle)

Eigenlijk suggereert dat:
- je kan de locatie apart updaten zonder de state te updaten (de app lijkt dat ook inderdaad te doen)
--> dat zou een fix kunnen zijn voor het monitor.py script waarmee je slechts 1 in plaats van 2 calls doet (en wellicht hoeft de auto daarvoor niet/minder wakker te worden)

- het kan nu ook wel degelijk zo zijn dat de server hier iets niet goed doet. De server krijgt wellicht status updates van de auto zonder locatie en doet er normaliter een locatie request achteraan om de status compleet te maken en dat werkt nu wat minder goed.

[Stefannn]

ZuinigeRijder schreef op woensdag 28 mei 2025 @ 13:02:
[...]


De Bluelink App maakt geen gebruik van hyundai_kia_connect_monitor API (open source), dus hoe Hyundai het geïmplementeerd heeft in hun Bluelink App is onbekend.

niet van de open source API client,
wel van de hyundai API server.

[ZuinigeRijder]

Ik heb een lokale test lopen met een monitor.cfg setting:

code:

monitor_force_sync_when_odometer_different_location_workaround = True

Wanneer er iets weggeschreven wordt naar monitor.csv:

code:

            # workaround for location is not updated anymore since may 2025
            # force sync when odometer is different when configured
            if (
                MONITOR_FORCE_SYNC_WHEN_ODOMETER_DIFFERENT_LOCATION_WORKAROUND
                and len(list_current_line) == 11
                and len(list_last_line) == 11
                and list_current_line[5].strip() != list_last_line[5].strip()
            ):  # odometer different
                print(f"Forced sync:\nline=[{line}]\nlast=[{last_line}]")
                MANAGER.check_and_force_update_vehicles(0)  # forced sync

[Stefannn]

ZuinigeRijder schreef op woensdag 28 mei 2025 @ 16:03:
Ik heb een lokale test lopen met een monitor.cfg setting:

code:

monitor_force_sync_when_odometer_different_location_workaround = True

Wanneer er iets weggeschreven wordt naar monitor.csv:

code:

            # workaround for location is not updated anymore since may 2025
            # force sync when odometer is different when configured
            if (
                MONITOR_FORCE_SYNC_WHEN_ODOMETER_DIFFERENT_LOCATION_WORKAROUND
                and len(list_current_line) == 11
                and len(list_last_line) == 11
                and list_current_line[5].strip() != list_last_line[5].strip()
            ):  # odometer different
                print(f"Forced sync:\nline=[{line}]\nlast=[{last_line}]")
                MANAGER.check_and_force_update_vehicles(0)  # forced sync

mooi!
Ik kan het voorlopig niet voor je testen.
Ik sta op het punt een megatrip te maken met de ioniq5 & kip shelter caravan.
Wellicht zie je me op andere fora

nb... ik kan niet de complete code zien maar ik neem aan dat je dit alleen aanroept "if location unchanged".
Daarnaast zou ik er wel een "max 1x" op zetten.

[ZuinigeRijder]

Stefannn schreef op woensdag 28 mei 2025 @ 16:51:
[...]
nb... ik kan niet de complete code zien maar ik neem aan dat je dit alleen aanroept "if location unchanged".

Dat gaat niet (altijd) werken. Wanneer de location onveranderd is, dan kan het nog de verkeerde zijn.
Voorbeeld:
1. monitor.py is net langsgeweest
2. je gaat met de auto van adres 1 naar adres 2.
3. je gaat met de auto van adres 2 naar adres 1
4. je gaat met de auto van adres 1 naar adres 3
5. monitor.py komt langs.

if location unchanged is hier waar (adres 1 regel 1 == adres 1 (vorige adres) regel 3). Maar toch moet er een forced sync gebeuren.

Daarnaast zou ik er wel een "max 1x" op zetten.

Daar moet ik nog over nadenken.

Maar zie mogelijk ook een ander probleem.
Voorbeeld:
1. monitor.py is net langsgeweest
2. je gaat met de auto van adres 1 naar adres 2.
3. je gaat rijden naar adres 3
4. monitor.py komt langs tijdens rijden, force sync.

De km stand van 2. is anders dan van 1, dus je doet in force sync. Je krijgt dan de km stand van het moment van opvragen van 3. tijdens het rijden en de locatie van dat moment van 3. Dan kloppen de begin en eindstanden niet, de SOC% niet, etc.En ook de locatie klopt dan niet bij het eindadres. 100% bulletproof krijg ik het niet, denk ik.

[Stefannn]

ZuinigeRijder schreef op woensdag 28 mei 2025 @ 21:48:
[...]


Dat gaat niet (altijd) werken. Wanneer de location onveranderd is, dan kan het nog de verkeerde zijn.
Voorbeeld:
1. monitor.py is net langsgeweest
2. je gaat met de auto van adres 1 naar adres 2.
3. je gaat met de auto van adres 2 naar adres 1
4. je gaat met de auto van adres 1 naar adres 3
5. monitor.py komt langs.

if location unchanged is hier waar (adres 1 regel 1 == adres 1 (vorige adres) regel 3). Maar toch moet er een forced sync gebeuren.


[...]

Daar moet ik nog over nadenken.

Maar zie mogelijk ook een ander probleem.
Voorbeeld:
1. monitor.py is net langsgeweest
2. je gaat met de auto van adres 1 naar adres 2.
3. je gaat rijden naar adres 3
4. monitor.py komt langs tijdens rijden, force sync.

De km stand van 2. is anders dan van 1, dus je doet in force sync. Je krijgt dan de km stand van het moment van opvragen van 3. tijdens het rijden en de locatie van dat moment van 3. Dan kloppen de begin en eindstanden niet, de SOC% niet, etc.En ook de locatie klopt dan niet bij het eindadres. 100% bulletproof krijg ik het niet, denk ik.

Ja.
Komt erop neer dat het alleen werkt als je nadat op een locatie bent aangekomen niet wegrijdt totdat het monitor.py script heeft gedraaid.
Voor een koerier zal het dus niet werken .
Ik draaide het script elk kwartier. Behalve voor de hele korte tochtjes naar de supermarkt werkt het in de praktijk dan toch heel aardig. Ik ben toch eigenlijk altijd wel minimaal een kwartier op een bestemming.

[ZuinigeRijder]

@Stefannn Ik ga een test doen met een max aantal keer per dag een force sync doen, wanneer de km stand verschillend is (instelbaar, default 10). Ben ook benieuwd of mijn BM2 monitor daar iets van terug ziet in de 12 volt logging.

Er is nog een zij effect. Een force sync verandert de last_updated_at én location_last_updated_at. Dus ik moet bij een verschillende km stand éérst een force sync doen en dan de last_updated_at wegschrijven van vóór de force sync, anders is de tijd namelijk de tijd van wegschrijven naar monitor.csv. En de volgende ronde, komt er dan mogelijk eenzelfde regel in monitor.csv met alleen de eindtijd verschillend. In principe waren tot nu (afgezien van forced sync) de tijden wanneer de auto uitgezet werd.

Moet even kijken of ik dan geen regel schrijf wanneer alléén de tijd verschillend is.

[Stefannn]

ZuinigeRijder schreef op donderdag 29 mei 2025 @ 08:49:
@Stefannn Ik ga een test doen met een max aantal keer per dag een force sync doen, wanneer de km stand verschillend is (instelbaar, default 10). Ben ook benieuwd of mijn BM2 monitor daar iets van terug ziet in de 12 volt logging.

Er is nog een zij effect. Een force sync verandert de last_updated_at én location_last_updated_at. Dus ik moet bij een verschillende km stand éérst een force sync doen en dan de last_updated_at wegschrijven van vóór de force sync, anders is de tijd namelijk de tijd van wegschrijven naar monitor.csv. En de volgende ronde, komt er dan mogelijk eenzelfde regel in monitor.csv met alleen de eindtijd verschillend. In principe waren tot nu (afgezien van forced sync) de tijden wanneer de auto uitgezet werd.

Moet even kijken of ik dan geen regel schrijf wanneer alléén de tijd verschillend is.

Als je dan toch BM2 monitoring gaat doen....
Dan kan je overwegen te testen of er 12V impact verschil is tussen:

code:

Full forced refresh:
        state = self._get_forced_vehicle_state(token, vehicle)
        state["vehicleLocation"] = self._get_location(token, vehicle)

versus:

code:

location only forced refresh:
        state["vehicleLocation"] = self._get_location(token, vehicle)

(NB, van mij hoeft het niet hoor, zomaar een idee)

[fredkroket]

Ik heb gisteravond de applicaties opnieuw geïnstalleerd.
Eerst draaide ik de applicatie op mijn "gewone" desktop, maar deze zit met 60 watt per uur me te hoog.
Ik had nog ergens een 7th gen Intel gebaseerde HP Elitedesk en die regelt het nu (met Ubuntu Linux) voor 4 tot 5 wat per uur . En het slaat natuurlijk nergens op een uiterst zuinige Ioniq te ondersteunen met een onzuinige computer .

In ieder geval, helaas werden de 2 documenten overschreven door een blanco exemplaar. Maar ik wist ook niet zeker welke bestanden ik over moest zetten om de huidige "stand" mee te nemen. Er zat pas 1 maand in, dus ik overleef dat wel.

Echter, vandaag op 2 adressen vrienden en familie bezocht, maar de locaties zijn gewoon correct geüpdatet. In de TRIP is het adres dan het startadres. Het is pas 1 dag, maar het lijkt wel te kloppen.

Echter, voordat ik de wijzigingen aangebracht had (toen het script nog op mijn Windows PC liep) is er op de 28e ineens wel iets aan de hand met de waardes van het verbruik in de hyundai-kia-connect-monitor file, dat is heel afwijkend. Ook de waardes van vandaag (door het script op Linux) zijn de waardes vreemd. Of wordt dit later gecorrigeerd in de file (nu viel het me toevallig op, kijkend naar de km per kwh op lijn 33).



De Dailystats van gisteren 23u (kijk dan naar de stats van de 28e)



De Dailystats van vandaag 23u (de stats van de 28e zijn dan een soort van bijgewerkt)



Misschien is het gewoon de werking dat eerst de dag "voorbij" moet zijn en maak ik me dus druk om niets.

[ Voor 15% gewijzigd door fredkroket op 29-05-2025 23:35 ]

[ZuinigeRijder]

@fredkroket Bij mij vult deze wel de matching informatie van summary in de dailystats van de laatste dag.
Heb jij "monitor_infinite" draaien en draai je dan summary én daarna dailystats?

[ Voor 5% gewijzigd door ZuinigeRijder op 30-05-2025 21:55 ]

[fredkroket]

ZuinigeRijder schreef op vrijdag 30 mei 2025 @ 21:55:
@fredkroket Bij mij vult deze wel de matching informatie van summary in de dailystats van de laatste dag.
Heb jij "monitor_infinite" draaien en draai je dan summary én daarna dailystats?

Ik heb het als volgt draaien:

Ctronjob doet het volgende:

*/30 6-23 * * * /home/fredkroket/hyundai_kia_connect_monitor-R4.5.1/run_monitor_once.sh >> /home/fredkroket/hyundai_kia_connect_monitor-R4.5.1/run_monitor_once.log 2>&1

De run_monitor_once.sh heeft dan de volgende taken:

/usr/bin/python3 -u ~/hyundai_kia_connect_monitor-R4.5.1/monitor.py >> run_monitor_once.log 2>&1
/usr/bin/python3 -u ~/hyundai_kia_connect_monitor-R4.5.1/summary.py sheetupdate > run_monitor_once.summary.log 2>&1
/usr/bin/python3 -u ~/hyundai_kia_connect_monitor-R4.5.1/dailystats.py sheetupdate > run_monitor_once.dailystats.log 2>&1

In de monitor.conf heb ik eigenlijk alleen de login gegevens voor Bluelink toegepast, monitor_infinite = False. Morgen moet ik weer wat ritten maken, dan kan ik er misschien weer wat meer van zeggen.

[fredkroket]

@ZuinigeRijder



Op de een of andere manier blijft in de monitor file het verbruik ook heel hoog. Daarbij klopt het adres toch ook niet altijd bij de ritten.

In de daily stats ben ik er ook nog niet uit...



Vertrokken met een accu op 100%.
Vervolgens heb ik via AC 6,25 kWh bijgeladen en via DC nog eens 6,7390 kWh.
Met 5% vervolgens aangekomen. Dus het totaal verbruik zou (en ik weet, het is niet lineair) er zou nog iets van 1,9kWh ingezeten moeten hebben.
38,3 + 6,25 + 6,7390 - 1,9 = 49,3 verbruikt (nog geen laadverlies bij AC meegenomen).

[ZuinigeRijder]

fredkroket schreef op maandag 2 juni 2025 @ 14:54:
@ZuinigeRijder

[Afbeelding]

Op de een of andere manier blijft in de monitor file het verbruik ook heel hoog. Daarbij klopt het adres toch ook niet altijd bij de ritten.

In de daily stats ben ik er ook nog niet uit...

Vertrokken met een accu op 100%.
Vervolgens heb ik via AC 6,25 kWh bijgeladen en via DC nog eens 6,7390 kWh.
Met 5% vervolgens aangekomen. Dus het totaal verbruik zou (en ik weet, het is niet lineair) er zou nog iets van 1,9kWh ingezeten moeten hebben.
38,3 + 6,25 + 6,7390 - 1,9 = 49,3 verbruikt (nog geen laadverlies bij AC meegenomen).

monitor.csv wordt gevuld met snapshots. Dus wanneer je DC gaat laden is de kans groot dat monitor.py niet aan het begin gedraaid heeft en niet aan het eind. En dit brengt het verbruik dus in de war. Je kunt met de hand de DC laadsessie tussenvoegen in monitor.csv (met overname van gegevens van voor de DC sessie en na de DC sessie). Eenzelfde probleem zal zich voordoen, wanneer je AC laadt en wanneer je meteen gaat rijden nadat de AC laadsessie afgebroken is of meteen gaat AC laden nadat de auto uitgezet is. Kans is groot dat eind/begin AC laadsessie niet geregistreerd is.

Het niet kloppen van adres van de ritten, zie de discussie vanaf hier:
ZuinigeRijder in "Ritbeheertools voor Hyundai Bluelink of Kia UV Connect"

[fredkroket]

ZuinigeRijder schreef op maandag 2 juni 2025 @ 16:02:
[...]


monitor.csv wordt gevuld met snapshots. Dus wanneer je DC gaat laden is de kans groot dat monitor.py niet aan het begin gedraaid heeft en niet aan het eind. En dit brengt het verbruik dus in de war. Je kunt met de hand de DC laadsessie tussenvoegen in monitor.csv (met overname van gegevens van voor de DC sessie en na de DC sessie). Eenzelfde probleem zal zich voordoen, wanneer je AC laadt en wanneer je meteen gaat rijden nadat de AC laadsessie afgebroken is of meteen gaat AC laden nadat de auto uitgezet is. Kans is groot dat eind/begin AC laadsessie niet geregistreerd is.

Het niet kloppen van adres van de ritten, zie de discussie vanaf hier:
ZuinigeRijder in "Ritbeheertools voor Hyundai Bluelink of Kia UV Connect"

Ik wist niet dat het DC laden het verbruik in de war zou brengen, echter was dat enkel gisteren het geval. Ik doe dit hooguit 1x per 2 maanden.

Verder weet ik waar het qua discussie begon, maar het leek bij mij op orde te zijn (gekomen). Alleen dus nog niet. Was meer een ter info.

[ZuinigeRijder]

R4.5.2: Configureerbare oplossing voor locatie die niet up-to-date is

Sinds mei 2025 heb ik last van een locatie die niet meer correct wordt bijgewerkt bij het uitzetten van de auto. In de ritbeheertools is te zien dat het adres vaak nog steeds het vorige bezoekadres is.

Meerdere gebruikers meldden hetzelfde probleem nadat ik het had genoemd.

Ja, de uiteindelijke kilometerstand en andere gegevens worden door de server geretourneerd, maar er is geen actuele locatie. Ook in de Bluelink-app, wanneer je naar de kaart gaat, wordt de oude locatie weergegeven. De enige manier om de huidige locatie van de auto te achterhalen, is door de knop 'Autolocatie' in de app uit en weer aan te zetten. Daarna is mijn vingerafdruk nodig om de huidige locatie op te halen.

@Stefannn schreef:

Dit betekent dat als ik de auto ergens in de stad parkeer, ik hem zonder bovenstaande truc helemaal niet meer kan vinden. En die truc is echt niet zo voor de hand liggend. Totdat je hierboven schreef, wist ik niet eens dat er een "automatische locatieknop" bestond.

Ik heb twee keer een e-mail gestuurd naar [e-mail] , maar ik krijg geen antwoord.

Maar de locatie is via deze tool niet langer betrouwbaar voor degenen die dit probleem hebben, omdat je helemaal niet wilt verversen, maar alleen de servercache wilt gebruiken. Voorheen werd de locatie naar de server gestuurd wanneer je de auto uitzette en kreeg je de laatste locatie terug via de server-API. Deze bug maakt het aspect van tripbeheer erg lastig; je moet nog steeds handmatig bijhouden waar je bent geweest, voor degenen die deze tool daarvoor gebruiken.

Ik heb een configureerbare oplossing bedacht. De volgende instellingen zijn toegevoegd aan monitor.cfg:

code:

monitor_force_sync_when_odometer_different_location_workaround = False
monitor_force_sync_max_count = 10

• monitor_force_sync_when_odometer_different_location_workaround: wanneer ingesteld op True, wordt een geforceerde update uitgevoerd wanneer de kilometerteller is gewijzigd, om de meest recente locatie op te halen (voor sommige auto's wordt de gecachte locatie sinds mei 2025 niet meer correct bijgewerkt bij het uitschakelen van de auto). Wijzig de instelling alleen in True als u dit probleem ondervindt EN u actuele locaties wilt hebben bij het uitschakelen van de auto.
• monitor_force_sync_max_count: (standaard: 10) Beperk het aantal gedwongen synchronisaties per dag wanneer de vorige instelling True 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 probleem 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.

[ZuinigeRijder]

R4.5.3: Kleine update op vorige release.

[BenAW]

Heb sinds begin december het monitor script draaien op een mini-pc onder Proxmox in een Debian container.
Werkt prima voor mijn Kia Sportage HEV. Zag ook de problemen met de laatste positie update en wilde de nieuwe versie van de monitor proberen. Clone van de container gemaakt, nieuwe monitor en api versie er op, geopy en cloudscraper er bij er draaien maar (dacht ik).
Krijg nu echter in allebei de containers een identieke foutmelding bij het inloggen. Met mijn beperkte programmeer kennis lijkt dit op een probleem bij het inloggen op de KIA server.
Iemand soortgelijke ervaringen?

code:

root@KIA-clone:/home/benaw/hyundai_kia_connect_monitor-R4.5.3# python3 monitor.py
20250731 13:52:41: INFO: Login using VehicleManager
20250731 13:52:42: WARNING: Exception: 'redirectUrl'
Traceback (most recent call last):
  File "/home/benaw/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 183, in login
    authorization_code = self._get_authorization_code_with_redirect_url(
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/benaw/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1102, in _get_authorization_code_with_redirect_url
    parsed_url = urlparse(response["redirectUrl"])
                          ~~~~~~~~^^^^^^^^^^^^^^^
KeyError: 'redirectUrl'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/benaw/hyundai_kia_connect_monitor-R4.5.3/monitor.py", line 646, in handle_vehicles
    MANAGER.check_and_refresh_token()
  File "/home/benaw/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/VehicleManager.py", line 147, in check_and_refresh_token
    self.initialize()
  File "/home/benaw/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/VehicleManager.py", line 82, in initialize
    self.token: Token = self.api.login(self.username, self.password)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/benaw/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 188, in login
    authorization_code = self._get_authorization_code_with_form(
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/benaw/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1200, in _get_authorization_code_with_form
    parsed_url = urlparse(response["redirectUrl"])
                          ~~~~~~~~^^^^^^^^^^^^^^^
KeyError: 'redirectUrl'
20250731 13:52:42: INFO: Sleeping a minute

[BenAW]

Klein beetje verder kijken dan mijn neus lang is leverde dit op:

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

Lijkt idd een verandering op de KIA server te zijn.

[ZuinigeRijder]

@BenAW Ik heb de combinatie van de laatste versie van hyundai_kia_connect_monitor met versie hyundai_kia_connect_api-3.43.0, die werkt bij mij. Latere versies heb ik niet geprobeerd.

Ik neem aan dat je de configuratiefiles goed ingevuld hebt?

[BenAW]

Mijn originele Debian container is onveranderd en werkte tot 2 dagen terug.
De clone container heeft (nog) niet gewerkt, omdat het niet lukte om in te loggen bij KIA.

Er zijn meerdere gebruikers met hetzelfde probleem blijkbaar dus ik neem aan dat de oplossing in de API moet komen.

[Stefannn]

Het gaat allemaal een beetje boven mijn pet,
Maar als ik de GitHub discussie zo lees heb ik het idee dat het fout gaat bij authenticatie.
Bij mij werkt alles nog. 10 minuten geleden nog een succesvolle request.

Maar... ik heb het idee dat de "Connect api" zo lang mogelijk gebruik maakt van een authorization-key.
Pas als die key verloopt moet hij een nieuwe key aanvragen met name&password.

Kortom.....
Bij @ZuinigeRijder en mijzelf blijft het werken zolang we niks wijzigen.

In de tussentijd de GitHub in de gaten houden.
De consensus is dat het een wijziging in de api aan der serverkant betreft. Er zijn nu een aantal mensen aan het reverse engineeren wat je moet doen om de api weer te kunnen bereiken.

> NB: ik gebruik het tool van @ZuinigeRijder niet (meer) maar roep de api direct aan (tool van @ZuinigeRijder is een beetje overkill want ik wil enkel de soc en range weten).

[ Voor 10% gewijzigd door Stefannn op 31-07-2025 17:05 ]

[ZuinigeRijder]

Oké, dus lijkt vooralsnog alleen een probleem met Kia integratie, Hyundai integratie heeft er (nog) geen last van.

[BenAW]

ZuinigeRijder schreef op donderdag 31 juli 2025 @ 17:06:
Oké, dus lijkt vooralsnog alleen een probleem met Kia integratie, Hyundai integratie heeft er (nog) geen last van.

Mee eens. Zal de github in de gaten houden en hiet terug rapporteren als er een werkende oplossing is.

[ZuinigeRijder]

Helaas is er nu ook het probleem bij Hyundai.

Ik heb het probleem sinds 15:00, Hyundai IONIQ 5: Login failed.

Hier kun je de voortgang voor een fix volgen op github.

[Stefannn]

ZuinigeRijder schreef op vrijdag 1 augustus 2025 @ 21:29:
Helaas is er nu ook het probleem bij Hyundai.

Ik heb het probleem sinds 15:00, Hyundai IONIQ 5: Login failed.

Hier kun je de voortgang voor een fix volgen op github.

Yep.. zelfde hier. Laatste succesvolle communicatie om 14:35.

[BenAW]

ZuinigeRijder schreef op vrijdag 1 augustus 2025 @ 21:29:
Helaas is er nu ook het probleem bij Hyundai.

Ik heb het probleem sinds 15:00, Hyundai IONIQ 5: Login failed.

Hier kun je de voortgang voor een fix volgen op github.

Gezien de discussie daar lijkt het dat het probleem vooralsnog alleen Europa betreft.

[Stefannn]

Goedemorgen
Als ik het zo lees:
- fix voor Kia zit in de release
- fix voor Hyundai is “under test” (die kan je dus wel downloaden en zelf testen, ik weet nog niet of ik dat ga doen, het gaat een beetje boven mijn pet allemaal)

[ocaj]

Mooi dat er zo snel een oplossing lijkt te komen.
Ik heb nu de api-versie 3.43.4 geprobeerd icm monitor-versie R4.5.3, maar dat geeft nog de volgende fouten:

code:

20250802 07:12:16: INFO: Login using VehicleManager
20250802 07:12:19: WARNING: Exception: 'NoneType' object is not subscriptable
Traceback (most recent call last):
  File "/root/kia/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 182, in login
    authorization_code = self._get_authorization_code_with_redirect_url(
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/kia/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1128, in _get_authorization_code_with_redirect_url
    ).group(1)
      ^^^^^
AttributeError: 'NoneType' object has no attribute 'group'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/root/kia/hyundai_kia_connect_monitor/monitor.py", line 646, in handle_vehicles
    MANAGER.check_and_refresh_token()
  File "/root/kia/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/VehicleManager.py", line 147, in check_and_refresh_token
    self.initialize()
  File "/root/kia/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/VehicleManager.py", line 82, in initialize
    self.token: Token = self.api.login(self.username, self.password)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/kia/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 187, in login
    authorization_code = self._get_authorization_code_with_form(
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/kia/hyundai_kia_connect_monitor-R4.5.3/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1152, in _get_authorization_code_with_form
    login_form_action_url = soup.find("form")["action"].replace("&", "&")
                            ~~~~~~~~~~~~~~~~~^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable
20250802 07:12:19: INFO: Sleeping a minute

@ZuinigeRijder Is er iets dat ook nog in jouw code aangepast moet worden, of doe ik gewoon iets fout ?

[Stefannn]

ocaj schreef op zaterdag 2 augustus 2025 @ 07:17:
Mooi dat er zo snel een oplossing lijkt te komen.
Ik heb nu de api-versie 3.43.4 geprobeerd icm monitor-versie R4.5.3, maar dat geeft nog de volgende fouten:


[...]

@ZuinigeRijder Is er iets dat ook nog in jouw code aangepast moet worden, of doe ik gewoon iets fout ?

Nee. Zie laatste comment van Marvinwankersteen op GitHub: de Hyundai fix heeft een paar componenten gemist in de integratie.
Dat gaat geheid snel goedkomen.
Kia werkt inmiddels. Succes is door meerdere gebruikers gemeld.

[ Voor 5% gewijzigd door Stefannn op 02-08-2025 07:51 ]

[ocaj]

Voor de volledigheid: Ik heb een Kia en dat werkt bij mij dus nog niet icm de monitor-code van ZuinigRijder, vandaar mijn vraag of daar ook nog iets aan aangepast zou moeten worden.

update: gaat snel: ik zie nu de opmerking van Marvinwankersteen op github. Ga even verder proberen.

[ Voor 22% gewijzigd door ocaj op 02-08-2025 08:05 ]

[ZuinigeRijder]

Bij mij werkt het weer voor mijn IONIQ 5 met https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/releases/tag/v3.43.4.

Stappen:
- download de zip
- unzip hyundai_kia_connect_api-3.43.4.zip
- verplaats subdirectory hyundai_kia_connect_api-3.43.4/hyundai_kia_connect_api naar hyundai_kia_connect_monitor/hyundai_kia_connect_api (oude subdirectory weggooien)

Je kunt kijken of het nu werkt met (in hyundai_kia_connect_monitor directory):

code:

python debug.py

[ Voor 8% gewijzigd door ZuinigeRijder op 02-08-2025 08:31 ]

[Stefannn]

ZuinigeRijder schreef op zaterdag 2 augustus 2025 @ 08:27:
Bij mij werkt het weer voor mijn IONIQ 5 met https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/releases/tag/v3.43.4.

Stappen:
- download de zip
- unzip hyundai_kia_connect_api-3.43.4.zip
- verplaats subdirectory hyundai_kia_connect_api-3.43.4/hyundai_kia_connect_api naar hyundai_kia_connect_monitor/hyundai_kia_connect_api (oude subdirectory weggooien)

Je kunt kijken of het nu werkt met (in hyundai_kia_connect_monitor directory):

code:

python debug.py

Super!
Heb je nog extra packages moeten installeren?
(Gewoon een vraag, ik kom er wel achter als ik ermee aan de gang ga)

[ZuinigeRijder]

@Stefannn Nee, geen nieuwe packages hoeven te installeren. Maar een vorige versie R4.3.0 moest ik wél een nieuw package installeren: cloudscraper

[ Voor 42% gewijzigd door ZuinigeRijder op 02-08-2025 08:48 ]

[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.