What causes the car to send an update?

[busywait]

I'm trying to understand how fresh the data provided by this integration can be when I configure it with Forced Refresh Interval = 9999, and what extra data I get when I use automation to call the integration "force refresh" service call.

I've noticed that sometimes my car updates its location even though the integration's "Last Updated At" sensor is unchanged. Does anyone know what needs to be happening in the car to send it's location (I'm in the UK with EU software in the car head unit).

I think that the locations get sent when I turn the car off. I've got an automation that calls the Force Refresh service when the location changes so that I keep the full set of car data (including battery levels) updated each time the car gets used.

I'd prefer it if the location was updated when the car gets turned on, then I could set up an automation to track each journey - but I guess it just doesn't 🤷‍♀️

Also, I have charging alerts setup (charge completed and 10 minutes before charge completed) in the car/Kia app. Do these cause new data to be sent from the car to the cloud servers? It seems a bit unpredictable whether this integration catches changes in battery level (maybe something to do with the blackout "No Force Refresh" settings?), but often it looks like the current battery level is sent at 10%, 20%, 30%, etc

I don't have any automated refresh triggered by the battery level changing, but I do trigger a full refresh when my home chargepoint is unplugged from the car.

With those two automations, I get a reasonably up-to-date view of the car's state without having to do any scheduled polling that would keep the car electronics awake and draw power from the little 12V battery.

[liamhildebrand]

I have a new car with kia connect, and I have the same issue. The data is far from live. The problem is that they have limit the data request by 200 in our country, to avoid battery problems with the car. Each data request take some enegry from the cars battery. So thats why they have limits on that.

[bobthebuilder4711]

The location is updated every time the car is turned off. I'm guessing this is so you can find it again via the app without having to poll the car.

Our last car was a Kia Cee'd Hybrid and that used to update every 30 minutes or so while charging. Or so I thought. Now reading about the updates getting sent at 10%, 20%, 30% and so on and that makes total sense. The small battery of the hybrid likely produces more frequent updates compared to a full blown EV with a much larger battery while charging at the same speed.

And yes, I can confirm with our new Kia Niro EV that the updates do in fact come in once the battery reaches a full 40%, 50%, etc. Haven't drained it much lower, but I'm guessing also at 10%, 20% etc.

Now I wonder what other sensors I should change to test what forces an update.

You don't really need to know the current SoC if the car has only be sitting around. So that's a plus. But you need to know how much the battery has been drained from the last trip. So a full update after turning off the car would indeed be nice.

That way you would be able to see the last SoC before starting to charge. From that you could estimate the SoC based on the kWh counted by the charger. (I'm using a 1-phase/3-phase charging brick with up to 11kW, but it doesn't ask the car for the SoC, so that has to come in via Kia Connect.) And that way you would have an up-to-date value for the SoC even if it didn't come from the car directly.

Only problem is if the limit is really at 200 minutes and you take a trip that is shorter than 3 hours and can't force an update.

[busywait]

"if the limit is really at 200 minutes"
The limit is 200 (or whatever number) of requests to the Web Api each day - plenty for my automations.

I do an update from the Web api cache every 15 minutes ("scan interval" in the integration config).

To avoid drain on the car 12V battery I minimise the number of forced updates from the integration when the car is off: I've got one automation that does a forced update every 12 minutes while the API shows engine is on, one forced update is triggered when my smart charger detects it has been connected, and I don't do any scheduled forced updates.

[edit: my automations also do a full forced update when the location changes, because location updates don't usually include the battery status]

I've found that fairly reliable except that

• the first forced update after the engine/car is turned off often returns a stale location
• a manually triggered event is usually needed to detect the engine/car is on, for example manually triggering a forced update or using the Kia Connect app status refresh

[bobthebuilder4711]

Oh, okay. Yes, 200 requests per day are plenty.

I'm fine with only getting a fresh update once the car is shut off. This is mainly for display in our kitchen/living room and of course for solar excess charging, so if the car is turned on and driving around, we don't need those two anyway.

Would you be so kind to show us the yaml of your automation that is triggered by the location update? Is it just this?:

triggers:
  - trigger: state
    entity_id:
      - device_tracker.niro_location

[busywait]

I was learning about HA automations and the Kia integration when I wrote the location change automation so I think it's too complicated, is also triggered by engine ON and OFF transitions, and relies on at least one timer, a YAML template sensor "car_gps", and a script that rate limits forced updates. It does work, but isn't a helpful example. The comment at the top might be helpful.

By the time I got the template binary_sensor.car_gps to work to indicate the car was moving I realised that the simple state change that you've used was probably sufficient for anything practical, but I've never got around to simplifying.

`alias: Home EV Start and End Journey Triggers
description: >-
When the car is turned off then a location update is sent. The updates come
without any status information about the car. So, assume that changing
locations, however small, indicate the car is recently active and a forced update will
not cause excessive power draw. April 2024: stale location data is sent in the
first forced update after the engine is turned off, and calling another forced
update gets the correct location.
mode: single
triggers:
...

• entity_id:
  • binary_sensor.car_gps
    from: "off"
    to: "on"
    id: GPSOn
    enabled: true
    trigger: state
    conditions:
• condition: state
  entity_id: timer.home_ev_usage_countdown
  state: idle
  enabled: true
  actions:
• choose:
  • conditions:
    • condition: trigger
      id:
      • GPSOn
        ...
        `

[bobthebuilder4711]

I've been monitoring the integration without adding anything. I just arrived with my Niro at 21:49. The location only updated around 10 minutes later at 21:57 and that's when all of the sensors where updated.

So either your automation has since been added to the integration or the car is sending more than the location now.

For me that means I'm going to try writing my own script for solar excess charging since I now know all the parameters. I'm already charging a stationary battery with solar excess with a self written script, so adding the car shouldn't be that hard to accomplish.

---

Last night I also noticed that all sensors for both cars switched to "unavailable" at around 22:00 and when I tried using the android app, it told me that I had hit the maximum amount of requests per day.

Seems like an update interval of 15 minutes and two cars was enough to hit the 200 early. Every 15 minutes is almost 100 in 24 hours. And with two cars it's almost 200. So looking at the app a few times and stopping charging for both cars seems to have been too much.

Will see if that changes once the Cee'd is going back to the leasing partner. For now I've set the interval to 20 minutes and that should give us enough room to get through the day.

[busywait]