Volkswagen lijkt api af te knijpen, werkt niet meer op Home Assistant

Volkswagen lijkt de toegang tot zijn api te hebben beperkt. Daardoor is het niet meer mogelijk Volkswagen-data te gebruiken in apps van derden, zoals Home Assistant. Het is nog onduidelijk of dat een bug is of dat Volkswagen bewust de toegang heeft afgeknepen. Dat laatste is niet ondenkbaar; fabrikanten doen dat regelmatig.

In de GitHub-repo van de Volkswagen-integratie voor Home Assistant melden tientallen gebruikers dat ze sinds woensdag geen toegang meer hebben tot sensors of bediening van hun Volkswagens in het smarthomeplatform. Ook op het Tweakers-forum melden gebruikers dat de api-endpoints niet meer bereikt worden.

Andere gebruikers denken de oorzaak te hebben gevonden, wat mogelijk een oplossing kan zijn. Het probleem lijkt een aanpassing van de OAuth-flow te zijn. Een gebruiker op GitHub beweert een nieuw authenticatieproces te hebben ontdekt waarmee het wel mogelijk moet zijn weer in te loggen, al bevestigen andere gebruikers nog niet of dat werkt.

Het is onduidelijk wat de oorzaak van het probleem precies is. Het zou kunnen dat Volkswagen simpelweg een fout heeft gemaakt bij het bijwerken van de api. Een andere mogelijkheid is dat het om bewust beleid gaat. Fabrikanten hebben in het verleden vaker open api's gesloten, waardoor thirdpartyintegraties niet meer werkten. Dat gebeurde eerder bijvoorbeeld al met Somfy, Bose, Panasonic en TP-Link. In sommige gevallen wordt zo'n besluit na ophef ook weer teruggedraaid. Dat deden bijvoorbeeld Haier en Daikin eerder al.

Sommige gebruikers vermoeden dat Volkswagen de api, die tot nu toe gratis was, op termijn betaald wil maken. Zo merken gebruikers op dat sommige integraties zoals Tronity nog wel werken. Tronity maakt alternatieve diensten voor auto's op basis van api's van fabrikanten, maar betaalt daar wel voor. En die kunnen de Volkswagen-api nog wél gebruiken.

Reacties (202)

[CasperWezep]

Hi, developer van de Homey integratie voor Volkswagen hier!

Na wat reverse engineering is mijn conclusie dat het een bewuste keuze is en geen bug. De nieuwe versie van de app doet bij het inloggen eerst een call naar het challenge-endpoint van Cariad, waarna er een reeks calls naar Google's Remote Key Provisioning-infrastructuur gaan. Die calls zijn bedoeld om via een hardware-gebonden sleutel te bewijzen dat je op een legitiem, niet-geroot Android-toestel zit. Het resultaat daarvan wordt meegestuurd als X-Assertion header bij het daadwerkelijke token-verzoek. De server valideert dat server-side en geeft een {"error": "invalid assertion"} terug als het niet klopt — inclusief een x-assertion-error: ASSERTION_FAILED in de response headers. Verdere technische details van mijn bevindingen kan je teruglezen in dit GitHub issue.

[magician2000]

En bedrijven zullen dit me alles blijven proberen. Meestal komen ze er vanaf met een 'oeps, foutje!', maar het is de hoogste tijd dat we stoppen met dit te geloven. Het is uitproberen en zorgen dat wat je koop niet meer je eigendom is.

Hacken die bende en de open source ingooien. Laat de EU daar maar eens wetgeving voor maken (legaal hacken en openbaren in dit soort gevallen, dan gaan bedrijven wel meer samenwerken en open zijn).

[Jelmer]

Dit is waar ik graag zie dat op EU niveau er een open standaard wordt afgedwongen voor alle automerken. Een universele interface voor smart bidirectional charging en basis functies als status, klimaat en vergrendeling. Bij voorkeur op basis van een fysieke interface zoals odb2 waar je een eigen gateway (diy of kant en klaar producten van derden) op kan aansluiten en zo ook naar de toekomst niet afhankelijk bent van de fabrikant van de auto.

[BRAINLESS01]

Volgens mij is dit al op Europees niveau geregeld en geldt het voor alle apparatuur die data genereert. Sinds 12 september vorig jaar is er de Data Act: https://digital-strategy.ec.europa.eu/en/policies/data-act

Hierin staat onder andere:

Right to access the data

When acquiring a 'traditional' product, you receive all of its components and accessories. However, in the case of connected devices (specifically within the Internet of Things (IoT)), new data is generated during normal usage. This adds to the product, becoming one of its essential components.The Data Act gives individuals and businesses the right to access the data produced through their utilisation of smart objects, machines and devices.

Volgens mij mag een bedrijf helemaal niet de toegang tot deze data beperken als het beschikbaar is, maar ik heb nog nergens iets gehoord over handhaving. Ik loop tegen hetzelfde probleem aan met mijn warmtepomp, die wel data heeft en dat ook naar de cloud kan uploaden, maar waar je alleen met een betaalde API bij kunt. Dat mag niet meer, maar ik heb ook niet echt behoefte om zelf een rechtszaak te starten.

[3_s]

Hoe je het ook kan lezen: je hebt het recht tot toegang tot je data. Aangezien hun eigen app nog werkt, kan je nog steeds aan je data. En dus voldoen ze.

Ik lees er ook niet in dat het gratis moet zijn: je mag aan je data, op voorwaarde dat je betaalt.

Maar goed, ik ben geen rechter, geen idee hoe die dat interpreteren.

[Rob Meerwijk]

Je betaalt en niet weinig ook. Bijna 10 euro per maand voor weconnect plus. En ze voldoen niet door je een aggregatie in de app aan te bieden. Je hebt recht op de ruwe data op eenvoudige wijze en in real time! Helaas gaat de EU DATA ACT alleen over data en niet over controls. Dat betekent dat op afstand je deuren sluiten als je dat vergeten bent niet via je Home Assistant kan doen. Daar heb je dan nog steeds die crappy app van VW voor nodig. Of je target SOC verhogen als je ver weg bent en weer naar huis wilt. Ook dat gaat niet.

Maar erger nog. De VW-App werkt ook niet meer op andere devices dan Android en Apple. Dat zou ons als tweakers toch ook woest moeten maken, toch! De helpdesk zegt doodleuk dat je smartphone met alternatief OS niet meer ondersteund wordt.

Kortom, Koop geen VW, Audi, Skoda, Cupra of aanverwante.

[BRAINLESS01]

In combinatie met deze wordt betalen voor je data lastig, denk ik:

Cost-effective repair and maintenance of connected products

Users of connected products may choose to share this data with third parties. This will enable aftermarket (e.g. repair) service providers to enhance and innovate their services, fostering fair competition with similar services provided by manufacturers. Consequently, users of connected products, including consumers, farmers, airlines, construction companies or building owners, will have the option to choose more cost-effective repair and maintenance providers (or undertake these tasks themselves), leading to potentially lower prices in the market. This could also extend the lifespan of connected products, thus contributing to the Green Deal objectives.

