Ritbeheertools voor Hyundai Bluelink of Kia UV Connect

[ZuinigeRijder]

Voor diegene die de scripts wil uitvoeren in Docker, zie deze discussie:

Docker: hyundai_kia_connect_monitor uitvoeren met cron

[hemertje]

Dank voor de update en de tip!

[brogast]

@ZuinigeRijder Ik heb speciaal een Tweakers account aangemaakt om je te bedanken voor deze scripts. Goed bezig!

[ColdRain]

't Heeft een hele tijd geduurd voor ik door had dat ook dit moest om het werkend te krijgen:

code:

python3 -m pip install "hyundai_kia_connect_api>=3.13.2"

Knap tooltje.

[ZuinigeRijder]

@ColdRain Je kunt ook de hyundai_kia_connect_api submap (dus de map 1 niveau dieper dan de zip) onder hyundai_kia_connect_monitor zetten, dan hoef je hyundai_kia_connect_api niet te installeren.

[ZuinigeRijder]

Nieuwe release R3.20.0: Toon afstand met 1 decimaal en strip op veel plaatsen .0

Voorbeelden van ondersteunde auto's (inclusief auto's met nieuw ccNC Infotainment):
- Hyundai (Bluelink): Ioniq, IONIQ 5, IONIQ 6, Kona
- Kia (Connect): EV6, EV9, Niro, Soul

[ Voor 45% gewijzigd door ZuinigeRijder op 23-02-2024 21:47 ]

[GHorsie]

Ik wil deze tool ook gaan gebruiken, en heb het geconfigureerd. Als ik de tool start krijg ik alleen de informatie van vandaag of om precies te zien het moment van draaien van de tool.

Is het ook mogelijk om oudere data op te halen?

[ZuinigeRijder]

@GHorsie In monitor.dailystats.csv en monitor.tripinfo.csv staan de statistieken van de laatste 3 maanden. monitor.csv wordt bij iedere aanroep geupdate van de op dat moment bekende informatie. Je kunt van monitor.csv geen historische informatie terugkrijgen van de server.

Ik roep monitor.py 3x per uur aan tussen 6:00 en 22:00 op mijn raspberry pi.

[GHorsie]

ZuinigeRijder schreef op maandag 1 april 2024 @ 21:31:
@GHorsie In monitor.dailystats.csv en monitor.tripinfo.csv staan de statistieken van de laatste 3 maanden. monitor.csv wordt bij iedere aanroep geupdate van de op dat moment bekende informatie. Je kunt van monitor.csv geen historische informatie terugkrijgen van de server.

Ik roep monitor.py 3x per uur aan tussen 6:00 en 22:00 op mijn raspberry pi.

Dank. Ik zie inderdaad de dagelijkse data in de andere bestanden.

Je kan alleen niet meer je trips zien want die worden volgens de documentatie uit de monitor.cv’s gehaald.

Overigens een tip voor installatie: aangezien de requirements.txt wordt bijgehouden kan je in één keer alle pakketten installeren door het volgende commando

python -m pip install -r requirements.txt

[ZuinigeRijder]

@GHorsie Ja en nee, dailystats.py laat de trips zien uit monitor.tripinfo.csv. Echter summary.py laat alleen de trips zien die in monitor.csv staan.

[ Voor 17% gewijzigd door ZuinigeRijder op 01-04-2024 22:32 ]

[CeesTax]

Ik heb zowel de hyundai-kia-connect-monitor als monitor.dailystats spreadsheet openstaan maar krijg bij het uitvoeren van python3 summary.py sheetupdate een foutmelding, zie hieronder. Hij kan de spreadsheet niet vinden. De monitor.dailystats spreadsheet blijft goed geupdatet worden.

