Ritbeheertools voor Hyundai Bluelink of Kia UV Connect

[Andre_FR2010]

Hoi, ik heb hier wat hulp nodig. Ik heb versie 4.3.0 geïnstalleerd, tevens de MQTT aangezet. In de MQTT broker ontvang ik berichten als ik 'luisteren naar onderwerp' (hyundai_kia_connect_monitor/#) activeer. Ik heb de entries van de voorbeeld configuratie.yaml overgenomen, maar ik zie geen entiteiten of sensors verschijnen. Ik maak vast ergens een denkfout in de configuratie.yaml (krijg geen foutmelding als ik deze check). Ik heb de entries van de voorbeeld configuratie.yaml letterlijk gekopieerd.
Ik heb al ESPALTHERMA succesvol draaien (ook via MQTT), die entries in de configuration.yaml zien er anders uit als in jouw voorbeeld configuratie.yaml. Als ik 1 entiteit/sensor werkend krijg, dan kan ik de rest van de 200+ zelf wel uitvogelen...

[ZuinigeRijder]

@Andre_FR2010 Ik heb zelf geen ervaring met HA/yaml, maar helpen deze instructies?

De originele MQTT yaml file was anders, zie deze link hierboven, ik heb zelf de eerste 2 regels toegevoegd, misschien fout?

[Andre_FR2010]

ZuinigeRijder schreef op dinsdag 10 december 2024 @ 22:01:
@Andre_FR2010 Ik heb zelf geen ervaring met HA/yaml, maar helpen deze instructies?

De originele MQTT yaml file was anders, zie deze link hierboven, ik heb zelf de eerste 2 regels toegevoegd, misschien fout?

Dank:
het volgende werkt nu (ga morgen verder met de rest aan te passen)

code:

sensor:
    - name: "MQTT_dailystats_trip_LAST_DAY_computed_day_consumption"
      state_topic: "hyundai_kia_connect_monitor/KMHKR81000000000/dailystats_trip/LAST_DAY/computed_day_consumption"
      unique_id: "MQTT_dailystats_trip_LAST_DAY_computed_day_consumption"
      value_template: "{{ value }}"
    - name: "MQTT_dailystats_trip_LAST_DAY_trip_time"
      state_topic: "hyundai_kia_connect_monitor/KMHKR81000000000/dailystats_trip/LAST_DAY/trip_time"
      unique_id: "MQTT_dailystats_trip_LAST_DAY_trip_time"
      value_template: "{{ value }}"

(VIN is aangepast)

[BenAW]

Ondersteun Kia Sportage HEV door standaardwaarden in monitor.py op te geven voor ev_battery_percentage, ev_battery_is_charging, ev_battery_is_plugged_in. Zie dit bericht in de Nederlandse taal van @BenAW.

Ben er nog niet diep in gedoken, maar heb nu ipv SOC% de waarde van Fuel% in monitor.py gezet.
Ipv van de eerste vaste waarde 100 staat daar nu {vehicle.fuel_level}
Zo iets moet ook mogelijk zijn voor range, de resterende rijafstand met de resterende hoeveelheid brandstof.
Nog geen tijd voor gehad, waarschijnlijk minder makkelijk te doen.

[ Voor 3% gewijzigd door BenAW op 10-12-2024 23:11 ]

[BenAW]

Ipv EV range heb ik nu Range in monitor.py staan.
Gebruikte syntax {vehicle.fuel_driving_range} ipv {ev_driving_range}

[CeesTax]

Ik krijg plots een Connection time-out, terwijl ik niets gewijzigd of toegevoegd heb.
20241212 23:34:30: INFO: Login using VehicleManager
20241212 23:34:30: WARNING: Exception: HTTPSConnectionPool(host='prd.eu-ccapi.hyundai.com', port=8080): Max retries exceeded with url: /api/v1/spa/notifications/register (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x10f3aa270>: Failed to establish a new connection: [Errno 61] Connection refused'))
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/urllib3/connection.py", line 199, in _new_conn
sock = connection.create_connection(
(self._dns_host, self.port),
...<2 lines>...

etc, etc.

Vervolgens slaapt hij een minute en blijft het opnieuw proberen, een loop dus.

[BenAW]

ZuinigeRijder schreef op maandag 9 december 2024 @ 13:17:
Ondersteun Kia Sportage HEV door standaardwaarden in monitor.py op te geven voor ev_battery_percentage, ev_battery_is_charging, ev_battery_is_plugged_in. Zie dit bericht in de Nederlandse taal van @BenAW.

Heb nu 26 ritten binnen kunnen halen. Wat opvalt is dat beginstand plus de som van de ritafstanden steeds meer afwijkt van de odometer waarde, momenteel zo'n 14km verschil.
Meest voor de hand liggende oorzaak het niet meenemen van de decimaal in de ritafstand.
Gemiddeld zo'n 0,5 km maal 26 is al 13 km gemist.
Is die decimaal niet beschikbaar vanuit KIA?

[ZuinigeRijder]

CeesTax schreef op donderdag 12 december 2024 @ 23:40:
Ik krijg plots een Connection time-out, terwijl ik niets gewijzigd of toegevoegd heb.
20241212 23:34:30: INFO: Login using VehicleManager
20241212 23:34:30: WARNING: Exception: HTTPSConnectionPool(host='prd.eu-ccapi.hyundai.com', port=8080): Max retries exceeded with url: /api/v1/spa/notifications/register (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x10f3aa270>: Failed to establish a new connection: [Errno 61] Connection refused'))
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/urllib3/connection.py", line 199, in _new_conn
sock = connection.create_connection(
(self._dns_host, self.port),
...<2 lines>...

etc, etc.

Vervolgens slaapt hij een minute en blijft het opnieuw proberen, een loop dus.

Blijkbaar zijn er voor die dag teveel opvragingen gedaan. Je zat bijna aan het eind van de dag. De volgende dag begint de teller weer bij nul. Heb je ook nog andere tools draaien om opvragingen te doen (HA of slimme laadapps?) of aan het testen geweest of vaak de App gebruikt om zaken op te vragen?

[ZuinigeRijder]

BenAW schreef op vrijdag 13 december 2024 @ 14:47:
[...]

Heb nu 26 ritten binnen kunnen halen. Wat opvalt is dat beginstand plus de som van de ritafstanden steeds meer afwijkt van de odometer waarde, momenteel zo'n 14km verschil.
Meest voor de hand liggende oorzaak het niet meenemen van de decimaal in de ritafstand.
Gemiddeld zo'n 0,5 km maal 26 is al 13 km gemist.
Is die decimaal niet beschikbaar vanuit KIA?

summary.py gebruikt de odometer en die heeft 1 decimaal. Helaas geeft in dailystats.py de API de afgelegde afstand zonder decimalen terug. Is daar waar het verschil ontstaat?

[Hippe Lip]

ZuinigeRijder schreef op vrijdag 13 december 2024 @ 14:53:
[...]
summary.py gebruikt de odometer en die heeft 1 decimaal. Helaas geeft in dailystats.py de API de afgelegde afstand zonder decimalen terug. Is daar waar het verschil ontstaat?

@ZuinigeRijder
Valt dat oplopende verschil ergens automatisch te corrigeren?
Ik roep maar een idee, niet gehinderd door al teveel inzicht in deze specifieke materie…

[CeesTax]

ZuinigeRijder schreef op vrijdag 13 december 2024 @ 14:51:
[...]


Blijkbaar zijn er voor die dag teveel opvragingen gedaan. Je zat bijna aan het eind van de dag. De volgende dag begint de teller weer bij nul. Heb je ook nog andere tools draaien om opvragingen te doen (HA of slimme laadapps?) of aan het testen geweest of vaak de App gebruikt om zaken op te vragen?

Ik heb er niets naast lopen. Nu om 18.50 weer gedraaid met weer dezelfde foutmelding. Het enige wat ik gedaan heb de afgelopen dagen was in mijn KPN modem het beveiligingsnivo op 'hoog' gezet. ik heb dit zojuist teruggezet op 'middel' en nu is alles weer normaal.
Dank voor de reactie.

[ZuinigeRijder]

Hippe Lip schreef op vrijdag 13 december 2024 @ 16:11:
[...]

@ZuinigeRijder
Valt dat oplopende verschil ergens automatisch te corrigeren?
Ik roep maar een idee, niet gehinderd door al teveel inzicht in deze specifieke materie…

Ik probeer al gegevens uit summary.py te matchen met de data van dailystats.py, maar dat lukt niet voor alle trips. Deze worden dan tussen ronde haakjes getoond (afstand of verbruik). Voorbeeld:

2024-12-10	Recuperation	Consumption	Engine	Climate	Electr.	Batt.Care
12.2kWh	3.2kWh	5.1km/kWh	11kWh	0.5kWh	0.8kWh	0kWh
71km	26.2%	19.5kWh/100km	90%	3.8%	6.2%	0%
	Trip	(10.3km/kWh)	Distance	Avg km/h	Max km/h	Idle
	11:17-11:51	(36.2km)	36km	69km/h	104km/h	2min
	08:14-08:54		35km	62km/h	104km/h	4min

Misschien zou ik wel het dagtotaal kunnen matchen. In dit voorbeeld 71 km, in werkelijkheid was dit 71.8 km. Maar dat gaat ervan uit dat de gebruiker geen snapshot gemist heeft en ook vaak genoeg monitor.py aanroept, zodat (bijna) alle ritten gregistreerd worden/historie opgebouwd is.

[Hippe Lip]

@ZuinigeRijder
Als je dagelijks rond dezelfde tijd de totale kilometerstand (ODO) opneemt, poets je dan niet vanzelf die onnauwkeurigheden weg?

Je baseren op alle snapshots en ervan uitgaan dat er geen gemist zijn, lijkt me geen goede basis. Er kunnen teveel redenen zijn dat er zomaar iets gemist wordt.

Maar je bent er intussen zo veel mee bezig geweest dat ik me niet kan voorstellen dat ik ‘eventjes’ je de gouden tip kan geven.

[ZuinigeRijder]

@Hippe Lip summary.py geeft de totalen wél goed aan. Eigenlijk is dailystats.py alleen maar de statistieken die je ook in de App kunt zien. Dus wordt getoond as-is. Met hier en daar een referentie/matching van summary.py data. Maar die totalen zijn niet zo spannend van dailystats.py, daarvoor kun je beter naar summary.py kijken.

Voorbeeld (lijnt hier niet allemaal goed uit)

Period	Date	Info	Odometer	Delta km	+kWh	-kWh	km/kWh	kWh/100km	Cost Euro	SOC%	Avg	Min	Max	12V%	Avg	Min	Max	#Charging	#Trips	Range
YEARLY	2024-12-12	344d	44766.8	11924.9	1864.7	-1880.9	5.6	17.9	462.71	47	56	12	100	71	87	71	255	140.1	749.1	169
MONTH AVG	2024-12-12	344d	44766.8	993.7	155.4	-156.7	5.6	17.9	38.56	47	56	12	100	71	87	71	255	11.7	62.4	169
WEEK AVG	2024-12-12	344d	44766.8	228.7	35.8	-36.1	5.6	17.9	8.87	47	56	12	100	71	87	71	255	2.7	14.4	169
DAY AVG	2024-12-12	344d	44766.8	32.7	5.1	-5.2	5.6	17.9	1.27	47	56	12	100	71	87	71	255	0.4	2.1	169
TRIP AVG	2024-12-12	706t	44766.8	15.9	2.5	-2.5	5.6	17.9	0.62	47	56	12	100	71	87	71	255	0.2	1	169
YEAR	2024-12-12	2024	44766.8	11238.8	1757.4	-1772.7	5.6	17.9	436.09	47	56	12	100	71	87	71	255	132	706	169
MONTH	2024-12-12	Dec	44766.8	413.3	65.4	-75.9	4.8	20.9	18.66	47	60	26	71	71	83	71	93	4	20	169
WEEK	2024-12-12	WK 50	44766.8	77.1		-15.3	4.4	22.6	3.77	47	58	47	69	71	77	71	84		4	169
DAY	2024-12-12	Thu	44766.8	5.3		-8.4	0.6	179.1	2.05	47	52	47	59	71	73	71	77		2	169
TRIP	2024-12-12	14:32	44766.8	2.7		-0.7	3.4	29.3	0.17	47	48	47	48	71	72	71	71		1	169
TRIP	2024-12-12	13:13	44764.1	2.6		-7.7	0.3	334.6	1.88	48	54	48	59	71	74	71	77		1	174
DAY	2024-12-10	Tue	44761.5	71.8		-7.0	9.1	11.0	1.71	59	62	59	69	77	79	77	84		2	218
TRIP	2024-12-10	11:52	44761.5	36.2						59	59	59	59	77	77	77	77		1	218
TRIP	2024-12-10	07:57	44725.3	35.6		-7.0	4.5	22.2	1.71	59	64	59	69	77	81	77	84		1	218

[BenAW]

Hippe Lip schreef op vrijdag 13 december 2024 @ 16:11:
[...]

@ZuinigeRijder
Valt dat oplopende verschil ergens automatisch te corrigeren?
Ik roep maar een idee, niet gehinderd door al teveel inzicht in deze specifieke materie…

Mooiste zou zijn als de API de ritafstand MET decimaal zou doorgeven.
Ik gebruik momenteel nog alleen monitor.py (en kml.py) en breng de data van monitor.csv en monitor.tripinfo.csv handmatig over naar een spreadsheet. Heb dus nog geen ervaring met gspread etc.
Workaround zou kunnen zijn alle ritafstanden ophogen met 0,5 km.

.

[Hippe Lip]

@ZuinigeRijder
Nou begint het me te duizelen. “Iets” te complex voor mijn voorstellingsvermogen, omdat ik dit nog niet in de praktijk kan brengen. Ben bang dat ik nog een paar maanden moet wachten op mijn I5…

[Hippe Lip]

BenAW schreef op zaterdag 14 december 2024 @ 09:24:
[...]
Mooiste zou zijn als de API de ritafstand MET decimaal zou doorgeven.
Ik gebruik momenteel nog alleen monitor.py (en kml.py) en breng de data van monitor.csv en monitor.tripinfo.csv handmatig over naar een spreadsheet. Heb dus nog geen ervaring met gspread etc.
Workaround zou kunnen zijn alle ritafstanden ophogen met 0,5 km.

Als ik het goed heb gaat het alleen mis (scheefloop) bij de statistieken?
Dan kun je er die halve kilometer wel zelf bij optellen, maar de statistieken worden gebouwd op de output van de API? Dan ben je dus te laat.

Verder zou die +0,5 inderdaad de juiste oplossing moeten zijn over langere tijd gerekend.

[BenAW]

Hippe Lip schreef op zaterdag 14 december 2024 @ 09:37:
[...]

Als ik het goed heb gaat het alleen mis (scheefloop) bij de statistieken?
Dan kun je er die halve kilometer wel zelf bij optellen, maar de statistieken worden gebouwd op de output van de API? Dan ben je dus te laat.

Verder zou die +0,5 inderdaad de juiste oplossing moeten zijn over langere tijd gerekend.

Ik gebruik de statistieken nog niet. Heb een Sportage HEV en lees nu de resterende benzine hoeveelheid in % en de berekende range uit. Ga wss zelf wat spreadsheet werk doen, omdat dit toch iets anders is dan de kwh van een EV. Volgende dingetje na de afstand in hele km's is de tankinhoud. Heb voor de eerste keer de tank volgegooid en nu ~50km later is de tankinhoud nog steeds 100%. Is wel erg zuinig

[GHorsie]

Ik begrijp het overzicht nog niet helemaal.

Het lijkt namelijk niet echt te kloppen:

Dit is de entry van 2024:
Teller Delta km
JAARLIJKS 13409.1 15809.7

Dat zou inhouden dat ik meer kilometers gereden heb dan de teller aangeeft

En voor dit jaar is er een nog groter verschil

Teller Delta km
JAARLIJKS 2025-01-04 13421.5 4526.0

Of begrijp ik het overzicht niet?

(De maand en week gemiddelde van 2025 klopt ook niet)

[ Voor 10% gewijzigd door GHorsie op 06-01-2025 23:30 ]

[ZuinigeRijder]

@GHorsie Jaarlijks geeft aan wat je zou gaan rijden met het huidige aantal kilometers gereden in dit jaar. Bij Jaar zie je hoeveel kilometer er dit jaar gereden is.

Misschien kun je een screenshot posten?

Voorbeeld: wanneer je op 31 december 9:00 uur de laatste rit gemaakt hebt, is JAAR en JAARLIJKS niet hetzelfde, want het tool rekent die paar uur niet gereden nog naar JAARLIJKS. Wil je dus weten wat je echt gereden hebt in 2024, moet je naar JAAR kijken.

[ Voor 36% gewijzigd door ZuinigeRijder op 07-01-2025 09:15 ]

[GHorsie]

ZuinigeRijder schreef op dinsdag 7 januari 2025 @ 09:07:
@GHorsie Jaarlijks geeft aan wat je zou gaan rijden met het huidige aantal kilometers gereden in dit jaar. Bij Jaar zie je hoeveel kilometer er dit jaar gereden is.

Misschien kun je een screenshot posten?

Voorbeeld: wanneer je op 31 december 9:00 uur de laatste rit gemaakt hebt, is JAAR en JAARLIJKS niet hetzelfde, want het tool rekent die paar uur niet gereden nog naar JAARLIJKS. Wil je dus weten wat je echt gereden hebt in 2024, moet je naar JAAR kijken.

Je bedoelt dit:


Maar wat je zegt betekent dus eigenlijk dat hij berekent dat ik dit jaar 14165km's ga rijden. Mijn tellerstand kwam natuurlijk erg dicht bij dat getal dus daarom viel het mij op.

[ZuinigeRijder]

@GHorsie De berekening is eenvoudig, het getal JAAR* 365 / aantal dagen van dit jaar, oftewel 13797.2 * 365 / 10 dagen = 14165,65 km

[ Voor 3% gewijzigd door ZuinigeRijder op 14-01-2025 17:07 ]

[GHorsie]

Ik merk dat de excel sheet niet alle data bewaard? (waarschijnlijk niet goed gelezen)

Is er ook een mogelijkheid om regelmatig een nieuwe excel-sheet te gebruiken zodat je alle data behoudt?

[ZuinigeRijder]

@GHorsie De Google sheet laat alleen ongeveer de laatste 125 rijen of zo zien. Dit omdat er een limiet is aan het aantal rijen vanuit gspread én om het aantal gegevens dat overgestuurd moet worden te minimaliseren.

De tekstuele uitvoer van summary.py en dailystats.py bevat wél alle data. Dit is ook een comma separated uitvoer, dus die zou je in een Excel kunnen inlezen om alle data te hebben.

[Hippe Lip]

ZuinigeRijder schreef op maandag 3 februari 2025 @ 21:58:
@GHorsie De Google sheet laat alleen ongeveer de laatste 125 rijen of zo zien. Dit omdat er een limiet is aan het aantal rijen vanuit gspread én om het aantal gegevens dat overgestuurd moet worden te minimaliseren.

Schrijf je naar een eigen-maak spreadsheet? Of kun je ook de Google Sheets integratie van HA gebruiken? daar kun je gerust honderden regels wegschrijven, weet ik inmiddels uit ervaring.

De tekstuele uitvoer van summary.py en dailystats.py bevat wél alle data. Dit is ook een comma separated uitvoer, dus die zou je in een Excel kunnen inlezen om alle data te hebben.

Zijn dit entiteiten in HA? Dan kun je ze dus zelf wegschrijven met de Google Sheets integratie?

[ZuinigeRijder]

@Hippe Lip Nee, mijn tools maken geen gebruik van HA, maar kan wel data wegschrijven naar MQTT en dat kun je koppelen aan HA. Daar kun je een eigen dashboard van maken.

Voorbeelden van een HA gebruiker hier.

[ Voor 30% gewijzigd door ZuinigeRijder op 03-02-2025 22:05 ]

[Hippe Lip]

Eerst woensdag de auto maar eens halen, maar als ik het zo lees dan ben ik de komende weken wel weer zoet

Grootste probleem is tijd; hoe krijg ik goedkeuring van de directie hier om daar zó veel tijd in te steken.
Maar eigenlijk kan ik niet wachten…

[ Voor 7% gewijzigd door Hippe Lip op 03-02-2025 22:14 ]

[ZuinigeRijder]

Sinds kort heb ik ook HA draaien, op Proxmox.

ZuinigeRijder in "Het grote Proxmox VE topic"

[Hippe Lip]

ZuinigeRijder schreef op maandag 3 februari 2025 @ 22:39:
Sinds kort heb ik ook HA draaien, op Proxmox.

ZuinigeRijder in "Het grote Proxmox VE topic"

@ZuinigeRijder Ah! Dat gaat me een hoop uitzoekwerk en dus tijd schelen. Dank!

Maar zie ik nou op de eerste regel van die post die je aanhaalt dat je een RPi draait op een microSD-kaartje? En daar schrijf je data naartoe? Zoek nou ff een goedkope SSD (met snoertje naar USB) om het daarop te zetten (en boot van USB), want anders ben je straks alles kwijt. Zo’n kaartje kan maar een zeer beperkt aantal keren schrijven en daarna overlijd die. Ik spreek uit ervaring van mijn eerste HA-opzet…

Nou moet je trouwens sowieso backups maken, maar toch…

[ZuinigeRijder]

@Hippe Lip Die Raspberry Pi heeft 11 jaar gedraaid, maar wel met logging schrijven naar RAM. Dus het kan wel met microSD. Maar ik heb afscheid hiervan genomen en een tweedehands Intel NUC 5 gekocht met een i3, 16 GB geheugen en 256 GB nvme SSD met maximaal 15 Watt verbruik. En daar draai ik Proxmox op met een VM met dietpi OS (vervanger van Raspberry Pi) en een VM met HA OS.

[ Voor 3% gewijzigd door ZuinigeRijder op 04-02-2025 08:20 ]

[ZuinigeRijder]

Ik heb trouwens maar een klein gedeelte van alle informatie opgenomen in Home Assistant.



Je kunt nog de historie grafieken zien via HA, maar wanneer ik precies wil weten wanneer ik waar geweest ben de laatste tijd, kijk ik in Google Spreadsheet. Zou ik een rit administratie achteraf moeten bijhouden van langere tijd geleden, zou ik naar de volledige uitvoer van summary.py en dailystats.py kijken.

Maar zelf hoef ik geen rit administratie bij te houden

[Hippe Lip]

ZuinigeRijder schreef op dinsdag 4 februari 2025 @ 08:34:
Ik heb trouwens maar een klein gedeelte van alle informatie opgenomen in Home Assistant.

[Afbeelding]

Je kunt nog de historie grafieken zien via HA, maar wanneer ik precies wil weten wanneer ik waar geweest ben de laatste tijd, kijk ik in Google Spreadsheet. Zou ik een rit administratie achteraf moeten bijhouden van langere tijd geleden, zou ik naar de volledige uitvoer van summary.py en dailystats.py kijken.

@ZuinigeRijder
Mooi wat je gedaan hebt met je Intel NUC. Voor mij wordt het dan te complex; kan het niet meer bevatten helaas. Want je hebt dan wel lekker veel power.
Hier ben ik overgestapt van RPi naar Odroid N2+ omdat de Pi het niet meer trok; werd te langzaam.

Na morgen (auto halen en CrossClimates erop) ga ik eens kijken wat je allemaal hebt gefabriceerd en of ik dat aan de praat krijg. Aanvankelijk dacht ik dat je dit op HA had draaien. Dat blijkt dus van niet en dan weet ik niet of het mij ook gaat lukken. Het ziet er wel aantrekkelijk uit met verdomd veel parameters die je uitleest.
Waarom kan de gewone I5-integratie van HA dat niet?

Maar zelf hoef ik geen rit administratie bij te houden

Nee, dat hoef ik ook niet. Belangrijkste voor mij is dat ik een (groot?) aantal parameters vanuit HA naar G. Sheets kan schrijven voor een basishistorie.

[hemertje]

Hippe Lip schreef op maandag 3 februari 2025 @ 22:13:
Eerst woensdag de auto maar eens halen, maar als ik het zo lees dan ben ik de komende weken wel weer zoet

Grootste probleem is tijd; hoe krijg ik goedkeuring van de directie hier om daar zó veel tijd in te steken.
Maar eigenlijk kan ik niet wachten…

welke auto wordt het?

[ZuinigeRijder]

@hemertje IONIQ 5 2025 PE (Product Enhancement) mét extra ruitenwisser

Hippe Lip in "Het Hyundai Ioniq 5 leveringen topic"

[ZuinigeRijder]

Hippe Lip schreef op dinsdag 4 februari 2025 @ 11:17:
[...]

Hier ben ik overgestapt van RPi naar Odroid N2+ omdat de Pi het niet meer trok; werd te langzaam.

Dan kun je de RPi uit de mottenballen halen en daar de ritbeheer tools op draaien en de data via MQTT naar HA sturen. Bij mij draaide de tools op bijna de langzaamste RPi die er te krijgen was (Raspberry Pi model B 512MB geheugen)

[ Voor 22% gewijzigd door ZuinigeRijder op 04-02-2025 13:06 ]

[Hippe Lip]

ZuinigeRijder schreef op dinsdag 4 februari 2025 @ 13:04:
[...]
Dan kun je de RPi uit de mottenballen halen en daar de ritbeheer tools op draaien en de data via MQTT naar HA sturen. Bij mij draaide de tools op bijna de langzaamste RPi die er te krijgen was (Raspberry Pi model B 512MB geheugen)

@ZuinigeRijder Daar ga ik dan binnenkort maar eens naar kijken.

En bereid je maar vast voor op een serie vragen (ondersteuning) van me voordat ik dat werkend heb…

[CeesTax]

Sinds 6-2 worden er in het monitor.csv bestand puntkomma's ( tussen mijn parkeerdata geschreven terwijl daar in alle voorgaande regels komma's (') stonden. What's going on?

[ZuinigeRijder]

@CeesTax Bij mij niet. Alleen bij het adres worden er ; gebruikt om de adresvelden te scheiden. Maar dat was altijd al zo. Heb je iets veranderd of nieuwe versie geïnstalleerd?

[CeesTax]

Nee, ik heb niets veranderd. In alle voorgaande regels staan er komma's (,) en in de laatste drie regels ; tussen de parkeerdata. Verder krijg ik geen foutmeldingen of zo. Het werkt nog steeds prima.

[ZuinigeRijder]

@CeesTax Kun je hier een aantal regels posten (met longitude/latitude en adressen aangepast) of via PM sturen.

[Stefannn]

Stefannn schreef op zondag 10 november 2024 @ 11:27:
[...]


A... dat helpt dus niet...
dank (dat scheelt weer vloeken).

Nb... Ik ga het voorlopig nog niet echt doen. Ik heb nog wat andere klussen.
In de "pauzes" kan ik het echter niet nalaten wat verkennend werk met de laptop/iPad te doen.

De homecomputer is (waarschijnlijk ook bij jou) volledig headless en kan ik met ssh en/of vnc zowel vanaf laptop maar zelfs vanaf de iPad in de luie stoel bereiken.

@ZuinigeRijder
nou... "voorlopig niet is geëindigd"
Het draait.

python op TinyCore Linux geïnstalleerd
Modules erbij
Jouw tools geinstalleerd
Geintegreerd met mijn home automation

Mooi: nu kan ik niet alleen laden met de smartevse laadpaal
Maar ook zien hoe vol de auto is

en dus bedankt voor dit tool en het publiceren ervan

[Stefannn]

@ZuinigeRijder
Half off topic,
Maar ik dacht dat j het wellicht wel leuk zou vinden om te zien hoe ik het ge-integreerd heb.
(just for fun)

[ZuinigeRijder]

R4.5.0 Ondersteun ook Google voor adres zoeken in plaats van alleen OpenStreetMap

Google kan nu ook worden geconfigureerd voor het opzoeken van adressen. Zie deze discussie. Standaard blijft Openstreetmap actief.

Opmerkingen:
- installeer python geopy-pakket (ook als u Google niet gebruikt voor het opzoeken van adressen), "pip install geopy"
- upgrade hyundai_kia_connect_api naar minimaal v3.33.3.

Als u Google wilt gebruiken om een ​​adres op te zoeken:
- maak een Google API-sleutel, zie dit bericht
- in monitor.cfg configureer geocode_provider = 2 en google_api_key =

hyundai_kia_connect_api is ook verbeterd door mij, zodat alleen adressen opgezocht worden, wanneer de vorige coördinaten verschillend zijn. Dit werkt alleen wanneer je monitor.py oneindig laat lopen. Dit werkt zowel voor Openstreetmap als voor Google. Configureer in monitor.cfg:

code:

monitor_infinite = True

Aangezien voor Google per maand 10000 opzoekingen gratis zijn, zorgt deze wijziging er ook voor dat je niet door gebruik van hyundai_kia_connect_monitor over deze limiet gaat.

[CeesTax]

geocode_provider = 2 ingevuld, google_api_key ingevuld met dit als resultaat:

20250409 23:14:34: INFO: Login using VehicleManager
20250409 23:14:34: WARNING: Exception: __init__() got an unexpected keyword argument 'geocode_provider'
Traceback (most recent call last):
File "/Volumes/OR2T/hyundai_R4.5.0/monitor.py", line 578, in handle_vehicles
MANAGER = VehicleManager(
TypeError: __init__() got an unexpected keyword argument 'geocode_provider'
20250409 23:14:34: INFO: Sleeping a minute

Ik doe blijkbaar iets verkeerd, maar wat als dit de enige wijzigingen zijn geweest naast de update naar 4.5.0?

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