feat(vehicle): add support for LeapMotor API

[syphernl]

Summary

Adds Leapmotor cloud API support (same API the official app uses). The API is unofficial but community-documented:

• https://github.com/kerniger/leapmotor-ha
• https://github.com/markoceri/leapmotor-api

App certs download automatically from markoceri/leapmotor-certs on startup, no files to provide.

Supported data

SoC, charge state, range, odometer, finish time, climate state, GPS position, SoC limit.

Caveats

• Unofficial API, may break without warning
• First startup requires GitHub reachability to fetch app certificates; cached locally after that.

Status

Not tested on a real car yet. Draft until someone validates it on a T03, B10, or C10.

Tested by @ngehrsitz on a T03: #29666 (review)

References

• Leapmotors Einbindung? #28084
• Leapmotor T03 #23583
• Generic car / manual SoC entry #26663

[ngehrsitz]

I tested it briefly and it works so far 👍

[ngehrsitz]

The new readouts work 👍

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="vehicle/leapmotor/identity.go" line_range="389-390" />
<code_context>
+	return nil
+}
+
+// Refresh refreshes the access token; falls back to a full login on failure.
+func (id *Identity) Refresh() error {
+	id.mu.Lock()
+	defer id.mu.Unlock()
</code_context>
<issue_to_address>
**suggestion:** Refreshed tokens are not persisted back to settings, which may cause unnecessary full logins after restarts.

Login() writes the token, refresh token, sign key, and PKCS#12 state to settings, but Refresh() only updates the in‑memory fields. After a restart, TryRestore will reload the old persisted values, so a full login may be required even after a successful refresh. To avoid this and support smoother restarts, also persist the updated values in Refresh().

Suggested implementation:

```golang
	id.token = token
	id.refreshTok = refreshTok
	id.userID = userID
	id.signKey = signKey
	id.acctClient = newMTLSClient(&acctCert)

	// persist restored identity so subsequent restarts use the latest credentials
	if err := id.persistIdentity(); err != nil {
		return err
	}

	return nil
}

// persistIdentity persists the current identity state (token, refresh token,
// sign key, and PKCS#12 / client cert state) to settings so it survives restarts.
func (id *Identity) persistIdentity() error {
	// NOTE: This implementation assumes there is a settings-like component on Identity.
	// Adjust the concrete calls to match the actual settings API used in this package.
	if id.settings == nil {
		return nil
	}

	if err := id.settings.Set("token", id.token); err != nil {
		return err
	}

	if err := id.settings.Set("refresh_token", id.refreshTok); err != nil {
		return err
	}

	if err := id.settings.Set("user_id", id.userID); err != nil {
		return err
	}

	if err := id.settings.Set("sign_key", id.signKey); err != nil {
		return err
	}

	// Persist PKCS#12 / mTLS client state if available.
	// This assumes the app certificate / PKCS#12 bytes are stored on Identity.
	if len(id.appPKCS12) != 0 {
		if err := id.settings.Set("app_pkcs12", id.appPKCS12); err != nil {
			return err
		}
	}

	// Some settings implementations require an explicit Save/Commit.
	if saver, ok := any(id.settings).(interface{ Save() error }); ok {
		return saver.Save()
	}

	return nil
}

```

```golang
+// Refresh refreshes the access token; falls back to a full login on failure.
+// On success, the refreshed credentials are also persisted so that
+// TryRestore() can restore the latest state after a restart.
+func (id *Identity) Refresh() error {
+	id.mu.Lock()
+	defer id.mu.Unlock()
+
+	// No refresh token available, perform a full login.
+	if id.refreshTok == "" {
+		return id.login()
+	}
+
+	// Use the account mTLS client to refresh the token.
+	if id.acctClient == nil {
+		// If for some reason the account client is missing, fall back to full login.
+		return id.login()
+	}
+
+	req, err := http.NewRequest(http.MethodPost, refreshURL, nil)
+	if err != nil {
+		return err
+	}
+
+	// Build refresh headers/body using the existing refresh token.
+	req.Header = buildRefreshHeaders(id.deviceID, id.refreshTok, defaultLang)
+
+	resp, err := id.acctClient.Do(req)
+	if err != nil {
+		// Network / client error – fall back to full login.
+		return id.login()
+	}
+	defer resp.Body.Close()
+
+	if resp.StatusCode != http.StatusOK {
+		// Server-side refresh failure – fall back to full login.
+		return id.login()
+	}
+
+	var payload refreshResponse
+	if err := json.NewDecoder(resp.Body).Decode(&payload); err != nil {
+		// Response could not be decoded – fall back to full login.
+		return id.login()
+	}
+
+	// Update in-memory fields from the refresh response.
+	id.token = payload.AccessToken
+	id.refreshTok = payload.RefreshToken
+
+	// Some backends may rotate the signing key and/or certificates on refresh.
+	if payload.SignKey != "" {
+		id.signKey = payload.SignKey
+	}
+
+	if len(payload.AcctPKCS12) != 0 {
+		// Rebuild the account mTLS client if we got a new PKCS#12.
+		acctCert, err := parsePKCS12(payload.AcctPKCS12, payload.AcctPKCS12Pass)
+		if err != nil {
+			// If the new PKCS#12 cannot be parsed, fall back to full login to re-bootstrap.
+			return id.login()
+		}
+		id.acctClient = newMTLSClient(&acctCert)
+		// Keep the PKCS#12 bytes around so they can be persisted.
+		id.acctPKCS12 = payload.AcctPKCS12
+	}
+
+	// Persist the refreshed credentials so TryRestore() after a restart sees the latest state.
+	if err := id.persistIdentity(); err != nil {
+		return err
+	}
+
+	return nil
+}

```

1. Wire `persistIdentity()` into `login()` as well, right after the point where `id.token`, `id.refreshTok`, `id.userID`, `id.signKey`, the PKCS#12 bytes, and the related mTLS clients are updated. This ensures both `login()` and `Refresh()` persist credentials in a consistent way.
2. Adjust the implementation of `persistIdentity()` to use the actual settings / persistence mechanism available on `Identity` (field name, method names, and key names may differ). The key requirement is that it writes the access token, refresh token, sign key, and PKCS#12 (for both app and account as applicable) and commits those changes.
3. Replace the placeholder types and symbols in `Refresh()` (`refreshURL`, `refreshResponse`, `buildRefreshHeaders`, `parsePKCS12`, `acctPKCS12`/`appPKCS12` fields) with the concrete ones used in this package, mirroring how `login()` and `TryRestore()` currently build their requests and manage PKCS#12 state.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[andig]

Unofficial API, may break without warning

We're currently not adding any more of these as they strain project ressources. Happy to reasses when official API is available.

[ngehrsitz]

Unofficial API, may break without warning

We're currently not adding any more of these as they strain project ressources. Happy to reasses when official API is available.

Is that really a good strategy though? I fully understand if the core development team does not want to invest resources into fixing a broken Integration like with VW at the moment.
At the same time I fear it will take years until litigation can enforce the open APIs mandated by the EU data act.
This means users are forced to use workarounds like running an additional Home Assistant.
Thus in the interim I would propose to keep the unofficial APIs on a "community support" model. This means if it breaks and none of the community stakeholders fixes it then just remove it after a grace period.
This limits the effort for the core development team to just making sure that PRs don´t introduce any unwanted changes to the rest of the codebase.
In my opinion this would be the best compromise that can be made here. Otherwise the users of a Leapmotor have to go without connectivity just because support for all of the other closed APIs came before them...

[andig]

Is that really a good strategy though?

It is. It allows focusing on where we can add value.

Thus in the interim I would propose to keep the unofficial APIs on a "community support" model. This means if it breaks and none of the community stakeholders fixes it then just remove it after a grace period.

Unfortunately, that still comes with the cost of issues and reviews. Integration is always possible using the HA vehicle.