Traceback (most recent call last):
File "/Users/tax/Hyundai/hyundai_kia_connect_monitor-R3.20.0/summary.py", line 1067, in <module>
spreadsheet = gc.open(OUTPUT_SPREADSHEET_NAME)
File "/Users/tax/Library/Python/3.9/lib/python/site-packages/gspread/client.py", line 160, in open
raise SpreadsheetNotFound
gspread.exceptions.SpreadsheetNotFound
20240403 14:26:50: Sleeping a minute
20240403 14:27:51: Exception:
Traceback (most recent call last):
File "/Users/tax/Library/Python/3.9/lib/python/site-packages/gspread/client.py", line 150, in open
properties = finditem(
File "/Users/tax/Library/Python/3.9/lib/python/site-packages/gspread/utils.py", line 105, in finditem
return next(item for item in seq if func(item))
StopIteration

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/Users/tax/Hyundai/hyundai_kia_connect_monitor-R3.20.0/summary.py", line 1067, in <module>
spreadsheet = gc.open(OUTPUT_SPREADSHEET_NAME)
File "/Users/tax/Library/Python/3.9/lib/python/site-packages/gspread/client.py", line 160, in open
raise SpreadsheetNotFound
gspread.exceptions.SpreadsheetNotFound

Iemand een idee waar ik het zoeken moet?

[CeesTax]

Uiteindelijk zelf opgelost. Dat het hyundai-kia-connect-monitor-spreadsheet niet werd gevonden lag aan het feit dat er een spatie aan het einde van de naam stond. En dat zie je niet meteen.

[ZuinigeRijder]

Nieuwe versie R3.21.0
% toegestaan ​​in wachtwoord

Nieuwe versie R3.22.0
SOC% is gewijzigd in float omdat nieuwere Kona- en ccNC-auto's halve percentages kunnen retourneren

[hemertje]

lekker bezig!

[ZuinigeRijder]

Nieuwe versie R3.23.0.

Het blijkt dat het in de auto getoonde verbruik inclusief regeneratie is berekend. Deze release corrigeert de berekening van dagelijkse statistieken. Nu moeten de dagelijkse verbruikscijfers beter aansluiten bij de verbruikscijfers die in de auto staan ​​weergegeven.

[ZuinigeRijder]

Nieuwe versie R3.24.0

Aan monitor.cfg is de instelling include_regenerate_in_consumption toegevoegd.

In R3.23.0 wordt bij het verbruik rekening gehouden met de regeneratie in de dagelijkse statistieken, om beter aan te sluiten bij de boordcomputerwaarden. Sommige gebruikers hebben echter betere resultaten in de oude situatie. Instelling toegevoegd, standaard is de oude situatie vóór R3.23.0.

[Andre_FR2010]

Top tool, na een paar dagen testen draait het op een Raspberry PI VM.
Aangezien ik nieuw ben met deze tool (en met het rijden van een EV) is mijn vraag: hoe kan ik op een makkelijke/veilige manier een nieuwere versie installeren?
Alvast bedankt...

[ZuinigeRijder]

@Andre_FR2010 Ik download de zip van een release, pak het uit in een tijdelijke folder en kopieer alles, behalve *.cfg bestanden naar de folder waar het geïnstalleerd staat. Daarnaast kijken of er mogelijk iets aangepast is aan *.cfg files, bijvoorbeeld in de laatste release is er een configuratie item toegevoegd aan monitor.cfg en deze toevoeging handmatig aanpassen.....

Voor de hyundai_kia_connect_api doe ik hetzelfde, uitpakken van de zip file en alle bestanden in de subfolder hyundai_kia_connect_api overschrijven naar de sub-folder hyundai_kia_connect_api.

[ZuinigeRijder]

Nieuwe release R3.26.0: Tijdelijke oplossing: de server retourneert last_updated_at vaak 2 uur eerder

Sinds 1 augustus 2024 retourneert de server in Europa vaak een 2 uur tijdsverschil vehicle.last_updated_at.
Het probleem is dat de in de cache opgeslagen update "last_updated_at" in ongeveer 50% van de gevallen een onjuist resultaat geeft.

@Steven77nl rapporteert dit probleem hier in Home Assistant .

Ik heb hetzelfde probleem in monitor.py en het lijkt te zijn begonnen op 1 augustus 2024.
Ik zie een verschil van twee uur herhaald in de monitor.csv, bijvoorbeeld:

code:

2024-09-28 00:00:57+02:00, ...
2024-09-27 22:00:57+02:00, ...
2024-09-28 00:00:57+02:00, ...
2024-09-27 22:00:57+02:00, ...
2024-09-28 00:00:57+02:00, ...
2024-09-28 08:14:06+02:00, ...
2024-09-28 10:14:06+02:00, ...
2024-09-28 08:14:06+02:00, ...
2024-09-28 09:03:20+02:00, ...
2024-09-28 11:03:20+02:00, ...
2024-09-28 09:03:20+02:00, ...
2024-09-28 11:03:20+02:00, ...

Ik heb hyundai_kia_connect_api bekeken, maar kan het probleem niet vinden, dus het lijkt erop dat de server mogelijk de verkeerde datum/tijd verzendt voor het in de cache opgeslagen laatste_updated_at. Kan het zijn dat een van de servers de datum/tijd verkeerd heeft ingesteld?

Je kunt een oudere tijdstempel niet zomaar negeren. Maar het is mogelijk dat de gegevens zijn gewijzigd en dat u nog steeds een oudere tijdstempel krijgt, die niet 2 uur vóór de vorige ligt, maar nog steeds ouder is dan de vorige datum/tijd......

Hier is een deel van mijn oplossing voor de Python-code (newest_updated_at en previous_updated_at zijn beide datetime-objecten met tijdzone-informatie):

code:

            if newest_updated_at < previous_updated_at:  # new entry older than previous?
                utcoffset = newest_updated_at.utcoffset()
                newest_updated_at_corrected = newest_updated_at + utcoffset
                if (
                    newest_updated_at_corrected
                    >= previous_updated_at  # newest not too old?
                ):
                    newest_updated_at = newest_updated_at_corrected

Er is nog steeds één situatie die niet kan worden opgelost. Stel dat het vorige tijdstempel meer dan twee uur geleden was. De nieuwe last_updated_at, is dat de tijdstempel met de verkeerde 2 uur of is dat de juiste tijdstempel?

[ocaj]

@ZuinigeRijder Ik zag de laatste tijd ook al rare dingen in de logging. Fijn dat er een fix is.

Ik zie dat er ook een fix is in de generieke api: https://github.com/Hyunda..._kia_connect_api/pull/641

Is het nou verstandig om van zowel de api als jouw monitor de laatste versie te installeren, of gaat dat elkaar tegenwerken?

[ZuinigeRijder]

@ocaj Die fix is niet goed, dus daar komt nog een nieuwe pull request van.Ik heb een ander voorstel gedaan, maar ook cdnninja heeft een nieuw voorstel gemaakt. Laten we kijken welke van de twee het wordt.

Bij de nieuwste voorstellen verwacht ik niet dat ze elkaar gaan tegenwerken, bij de huidige versie weet ik het niet zeker. In principe is alleen de monitor.py aanpassing nodig voor jou.

[ocaj]

Dank voor je snelle reactie en je inzet.
Ik wacht nog wel even een weekje of wat af en dan update ik alles in 1 keer (aangenomen dat jullie eruit komen wat nu de beste oplossing is).

[ZuinigeRijder]

@ocaj Mijn voorstel is net overgenomen in hyundai_kia_connect_api 3.23.4. Die zou ik inderdaad niet meteen overnemen (HA gebruikers zullen die wel testen), maar de laatste release van hyundai_kia_connect_monitor gebruik ik al een hele tijd met goede resultaten, dus die release zou jouw probleem als het goed is oplossen. Voor monitor.py is die workaround van hyundai_kia_connect_api niet relevant.

[ZuinigeRijder]

Ik heb trouwens zelf handmatig de verkeerde regels verwijderd (twee uur eerdere tijd) uit monitor.csv en soms 2 uur erbij opgeteld. Aan het patroon kun je wel zien of je deze moet verwijderen of de tijd moet aanpassen. Dubbele identieke regels kun je daarna ook nog verwijderen. Ik moest teruggaan tot ergens in augustus 2024.

[ZuinigeRijder]

R3.27.0 Configuratie van de verbruiksefficiëntiefactor toegevoegd

Ik denk dat de verbruikswaarden van de boordcomputer gecorrigeerd worden met een efficiëntiegetal, bv. 1 kWh energie levert 0,9 kWh echte energie op (verlies bij het omrekenen van kWh batterij door de auto). Daarom heb ik een efficiëntieconfiguratiefactor geïntroduceerd in monitor.cfg, consumption_efficiency_factor_dailystats en consumption_efficiency_factor_summary. Wanneer u deze bijvoorbeeld op 0.9 zet, gaat bij de conversie 10% van de energie verloren en wordt gebruikt bij de verbruiksberekening. Standaard zijn de waarden 1.0, dus geen correctie.

De volgende vermeldingen zijn toegevoegd aan monitor.cfg:

consumption_efficiency_factor_dailystats = 1.0
consumption_efficiency_factor_summary = 1.0


Ik heb een tijd geleden include_regenerate_in_consumption toegevoegd, voor de verbruiksberekening in de dagelijkse statistieken. Ik denk echter dat de bovenstaande 2 configuratie-items beter zullen overeenkomen met de waarden van de boordcomputer.

[Hippe Lip]

@ZuinigeRijder
Bedoel je dat die 10% de verwachte laadverliezen zijn? Die lijken me dan aan de lage kant.
Ik houd nu al een tijdje statistieken bij van het laden van mijn e-Niro. HA schrijft bij elke keer laden aan mijn laadpaal thuis wat waarden naar Google Sheets, waaronder de accuwaarde (%) bij insteken en bij losnemen van de stekker, plus de meterstanden van mijn tussenmeter in de meterkast. Zo kom ik tot een laadverlies van tussen de tussen 16 en 20%!

[ZuinigeRijder]

@Hippe Lip Nee, hiermee bedoel ik het efficiëntie verlies om van de kWh in de hoogvolt batterij om te zetten naar de gebruikers en aandrijving. Bij een lange rit ligt dat bij mij in de orde van 10% tot 12%. Maar ja, je kunt de factor zelf ijken en instellen met een lange rit en de boordcomputer waardes onthouden en vergelijken met bijvoorbeeld dailystats.

[ Voor 12% gewijzigd door ZuinigeRijder op 08-10-2024 21:19 ]

[ZuinigeRijder]

R4.0.0: Grote update: introductie van het oneindig uitvoeren van monitor.py

Het regelmatig verzamelen van de in de cache opgeslagen servergegevens door monitor.py is eenvoudiger gemaakt, bijvoorbeeld door de opdracht "python monitor.py" eenmaal per uur en/of oneindig uit te voeren . Een server is natuurlijk het beste. Ik gebruik een Raspberry Pi, maar het kan ook regelmatig of oneindig op een Windows 10- of Mac-computer, mits de computer aanstaat.

Opmerking: elke keer dat monitor.py om cacheserverwaarden vraagt, wordt er een momentopname gemaakt van de nieuwste servercachewaarden als deze verschillend zijn. Hoe vaker u het gebruikt, hoe beter de kosten en ritten kunnen worden gedetecteerd door summary.py. De eenvoudigste manier is om monitor.py oneindig uit te voeren.

Configuratie-items toegevoegd aan monitor.cfg:
- monitor_infinite, indien ingesteld op True monitor.py blijft actief met monitor_infinite_interval_minutes tussen het ophalen van serverwaarden in de cache
- monitor_infinite_interval_minutes, interval in minuten tussen het ophalen van in de cache opgeslagen serverwaarden
- monitor_execute_commands_when_something_written_or_error, wanneer nieuwe in de cache opgeslagen serverwaarden worden opgehaald, worden de opgegeven opdrachten (gescheiden door puntkomma;) uitgevoerd. Zie opmerking 1.
* voorbeeld: monitor_execute_commands_when_something_written_or_error = python -u summary.py sheetupdate > summary.log;python -u dailystats.py sheetupdate > dailystats.log

Opmerking 1: in combinatie met oneindig (monitor_infinite = True) worden summary.py en dailystats.py alleen uitgevoerd als er iets is gewijzigd of als er een fout is opgetreden (of één keer per dag). U hoeft summary.py en dailystats.py niet afzonderlijk uit te voeren en het wordt alleen uitgevoerd wanneer dat nodig is.

Opmerking 2: een Bluelink USA-gebruiker heeft ontdekt dat er een limiet is voor het aantal logins, niet voor de volgende oproepen. Daarom is de optie om monitor.py oneindig uit te voeren een goede keuze. De monitor.py oneindig logt slechts één keer per dag in en vervolgens worden de daaropvolgende oproepen gedaan met de opgehaalde informatie. Helaas voor Europa is het totaal beperkt tot ongeveer 200, dus het aantal logins doet er niet toe. Voor de andere regio's ken ik de limiet en het gedrag niet.

Afhankelijk van uw normale rijgedrag kiest u de beste optie voor u. Voorbeeld:
- voer monitor.py oneindig uit (monitor_infinite = True) met monitor_infinite_interval_minutes = 15 (betekent 96 verzoeken per dag en 1 login per dag)

Toegevoegd Voorbeeldscripts voor het uitvoeren van monitor.py oneindig voor Raspberry Pi en andere op Linux gebaseerde systemen.

Er is een aparte Python-tool toegevoegd, tail2GoogleSheet, om de inhoud van een bestand op een server te volgen en naar een Google-spreadsheet met dezelfde bestandsnaam te sturen. Voorbeelden: volg monitor.csv of het uitvoerlogbestand van monitor.py . Geweldig om de laatste -n regels van een logbestand of een ander bestand op uw smartphone, tablet of computer te kunnen bekijken zonder in te loggen op de server.

Toegevoegd Configuratie van standaardregistratie en opmaak van logboekregistratie .

Opmerking 3: Vergeet niet logging_config.ini naar uw hyundai_kia_connect_monitor directory te kopiëren.

Opmerking 4: De mogelijkheid om monitor.py één keer uit te voeren is nog steeds de standaard, hoewel monitor_infinite = True voordelen heeft. Investeer dus wat tijd om over te schakelen naar de nieuwe manier om monitor.py oneindig uit te voeren.

[ZuinigeRijder]

R4.0.1: kleine fix: monitor_execute_commands_when_something_written_or_error niet uitgevoerd

[Maarten69]

Zou je dat inloggen onbeperkt updaten eens wat beter kunnen toelichten?
Kun je nou elke 15 min de data ophalen?

[ZuinigeRijder]

@Maarten69 Voor een Bluelink USA gebruiker is de limiet iets van 20x de cached server waardes ophalen mogelijk, wanneer iedere keer wordt ingelogd. Voor de USA gebruiker is het maar éénmaal inloggen per dag het effect dat hij onbeperkt de data kan ophalen.

Hier in Europa is de limiet veel hoger, iets van 168x de cached server waardes ophalen, maar éénmaal inloggen zorgt er NIET voor dat je onbeperkt de data kan ophalen. De limiet blijft 168. Zie deze discussie.

Maar ja, ik kan iedere 15 minuten x 24 uur de cached server data ophalen met optie infinite, dat is 96x. Dus je hebt nog ruimschoots een aantal keer over voor gewoon Bluelink of Connect App daarnaast te blijven gebruiken.

Maar infinite heeft ook één ander belangrijk voordeel, je kunt summary.py en dailstats.py in combinatie met infinite alleen uitvoeren wanneer er iets veranderd is. Dus dat is duurzamer, want gebruikt minder resources

[Maarten69]

Bedankt voor je duidelijke uitleg!

[ZuinigeRijder]

R4.0.2: fix: monitor.py wordt niet meer één keer uitgevoerd bij optie monitor_infinite = False

[ZuinigeRijder]

R4.0.3: fix om opdrachten minstens één keer per dag uit te voeren

[ZuinigeRijder]

Voor diegene die de laatste -n regels van een server log-file (of andere file) op een telefoon, tablet of PC willen bekijken, zonder in te loggen op deze server, heb ik een ander tool gemaakt: tail2GoogleSheet.

Ik gebruik deze om wel eens de output/foutmeldingen van monitor.py te bekijken. En naar de laatste regels van monitor.csv te kijken. Zie hier hoe je dit kunt gebruiken.

[ZuinigeRijder]

R4.1.0: Ondersteuning toegevoegd voor Domoticz en/of MQTT Broker (bijv. HomeAssistant, ioBroker)

Belangrijke opmerking: er is een afhankelijkheid van het volgende pakket toegevoegd: paho_mqtt>=1.6.1

Veranderingen aan de uitvoer csv bestanden, worden ook naar Domoticz en/of MQTT Broker gestuurd (bijvoorbeeld HomeAssistant, ioBroker) wanneer geconfigureerd. Wanneer geconfigureerd, wordt de data gestuurd naar mqtt_main_topic/VIN/subtopic.

Voorbeeld screenshot met MQTT Explorer:

[ Voor 6% gewijzigd door ZuinigeRijder op 07-11-2024 12:36 ]

[Stefannn]

Vraagje,
Is die afhankelijkheid van packages “echt nodig”?
Of is er een “minimum versie” denkbaar waarbij dat niet zo is?

De reden is dat ik op Tiny Core Linux draai.
Dat werkt op een super trage machine en draait volledig in ram.
Applicaties gaan standaard via .tzc files die als compressed archive worden gemount.
Op zich kan ik de noodzakelijke packages downloaden maar dan heb ik ze niet zo mooi via compressed archive.
Compressed archive heeft wel wat voordelen (bootspeed, volledig in ram, kan niet vervuilen).

Ik vind deze python applicatie heel mooi maar ik wil ze eigenlijk enkel gebruiken als “domme download van bluelink”, dus zonder alle database eigenschappen. Enkel als download zodat ik er in mijn homeautomation mee verder kan.

Kortom….
Is er een uitgeklede “interface only” versie (cq dat je maar een gedeelte gebruikt) waarmee je die packages niet nodig hebt?

[ZuinigeRijder]

@Stefannn Dan kun je alleen monitor.py draaien. Deze is afhankelijk van Python 3.9 of hoger en hyundai_kia_connect_api en daarmee afhankelijk van de volgende pakketten:

code:

beautifulsoup4>=4.10.0
python_dateutil>=2.8.2
pytz>=2021.3
requests>=2.28.1

monitor.py is NIET afhankelijk van gspread:

code:

gspread>=5.6.2

monitor.py afhankelijkheid van paho_mqtt is sinds kort toegevoegd, maar wanneer je versie R4.0.3 gebruikt, is deze afhankelijkheid NIET nodig:

code:

paho_mqtt>=1.6.1

De reden is dat ik op Tiny Core Linux draai.
Dat werkt op een super trage machine en draait volledig in ram.

Ik heb de scripts op een oude Raspberry Pi van 2013 draaien (alle log-files in RAM, Bulls-Eye OS, geen desktop-UI), inclusief andere scripts voor uitlezen 2 omvormers en uitlezen slimme stopcontacten, en daar draait het ook op, inclusief uitvoeren van summary.py en dailystats.py.

code:

Raspberry PI type B Versie 2.0 met 512MB RAM

P.S. wanneer je de *.csv copieert, kun je summary.py en dailystats.py ook op Windows, Linux of MAC runnen.

[ Voor 32% gewijzigd door ZuinigeRijder op 10-11-2024 10:11 ]

[Stefannn]

ZuinigeRijder schreef op zondag 10 november 2024 @ 09:38:
@Stefannn Dan kun je alleen monitor.py draaien. Deze is afhankelijk van Python 3.9 of hoger en hyundai_kia_connect_api en daarmee afhankelijk van de volgende pakketten:

code:

beautifulsoup4>=4.10.0
python_dateutil>=2.8.2
pytz>=2021.3
requests>=2.28.1

monitor.py is NIET afhankelijk van gspread:

code:

gspread>=5.6.2

monitor.py afhankelijkheid van paho_mqtt is sinds kort toegevoegd, maar wanneer je versie R4.0.3 gebruikt, is deze afhankelijkheid NIET nodig:

code:

paho_mqtt>=1.6.1

[...]


Ik heb de scripts op een oude Raspberry Pi van 2013 draaien (alle log-files in RAM, Bulls-Eye OS, geen desktop-UI), inclusief andere scripts voor uitlezen 2 omvormers en uitlezen slimme stopcontacten, en daar draait het ook op, inclusief uitvoeren van summary.py en dailystats.py.

code:

Raspberry PI type B Versie 2.0 met 512MB RAM

tiny core heeft "out of the box" alleen de pytz extensie
Ik bedenk me echter dat ik eigenlijk waarschijnlijk gewoon enkel het API pakket kan gebruiken.
Met een minuscuul pythonscriptje zou ik een uitlezing moeten kunnen doen en het resultaat in een text-file wegschrijven.
Mijn homeautomation heeft alles in 2 talen: C en php. Ik wil eigenlijk geen grote zaken in een andere taal toevoegen. Enerzijds omdat python voor mij nieuw is, en anderzijds omdat dat weer een extra afhankelijkheid geeft. Een simpel "python gateway" heeft de voorkeur dus.

Bij mij draait het op een 500MHz ultra low power i486 single core processor. Op zich kan die processor dit wel aan. Maar de bottleneck zit hem in de python extensies. Ik gebruik bij voorkeur packages die "standaard door de distributie worden ondersteund".
ik krijg het geheid wel voor elkaar om het met eigen downloads voor elkaar te krijgen maar dit is een project dat nog 20 jaar mee moet (na de 16 sinds 2008 die het achter de rug heeft) dus ik ben erg terughoudend met "spagethy creëren".

NB: het is al een hele verbetering ten op zicht van een half jaar terug. Toen zat ik nog op DSL en was het gods onmogelijk om python3.9 aan de praat krijgen. python3.9 draait inmiddels.
(Jouw full package heb ik van de zomer vanaf MacBook aan de praat gekregen, fun)

[ZuinigeRijder]

@Stefannn monitor.py is samen met monitor_utils.py ook nog geen 1000 regels, hyundai_kia_connect_api is veel groter, dus die paar extra python regels doen het er dan niet meer toe En die afhankelijkheden zitten al in hyundai_kia_connect_api

[ Voor 14% gewijzigd door ZuinigeRijder op 10-11-2024 11:08 ]

[Stefannn]

ZuinigeRijder schreef op zondag 10 november 2024 @ 11:07:
@Stefannn monitor.py is samen met monitor_utils.py ook nog geen 1000 regels, hyundai_kia_connect_api is veel groter, dus die paar extra python regels doen het er dan niet meer toe En die afhankelijkheden zitten al in hyundai_kia_connect_api

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]