Het doel is dat je bij je data kunt zodat anderen reparatiediensten kunnen aanbieden, als je daar vervolgens nog een extra abonnement bij de fabrikant voor nodig hebt vallen die voordelen weer weg.

[SunnieNL]

Je krijgt toch gewoon toegang tot die data via de VW App? Er staat nergens dat het moet via een publieke API. En er staat ook niet dat je die data moet kunnen benaderen via het device zelf. Dat kan nog steeds via een cloud service van de fabrikant lopen.

[CopyCatz]

Het probleem is alleen dat DIY software als Home Assistant een impact kan hebben op de auto; we hebben hetzelfde gehad met de Kia/Hyundai bluelink integratie waarbij gebruikers te enthousiast de api aan het pollen waren waardoor de 12v accu werd leeggetrokken en soms beschadigd raakte. Uiteindelijk heeft de fabrikant een server side cache moeten instellen waardoor de auto niet onnodig werd gepolld. Een universele interface rechtstreeks op de auto zonder tussenkomst van een fabrikant komt dus wel met een zekere verantwoordelijkheid.

[-DEVON-]

Dat klinkt eerder als een verkeerde implementatie aan de fabrikant-zijde. Die moet tegen dit soort fouten bestand zijn.

[cricque]

Veel mensen hebben geen kaas gegeten van programmeren. Een scriptje maken (tegenwoordig met behulp van AI) lukt meestal nog wel, maar ze hebben totaal geen idee wat de impact is.

Als jij nu iets maakt dat elke seconde gaat checken is er iets nieuws .. is er iets nieuws .. Ik krijg voor mijn eigen software dikwijls deze vraag ... En dan zeg ik nee ... ik zal wel pushen als er iets nieuws is, niet omgekeerd, constant pollen is not done. Uiteraard zit je dan met het probleem ... ja maar ik heb geen vaste url etc, en dan is het pollen ... Uiteraard zijn daar oplossingen voor, maar daar moet je dan ook van op de hoogte zijn uiteraard. Enja ik wil data elke seconde ! En dan krijg je deze dingen

Uiteraard kan een api rate limits opzetten en zo moeilijk is dat niet. Dat is iets wat ik mijn studentjes ook wel aanleer, altijd een rate limit op je api zetten als je die voor het publiek open zet. Voor jezelf hoeft dat uiteraard niet, maar als je anderen toegang geeft, rate limits ... Uiteraard zijn er misschien bepaalde gevallen waar dit niet wenselijk is, maar ik ken bitter weinig situaties waar iemand elke seconde gegevens moet ophalen van een publieke api

Bij een wagen zie ik dit bijvoorbeeld voor de laadstatus wel gebeuren, maar dan nog zou er moeten gepushed worden.

Deels de fout van de fabrikant ja ... Maar een gebruiker mag je niet onderschatten hoor

[TheVivaldi]

Het lijkt mij dat als je meer nodig hebt dan de rate limit toestaat, dat een mailtje met de vriendelijke vraag plus uitleg waarom volstaat?

[Gwaihir]

Waarom zijn al die API's dan standaard polling? Zeker van device (auto) naar cloud hoort dat toch gewoon een push systeem te zijn? Als het om een cloud api gaat (niet rechtstreeks naar de auto), dan vind ik het sowieso fout van de fabrikant.

Ik heb hier IoT devices op batterijen die je omwille van zuinigheid helemaal niets 'even' kunt vragen. Die checken zelf elk 10 minuten (instelbaar) even in: de nieuwe metingen + het legen van hun 'inbox' van verzoeken aan hen. Daar tussendoor is hun netwerkmodule niet actief.

[BugBoy]

Pushen van informatie is best lastig, omdat je meestal geen webhook kan gebruiken (client zit achter NAT, firewall, ...) en anders moet je een connectie open houden. Dat kost erg veel resources als je dat op hele grote schaal moet doen. Polling is vaak veel eenvoudiger, maar je moet wel rate-limiting inbouwen om clients af te stoppen die rare dingen doen...

[Reactie gewijzigd door BugBoy op 29 mei 2026 12:11]

[SunnieNL]

Voor pollen moet je (in geval van een auto) toch ook continue de verbinding open hebben. Als ik hobbel met een 4G verbinding, dan heb ik steeds wel/geen verbinding, met andere IP adressen, etc. De auto moet toch al de verbinding opbouwen, dan kan die ook een pull doen.

Die IOT apparaten op batterijen leveren ook hun gegevens aan een caching server, waar jij met je client weer tegenaan praat.

[BugBoy]

Voor push moet een TCP verbinding open blijven staan. Bij polling kan die na elk request de verbinding weer sluiten. Dat scheelt een hoop verbindingen op je server (tenzij je natuurlijk als een dolle gaat lopen pollen). Op schaal is informatie pushen echt een lastig iets...

[SunnieNL]

Bij een pol moet de verbinding ook open blijven staan omdat de auto niet continue op hetzelfde ip bereikbaar is en daarnaast ook meestal achter een mobile firewall van de provider staat. Juist bij een push van auto naar cache server Kan de verbinding dicht.

[Reactie gewijzigd door SunnieNL op 29 mei 2026 19:49]

[-Vasa-]

Wat je maakt is ook niet persé hoe gebruikers het beginnen te gebruiken. Als je een API maakt voor iets zoals een wagen kan ik mij voorstellen dat de originele scope hiervoor niet was dat je rekening moet houden dat users zonder besef van waarom het niet mag, gaan beginnen pollen op een manier dat de batterij wordt leeggezogen.

Rate-limiting implementeren zullen ze nu misschien wel in de toekomst doen, maar ik kan mij echt wel voorstellen dat dat dus niet in de originele scope zat.

[procyon]

Sorry, maar een leeglopende 12V-accu in een BEV is gewoon een ontwerpfout. Bij mijn Tesla was de 12V-accu op een gegeven moment volledig defect. Het infotainmentsysteem meldde toen dat de hoogspanningsaccu de functies had overgenomen, maar dat dit zou leiden tot een hogere phantom drain. Ook softwareupdates konden niet meer worden uitgevoerd zonder een werkende 12V-accu.

Zo hoort het in principe ook te werken: wanneer de spanning van de 12V-accu te laag wordt, moet deze automatisch worden bijgeladen vanuit het grote accupakket, ook wanneer de auto stilstaat.

Als gebruikers hun 12V-accu toch leeg konden krijgen, dan heeft de fabrikant dit waarschijnlijk niet of onvoldoende geïmplementeerd. De onderliggende oorzaak ligt dan bij het ontwerp van het systeem en niet bij het gedrag van de gebruikers.


