Expose eBike battery attributes (eBikeBatteryRemaining, eBikeBatteryUsage, eBikeMaxAssistModes) on last_activity sensor

[hoffeck]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

I ride an e-bike (Giant Stance E+1) tracked via a paired Edge/watch. Garmin Connect's web UI shows a dedicated "E-Bike-Leistung" (E-Bike Performance) tab per activity with battery level, battery usage, and assist mode — but none of this is exposed on sensor.garmin_connect_last_activity in Home Assistant.

Describe the solution you'd like

Device: Garmin Edge 1050, paired with a Giant Stance E+1 via ANT+ LEV (the standard e-bike profile).
I inspected the raw response from https://connect.garmin.com/gc-api/activity-service/activity/{activityId} (the summary endpoint, via browser devtools) for one of my e-bike activities, and it already contains:

json"eBikeMaxAssistModes": 7,
"eBikeBatteryUsage": 19,
"eBikeBatteryRemaining": 42,
"eBikeAssistModeInfoDTOList": null

Looking at custom_components/garmin_connect/sensor.py, the lastActivity sensor's attributes_fn already passes through all keys from data["lastActivity"] generically (excluding polyline/hasPolyline):

pythonattributes_fn=lambda data: {
k: v
for k, v in (data.get("lastActivity") or {}).items()
if k not in ("polyline", "hasPolyline")
},

So the gap isn't in sensor.py — these fields simply aren't present in the dict returned by ha_garmin's GarminClient.fetch_activity_data() yet. Since that method already extracts a large, specific set of fields from the same summary endpoint (distance, averageHR, avgPower, hrTimeInZone_1..5, etc.), it looks like eBikeBatteryRemaining, eBikeBatteryUsage, and eBikeMaxAssistModes were just not part of the original field list.

Could these three fields be added to whatever builds the lastActivity dict in ha_garmin? Since sensor.py already passes everything through generically, no sensor.py changes should be needed on the integration side once the client returns the fields.

Describe alternatives you've considered

Querying the Garmin API directly outside of the integration (separate auth session, rate-limit risk, duplicate polling).
Manually logging battery % after each ride via an input_number helper — works but defeats the purpose of automatic tracking.

Happy to test a PR/beta build against my account if useful (I have e-bike activities recorded roughly weekly).

Additional context