R4.2.0: summary.py en dailystats.py sturen nu ook data naar Domoticz en/of MQTT Broker

summary.py en dailystats.py kunnen nu ook gegevens naar MQTT-Broker of Domoticz sturen.

Vanwege deze toevoeging is de MQTT- en Domoticz-uitvoer van monitor.py enigszins gewijzigd.

monitor.py voorbeeld:


summary.py voorbeeld:


dailystats.py voorbeeld:

[ZuinigeRijder]

R4.2.1: Fix: MQTT/Domoticz summary.py-items werden niet verzonden als de taal NIET Engels was

[BenAW]

@ZuinigeRijder Allereerst complimenten voor een mooi stuk software.
Heb net een nieuwe Sportage HEV en heb een poging gedaan om data binnen te halen.
Gaat eigenlijk behoorlijk goed.
monitor.tripinfo.csv vult met de ritgegevens zoals verwacht, prima.
Krijg alleen een melding over een Unexpected line, waarin wel vrijwel alle gegevens staan zoals hierboven onder monitor.
"WARNING: Skipping Unexpected line: 2024-12-04 15:27:54+01:00, 4.822022, 52.688039, False, 99, 62.7, None, None, None, 3; straat; dorp; Dijk en Waard; Noord-Holland; Nederland; 1234 XX; Nederland, -1
20241205 19:45:30: INFO: Sleeping a minute

