Your opinion on the Fleet API pricing?

[jlestel]

On 11/27, Tesla finally published the Fleet API pricing: https://developer.tesla.com

A French expression says that you can fool a person a thousand times. You can fool a thousand people once. But you can't fool a thousand people, a thousand times!

So, I think this is potentially great news for Teslamate... let me explain:

1. The business model favors the creation and use of one Tesla Oauth app per Tesla customer to take advantage of the $10 offered per month.
2. There are fewer limitations than on the Fleet API when it was free (especially on calls to vehicle_data and the frequency of the fields that interest us in streaming).
3. These $10 should cover Teslamate's needs for 1 or 2 vehicles (depending on their use) by offering an experience much closer to that of the Owner API in Teslamate.

When we are given $10 per month we have to know how to take advantage of it : I'm simplified the process to create your own Tesla API Application and then be able to use it directly between Teslamate and Tesla (or via a third party).
Here is an easy way to register your own Tesla API Application

Finally, there is still the point of streaming for which we'll need a new container for Telemetry and succeed in producing an output similar to legacy streaming, I plan to work on the subject later.

There you go, I wanted to share these impressions with you and I'm curious to have yours.

PS1: I noticed that they had previously introduced a version for open-source applications but it was removed. The lifespan of this feature must have been very short!

PS2: I obviously have a thought for all the third-party solution publishers who now pay for the billions of calls from their thousands of Teslas. Good luck!

[swiffer]

Thanks opening the discussion.

I wonder if Streaming can be simplified. If understood correctly it makes sense to add the official tesla fleet-telemetry container (https://developer.tesla.com/docs/fleet-api/fleet-telemetry) to the docker compose stack. this one needs to be publicly available.

As it's recommended to use kafka I would vote for adding kafka to the docker compose stack as well and fetch data from kafka within the teslamate container instead of using google pubsub (making the whole stack no longer self-contained and depending on google as cloud provider).

[swiffer]

exactly - if i understood correctly both @jlestel and @pkuehnel worked on a "translation layer / service" within their projects with the goal of mocking the original streaming api websocket connection so that no changes are necessary on TeslaMate side.

Solution Architecture

Var1: This is the solution currently referred to in our docs (by @jlestel)

-> https://github.com/MyTeslaMate/websocket
-> https://docs.teslamate.org/docs/guides/api#streaming-via-tesla-telemetry

Tesla / Vehicle -> Official Fleet-Telemetry Service (self-hosted) -> Google PubSub (cloud) -> MyTeslaMate (websocket) (selfhosted) -> TeslaMate (self-hosted)

Var 2: Next there is the solution (proposed by @pkuehnel)

tl;dr I have a completely working Docker integrated solution that consumes data via Fleet Telemetry and sends it to clients via WebSocket. Is working hosted and on premises. I don't think it would get any simpler for TeslaMate users to set everything up.

Tesla / Vehicle -> Official Fleet-Telemetry Service (self-hosted) -> Docker Service by @pkuehnel -> TeslaMate (self-hosted)

My understanding is that this solution covers the parts of Google PubSub and MyTeslaMate (websocket) within one service - right?

Var 3: Changing the way TeslaMate fetches data collected via Fleet Telemetry

• The official Tesla Fleet Telemetry container publishes data to multiple backends (with kafka beeing the preferred one) / maybe soon to MQTT
• TeslaMate could be adapted to fetch messages via one of these message brokers avoiding a mocking service in between.

What are the drawbacks?

Before going forward I would prefer bringing more clarity in the Up/Downsides of switching to Tesla Fleet Telemetry - the docs are really vague here currently -> https://docs.teslamate.org/docs/guides/api#why-tesla-fleet-and-telemetry-only-have-drawbacks

• Requires Vehicle Software 2024.26 / 2023.20.6
  • via https://developer.tesla.com/docs/fleet-api/fleet-telemetry#prerequisites
• The vehicle must not be a pre-2021 Model S or Model X.
  • via https://developer.tesla.com/docs/fleet-api/fleet-telemetry#prerequisites
• Elevation and Power are not available
  • via https://github.com/MyTeslaMate/websocket?tab=readme-ov-file#limitations
• Limited to ~ 1 Mio Streaming Signals per Month when going with the free plan
  • via https://developer.tesla.com/
• Realtime Data is limited to 60 reqs per minute, giving us ~1s data resolution (max) vs 250ms via owners / streaming api
  • via https://developer.tesla.com/docs/fleet-api/getting-started/billing-and-limits#rate-limits
• adds complexity to the stack (additional services, accessability via internet)

Limitations / 10$ monthly Budget

Considering the usage based pricing outlined here: https://developer.tesla.com/ and the rate limits

• Streaming API currently pushes 7 fields (latitude, longitude, speed, power, odometer, battery_level, elevation) every 250ms.
• additional attributes are fetched every 15 (streaming enabled) / 2.5 (streaming disabled) seconds via owners API (~24 fields).

Looking at 2024-10 data in my instance (streaming api enabled) - when truncating data to second I got these number of signal changes:

that is well within limits (2200km / 40h driving) of 900.000 signals per month so I guess most of us would fit within free tier.

What is high granularity data used for?

Within dashboards we often filter out streaming data to be able to calculate long-term statistics on low spec'd devices. Reducing the data samples by 4x (250ms vs 1s) would most likely help without really reducing accurary of metrics gathered.

That said we do calculate some metrics that would suffer:

• Drive Details: Energy recovered through regenerative braking (uses power field, no longer available!)
• Multiple Dashboards: Elevation (use elevation field, no longer available, needs handling via SRTM!)
• Multiple Dashboards: Speed Histogram (less accurate)
• Multiple Dashboards: GeoMap (less accurate - but e.g. Visited dashboard is already downsampled to 1 point per minute)

What now?

• What have I missed / misunderstood?
• Any signs of the Owners API shutting down?
• Clarify the docs based on the findings?
• Estimate effords needed per approach (see Var 1-3 above)?
• Act now or wait to see how fleet-telemetry / pricing changes in the next months?

Owners API is still working fine here - but waking up one day having it no longer available without beeing prepared would be sad.

Slightly offtopic

We currently do support Streaming API and Polling only. The benefits of Streaming API are higher data granularity (10x / 2.5s vs 0.25s) and improved sleep behavior while not missing drives. Anything else?

When additing additional opens for data collection it would be great to have some sort of decision matrix / overview of all methods available for users to make informed decisions.

[arcastro]

Thank you for the summary @swiffer , that's very informative!

That said we do calculate some metrics that would suffer [such as] Drive Details: Energy recovered through regenerative braking (uses power field, no longer available!)

The official Fleet Telemetry Docs point to the vehicle_data.proto for a full list of available fields. One of those seems to be LifetimeEnergyGainedRegen. I'm not running the fleet-telemetry service so I don't know what this field looks like in practice, but from the name alone, it seems to match your description. Could we use this directly instead of the previous power field?

Multiple Dashboards: Elevation (use elevation field, no longer available, needs handling via SRTM!)

Does the SRTM idea essentially use some map to determine elevation from a given lat/lng? I'm not opposed. But I'm surprised there's no open issue on the fleet-telemetry repo asking about it. Maybe they'd be willing to include a field for elevation, or offer some other alternative.

--

The other drawbacks don't seem particularly bad to me. But I'm definitely biased. I'm sure if my vehicle were excluded, I'd feel a little different 😅

[brianmay]

My vision - if you can use tesla-telemetry that is:

A lot of the complexity in teslamate would now be redundant. For example, my understanding is there would be no need to keep track of car trying to sleep anymore, Tesla code would handle all of this complexity itself (and hopefully with better results).

Also: People want to run this on low powered computers, e.g. RPI4. I personally don't think elixir/beam is really a good match here.

I think it might be worth considering creating teslamate from scratch in some new language. All it has to do (assuming MQTT PR is merged) is read in a stream of MQTT data, and then send it out to the database and MQTT using compatible schemas to what we have already.

The challenging parts might be mapping the fields, and correctly identifying start/stop of charges and drives (as the database schema requires this).

I would consider doing this myself, but my car is too old, so I can't.

[swiffer]

I somehow missed mentioning some of the benefits, definitely a telemetry only based solution is preferable for the reasons you mentioned above. I would assume it greatly reduces complexity / amount of code of the teslamate project going forward.
In addition fleet-telemetry offers additional fields we currently don't have. e.g. we could start logging if autopilot is active and building some statistics around that.

[pkuehnel]

In my opinion, the database schema needs to be changed as the data will not come in sync anymore. Currently, longitude and latitude are not nullable in the Positions table, for example, but there won't be a new location every time e.g., charging current changes.

[pkuehnel]

tl;dr I have a completely working Docker integrated solution that consumes data via Fleet Telemetry and sends it to clients via WebSocket. Is working hosted and on premises. I don't think it would get any simpler for TeslaMate users to set everything up.

Long version:
In my opinion TeslaMate should simply not try to hold on the old streaming API as it further complicates everything. Instead, it should be able to consume data directly from Kafka or something like MQTT or custom Web socket. I do not know if it is possible to set up authentication on Kafka. Here is why authentication will be needed: Not everybody using TeslaMate will have the technical skills and requirements to set up Fleet Telemetry — in Germany, for example, there are internet providers that do not have a dedicated IP v4 address for each customer. This results in (as far as I know) DynDNS not working correctly and the cars not being able to stream data to it. I am the developer of https://github.com/pkuehnel/TeslaSolarCharger. I used to use TeslaMate to get the car data and TeslaMateaAPI to send commands to the car. As Tesla started removing support of sending commands from the owner API, I started using the Fleet API and Fleet Telemetry. I have a hosted Fleet Telemetry server for everyone with a C# application that consumes the Kafka messages and sends them (converted to a custom format as Tesla loves to change the Fleet Telemetry messages and not every client updates in time, so I can react faster) via WebSocket to all my users. The authentication is very simple: The client comes with a WebSocket start request, including the VIN and the Tesla Token, my Backend checks via Fleet API if the VIN is part of the account with the Tesla Token. If yes, the car's Fleet Telemetry is configured and streaming starts. Everything is set up in Docker, and I do not think it could become any easier to set this up for any user at home. I would love to help TeslaMate out of the current situation and share my software, so everyone can use it at home or use my backend server (like currently every TeslaSolarCharger user does, as it is still free). The only two issues that are currently there:

1. As TeslaMate used to get all signals at the same time: This won't work anymore as the Fleet Telemetry data is sent asynchronous based on their changes (so at least longitude and latitude in the Positions table needs to become nullable).
2. Currently, I send the WebSocket data in my custom format, so TeslaMate won't be able to consume it right now, but no problems for me to change that (if you tell me what TeslaMate needs). From Wednesday onwards, I have time 24/7 the rest of the year.

[swiffer]

thanks offering your help! much appreciated - could you read through and see if my summary is correct?

[brianmay]

Each account receives a $10 monthly discount that will cover the cost to create useful automations for a few vehicles. For example, this can roughly cover data streaming, 100 commands, and 2 wakes per day for two vehicles.

Not sure I understand the "... for two vehicles part". But I gather these limits have to be shared across all your cars.

That seems pretty terrible. Only 100 commands across all your cars per month? That is around 3 commands a day.

Only two wakes per day? Consider that wakes often succeed, but the car still isn't actually awake. Do all these failed wake attempts count?

Maybe these limits won't affect Teslamate using the newer API, as Teslamate never sends wake up requests, and maybe doesn't send commands (not sure if polling counts here or not). But it certainly affects my code to turn on/off charging based on amber prices. And I can't agree to the developer terms and conditions while I am using the legacy API for that.

On the topic of switching to the new streaming API, AFAIK that still doesn't work with older cars, even older case with the upgraded MCU.

I may have missed something, don't understand how kafka is going to help us in anyway. We still need to get the data from Tesla, and I don't think we can use kafka for that.

[swiffer]

👍 no worries - I guess their example is based on the sum of streaming, command and wakes

[zlymeda]

@zlymeda Same page:

@swiffer Thanks for that. No time to look right now :-(

it says 100 commands per day, or that's how I understand it. and that would make sense as 1000 commands costs $1

[brianmay]

OK, I see the way the wrote that is confusing. Particularly with the comma after the "100 commands".

Lets assume that is 100 commands per day. That is just over 4 an hour, less if you have more then 1 car. I think I could work with that (e.g. by rate limiting my code to one command every 15 minutes). I already do try to rate limit to 5 minutes IIRC anyway.

However 1 command every 15 minutes is useless if the car isn't going to respond to them because it is asleep.

The 2 wakes per day still makes me nervous. Particularly as I don't know what constitutes a wake. e.g. just today my code was repeatedly sending wake requests for over half an hour and the car still would not respond correctly to a charge command. I had to manually unlock the car to get it to respond. If every attempt to wake the car counts as towards the 50 wakes per $1 my costs could easily go through the roof.

Even if only successful wake attempts (and I mean we successful as in we can send a command, not just get a success from the wake up command) get charged, I still don't see how we can send 100 commands a day if we can only send 2 wake up requests per day.

When the car is driving, sure you can send commands and not have to wake the car up, but I typically don't want to try to charge the car during these periods :-)

Then again, my car is too old anyway...

[zlymeda]

I use commands to charge my tesla via solar.. and now during the winter to charge it at night for lower prices.
But I am only using BLE to execute the command - I have modified the http-proxy to use BLE and not HTTP. They recently added a way to red some data via BLE - but I haven't had time to test that. You can even wake-up the car via BLE.

so if your use case is similar you can use BLE as well. I don't really have a use case for sending commands when I am away from my home, I use it for charging at home only.

[brianmay]

Pretty sure my car is too old for BLE command support also. :-(

[netdata-be]

I see that the holiday update will bring a bunch of fields which are currently filled using the vehicle_data
https://github.com/teslamotors/fleet-telemetry/pull/248/files

I think indeed that teslamate should shift towards consuming / subscribing to an MQTT and less rely on the vehicle_data

[lotharbach]

I just want to throw in a possibility that I think is worth considering: the fleet-telemetry server is a "reference implementation for Tesla's telemetry protocol", there is no need to run exactly that piece of software. TeslaMate could become a protocol-compatible fleet telemetry server written in elixir, and the protocol honestly does not look very complicated. Of course you would need to expose it to the internet then, in a way that works with mTLS. Still sounds much easier to run self-hosted, and less compatability issues and just less stuff outside of TeslaMates control. Receive data directly from vehicle on a websocket, read the interesting fields, write it to postgres.

We could also add some nice helpers regarding developer account setup, key creation, partner registration and setting the telemetry config.

[KrzysztofHajdamowicz]

https://developer.tesla.com/docs/fleet-api/fleet-telemetry#system-behavior
New info from Tesla.

Looks like streaming of whole car data every second is intended behavior.

[adjego]

So on the main page

Starting February 1, 2025, applications will begin accruing charges based on API usage. Billable events accumulated in December 2024 and January 2025 will not be billed.

Does this mean when i'm not using a developer account, so i don't change anything and keep using Teslamate the same way as i'm using now, will be billed based on what Teslamate is requesting? I see there is a rate limit:

Excessive Bill Protection: By default, each account has a billing threshold corresponding to the discount described above. This threshold can be increased once a payment method is added to the account. It is recommended to configure a billing threshold to prevent unexpected bills. Current usage is available on the billing and usage page of the application management dashboard.

I can offcourse first just try and see what happens and if i even exceed this $10, but what are your thoughts on this?

[brianmay]

I think there is no provision for billing from the owners API. Which is what Teslamate is still using.

It could stop working at any time without any notice. Although now that Tesla is able to charge large fleet operators to access the API to manage their large fleets, I suspect they really don't care about the relatively low numbers of hobbyists that are using the owners API for private reasons.

Particularly as - to the best of my knowledge - their own mobile app is still using the owners app. And it would look really bad if they moved the app to the fleet API and potentially started charging owners. Which has been free up to now. Of course they could give themselves some sort of free tier. But that could be reverse engineered, and we basically have the owners API again.

[chicagoandy]

Question - has Tesla indicated the owners API is going away?

I see posts from April here: #3792 and it seems we can just carry on using Owners and Streaming API. Is that the current plan?

Or is the Fleet API something we'll need to do?

[brianmay]

Tesla says the owners API is going away. They have been saying so for some time. But so far no actual evidence that this is going to happen. Still it could happen any time with no notice.

The Fleet API has no provision for streaming from older cars. So even if I wanted to I can't move to the fleet API.

I can't even move my own project code to using the fleet API (old JSON protocol which I believe(?) still works fine on older cars), which technically would be fine. Because that requires agreeing to the developer's terms and conditions, which prevent me from using the owners API for Teslamate.

[Dulanic]

Tesla says the owners API is going away. They have been saying so for some time. But so far no actual evidence that this is going to happen. Still it could happen any time with no notice.

The Fleet API has no provision for streaming from older cars. So even if I wanted to I can't move to the fleet API.

I can't even move my own project code to using the fleet API (old JSON protocol which I believe(?) still works fine on older cars), which technically would be fine. Because that requires agreeing to the developer's terms and conditions, which prevent me from using the owners API for Teslamate.

I am hoping this is the case, Tesla has been very inconsistent in it's information around APIs and what they are doing, which is no surprise. But the downside is, we are reliant upon the whim of tesla and why they just go boom and blow it all up.

[lotharbach]

has Tesla indicated the owners API is going away

Maybe that is not quite the right question. I don't think it is going away. I still think switching to Fleet API would be better.

a) "Owner API" is only one part of the "Tesla Mobile App backend". The Tesla App also uses a "streaming" websocket, which can also be used in TeslaMate, and since last year a "messaging" websocket for vehicle commands. Also of course there is the "auth" backend to log in and refresh oauth tokens. We know all of this only because we are able to watch network traffic from the Tesla App and decompile the Tesla App binary, and have reverse engineered the most relevant details for years. Fundamentally this is impossible to prevent for Tesla, even if they really removed the specific "Owner API" piece the larger principle of "doing what the App does" would continue to work. But Tesla could make it much much harder to re-implement and/or play cat and mouse by simply always changing stuff. I believe we will always be able to "pretent" to be the Tesla App and if our behavior is 100% identical to the App there is no practical way to block it.

b) The Tesla App and it's backend is going to evolve and change together even faster now. I believe that in the past, some larger fleet operators were officially allowed and supported by Tesla to use the "Owner API" for their own processes and integrations, because there was no alternative and they had to automate stuff. Now Tesla provides an alternative for quite some time and has certainly worked with all official partners to switch to the Fleet API. Which means they are now unburdened and can completely focus on what the Tesla App (and maybe other Tesla internal workflows) actually still needs. The owner APIs vehicle_data endpoint for example returns a protobuf data structure inside the JSON response for a large part of the vehicle status, if you use the Tesla App user-agent header. So right now they likely have an explicit "non-App response" fallback code in their backend, and I believe they will start removing such things and consolidate data formats etc. This could happen at any time, piece by piece, and then break Teslamate until somebody has volunteered a solution, which could take days or weeks.

c) As the Fleet API costs money, there are legal means in place to discourage "cheating". I believe Tesla will mainly use legal means (and simply the threat of legal action should be enough for most) to starve off all larger unofficial API users. I don't believe they will actually legally target hobbyists.

d) The Fleet API and especially the Telemetry looks actually superior on a technical level and has no risks regarding sudden changes or legal threats. Together with the 10$ discount for individuals this means we could have an actually better data logger which is still completely free for self hosted hobbyists. It's "just" a technical challenge, and maybe more importantly, an issue of volunteer time. It might also be harder to setup than a paid solution, but the privacy/security aspect will always be enough for me to at least try.

[brianmay]

You missed the bit where older cars - even with the upgraded MCU - do not support the fleet streaming API or the command API. So the owners API + streaming websocket is the only option for Teslamate (and the mobile app) really.

[lotharbach]

Telemetry is coming for all vehicles and even if it doesn't for a while, a polling setup at 95% discount doesn't sound unworkable and works with the current version of TeslaMate.

Model S/X vehicles produced before 2021 will have a 95% vehicle_data discount until Fleet Telemetry is broadly available for these vehicles.

Anyway it is always up to the volunteers that actually do the work. Maybe it will be TeslaMate-legacy as a separate project/branch if that is wanted by some, or maybe a new TelemetryMate needs to be started if current project owners are not on board and are going to maintain status quo for as long as they can. I am not able to develop either of those solutions so who am I to judge.

[brianmay]

I put this in a bad place, going to copy it here:

Unfortunately, other car brands aren't any better. I see that there has been work to reverse engineer the MG protocols. But not officially supported, so it could stop working. BYD seems to be getting nowhere.

Maybe installing our own logger might be a better approach. Google shows me links like https://docs.openvehicles.com/en/latest/introduction.html https://github.com/bassmaster187/TeslaLogger - I seem to remember this being discussed here previously, with a reference to a good OVMS adapter that I can't find right now. But now Tesla is talking about locking down the API more and more - particularly for older cars which have limited support with the newer APIs this might be worth revisiting.

Having a charger that supports OCPP might be a better bet for turning on/off charging. Although I have no idea what OCPP is like to program, and what data - if any - it gives you. There is rumors that Tesla Wall chargers might get OCPP in the future, but I won't believe it until it happens.

I suspect the reversed engineered API is not going away anytime soon. I think Tesla doesn't really care enough. They just want another excuse to charge large fleet owners $$$ on a subscription basis, and they have got that. But the fact it could disappear without warning and break my systems that rely on streaming, and there is no newer streaming API that works with the older cars, kind of reduces my enthusiasm for developing this code.

[brianmay]

If the owners API stops working and the fleet API is not satisfactory, this does look like a possible alternative:

https://docs.openvehicles.com/en/latest/introduction.html

On the plus, this looks like it is independent of the car manufacturer. And looks like it uses MQTT.

On the negative, need to supply your own data connection (if you want this). And support for Tesla is limited or non-existent depending on the model.

Other cars have better support, e.g. Nissan Leaf is excellent (not sure if this car is desirable for other reasons...). MG4 is reasonable, although missing charge start/stop support. BYD Atto3 is listed also. I guess support could change also at the whim of the car manufacturer, but I suspect is isn't going to be the same red target as the official API.