Fleet Telemetry

Fleet Telemetry is the most efficient and effective way of gathering any type of data from vehicles. It allows vehicles to stream data directly to a server, eliminating the need to poll the vehicle_data endpoint. This prevents unnecessary vehicle wakes and battery drain. Fleet Telemetry is not fully equivalent to the vehicle data endpoint but provides important data in an efficient and economical manner. See Cost Optimization Case Studies for details of the cost savings available by using Fleet Telemetry.

The Fleet Telemetry server must be running on a server exposed to the public internet. The GitHub repository has source code and examples of running the server.

To configure a vehicle, confirm all pre-requisites are met. Then, send a configure Fleet Telemetry request through the vehicle-command HTTP proxy. The proxy will sign the configuration using the configured private key and forward the request to Fleet API.

For a vehicle to be able to stream data, a few conditions must be met:

• The vehicle must not be a pre-2021 Model S or Model X.
• Vehicles must be running firmware version 2024.26 or later.
  • Applications configured with the legacy certificate signing process require 2023.20.6 or later.
• The virtual key is paired with the vehicle.

Pairing a Key

To pair a key to the vehicle, direct the user to:

https://tesla.com/_ak/developer-domain.com

This will allow the user to add the key to their vehicle through the Tesla mobile app.

Troubleshooting:

• If receiving a message stating the user has not granted this third party app access, ensure the user is logged into the Tesla app with the same email used when authorizing the third party application.
• If receiving a message stating the application has not registered with Tesla, ensure the register endpoint has been called for the region the user is located in.

Once all pre-requisites are met, use the Fleet Telemetry configure endpoint to send the desired configuration to the vehicle. Configurations are signed and cannot be edited by Tesla. If a required authorization scope is revoked, making a configuration invalid, the configuration will be removed from the vehicle.

A full list of fields are available in the open source repository's vehicle_data.proto file. Documentation improvements for available fields are coming soon.

Fleet Telemetry consists of two event loops:

1. The event collector gathers data in 500 millisecond buckets. Once 500 milliseconds has elapsed, all fields that have emitted values are delivered to the remote server.
2. Each field's value is only sent to the event collector once two conditions are met: interval_seconds has elapsed since the field was last emitted and the field's value has changed.

System state transitions:

Assume the "VehicleSpeed" field is being streamed with interval_seconds set to 1.

Failure handling:

• Loss of connectivity: the vehicle will buffer 5000 messages which is at least 2,500 seconds of data. Once reconnected, all messages will be delivered.
• Server disconnect: the vehicle will buffer messages, as described above. It will attempt to reconnect in an exponential backoff with a maximum retry delay of 30 seconds.
• A vehicle's connectivity state can be monitored through Fleet Telemetry connectivity events.

This is a sample configuration which collects data from the most commonly used fields when building applications.

{
    "fields": {
        "VehicleSpeed": { "interval_seconds": 10 },
        "Location": { "interval_seconds": 10 },
        "Soc": { "interval_seconds": 60 },
        "DoorState": { "interval_seconds": 1 },
        "Odometer": { "interval_seconds": 60 },
        "Locked": { "interval_seconds": 1 },
        "EstBatteryRange": { "interval_seconds": 60 },
        "ChargeAmps": { "interval_seconds": 1 },
        "DetailedChargeState": { "interval_seconds": 1 },
        "VehicleName": { "interval_seconds": 1 },
        "TpmsPressureFl": { "interval_seconds": 1 },
        "TpmsPressureFr": { "interval_seconds": 1 },
        "TpmsPressureRl": { "interval_seconds": 1 },
        "TpmsPressureRr": { "interval_seconds": 1 },
        "TpmsLastSeenPressureTimeFl": { "interval_seconds": 1 },
        "TpmsLastSeenPressureTimeFr": { "interval_seconds": 1 },
        "TpmsLastSeenPressureTimeRl": { "interval_seconds": 1 },
        "TpmsLastSeenPressureTimeRr": { "interval_seconds": 1 }
    }
}

During regular driving, a small subset of the desired fields are regularly streamed thanks to change based streaming described above.

• VehicleSpeed: 6 signals per minute
• Location: 6 signals per minute
• Soc: 1 signal per minute
• Odometer: 1 signal per minute
• EstBatteryRange: 1 signal per minute
• Remaining fields: not streamed regularly

This results in approximately 15 signals streamed per minute of driving, yielding a cost of $0.0001/minute or $0.006/hour.

The other fields are streamed on vehicle startup and infrequently as the value changes. For this estimation, generously assume each field is streamed 3 extra times per hour. This results in 18 * 3 = 54 additional signals, yielding a cost of $0.00036/hour.

For this basic configuration, an hour of driving would cost about $0.00636.