Bij Tesla is overigens de polling rate gelimiteerd (ik gebruikte dit om op 5 seconde niveau de laadsnelheid aan te passen om niet over mijn stroom limiet te gaan. (Met Homey die de P1 meter uitlas).

Dat bleken teveel acties waarna Tesla me vriendelijk vroeg of ik voor meer polling acties een betaald account wilde overwegen. Niet gedaan overigens want er zijn betere manieren om het maximale stroomverbruik te beperken.

[Reactie gewijzigd door procyon op 29 mei 2026 10:03]

[-Vasa-]

Hoe batterijen mekaar moeten opladen weet ik toegeven niet veel van in de zin van hoe makkelijk en logisch dat is om te implementeren. Wat jij zegt kan dus zeker waar zijn, maar ik weet dat niet.

Ik was met mijn antwoord eerder aan het denken aan situaties die ik in mijn eigen kennisveld wel al heb ondervonden. Een REST-API die eigenlijk in eerste instantie ontworpen is voor intern gebruik en zelf-referentie omdat het nu eenmaal makkelijker is om te gebruiken op die manier en relatief future-proof is als je kan vermoeden dat het ooit van buitenaf bereikbaar zou moeten zijn. (En met buitenaf bedoel ik een sessie die niet op hetzelfde device wordt uitgevoerd, bijvoorbeeld het infotainment en de eigenlijke wagensturing zijn in theorie minstens twee logische verschillende devices en sessies, hoewel dat allemaal in dezelfde wagen zal zitten)

Als je dan begint met je eigen app ben je nog altijd in een situatie waarin externen kunnen beginnen dingen te doen die je niet verwacht had. Zelfs eigenlijk dan nog als je externe partners toelaat om een implementatie te maken. Het is pas wanneer "iedereen" mag beginnen spelen met die interfaces dat je gaat beseffen dat niet iedereen nadenkt over zaken zoals resource verbruik en performantie van implementaties. En je kan dan wel stellen dat je maar beter je best had moeten doen om dat softwarematig dicht te schroeven, maar anderzijds zou je ook mogen verwachten dat als iemand iets ontwikkelt om bijvoorbeeld statussen te monitoren van een dienst (of in dit geval wagen), dat die persoon die dat ontwikkelt, dat doet op een manier dat de monitoring acties op zich geen negatieve invloed hebben op het geen je wilt monitorren.

[Reactie gewijzigd door -Vasa- op 29 mei 2026 10:09]

[kozue]

Dat bleken teveel acties waarna Tesla me vriendelijk vroeg of ik voor meer polling acties een betaald account wilde overwegen. Niet gedaan overigens want er zijn betere manieren om het maximale stroomverbruik te beperken.

Maar ben ik dan de enige die het raar vind dat Tesla voor jou kan bepalen wat je wel en niet met je auto mag doen? Als ik iedere seconde wil pollen en m'n accu leeg laten lopen, is dat toch mijn eigen keuze? Waarschuwingen of beperkingen om het systeem te beschermen lijken me logisch, maar meer betalen om meer te mogen pollen? Een "betaald account"? Wat een onzin. Je hebt nota bene dik betaald voor die auto, en dan proberen ze er nog de baas over te spelen.

M'n eerste gedachte was "moet je maar niks van die idioot Musk kopen", maar ik denk dat Tesla hier tegenwoordig lang niet de enige in is. Ze proberen hun producten steeds meer tot een licentie om te bouwen, en daar mag de wetgeving best eens wat aan doen.

[procyon]

Denk dat je het niet helemaal snapt; die API polling gaat via hun servers zodat je je auto overal ter wereld kan bedienen. Dus het is geen recht dit te mogen doen. Dat ze het gratis beschikbaar stellen is gewoon mooi en dat ze een aantal polls gratis aanbieden is gewoon prima. Maar gedurende laadsessie van uren elke 5 seconde een polling request te doen maakt dat je op maandbasis snel door je gratis tegoed heen bent.

Het is overigens de 'fleet API' en je kan dus echt bizar veel bedienen en uitlezen op afstand.

Geen idee of andere fabrikanten dat überhaupt hebben en als ze het hebben wat je ermee kan doen of wat de beperkingen zijn. Ik zie het glas hier eerder halfvol dan halfleeg.

[sterreke]

Heb ik ook een tijdje gebruikt, toen het nog onbeperkt was. Ik las (en paste het laadvermogen) wel maar on de 30 seconden aan. Maar om niet aan limieten gebonden te zijn, doe ik het nu met een raspberry pi over een Bluetooth verbinding. Zie https://github.com/tesla-local-control/tesla-local-control-addon

[Kastermaster]

Ik kan mij dit eerlijk gezegd niet voorstellen. Met nieuwe digitale wetgeving in het vooruitzicht is security en privacy by design gewoon een vereiste. Bovendien wordt op iedere school waar je leert programmeren in de eerste lessen al verteld dat je software katproof/foolproof moet zijn. Dat betekent dat je fouten netjes afvangt, en daar hoort ook een hoge polling rate bij.

[-Vasa-]

Security by design heeft niets met rate-limiting te maken. Als je een degelijke authenticatie-routine hebt, is secure by design al gecovered. En het foolproof zijn is een eeuwige strijd. Als je ergens begint te werken als ontwikkelaar zal je eerste uitleg meestal net zijn dat je moet schrijven wat gevraagd is om te schrijven, binnen de tijd die is toegewezen. Als jij als junior dan komt vertellen dat je op school hebt gezien dat de scope waar mogelijk een 20-tal mensen een paar weken meetings over hebben gehad, fout is, zal wel een andere ontwikkelaar gevonden worden die niet snapt waarvoor ie betaald wordt.

En zoals ik al had gezegd, feature-creep is een ding, ik kan het niet zeker weten, maar ik ben vrij zeker dat hoe dat nu gebruikt wordt, niet voorzien was in de scope. Bijkomend ga je zelf met wat "standaard" rate limiting is, meestal nog iets anders doen dan wat nodig is voor een systeem dat eigenlijk op een 12V batterij werkt en afhankelijk van het data-bereik van de sim kaart ook nog eens andere battery-drain gaat hebben die je niet gaat kunnen berekenen.

[SunnieNL]

Als je een API maakt voor een auto, zorg je er voor dat deze API niet rechtstreeks met de auto praat maar met de middleware. Security technisch wil je geen publieke API rechtstreeks met een auto verbinden.

De middleware vangt de polling af en via de auto kan nog steeds een MQTT of Push komen richting de middleware. Al gok ik dat het technisch nog beter is om publieke client <> Middleware <> Database <> Middleware <> Auto te hebben.

[Reactie gewijzigd door SunnieNL op 29 mei 2026 14:17]

[mijsk1974]

Ja doei.

Men gebruikt derden software die wel werkt maar niet ondersteund wordt en dan moet de fabrikant het maar oplossen? Als ik mijn lampen laat branden of mijn sleutel in de auto laat liggen is men tegenwoordig zo vriendelijk mij daar op te attenderen. Maar het is nog steeds een service aan de gebruiker, waarvoor je via via heus wel betaald hebt maar toch een service. De verantwoordelijkheid ligt bij de gebruiker. Als ik een blikopener gebruik om mijn auto open te maken kan ik toch ook niet klagen als hij niet meer goed sluit? Men gebruikt een tool waar de fabrikant niet van uitging dat die gebruikt zou gaan worden. Los het zelf op.

Dit soort argumenten gebruiken fabrikanten om juist alles af te grendelen.

[trucker0werner]

Precies, api vragen om data betekent niet dat Api data moet verversen. Api krijgt data bij starten en stoppen van de wagen. Bij laden is dat elke x sec of minuten. Puur om door te geven dat hij vol is. Zodat je bij kan houden Hoe vol hij precies zit op dat moment.

[Gropah]

Maar als er een open standaard komt, die ook voorschrijft hoe vaak te pollen kan de fabrikant daar zn systeem op afstellen, en kunnen ontwikkelaars voor home assistant (en andere diensten) zich er ook aan houden ipv dat ze maar wat moeten gokken. En scripties gegenereerd door LLMs zullen die dan hopelijk ook aanhouden. Dus waarom zou een open standaard hiervoor een probleem zijn?

[Joost1981_2]

Sorry maar als je daar de DIY software de schuld van gaat geven is de kwaliteit van software in de auto nog triester dan ik dacht. Je legt de verantwoordelijkheid dus meer bij de FE/App? Dit snap ik als engineer echt niet

[SunnieNL]

Een server-side cache lijkt me sowieso wel iets wat je wilt als fabrikant. Je wilt toch niet dat elke call eerst naar de auto gaat en dan terug? Daarnaast is zo'n cache een stuk veiliger. Als er iets mis gaat kom je alleen bij de cache en niet in de interface naar de auto. Statusverandering van de auto doen dan een push naar de cache. En alle pulls van client worden dan afgehandeld door de cache. Volgens mij werkt dat al zo bij Volvo en bij BMW. Je krijgt daarbij een melding van de laatste status update door de auto. Is dat lang geleden dan kan de cache altijd nog een pull doen bij de auto. Of je bouwt een MQTT stream op de backend waarbij auto's continue hun status streamen die dan in de cache kan worden opgevangen.

Bij Volvo kreeg ik zelfs de melding na een aantal dagen niet rijden dat de auto in een meer diepere slaap zit en minder responsive zou zijn (omdat de auto minder vaak checked bij de server wat hij moet doen)

[rene_fb]

Bij voorkeur op basis van een fysieke interface zoals odb2 waar je een eigen gateway (diy of kant en klaar producten van derden) op kan aansluiten

LOL. Laten we dat vooral niet doen...

De OBD is een diagnose interface met voor een groot deel onversleutelde data (al zie je langzaam wel meer secure diagnostics en zaken als SecOC).

Op die poort allerlei kastjes aansluiten (ook van die dongels van verzekeringen etc.) Is als de auto midden in de stadt parkeren en de sleutels op het dak leggen.

En als het doel is "smart bidirectional charging", laten we dat dan lekker via de CCS2 lopen, die heeft niet voor niets ook een data communicatie ingebakken.

[Earth_Apple]

Hij zegt toch zoals ODB2? Laat ze maar een nieuwe standaard samen uitvogelen waar alleen de veilige data uit verkregen kan worden, en niet de hele auto mee bestuurd kan worden/geprogrammeerd kan worden. Eventueel een poort die alleen data eruit stuurt, vergelijkbaar met een P1-poort van je stroommeter. Verder afhandeling van het laadproces kan wel via CCS2.

[iAR]

Waarom beperken tot automerken? Binnen de domotica worden ook veel beperkingen behouden. Vaak werkt het wel maar als de producent besluit dat het niet meer werkt heb je afval.

[trucker0werner]

Helemaal eens. Wij bezitten de product en dus willen we toegang tot onze data dat wordt verzonden.

Via de app krijg je helft van de data soms te zien.

Zowel bij ford als bij seat komt er meer data aan bij de fabrikant dan dat we in de app zien

[pdidi]

Autofabrikanten zijn verantwoordelijk voor de cybersecurity gedurende de gehele life cycle, vastgelegd in EU UN r155 richtlijn en onder toezicht van goedkeuringsinstanties zoals RDW. Hierin worden external interfaces zoals OBD als hoog risico benoemt. Hoe meer DIY access je toelaat, hoe hoger het risico. Autofabrikanten zoals Tesla dekken zich daar als volgt voor in:

De Beperkte garantie nieuwe auto geldt niet voor schade aan de hardware of software van uw auto, verlies van of schade aan (persoonlijke) gegevens die naar uw auto zijn geüpload, als gevolg van aanpassingen van of toegang tot voertuiggegevens of -software door onbevoegden, inclusief, maar niet beperkt tot, onderdelen of accessoires van andere leveranciers dan Tesla, aanpassingen, toepassingen van derden, virussen, bugs, malware of andere vormen van inmenging of cyberaanvallen;

[Reactie gewijzigd door pdidi op 29 mei 2026 11:30]

[helloitsme]

Zie dit bericht voor een toelichting: Senaxx in "Het grote Škoda ENYAQ (iV) topic - Deel 4"

[3raser]

Lijkt me duidelijk. Alleen goedgekeurde apps van derden mogen nog gebruik maken van de API. Home Assistant gaat daar dus niet meer bij horen. Met heel veel geluk kan Home Assistant straks misschien via een goedgekeurde app van derden weer data verwerken maar ik zou er eigenlijk niet op rekenen. Volkswagen lijkt dit vooral te doen om de service stabieler te maken wat dus zoveel wil zeggen als dat ze nu teveel API requests kregen en dat ze van die bulk af willen.

[lenwar]

Home Assistant gaat daar dus niet meer bij horen.

Nou ja. Waarom niet? Als Nabu Casa of eventueel de HACS-module schrijver dat weet te regelen met Volkswagen is het toch prima? Ik weet natuurlijk niets van de kwaliteit van de huidige module. Voor hetzelfde geld zit die ongelofelijk te bashen tegen die API.

We zagen iets dergelijks een tijd geleden ook met de HACS-module voor Zonneplan. De gezamenlijke gebruikers van die module deden een soort DDOS op de Zonneplan APIs (tot op het niveau dat hun eigen dienstverlening er onder leed). Zonneplan blokkeerde de API voor derden, nam contact op met de HACS-module eigenaar, en ze hebben samengewerkt om het weer te laten werken, maar dan op manier dat Zonneplan er geen last van had. Probleem opgelost.

Ik heb dit later ook met een ander product gezien, alleen ging dat product in eerste instantie gelijk dreigen met rechtszaken e.d. En een paar dagen later was alles opgelost door samenwerking. (ben even kwijt welk bedrijf dat was.)

Edit
Die laatste betrof Haier (Van de merken Haier/Candy/Hover)

[Reactie gewijzigd door lenwar op 29 mei 2026 09:29]

[3raser]

Noem me slecht van vertrouwen, maar ik ga er vanuit dat de partijen die straks goedkeuring krijgen ook moeten gaan betalen voor het gebruik. Ik denk dat Volkswagen letterlijk af wil van iedere vorm van gratis gebruik van de API, simpelweg omdat zij er anders niets aan verdienen. Zie het voorbeeld van Tronity, die blijkbaar nog wel werkt. Is die al door de VW keuring gekomen of is dat omdat ze al betaalden voor het gebruik? Ik gok dat laatste.

[lenwar]

maar ik ga er vanuit dat de partijen die straks goedkeuring krijgen ook moeten gaan betalen voor het gebruik

Dat hoeft natuurlijk ook niet per se fout te zijn. Zeker niet als daar ook nog wat tegenover staat. Ik heb zelf geen 'slimme auto', maar stel dat je een paar euro per jaar je spullenboel kunt uitlezen (dus dat je een token gebruikt in de HA-configuratie), dan kan dat het toch waard zijn voor iemand?

Ze 'moeten' die API natuurlijk niet gratis aanbieden. Dat is hooguit 'leuk voor de klanten'.

Maar goed. Wat ik al schreef. Zonneplan en Haier sloten de boel af vanwege 'verkeerd gebruik' van de APIs. Ze hadden er last van. Misschien is dit ook zo bij VW. En misschien is het inderdaad gewoon een flauw iets van VW of willen ze centen zien. Wie zal het zeggen.

Er zijn ook andere integraties van HA zelf voor auto's, dus blijkbaar doen niet alle merken (heel) moeilijk:
https://www.home-assistant.io/integrations/?cat=car

[.oisyn]

Ze hadden er last van

Ze hadden er last van omdat ze per se kiezen voor een cloud oplossing ipv dat die data gewoon lokaal uit het apparaat te halen is.

Ik heb hier aircos van Mitsubishi. Die "Smart m-air" app is een gedrocht, en ik moet elke keer 2s wachten op updates omdat die servers waarschijnlijk in Japan staan oid. Iemand heeft het protocol reverse-engineerd, en via Home Assistant kan ik die dingen dus gewoon lokaal aanspreken. Ze reageren dan ineens instant op status-updates en commando's.

[lenwar]

Dat is natuurlijk weer een andere discussie . Ik zie ook het liefst alles gewoon lokaal. Ik heb een 1ste generatie Duux ventilator. Die maakt gebruik van het Tuya-gebeuren. Ik heb een HACS-module "LocalTuya". Daar kun je met de tokens van het apparaat hem ook lokaal bedienen. M'n Duux hangt niet meer aan het internet. Alles lokaal via Home Assistant. Zelfde met m'n Siemens oven/kookplaat. Daar heeft ook iemand iets gebouwd. (Wat draait als een Addon die met MQTT praat)

In het geval van een auto is dat misschien wat minder praktisch. (gezien die ook wel is buiten je eigen LAN is ).

[.oisyn]

Ja eens, met een auto is het wat lastiger, al zou het natuurlijk in principe geen probleem zijn als dat ding gewoon met je lokale wifi verbindt als hij op de oprit staat. Je kunt je afvragen hoe zinnig home automation is voor een auto die onderweg is .

[lenwar]

Dat is ook weer zo

[TrekVogel]

Smart-m-air is het meest wanstaltige gedrocht dat ik ooit heb gezien. De wifi module is gewoon een Espressif SoC die weliswaar alleen 2.4Ghz kan, prima op mixed AP's werkt als die goed geprogrammeerd is. Deze firmware ziet het netwerk bij mixed mode vaak wel maar wil er niet mee verbinden. Tot niet zolang geleden was het zelfs zo dat Ziggo op afstand modem instellingen moest aanpassen omdat het anders niet werkte. Er is een DIY ESP module met firmware die veel beter werkt.

De app is met zo erg. Naar verluidt gemaakt door de drummer van de Jostiband toen die werkloos raakte. Het is traag, gebruikers zitten elkaar in de weg en werkt vaak gewoon niet. Dat is als je al kunt inloggen. Als je namelijk niet alles gewoon zelf intypt maar je toetsenbord b.v. je emailadres laat invullen werkt het 99% van de keren niet! iPhone is hier nog moeilijker bij dan Android.

MHI airco's zijn erg goed maar hun wifi oplossing is verschrikkelijk. DIY werkt geweldig. Wil je dat niet, vraag dan om de (dure) Intesis AC Cloud oplossing, die werkt wel goed.

[TrekVogel]

Zonneplan is ook niet zo'n slechte partij als ik het zo zie. Ik heb het idee dat zij begrijpen dat we vooruit moeten en we de pioniers nodig hebben. VW is ongeveer het tegenovergestelde.

[lenwar]

Volgens mij kun je dat stellen over de volledige Europese auto-industrie. Die worden links en rechts ingehaald door de Chinese industrie. Het hele concept van bewust incomplete auto’s ontwerpen, en de ‘extraatjes’ tegen achterlijke meerprijzen aanbieden tegen een standaard-auto met alles erop en eraan. (Wat dus een luxere auto goedkoper maakt om te produceren, door een simpelere fabriekslijn)

Over Zonneplan weet ik het niet. Ze doen in elk geval alsof, maar het blijft natuurlijk een bedrijf dat centen moet verdienen (geen oordeel, gewoon een feit 😊). Ik ben eigenlijk ook erg benieuwd hoe ze het gaan doen wanneer de salderimg wegvalt, want dan is je zonnestroom ineens geen droppie waard. Sterker nog. Dan zijn er ineens heel veel meer ‘negatieve stroomprijs-uren’ bij het terugleveren (het gebeurd best vaak dat de stroomprijs onder de 13ct (met belasting) is.)

[TrekVogel]

Volledig eens over de auto industrie. China loopt voor en niet een beetje. Terwijl we in de eu steeds strengere eisen kregen, moest de industrie nog wel in de benen gehouden worden. Dat werkt niet.

Zonneplan is ook geen filantropische instelling, ook daar moet geld verdiend worden. Net zoals bij andere aanbieders van energie. Maar ze bieden zonnepanelen, batterijen en energiecontracten aan. Naar mijn weten hebben ze geen eigen centrales. Dat maakt ze flexibel, maar hoe lang zoiets werkt weer niemand.

[lasharor]

Als het volume een probleem is kunnen ze het beter oplossen door kosten te introduceren. Tesla geeft bijvoorbeeld 10 dollar aan gratis API calls per maand. Daarna moet je betalen.

Wat je dan ziet is dat ontwikkelaars beter hun best doen om de API calls te beperken. Dus, daarmee zet je een stap naar het oplossen van het probleem.

[3raser]

Ik denk niet dat meedenken met de klant een onderdeel is bij de Volkswagen groep. Dat zie ik vooral aan de abonnementskosten voor het gebruik van de app om je eigen auto op afstand uit te kunnen lezen. En dan heb ik het nog niet eens over op afstand bedienen (zoals climate control). 70 euro per jaar om te kunnen zien of mijn accu vol is... heel normaal bij Volkswagen.

[sdk1985]

Maar zo vreemd is het toch niet in het betalen voor de datasim in je auto? Iemand moet die verbinding betalen.

[mcmd]

Dat lijkt me in dit geval niet zo'n sterk argument. Ze zullen de verbinding voornamelijk gebruiken voor het verzamelen van allerlei gegevens om hun producten te kunnen verbeteren en de klant te waarschuwen dat de auto binnenkort een service beurt nodig heeft.
Meer "eigenbelang" dan consumentenbelang lijkt mij.

[Annihilism]

Hangt er ook vanaf of je ook zonder die data-sim via Wifi of je telefoon bepaalde functies gewoon kunt gebruiken. Sommige fabrikanten maken het wel erg bont. Mijn auto heeft er (tot nu toe) geen last van en het meeste heeft geen extra kosten. Betalen om te zien of je batterij vol is of niet vind ik eigenlijk wel van de zotte gezien hoe basaal het is (maar ik heb geen volkswagen dus geen idee of dat zo is, ik neem het nu even aan van 3raser).

[vDorst]

Ja/Nee, probleem dat ik er mee heb, dat je geen keuze hebt. Prima dat ze een dienst aanbieden voor mensen die geen kennis/behoefte of de rompslomp willen. Het is nu niet mogelijk om zelf een simkaart erin doen of wifi te gebruiken en een eigen dienst/proxy opzetten om de data te verwerken. Tevens dat er geen redelijke kosten aan vast zitten. Redelijk noem ik < 10 euro per jaar.

[Rannasha]

Maar zo vreemd is het toch niet in het betalen voor de datasim in je auto? Iemand moet die verbinding betalen.

Op zich niet, maar de kosten (~10 per maand na de eerste 2 jaar gratis, bij mij iig) zijn veel hoger dan de kosten van de dataverbinding voor de fabrikant. Dergelijke data diensten worden door fabrikanten in bulk ingekocht voor een fractie van wat wij als consumenten voor onze mobiele abonnementen betalen.

[Manderlay1]

Tja moeten ergens het geld halen dat ze verliezen omdat men veel minder onderhoud moeten uitvoeren op de elektrische wagens

[TrekVogel]

Dat is het wel een beetje denk ik. Op de auto zelf halen ze weinig marge. Beurten zijn bij de dealer heel erg duur geworden. Mijn vader heeft na heel wat jaren VW weer vaarwel gezegd en is terug naar Mazda. Meer luxe en qua onderhoud voordeliger terwijl de aanschafprijs toch aantrekkelijker was.

[cricque]

API rate limits instellen et voila problem solved

[Justin2000]

Zo is het, netjes ff een 360 min interval op refresh in skoda integratie ingesteld en geen gedoe. Ik snap de VAG groep wel wat betreft de aantallen requests per 24u. Ja je 12v accu systeem zou daar tegen moeten kunnen, maar zo ver is het blijkbaar nog niet.

[Polderviking]

Ze ruiken gewoon meer geld in een gesloten systeem.

Die API ontlasten was ook gelukt met een domme ratelimiter.

[Reactie gewijzigd door Polderviking op 29 mei 2026 09:12]

[HenkEisDS]

benieuwd hoe makkelijk het gaat zijn om als consument of als app bouwer een api-key te krijgen. Ik ga het proberen in elk geval.

[dooiedodo]

Ah.. mooi dat dit wat meer media aandacht gaat krijgen. Door dit gerommel in de cloud krijg ik weer de neiging om toch alternatief te zoeken. Smartcar was de eerste, maar daar is ook api wijzigingen oorzaak van niet werkend boarding voor HA.

Als back up ga ik de BT ODB route maar eens uitproberen, heb eigenlijk alleen de batterij % nodig en manier om te weten of de auto voor de deur staat. Ik hoef die meukige cloud api's niet perse, dus weer een klein hobby projectje voor het weekend

[JanHenk]

Het nadeel van een Bluetooth OBD dongel is dat ie - in geval van Volkswagen (en ook mijn vorige Skoda) - het alarm triggert als je iets wil uitlezen. Dat is dus ook geen reële optie in dit geval.

[rammes]

Ik kreeg 13 mei deze mail :

Op 20 mei voert Volkswagen Groep een technische aanpassing door. Daardoor verandert er ook iets voor gebruikers van auto' s van Volkswagen, SEAT, Škoda en Audi. Wij zorgen ervoor dat uw auto automatisch wordt overgezet naar een nieuwe oplossing, zodat u kunt blijven Slim laden. Dit doen wij tussen 12 en 18 mei.

Wat verandert er voor u?

Na de overstap zijn een aantal functies niet meer beschikbaar voor uw auto.

Als u zonnepanelen heeft gekoppeld, heeft deze instelling daarna geen effect meer op het laden van uw auto. Uw auto wordt wel zoveel mogelijk overdag geladen, tussen 12:00 en 16:00 uur. Zo is de kans groot dat u alsnog laadt met uw eigen zonnestroom.

Ook het instellen van een direct laaddoel - waarbij uw auto eerst automatisch oplaadt tot een bepaald percentage - werkt daarna niet meer. 

Als er geen vertrektijd is ingesteld op een dag en de auto staat wel aan de oplader, dan wordt er gekeken naar de dagen die wel ingevuld zijn. Stel dat er dan een dag met een vertrektijd om negen uur in de ochtend is en een andere dag met zeven uur in de ochtend, dan wordt uitgegaan van de vroegste vertrektijd.

Heeft u een vast of variabel stroomcontract bij Vattenfall of TijdPrijs? De beloning blijft gelijk: 2,5 cent per slim geladen kWh. Maar de getoonde besparing kan afwijken omdat er geen link meer is met de actuele tarieven.

Wij kijken naar de mogelijkheden om deze functies in de toekomst weer beschikbaar te maken.

Wat blijft hetzelfde

Slim laden blijft gewoon beschikbaar via de Vattenfall Energie-app. U kunt nog steeds uw laadgegevens bekijken en uw gewenste laadniveau en vertrektijden instellen.

[The-Source]

Een fabrikant is niet verplicht om het te bouwen. Maar als je het éénmaal al gebouwd hebt en daar wellicht ook met eigen app gebruik van maakt. Waarom dan dit soort acties, wie op z'n corporate stoel denk dat dit gebruiksvriendelijk is.
Meeste auto fabrikanten zijn niet echt goede app bouwers. Zo ook Renault die op sommige toestellen (bijvoorbeeld OnePlus 12) issues met labels dat teksten niet goed worden geparsed. Maar met intergratie home assistant was het gewoon 5x sneller om climate-controll aan te zetten op afstand dan ook maar eerst wachten tot de Renault app geladen was.
En dat is dus ook 1 van de redenen dat ik auto liever in HA gekoppeld heb dan via fabrikant app

[SMGGM]

Ter verdediging van de fabrikant: vaak zijn zulke toegangen geen feature van de fabrikant maar eerder hobby programmeurs die de API's gaan reverse engineeren. Dan is het de vraag of de fabrikant dit zal gedoogd toelaten of acties gaat ondernemen dit te verhinderen.

Ik heb zelf geen VW, maar wel een Kia en zie daar iets soortgelijk. Zo heeft Kia een jaar geleden een verplichte captcha toegevoegd die het onboarding process een stuk complexer heeft gemaakt. Ook weer ter hun verdediging kan dit een rechtmatige reden zijn ter verdediging van bots, maar er zijn andere manieren om dit te verhinderen.

Een andere reden om dit als fabrikant actief te gaan verhinderen is de druk dit legt op de batterij van de wagen. Bij Kia alvast is een "hard refresh" een belasting op de 12V batterij. Doe je dit te vaak, dan trek je die batterij plat met een serieus ongemak als gevolg. De integratie die ik gebruik in HA geeft hier ook een waarschuwing op en stelt zelf voor dit niet te vaak te doen.

in de ideale wereld natuurlijk doet een fabrikant hier gewoon niet moeilijk over en hebben ze (bij voorkeur) lokale toegang. Omdat een wagen iets in beweging is, is wifi met verbinding op je lokaal netwerk al wat moeilijker, maar er zijn zat veel fabrikanten (ik kijk naar jou Vaillant) die dit gewoon niet mogelijk maken. Bij Vaillant gaat mijn HA (die letterlijk op 2m van de Vaillant gateway staat) telkens de refresh halen vanaf het internet met de nodige belasting (en kost) bij de fabrikant.

[Polderviking]

Wordt ook hoog tijd dat regelgeving veranderd, het is best raar dat bedrijven dat mogen bepalen.

API's die gaan over functionaliteit van iets wat je gekocht hebt en/of jou data uitwisselen moeten gewoon goed gedocumenteerd en open en toegankelijk zijn voor de eindgebruiker.
Mocht die daar software van een derde partij willen gebruiken of er misschien zelfs zelf tegenaan programmeren moet dat gewoon een optie zijn.

En willen bedrijven hun infrastructuur daar niet voor openstellen, dan moeten ze maar zorgen dat hun, in dit geval auto, lokaal aan te spreken is.
Dan heb je ook helemaal geen kans dat er api's overdonderd raken waar andere klanten last van kunnen krijgen.

Dan kunnen ze natuurlijk mensen niet echt meer uitknijpen op dingen als verwarmde stoelen enzo maar dat mag niet het probleem van de consument zijn.

[Reactie gewijzigd door Polderviking op 29 mei 2026 09:32]

[SMGGM]

Ik vind dit een zeer moeilijke discussie.

De EU is best al veel sectoren aan het verplichten om dingen open te zetten. Kijk naar heel de bankensector die verplicht is geworden (PSD2) om toegang te geven tot externe partijen. De volgende stap is FIDA, waarbij de scope een heel stuk ruimer wordt met als doel "open finance". Hier komt massa's veel kritiek op want PSD2 alleen heeft alle financiële instellingen samen miljarden gekost zonder enige terugverdienmodel. Het resultaat is dan dat men het op andere manieren moet terugverdienen. Bij FIDA zou het bedrijf wel een realistisch kost mogen doorrekenen aan de derde partij die de data wil ophalen, om tegemoet te komen op het grootste punt van kritiek op PSD2.

Het doel van die regelgeving is innovatie forceren in sectoren (banken, verzekeringen, brokers...) die van nature zeer conservatief zijn en vaak monopolistisch gedrag vertonen. Ook kost de interactie met banken bedrijven natuurlijk veel geld (niemand vindt het prettig betalingen die al goedgekeurd zijn in interne systemen nog eens goed te keuren bij de bank).

Kijken we naar consumenten elektronica, dan zie je wel dat hier wat meer concurrentie is. Vele sectoren bieden het simpelweg als feature aan en is er concurrentiële druk om hetzelfde te doen. Een slimme lampen fabrikant die nu nog een gesloten systeem hanteert zal niet lang leven, maar helaas is die druk nog niet zo groot bij pakweg fabrikanten van centrale verwarming.

Als de EU daar ook regels op gaat leggen, dan ga je zeer snel opnieuw de kritiek krijgen dat de EU zich teveel moeit en alleen maar regels oplegt die de fabrikanten zullen doorrekenen. Als de markt er dus van nature naartoe gaat (ookal is het in kleine stappen), dan valt op dat de EU er zich minder mee gaat moeien om die kritiek niet te krijgen.

[Reactie gewijzigd door SMGGM op 29 mei 2026 09:55]

[vlijmen]

Volledig akkoord, bij de VW-app is dat niet anders. Hij werkt niet soepel en je kunt er eigenlijk niks meer mee dan ontgrendelen en de airco aanzetten. In HA had ik niet alleen meer opties, maar vooral het feit dat ik het kon automatiseren.

Zowel het laden ging wanneer ik het wilde op basis van batterij percentage, zon-opwek etc. Maar ook de airco ging vanzelf aan afhankelijk van tijdstip en locatie. De VW-app kan dit niet dus is voor mij geen oplossing.

[CAPSLOCK2000]

Een fabrikant is niet verplicht om het te bouwen.

Misschien moeten we dat maar eens veranderen. Ik vind het eigenlijk wel goed klinken om te zeggen dat je het recht hebt om te weten hoe je apparaat werkt, dat je alle sensoren kan uitlezen, zien wat voor software er draait en hoe die werkt, en dat je dat zelf kan doen zonder hulp van een bedrijf (dat ooit zal ophouden te bestaan).

Op een bepaalde manier lijkt het me zelfs noodzakelijk als we auto's lang op de weg willen houden in plaats van dat ze na een paar jaar als e-waste eindigen alleen omdat de software niet meer wordt bijgewerkt.

Niet alleen voor auto's maar eigenlijk voor alle moderne apparatuur. Telefoons, tablets en laptops zijn op het punt dat de CPU en SSD meer dan 10 jaar mee gaan, en met de huidige prijzen RAM ook. De batterij en het scherm zijn de zwakke punten maar die zijn steeds makkelijker te vervangen dankzij right-to-repair wetten. Nu de software nog.

[r2504]

Dit was bij BMW ook het geval een goed halfjaar geleden... uiteindelijk is er een nieuwe API beschikbaar gekomen met een verbeterde authenticatie.

[JP1980]

Nou ja 'verbeterd', de CarData integratie heeft vertraging op de lijn wat betreft de SOC indicator, en je kunt klimatiseren niet starten wat vroeger wel kom. Had net een mooie integratie klaar op m'n wallpanel in de hal om klimatiseren te starten blokkeren ze de boel.

[SadisticPanda]

Het is verschrikkelijk, tov van de bimmerconnected van vroeger.

Nieuwe Api is gelimiteerd, Read-only en dan nog zo onnauwkeurig als iets in vele gevallen dus moet er met veel haken en ogen proberen het beetje te laten kloppen terwijl alles mooi beschikbaar is in de bmw app maar ja, daar mag je niet meer aan.

Ps. Ik ben de maintainer van de nieuwe Cardata, dus ik weet wat een gedoe het is, maar het is helaas roeien met de riemen die we krijgen van BMW.

[JP1980]

Alle begrip voor en bedankt voor je inspanningen. Werkt prima binnen uiteraard wat BMW aanbied dus meer kan je ook niet verwachten.

Heb mijn eigen SOC indicator gemaakt die iets accurater is die gebruikt de cardata SOC input en daarbij tel ik de geladen energie van de laadpaal bij op. Zo heb ik in HA een redelijk accuraat beeld van de SOC wat essentieel is om een beetje slim te laden (sturen op prijzen en thuisaccu). Maar iets wat vroeger werkte moeten we nu weer tegenaan scripten.

[oscar oscar]

Die kan wel nog steeds niet wat de vorige kon, tenminste niet op mijn auto, en meer beperkingen op hoe vaak je de API mag oproepen waardoor mijn automations niet meer werken en ik een alternatief heb moeten zoeken.

[Elidibus]

Grappig genoeg werkt CarData wel met onze i3, terwijl het voor de change niet werkte.

[jongetje]

Als je het ze vraagt zullen ze vast antwoorden dat het een product eigenschap is...

[TheDudez]

Daarom altijd voor een product gaan met lokale api al is dat wel lastig bij een auto. Bij alle auto's is volgens mij cloud. Maar het zou niet nodig moeten zijn cloud.

Fijn als het werkt via de cloud en home asistant maar je moet er altijd vanuit gaan dat ze het afsluiten.

[Reactie gewijzigd door TheDudez op 29 mei 2026 08:38]

[vlijmen]

Ik zie niet direct voor me hoe dit zou kunnen werken zonder over internet te gaan. Je auto staat natuurlijk niet altijd stil bij huis zodat je lokaal op de wifi kan of er een kabel in kan steken. Wellicht dat er iets bestaat om op de OBD2-poort aan te sluiten en dan via internet naar je lokale netwerk kan gaan zonder "cloud oplossing" er tussen. Maar dat lijkt me wel een ingewikkelde work around om toe te passen.

[Horla]

klopt, in mijn Nissan Leaf heb ik sinds kort ovms zitten omdat Nissan hun servers heeft uitgezet. Was kwestie van een klepje open doen, in OBD-poort een kabel steken en verbinden met een bakje (en het bakje configureren). Als je het echt netjes wil wegwerken, dan wordt het wel wat moeilijker

[Mathijs Kok]

Was kwestie van een klepje open doen, in OBD-poort een kabel steken en verbinden met een bakje

En 250 euro betalen en een gsm abbo hebben....

[Horla]

Voor niets gaat de zon op . Pas op: ik heb ook lang getwijfeld maar ik hoop die auto toch nog een vijftal jaar te gebruiken. GSM abbo is enkel als je ook op de baan info wil hebben. Dan zit ik doorgaans in de auto en weet ik hoeveel kilometers hij nog kan. Voor die paar dagen in het jaar dat ik van op afstand airco/verwarming van op afstand wil aanzetten en niet thuis ben, heb ik dat niet nodig.

Het belangrijkste voor mij (en waarschijnlijk de meesten) is het starten van laden als de zonnepanelen opbrengen en weten op welk percentage de auto zit. Dat kan perfect via de wifi versie (in mijn geval i.c.m. een shelly en Home Assistant).

[denneappel]

Exact! Mijn Volkswagen E-UP rijdt hier ook mee rond. Werkt perfect. Onderweg via de Hologram simkaart en thuis op de Wifi realtime updates. OVMS heeft een hele goede api en ook MQTT ondersteuning.

[TheDudez]

Als die voor de deur staat via de Wifi met mqtt. Dan kan je in ieder geval laten opladen. Op afstand uitlezen is inderdaad lastig.

[Rannasha]

Ik zie niet direct voor me hoe dit zou kunnen werken zonder over internet te gaan. Je auto staat natuurlijk niet altijd stil bij huis zodat je lokaal op de wifi kan of er een kabel in kan steken.

De meest interessante automatiseringsfuncties gebruik je vooral thuis. Denk aan dingen als opladen automatisch regelen aan de hand van dynamische energietarieven. Of het activeren van de climatisering aan de hand van een actie in je ochtendritueel.

Eventuele data-logging kan altijd gebufferd worden tot de auto weer bij het thuisnetwerk is.

[vlijmen]

Kwa laden is het thuis inderdaad, maar daar staat de auto in de schaduw. Klimatiseren doe (deed) ik dus ook op diverse werk locaties automatisch afhankelijk van waar en hoe laat ik daar vertrek.

Het laden zie ik minder als een probleem, hoewel een minimum percentage fijn is (was) kan ik onze laadpaal en slimme kabel ook rechtstreeks op de P1 meter sturen dus heb ik de auto data daar niet direct voor nodig.

[CH4OS]

Prima dat ze het afsluiten, maar kondig dat dan eerst netjes aan bij de gebruikers. Dat laatste is niet gebeurd lijkt het.

[Reactie gewijzigd door CH4OS op 29 mei 2026 08:44]

[mvn23]

De redenatie zal zijn dat het geen ondersteund gebruiksscenario is, dus hoeft er geen rekening mee gehouden te worden bij updates.

Mazda heeft een tijdje terug precies hetzelfde gedaan en is zelfs actief achter de developers van de integratie aan gegaan.

[RVervuurt]

Onze Buzz is gekoppeld aan de WiFi als ie thuis is, dus in principe zou je 'm daar gewoon lokaal moeten kunnen aanspreken.

[Audione0]

As designed or a feature.. :P

Ik weet niet of het er indirect mee te maken heeft, maar de Cupra (VAG groep auto) en de Cupra app op Homey vinden elkaar ook niet meer. (al werkt dit al een tijdje niet meer)

[Reactie gewijzigd door Audione0 op 29 mei 2026 09:28]

[vlijmen]

De work around werkt inmiddels ook al niet meer sinds enkele uren nadat deze gedaan was. Het lijkt al eerder aangekondigd te zijn, hoewel daar weinig details in staan:
https://drivesomethinggreater.com/newsroom/short-news/2026-4-02-Transition

Ik vind dit persoonlijk een zeer slechte zaak en hopelijk gaan ze onder druk net als Haier dit terugdraaien. Mijn connected car is voor mij nu niet meer connected want hun App is traag en veel te beperkt.

[Sandor_Clegane]

De fout is dat je denkt dat het 'jouw' connected car is. Het is hun connected car en jij bent de revenuestream die op het stoeltje zit.

[vlijmen]

Klopt dat dit de revenue stream is, daarom is dit ook een "betaalde" service. Maar het is toch echt mijn auto. Hoewel de basis connectie gratis is gedurende 10 jaar als ik mij niet vergis. Onder de EU Data Act is het echter wel mijn data die ze vrij toegankelijk zouden moeten maken.

Ze proberen dit nu via een download te doen waar je zeer beperkte data kan ophalen. Maar dit genereren duurt veel te lang en is natuurlijk helemaal niet hoe de Data Act bedoeld is voor dit soort data.

[Zwarte_os]

Exact, smoel houden en doorbetalen aub.
Zonder gekheid, ik heb bij een automaker in Duitsland mogen rondlopen en ik weet niet wat het is maar de managers hebben zo'n rare blik op IT en cloud.

Klanten bedienen is ook niet belangrijk in dat geheel, misschien zelfs het vervelendste proces binnen auto's maken. Binnen de design afdeling had niemand kennis van UX of onderzoek doen, er waren alleen maar stylisten (wel hele goede). Die gevestigde automerken hebben ontzettend last van hun verticalen, die moeten hun revolutie echt nog meemaken.

[Codeaction]

Typisch, Hyundai / Kia hebben recent het zelfde gedaan met de invoering van een nieuwe platform. Daarmee werkt Trionity overigens 20 dagen nu niet.

[Reactie gewijzigd door Codeaction op 29 mei 2026 08:37]

[walteij]

Ik heb toevallig gisteravond mijn Ioniq 5 in HA gezet, werkt als een zonnetje. 76 sensoren/entities die ik probleemloos kan uitlezen.

[Codeaction]

Klopt . HA heeft een omweg gevonden. Helaas andere integraties nog niet (homey, tibber).