In de KIA Connect app zie ik ook de brandstofhoeveelheid als grafiekje.
Waarom is die line Unexpected?

[ZuinigeRijder]

@BenAW Dit komt door "None, None, None" waardes, blijkbaar heeft de HEV geen "SOC%, charging, plugged".

Je kunt monitor.py aanpassen, zodat deze waardes met default waardes worden weggeschreven.

regel 442:

code:

        line = f"{newest_updated_at}, {location_longitude}, {location_latitude}, {vehicle.engine_is_running}, {vehicle.car_battery_percentage}, {float_to_string_no_trailing_zero(odometer)}, {vehicle.ev_battery_percentage}, {vehicle.ev_battery_is_charging}, {vehicle.ev_battery_is_plugged_in}, {geocode}, {ev_driving_range}"  # noqa

veranderen in (SOC% is altijd 100%, niet laden, geen laadstekker geplugd):

code:

        line = f"{newest_updated_at}, {location_longitude}, {location_latitude}, {vehicle.engine_is_running}, {vehicle.car_battery_percentage}, {float_to_string_no_trailing_zero(odometer)}, 100, False, False, {geocode}, {ev_driving_range}"  # noqa

[BenAW]

@ZuinigeRijder Bedankt, super snelle hulp ;-)

In 1 keer werken voor deze amateur programmeur.

[ZuinigeRijder]

R4.3.0: Diverse bugfixes

Problemen opgelost wanneer het wachtwoord in monitor.cfg speciale tekens bevat (% wordt bijvoorbeeld gebruikt voor interpolatie van ConfigParser). Zie dit probleem

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.

Voorbeeld configuratie.yaml toegevoegd, dankzij Bluhme1. Bekijk hier screenshots en enkele Home Assistant-instructies .

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