Replies: 6 comments 18 replies
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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 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)
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
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
Limitations / 10$ monthly Budget Considering the usage based pricing outlined here: https://developer.tesla.com/ and the rate limits
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:
What now?
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the summary @swiffer , that's very informative!
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?
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 😅 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
thanks offering your help! much appreciated - could you read through and see if my summary is correct? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
👍 no worries - I guess their example is based on the sum of streaming, command and wakes |
Beta Was this translation helpful? Give feedback.
-
it says 100 commands per day, or that's how I understand it. and that would make sense as 1000 commands costs $1 |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
|
I use commands to charge my tesla via solar.. and now during the winter to charge it at night for lower prices. 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. |
Beta Was this translation helpful? Give feedback.
-
|
Pretty sure my car is too old for BLE command support also. :-( |
Beta Was this translation helpful? Give feedback.
-
|
I see that the holiday update will bring a bunch of fields which are currently filled using the vehicle_data I think indeed that teslamate should shift towards consuming / subscribing to an MQTT and less rely on the vehicle_data |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
https://developer.tesla.com/docs/fleet-api/fleet-telemetry#system-behavior Looks like streaming of whole car data every second is intended behavior. |
Beta Was this translation helpful? Give feedback.
-
On 11/27, Tesla finally published the Fleet API pricing: https://developer.tesla.com
So, I think this is potentially great news for Teslamate... let me explain:
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!
Beta Was this translation helpful? Give feedback.
All reactions