Integration version: 3.0.10 (installed via HACS)
The "E-Bike-Leistung" (E-Bike Performance) tab on the Garmin Connect activity page confirms the same three metrics visually (Akkuverbrauch/Akkuladestand chart, Assistenzmodus chart) — so this isn't just a stray field, Garmin's own UI relies on it too.
Translation strings in ebike_de.properties (fetched via Garmin Connect's web frontend) confirm the intended labels: battery_level, e_bike_battery_level, e_bike_battery_use — suggesting these are stable, documented-internally field names rather than experimental/unstable ones.
Happy to attach a screenshot of the E-Bike Performance tab if useful.

[hoffeck]

Following up on my earlier comment — I dug into the installed ha-garmin 0.1.29 source directly (docker exec homeassistant grep/sed on client.py) and found why this still doesn't work despite the version bump.
Root cause: fetch_activity_data() builds last_activity directly from the list endpoint response, not the per-activity detail endpoint:
pythonrecent_activities = await self._safe_call(self.get_activities, 0, 10)

last_activity: dict[str, Any] = {}
if recent_activities:
last_activity = dict(recent_activities[0])
activity_id = last_activity.get("activityId")

# Fetch polyline
if last_activity.get("hasPolyline") and activity_id is not None:
    try:
        activity_details = await self.get_activity_details(
            int(activity_id), 100, 4000
        )
        if activity_details:
            polyline_data = activity_details.get("geoPolylineDTO") or {}
            ...
            last_activity["polyline"] = [...]
    except GarminAPIError as err:
        ...

get_activity_details() is called here — but only to pull geoPolylineDTO for the route polyline. Nothing else from that response gets merged into last_activity.
The ALLOWED_ACTIVITY_KEYS allowlist was correctly extended with eBikeBatteryRemaining / eBikeBatteryUsage / eBikeMaxAssistModes (confirmed via grep — they're there, under the "E-bike (ANT+ LEV, e.g. via Edge devices)" comment). But recent_activities[0] — the list-endpoint response last_activity is actually built from — never contains these fields in the first place. I confirmed this independently earlier by inspecting the raw Garmin API response: the summary endpoint (activity-service/activity/{id}, i.e. what get_activity_details() already fetches for the polyline) does return eBikeBatteryRemaining, but the list endpoint (get_activities) apparently doesn't.
Suggested fix: since activity_details is already fetched in that same code path (for the polyline), it would just need to also merge the e-bike keys from it into last_activity, e.g.:

pythonif activity_details:
for key in ("eBikeBatteryRemaining", "eBikeBatteryUsage", "eBikeMaxAssistModes"):
if key in activity_details:
last_activity[key] = activity_details[key]
...
Happy to test a fix against my account if useful.

One more thing: the same gap likely applies to sensor.garmin_connect_last_activities (the list of the 10 most recent activities) — those come straight from get_activities() with no get_activity_details() call at all, so they'd never carry the e-bike fields even after a fix to the last_activity path above. Probably out of scope for a quick fix (fetching details for all 10 would be 10x the API calls), but worth knowing so it doesn't look like a second bug later.

[cyberjunky]

Great analysis, thanks — that was exactly it. One correction to the suggested patch: get_activity_details() hits activity-service/activity/{id}/details (chart/polyline data), which doesn't carry the e-bike fields either. What you verified in devtools was activity-service/activity/{id} — the plain summary endpoint. So the fix fetches that endpoint directly.

Implemented in ha-garmin 0.1.30: for cycling-type activities, lastActivity is enriched with eBikeBatteryRemaining / eBikeBatteryUsage / eBikeMaxAssistModes from the activity summary. The result is cached per activity, so it costs one extra API call per new ride — not per poll (rate limits stay happy).

On your last point: correct, the last_activities list (10 most recent) won't carry these fields — enriching all 10 would mean 10x summary calls, not worth it. The fields live on last_activity only; documented behavior, not a second bug.

Will ping here once the next integration release with ha-garmin 0.1.30 is out so you can verify against your account.

[hoffeck]

Update after digging further (installed ha-garmin 0.1.31 via HACS 3.0.14, so this is against the shipped fix, not a stale environment):

Confirmed: The raw HTTP response from get_activity() (activity-service/activity/{id}) does contain the e-bike fields — verified repeatedly via debug logging:

2026-07-14 20:23:37.984 DEBUG [ha_garmin.client] API response from https://connectapi.garmin.com/activity-service/activity/23595650450: {..., 'eBikeMaxAssistModes': 7, 'eBikeBatteryUsage': 8, 'eBikeBatteryRemaining': 64, ...}

But: with a debug line inserted immediately after summary = await self._safe_call(self.get_activity, activity_id) or {} inside _get_ebike_fields(), logged at the exact same timestamp (20:23:37.984):

2026-07-14 20:23:37.984 WARNING [ha_garmin.client] DEBUG summary direct: remaining=None type=<class 'dict'> keys_sample=['activityId', 'activityUUID', 'activityName']

So at the same millisecond, the same logical call: the raw response (logged inside _request(), result = response.json(); _LOGGER.debug(...); return result — no processing in between, verified line by line) has eBikeBatteryRemaining: 64, but summary.get("eBikeBatteryRemaining") in _get_ebike_fields() returns None.

I checked _request() end-to-end — there's no transformation, caching, or filtering between the debug log and the return result statement. ACTIVITY_ESSENTIAL_KEYS and EBIKE_ACTIVITY_KEYS both correctly list the three e-bike keys (no typos, no duplicate/shadowing definitions — checked via grep -n). No .pyc cache staleness (timestamps match .py exactly). No second copy of ha_garmin anywhere on the filesystem.

This reproduced consistently across multiple full container restarts and multiple polling cycles, always the same way: raw response has the fields, summary (same activity, same call, same instant) doesn't.

My best guess at this point is a race condition or shared-state issue between the multiple coordinators (Core/Activity/Training/etc. all polling independently) — but I've hit the limit of what I can diagnose via read-only grep/sed inspection and manual debug-log insertion. This might need actual breakpoint debugging or a print of id(summary) / object identity across the call boundary to pin down. Happy to run any specific test you'd want on my setup — I have Docker exec access and can add temporary debug lines.