Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating keys for telemetry #201

Open
tobiasstegge opened this issue Aug 26, 2024 · 3 comments
Open

Creating keys for telemetry #201

tobiasstegge opened this issue Aug 26, 2024 · 3 comments

Comments

@tobiasstegge
Copy link

Dear Tesla Dev Team,

We are building an application where end-consumers can connect their Tesla vehicles. We are hesitant to use the Tesla Fleet Telemetry because we think that the additional step in the sequence to create Fleet Keys does not result in a good user experience.

We are handling the Tesla connect flow in a web view, where the user is redirected to the Tesla IdP. We support that step since it adheres to the OAuth2 token exchange standard.

However, once the account is linked, we need to redirect the user to the Tesla app for all of the vehicles connected to their account. To do this, we need to redirect the user to "https://tesla.com/_ak/developer-domain.com" and instruct them to select the correct vehicle in the app. Since there is no way to provide a redirect back to us, it is also difficult to track as a third party if this was successful.

We would like to suggest a different way to create keys for vehicles without having to direct the user to the Tesla app. We think it would provide a better user experience in third-party apps if the end-user does not need to follow additional steps to create these keys. It would be beneficial for third parties if they could activate the streaming client just using the /vehicles/fleet_telemetry_config endpoint, and the Fleet Keys are automatically created for those vehicles.

@patrickdemers6
Copy link
Collaborator

Thanks for the feedback. I agree, the key pairing process is a bit cumbersome right now.

To check if a vehicle has the key present, you can use the fleet_status endpoint. A redirect is not a bad idea, I will take this to the team.

Tesla does not have the ability to add keys to a vehicle, and keeping keys as a part of this flow is vital for ensuring data is streamed to an authorized party.

@Bre77
Copy link

Bre77 commented Aug 26, 2024

Patrick, to add one more piece to this, the "Finish Setup" on https://www.tesla.com/_ak/teslemetry.com doesn't do anything. That also seems to confuse users that manage to launch the page but not the app.

@corsair
Copy link

corsair commented Sep 13, 2024

@patrickdemers6

When a vehicle owner authorizes access to their Tesla Account to a third-party, the OAuth "scope" selection already clearly communicates what the third-party will have access to and be able to modify:

Allow access to your vehicle commands, including commands such as add/remove driver, access Live Camera, unlock, wake up, remote start, and schedule software updates

Due to the above phrasing, vehicle owners are left with the impression that the third-party can already successfully send commands on their behalf to their vehicle(s). Despite improving onboarding to communicate this additional setup requirement better, this still is a common frustration felt by almost all developers universally.

Since the inception of the Fleet Key requirement, I have personally received hundreds of complaints from vehicle owners due to the complexity and frustration of setting it up on each vehicle individually. This becomes exponentially more frustrating for large families or fleets and has impacted customer happiness. In some unfortunate cases, this alone has resulted in lost business due to a customer's unwillingness to "do this multiple times" when we communicate this is by design from Tesla and for their safety/security.

While I understand security is paramount, and Tesla desires to keep all communications between the vehicle and the authorized party secure, better options must be available, especially since the vehicle owner has already consented to commands being sent by the authorized party.

Tesla is already aware of the existence of the hosted public key via the usage of the /api/1/partner_accounts register endpoint, so why not consider the following:

  • A) Upon approving access to a third-party and granting the "Vehicle Commands" scope, send the virtual key to any vehicles owned by the Tesla Account. If the vehicle is not online and/or can not accept the virtual key, assign a queue for this with a reasonable timeout and retry period.

  • B) When visiting /_ak/example.com and being sent to the Tesla mobile app, a dialog window will pop up, allowing the account owner to select either "All Vehicles" or "Select Vehicles" and check which they'd like to include.

Either of these should vastly improve user experience for vehicle owners, lessen frustrations felt by larger families or fleets, and provide a smoother experience for developers when onboarding users and vehicles for the first time.

I understand that any change to this implementation can't happen overnight, and it's crucial to ensure that any updates to existing implementations are handled with care. However, as deliveries continue and interest in third-party services grows, improving this is paramount to ensuring healthy relationships with developers and vehicle owners. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants