Ritbeheertools voor Hyundai Bluelink of Kia UV Connect

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