My Hyundai Inster is connected again too.
Thanks for the fix.
Great work. Thanks!
I have had a Kia EV6 for a month now, and as of today (living in the Netherlands) I’m also getting the message::
[Error: koppelen mislukt: CCI token exchange failed: HTTP 400 - [“code”:9035,“message”:“Unusual activity has been detected so youve been logged out. Please restart te app.”,“errors”:[]}. This may indicate a Hyundai API change.]
I’m somewhat reassured to read here that other users are experiencing this too. But I’m a bit concerned that I’m reading it’s working again for many people, but not yet for me. I live in The Netherlands
Does anyone have a tip for me??
did you install the test version? If you do not want that you need to wait until Athom approves the version for stable users.
I am driving in a kia ev6 since a month. Now I’m having this issue. Ineens
Thanks Gruijter for your response. I just tried the experimental version, but unfortunately, it gives me exactly the same message.
Super! Het werkt op de test app.
@Gruijter Surprisingly, the experimental version is working now! Thanks for your help.
Hi @Gruijter,
I noticed that my battery alarm fired on the dashboard widget. However, it notes it as the 12v battery alarm. (I checked the 12v, it was 70% with the alarm set way lower). Normal battery alarm was set to 40%.
This report is from 5 hours later but maybe helpful: 8927e19d-9bcf-4361-9295-2277c7c1f348
Is it possible to make the dashboard widget clickable, such that the car device page opens? Like when clicking a lamp on your dashboard?
Thank you for adding the Kia USA verification flow. I tested version 2.6.6.
Pairing successfully reaches the verification screen and correctly displays my email and SMS options. However, selecting either option and pressing “Send code” immediately returns:
“Pairing failed: Invalid OTP key”
The failure occurs before a verification code is sent or entered.
Homey diagnostic report code:
b09a93de-acd9-4f62-aa61-3c96e2fcb2e2
no. that only seems to work for built-in homey widgets
Thanks both battery alarms work fine on the widget now!
Good news: I tested version 2.6.7, and the original USA OTP problem is fixed.
I selected email, Kia successfully sent the verification code, and Homey accepted it. Pairing then advanced to “New Devices Found,” but instead of displaying the vehicle it showed:
“Cannot read properties of undefined (reading ‘split’)”
I submitted a new diagnostic report immediately afterward:
“f20e03f2-432f-4b17-8de3-20557c1122b3”
I reviewed the current 2.6.7 path again. The OTP verification handler appears to have completed final authentication, retrieved at least one vehicle, and passed the cached-state/odometer check before opening “list_devices”.
In “buildDeviceSettings()”, the current code contains:
regDate: vehicleConfig.regDate.split(’ ')[0],
Kia USA’s “getVehicles()” does not create or normalize “regDate”; it is present only if Kia’s raw “vehicleSummary” entry provides it. The upstream Python Kia USA implementation does not read a registration-date field from that response.
This is therefore the strongest candidate for the error. The diagnostic report’s stack trace and logged “vehicleConfig” should confirm whether “regDate” is absent.
A minimal defensive correction would be something like:
regDate: String(
vehicleConfig.regDate || vehicleConfig.enrollmentDate || ‘’
).split(’ ')[0],
I also noticed a likely second USA mapping issue immediately afterward. “getVehicles()” maps the Kia “nickName” field to “vehicleConfig.name”, but “list_devices” uses:
name: vehicleConfig.nickname,
For Kia USA, that may also be undefined. A safer device name would be:
name: vehicleConfig.nickname || vehicleConfig.name || vehicleConfig.vin || vehicleConfig.id,
I have not attempted another pairing or tested SMS. Email OTP delivery and verification already succeeded, so I am waiting for your guidance or another test build.
New version 2.6.8 was just released to the app store:
- Fixed pairing for USA and other regions (please test @wevon )
- Improved privacy of diagnostic reports
- Minor API fixes for EU
- Prepare GSPA-port
New test version 2.6.9 is ready:
- Fixed USA session expiry and commands
- Fixed USA distance units
- Improved session recovery for Canada
@wevon please test 
Hi Robin,
Good news on version 2.6.9. After repairing the connection, I tested Climate control on and off twice and physically verified the vehicle each time.
The first on and off commands worked. I then left the connection idle for approximately 12 minutes and tested again. Climate control on started the engine, and Climate control off stopped it. I verified the engine and instrument cluster physically without taking my phone or key to the vehicle, and I did not use Kia Access or manual Refresh during the test.
The distance correction is also working. Homey now displays the range correctly in miles, currently 290 mi rather than km. The odometer, which was not displayed before, now also appears correctly at 2,165 mi.
This is a clear improvement over version 2.6.8.
Hi Robin,
I found one remaining timing issue in version 2.6.9.
The vehicle was physically unlocked, and Homey correctly showed Unlocked after its 5:40 PM automatic update. At approximately 5:49 PM, I pressed Lock in Homey.
Homey first logged “Locked by Werner Vondrak via mobile,” but a few seconds later logged “Unlocked by Kia” and changed the control back to Unlocked. Kia then sent an official confirmation email stating that the remote Lock request succeeded. At 6:03 PM, Homey’s next automatic update changed the vehicle to Locked.
For context, I traced the sequence through the current code:
• “runQueue()” waits five seconds after Lock and then enqueues “doPoll({ forceOnce: true })”.
• USA “forceRefreshVehicleState()” sends “/rems/rvs” and then immediately reads “/cmm/gvi”.
• The returned status is applied without checking whether its “syncDate” advanced beyond the pre-command status.
That appears consistent with what I observed: the Lock command succeeded, but the immediate follow-up read returned the previous Unlocked status. The later scheduled poll retrieved the updated Locked status.
I initially considered including a retry example, but “forceRefreshVehicleState()” is shared by several functions, so I did not want to suggest a change without understanding all the design considerations. I hope the test sequence and code path are useful in determining the best approach.
New version 2.7.0 is released:
- Improved command status checking
- Improved cached polling strategy
- Fixed status reverting after commands
@wevon u know what to do
Hi Robin,
Version 2.7.0 has now reached my Homey. Thank you for addressing the command-status and stale cached-status behavior we reported. I have not yet repeated the lock-status test under 2.7.0, but I will report back after I have had an opportunity to test it.
I also noticed something in the current source regarding seat heating and ventilation. The USA connector appears to support separate settings for the driver, front passenger, rear-left, and rear-right seats.
KiaUvoApiUSA._seatSettings() appears to support:
0 = off
3, 4, 5 = low, medium, and maximum ventilation
6, 7, 8 = low, medium, and maximum heating
At the Homey layer, SEAT_STATUS currently exposes only OFF and MEDIUM_HEAT. The regular A/C action sends all seats off, while the defrost action sends all four seats at medium heat.
Would you consider exposing the existing seat values through a Flow action card? For example, a card allowing the user to select the seat and the desired heating or ventilation level would let us include driver-seat cooling or heating in a remote-start Flow while leaving the existing climate-control actions unchanged.
My vehicle is a 2026 Kia Sorento PHEV in the USA. I would be happy to test the feature if you decide to expose it.
@Gruijter Is the KIA F***** with us again? Unit is offline and repair don’t work, (Faild to login) 
