Elevation recording stops during longer drives (?)

[accolon]

First of all, I'm starting a discussion instead of opening an issue because I'm still investigating whether this is a common problem.

In the past few weeks, my Teslamate stopped recording elevation values for several drives after about an hour.

Looking at the database tables directly, all affected position rows are missing elevation values. At the same time, they are containing values in ideal_battery_range_km instead, though -- both values seem to be mutually exclusive.

I found two similar observations ...:
#5438
#5271

... but no cause or explanation.

1. It seems that whenever Teslamate records the range, it doesn't record the elevation. Is this by design or is this an API limitation?
2. Why does this behavior seem to switch after some time, stopping the recording of the elevation for the rest of a drive?

(My Teslamate is on v4.0.1, I'm still using the Owner API and always have.)

[JakobLichterfeld]

Thanks for reporting.

This is not indented design nor reproducible on my end. As you are not using Streaming API it doesn't seem to be a rate limit. But please check your logs. Without the logs, it's impossible to see more clearly into the crystal ball.

[accolon]

Thanks for your reply and the reminder about the log. There's indeed a hiccup which coincides which the "switching" of recorded values, but I'm still not sure how all this comes together.

I went through the database looking at several past drives and their corresponding position records:

• Usually Teslamate gets/records about 2 to 4 position entries per second.
• Every single entry contains values for these columns: id, date, latitude, longitude, speed, power, odometer, battery_level, car_id, drive_id
• Most entries contain a value for elevation while all other columns (except for the ones mentioned above) are empty (i.e. NULL).
• About every 50th position entry (about every 15 seconds) does not contain a value for elevation, but instead values for all the other columns (like ideal_battery_range_km, different temperatures, heater status, TPMS and so on).
• Most of my past drives have been recorded following this pattern.
• Interesting: The last time my Teslamate recorded elevation together with all the other values was on 2024-06-06. Since then, it's either elevation or the other ones.

Regarding my original problem, after looking at the logs:

• For the first 50 minutes of my recent affected drive, all position records follow the pattern described above.
• According to the Teslamate main container's Docker log (see below), the vehicle then went offline for a short time.
• When it came back online, the pattern changed: Teslamate recorded only "full" entries (without elevation) about every 3 seconds for the rest of the drive.
• After a short stop to charge the battery, the next drive was recorded normally again.
• I could confirm these findings for another drive which is also missing the elevation values after about an hour of driving.

Docker log (shortened)

2026-07-19 19:45:39.576 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/92xxxxxxxxxxx36/vehicle_data -> 408 (9086.254 ms)
2026-07-19 19:45:39.576 [warning] TeslaApi.Error / %{"error" => "{"error": "timeout"}", "error_description" => "", "response" => nil}
2026-07-19 19:45:39.576 car_id=1 [error] Error / :unknown
2026-07-19 19:45:48.597 car_id=1 [info] Received stream data: :inactive
2026-07-19 19:45:58.670 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/92xxxxxxxxxxx36/vehicle_data -> 408 (9092.463 ms)
2026-07-19 19:45:58.670 [warning] TeslaApi.Error / %{"error" => "{"error": "timeout"}", "error_description" => "", "response" => nil}
2026-07-19 19:45:58.670 car_id=1 [error] Error / :unknown
2026-07-19 19:46:08.676 [notice] :alarm_handler: {:set, {TeslaMate.Vehicles.Vehicle_1_api_error, :fuse_blown}}
2026-07-19 19:46:08.738 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/92xxxxxxxxxxx36/vehicle_data -> 408 (65.681 ms)
2026-07-19 19:46:08.806 car_id=1 [info] Stream disconnecting ...
2026-07-19 19:46:08.806 car_id=1 [warning] Vehicle went offline while driving
2026-07-19 19:46:13.876 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/92xxxxxxxxxxx36/vehicle_data -> 408 (68.432 ms)
2026-07-19 19:46:19.019 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/92xxxxxxxxxxx36/vehicle_data -> 408 (76.611 ms)
2026-07-19 19:47:08.683 [notice] :alarm_handler: {:clear, TeslaMate.Vehicles.Vehicle_1_api_error}
2026-07-19 19:47:32.896 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/92xxxxxxxxxxx36/vehicle_data -> 408 (68.805 ms)
2026-07-19 19:48:03.027 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/92xxxxxxxxxxx36/vehicle_data -> 408 (67.824 ms)
2026-07-19 19:48:33.328 car_id=1 [info] Vehicle came back online after 4 min

TL;DR:

1. The question remains why the "full" records don't contain the elevation value -- e.g. like @swiffer also described.
2. Now that I know why some of my drives are not showing the elevation anymore: Why does the Tesla API (?) seemingly switch to "full" records only (although with a higher time resolution, i.e. every 3 instead of every 15 seconds) after the vehicle was "offline"?

[JakobLichterfeld]

Thanks for the logs — with them the behavior is clear. Here is what happens:

1) elevation vs. the "full" columns — by design (API limitation)

TeslaMate records positions from two different sources:

• Streaming API (websocket): several data points per second, but only a small set of fields: timestamp, lat/lng, speed, power, SoC, odometer — and elevation.
• vehicle_data polling (REST): while driving with streaming active, TeslaMate additionally polls the full vehicle data every 15 s. Those rows contain ranges, temperatures, TPMS etc., but the REST endpoint does not provide altitude at all. With the streaming API enabled, TeslaMate leaves elevation empty on those rows instead of doing an SRTM lookup.

So elevation only ever comes from the streamed rows. The SRTM backfill task doesn't fill the gaps either, as it only processes drives without any streamed positions. Your "combined" rows before June 2024 will have originated from exactly that backfill, i.e. drives where the stream wasn't delivering and the drive was treated as non-streamed. This also answers @swiffer's question from #5438.

2) The switch to "full rows only" after the car went offline mid-drive

The repeated 408 timeouts from the Owner API tripped the internal circuit breaker — the vehicle was treated as offline while driving and the stream was disconnected. When the car comes back online mid-drive, the drive is resumed, but in this resume path the streaming websocket is currently not re-established. TeslaMate falls back to pure REST polling at the driving interval (default 2.5 s — your ~3 s observation) for the rest of the drive. Only when the state machine passes through the online state again (after your charging stop) is the stream reconnected, which is why the next drive was recorded normally.

So nothing is lost except elevation — the higher-frequency full rows are the designed polling fallback.

Point 2 is worth fixing: the stream should be reconnected when a drive resumes after an offline phase. I've opened #5534 to track this.

🤖 Comment drafted with Claude Code (Fable 5 extra) — sponsored by Claude for Open Source