Tesla Fleet: Selora as the Shortcut

Summary

Connecting a Tesla vehicle to Home Assistant through the Tesla Fleet integration is one of the most configuration-heavy cloud integrations we support: the homeowner must create a Tesla developer application, choose the right OAuth grant types, register allowed origins and a redirect URI, select API scopes, retrieve client credentials, and expose a public key file over the web so the Fleet API can validate signed commands. Done by hand, that is a long, jargon-heavy multi-hour setup that produces an opaque failure point when any step is wrong.

This feature makes Selora the shortcut: the homeowner never touches the Fleet configuration. Selora provisions the whole chain behind the scenes: developer application, credential storage, public key hosting, and the OAuth callback. It uses the public URL and per-home resources that Secure Remote Access already provides. It extends the same pattern we use for the Selora Alexa skill : a published integration that routes to each customer’s own Home Assistant through Selora Connect, instead of a third-party cloud.

What the raw setup requires today

From the Home Assistant documentation, a working Tesla Fleet installation needs all of the following:

1. A verified Tesla account.
2. A Tesla developer application at developer.tesla.com with:
   • OAuth grant types: Authorization Code and Machine-to-Machine.
   • An Allowed Origin URL: the customer’s own web domain, public and reachable.
   • An Allowed Redirect URI: https://my.home-assistant.io/redirect/oauth (My Home Assistant) or the instance’s /auth/external/callback, which means HA must be reachable at a stable public URL.
   • API scopes: Vehicle Information, Vehicle Location, Vehicle Commands, and the Energy Product scopes for Powerwalls/solar.
3. Client ID / Client Secret entered into the HA config flow.
4. Command signing: a public key file hosted at a URL Tesla can fetch, paired with a private key the integration uses to sign vehicle commands. Hosting this file is the step that breaks most first-time setups: it requires the NGINX SSL proxy app or an external service.

Every one of those steps is configuration the customer cannot meaningfully validate, and every one is a support ticket waiting to happen.

What Selora does instead

Selora already owns the two hard prerequisites:

• A public, stable URL per installation. Remote Access publishes every Hub over a per-home public endpoint with TLS, providing the exact “Allowed Origin” and “Redirect URI” values the Fleet API demands, without the customer configuring port forwarding, a domain, or the NGINX app.
• Per-home resources that third-party services route to. We create and manage integration-scoped resources the same way we do for Alexa : a registered application record, a callback path, and a key endpoint scoped to that home.

The plan is to drive the setup through Selora Connect so the homeowner’s interaction is: “Link your Tesla account → sign in at tesla.com → done.”

Concretely, Selora takes on:

• Developer application. Selora creates (or pre-registers) the Fleet developer application with the grant types and scopes, binding the Allowed Origin and Redirect URI to the home’s Selora public URL. The customer only signs the OAuth consent screen.
• Public key hosting. We host the command-signing public key at a Selora-scoped URL under the same public endpoint, with no NGINX app, no external key host, no third party in the path.
• Private key management. The signing private key is generated and stored on the Hub (or in secure Selora storage) like any other credential; it is the integration’s config/tesla_fleet.key equivalent, managed by Selora.
• Config flow automation. The Client ID/Secret are injected, and the config flow completes server-side, so the customer never pastes credentials.
• Lifecycle. Re-auth on token expiry, key rotation, and clean removal of the integration instance (unregister + key deletion) all handled by Selora.

After linking, the vehicle’s entities (charge state, climate, commands, energy sites, wall connector) appear in the homeowner’s HA exactly as a manual setup would produce them, but with Selora as the maintained integration layer.

What we evaluate / decide

• Per-home vs. shared developer application. One Fleet application per installation (cleanest separation, more app records) vs. a shared Selora application with per-home origins. Tesla’s model allows multiple origin URLs; we need to pick the one that keeps multi-home installs isolated.
• Key hosting location. Public key on the Selora public endpoint (simplest, one more URL family) vs. per-Hub hosting.
• OAuth callback path. Reuse the Remote Access endpoint vs. a dedicated callback path, and whether My Home Assistant’s redirect (my.home-assistant.io) can be bypassed entirely since we already hold the public URL.
• Scope defaults. Which scopes to request by default (vehicles only vs. vehicles + energy), and how Powerwall/solar homes are handled.
• China region. The integration does not support the China region; confirm we simply surface a clear “not available” rather than a broken flow.
• Companion experience. The link flow in the Selora app: one tap, a tesla.com sign-in, and the vehicle appears, mirroring how Alexa pairing feels to the customer.

Why this matters

Tesla owners who want HA control today hit a wall of self-hosting-style configuration on a managed Hub: public key hosting, a real domain, OAuth grant types. That friction is precisely what Selora exists to remove, and we already own both enabling pieces (public URL per home, per-home integration resources). A “link your Tesla” shortcut converts one of the most requested and most error-prone cloud integrations into a tap-and-go feature, with Selora owning the credentials and the maintenance: the same trust story as remote access and Alexa.

Scope

In scope (this roadmap entry)

• Provision the Fleet developer application, OAuth callback, public key hosting, and command-signing key on the Selora side.
• Inject credentials and complete the HA config flow server-side.
• Manage key/credential lifecycle (rotation, re-auth, removal) per home.
• Expose vehicle/energy entities as the integration already provides.

Out of scope (for now)

• In-app Tesla command surfaces (lock/unlock, climate), which build on the integration once linked.
• Fleet API usage beyond the HA integration.
• China-region support (not supported by the integration).

Success

• Homeowner links a Tesla in the app without touching developer.tesla.com, a public key file, or OAuth terms.
• A working integration is visible in HA within minutes of linking.
• Key rotation and re-auth succeed without customer action; removal is clean.

Open questions

• One developer application per home, or a shared application with per-home origins?
• Public key hosted on the Selora endpoint or per-Hub?
• Default scopes: vehicles only, or vehicles + energy by default?
• How does the Companion app present the link flow and the resulting entities?