feat: add DayTripInfoEntity for per-trip sensor data#1698
Conversation
Wires the library's existing `update_day_trip_info()` call into the
coordinator and surfaces the result as a new sensor per vehicle.
Coordinator (cached-state branch of `_async_update_data`):
- Compute `today_str` once per cycle from `dt_util.now()`.
- For each vehicle, call `vehicle_manager.update_day_trip_info` via
`async_add_executor_job` (library call is synchronous).
- Wrap in `try/except Exception` with a DEBUG log so a `NoDataFound`,
an unsupported region/firmware, or a transient backend error becomes
a debug line — never `UpdateFailed`.
Sensor (`DayTripInfoEntity`):
- Registered unconditionally in `async_setup_entry` (one per vehicle),
so the entity exists at startup even when `vehicle.day_trip_info` is
still `None`.
- `state` returns `len(trip_list)` when populated, else `0` — never
`unavailable`.
- `state_attributes` exposes:
- `date` — ISO `YYYY-MM-DD`
- `summary` — day totals (drive_time, idle_time, distance, avg/max speed)
- `trip_list` — per-trip dicts with ISO 8601 `start_time` / `end_time`,
drive/idle time, distance, avg/max speed
- Helpers convert the library's packed `YYYYMMDD` / `HHMMSS` strings to
naive ISO 8601 local timestamps — friendlier in HA cards than the raw
strings.
- Translation entry added to `strings.json` and `translations/en.json`.
Tested on a real Hyundai Kona Electric (EU):
- Integration reloads cleanly; no `UpdateFailed` in HA logs.
- Sensor registers; state goes 0 -> positive integer as trips happen.
- `start_time` / `end_time` render correctly in HA cards.
- Empty-state path (car parked, `NoDataFound`) -> DEBUG line, sensor
stays at `0`; populated path -> full trip list + day summary.
Tags the fork install as 3.3.0-trip so HACS picks it up as newer than upstream's 3.3.0. The codebase is upstream 3.3.0 plus the per-trip sensor changes from PR Hyundai-Kia-Connect#1698 — no other deltas. Tag has no -trip.N iteration suffix; future revisions can bump to -trip.1, -trip.2, etc. if needed before the PR merges.
| # Per-trip data. The library implements update_day_trip_info() but the | ||
| # upstream coordinator never calls it. Trip data must not fail the | ||
| # coordinator update — wrap in try/except so a NoDataFound, an | ||
| # unsupported region/firmware, or a transient backend error becomes a |
There was a problem hiding this comment.
Based on this I wonder if we should have setting to turn this on and off? As well do we want to be polling this every time using API calls?
| VehicleEntity(coordinator, coordinator.vehicle_manager.vehicles[vehicle_id]) | ||
| ) | ||
| # day_trip_info starts None and is populated by the coordinator's | ||
| # first update — register unconditionally so the entity exists even |
There was a problem hiding this comment.
Doesn't this mean it will show up for people with cars that don't support it?
|
I have a Gas Kona 2024, and this endpoint work event if not EV (tested with postman) |
It should as trip details are implemented here: https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/blob/master/hyundai_kia_connect_api/KiaUvoApiCA.py It normalizes to the data model for the regions that implement it. Are you able to install this patch and test it out? |
|
No, its already available a long time at HA, see Screens: |
4 participants
Summary
Adds a new
DayTripInfoEntitysensor exposing per-trip data for today, plus the coordinator wiring to populate it. The library (hyundai_kia_connect_api) already implementsupdate_day_trip_info(), but the upstream coordinator never calls it, so the data is unreachable from HA. This PR closes that gap.What it adds
A single new sensor per vehicle (translation key
day_trip_info, e.g.sensor.<car>_day_trip_info):0if no trips yet or endpoint unsupported, neverunavailable).date— ISOYYYY-MM-DDfor the day represented.summary— day totals:drive_time,idle_time,distance,avg_speed,max_speed(ornullbefore the first successful fetch).trip_list— per-trip dicts withstart_time/end_time(naive ISO 8601 local),drive_time,idle_time,distance,avg_speed,max_speed.How it works
coordinator.py— in the cached-state branch of_async_update_data(), after the existingupdate_all_vehicles_with_cached_state()call:today_str = dt_util.now().strftime("%Y%m%d")once.self.vehicle_manager.vehiclesand callvehicle_manager.update_day_trip_info(vehicle_id, today_str)for each.async_add_executor_job.try/except Exceptionwith a DEBUG log so aNoDataFound, an unsupported region/firmware, or any transient backend error becomes a debug line, not anUpdateFailed. Integration availability is preserved on vehicles/regions where the endpoint isn't supported.sensor.py— addsDayTripInfoEntity(SensorEntity, HyundaiKiaConnectEntity):async_setup_entry(one per vehicle). The entity is created at startup even whenvehicle.day_trip_infois stillNone— otherwise users wouldn't see the sensor until the first successful fetch.statereturnslen(trip_list)when populated, else0.state_attributesreturns{}whenday_trip_infoisNone; otherwise the structure above.YYYY-MM-DDTHH:MM:SS) — friendlier than the rawYYYYMMDD/HHMMSSstrings the library returns.mdi:calendar.strings.json/translations/en.json— adds theday_trip_infotranslation entry.Testing
Verified on a real Hyundai Kona Electric (EU):
UpdateFailedin HA logs.sensor.<car>_day_trip_inforegistered in the HA entity registry; state goes from0→ positive integer as trips happen during the day.start_time/end_timerender correctly in HA cards (the ISO-8601 conversion was necessary — the raw library strings were unfriendly).NoDataFoundfrom the endpoint → DEBUG line, sensor stays at0) and the populated path (after drives, attributes carry the full trip list and day summary).No new dependencies; all changes use existing library APIs.