Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

TeslaMate [megathread]

This site may earn commission on affiliate links.
Sounds more like your authentication to Tesla might have lapsed. Missing timezone would really just throw an error when charging, not prevent data from being collected. Did you change your Tesla account password anytime recently?
He's missing data from the overview page which I took as a DB issue. Although I dare say that depends on what is missing/being shown.
@kitenski care to share your overview page?
 
  • Like
Reactions: cwanja
He's missing data from the overview page which I took as a DB issue. Although I dare say that depends on what is missing/being shown.
@kitenski care to share your overview page?
1709298200198.png
 
Database logs have lots of this from yesterday


Code:
teslamate-1  | 2024-02-29 22:11:46.069 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:12:15.133 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9061.393 ms)


teslamate-1  | 2024-02-29 22:12:15.133 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:12:15.134 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:16:45.749 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9069.669 ms)


teslamate-1  | 2024-02-29 22:16:45.750 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:16:45.750 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:17:14.819 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9067.030 ms)


teslamate-1  | 2024-02-29 22:17:14.820 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:17:14.820 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:17:43.881 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9058.282 ms)


teslamate-1  | 2024-02-29 22:17:43.881 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:17:43.882 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:18:12.945 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9060.477 ms)


teslamate-1  | 2024-02-29 22:18:12.945 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}
 
Database logs have lots of this from yesterday


Code:
teslamate-1  | 2024-02-29 22:11:46.069 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:12:15.133 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9061.393 ms)


teslamate-1  | 2024-02-29 22:12:15.133 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:12:15.134 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:16:45.749 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9069.669 ms)


teslamate-1  | 2024-02-29 22:16:45.750 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:16:45.750 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:17:14.819 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9067.030 ms)


teslamate-1  | 2024-02-29 22:17:14.820 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:17:14.820 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:17:43.881 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9058.282 ms)


teslamate-1  | 2024-02-29 22:17:43.881 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}


teslamate-1  | 2024-02-29 22:17:43.882 car_id=1 [error] Error / :unknown


teslamate-1  | 2024-02-29 22:18:12.945 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929720821167018/vehicle_data -> 408 (9060.477 ms)


teslamate-1  | 2024-02-29 22:18:12.945 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}
That looks like it is still making the old, deprecated, API calls. i.e. you need to update to 1.28.3.
 
  • Like
Reactions: MP3Mike
Hello,

Currently i am having Tesla Model 3 with teslamate installed in my raspberry pi. I am trade in my Model 3 to Model Y. how should i setup my teslamate to my model Y ?
do i need to delete the database and reinstall again or what should i do ?
I dont want to loose the supercharger database in the teslamate
 
Hello,

Currently i am having Tesla Model 3 with teslamate installed in my raspberry pi. I am trade in my Model 3 to Model Y. how should i setup my teslamate to my model Y ?
do i need to delete the database and reinstall again or what should i do ?
I dont want to loose the supercharger database in the teslamate
It should just detect the Model Y getting added to your account and add it as an additional vehicle. (So you don't lose the history from the Model 3.)

I'm not positive, but I think you might have to restart TeslaMate to trigger it looking for new vehicles.
 
Thanks. Is there a way where i can get updated list of all US super charger and charge amount to update to my database
There may be other ways to get a list of all supercharger sites, but the way I do it is to pull the supercharge.info database. I forget where I found out how to do this, but here's except of a python script which I use to pull it. This actually will give you the full worldwide database behind the supercharge.info site, but has region, country, state type of fields which you can use to filter what you want. It also is not just currently open, but what supercharge.info tracks as those in the 'permit' or 'construction' status.

from urllib.request import urlopen
import json
url = "https://supercharge.info/service/supercharge/allSites"
response = urlopen(url)
sc_data = json.loads(response.read())
 
There may be other ways to get a list of all supercharger sites, but the way I do it is to pull the supercharge.info database. I forget where I found out how to do this, but here's except of a python script which I use to pull it. This actually will give you the full worldwide database behind the supercharge.info site, but has region, country, state type of fields which you can use to filter what you want. It also is not just currently open, but what supercharge.info tracks as those in the 'permit' or 'construction' status.

from urllib.request import urlopen
import json
url = "https://supercharge.info/service/supercharge/allSites"
response = urlopen(url)
sc_data = json.loads(response.read())

Then, to generate the IMPORT commands necessary to import them into the database, add this code to the above:



import datetime
stamp = datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S')
for sc in sc_data:
if sc['address']['region'] != "North America":
continue
name = sc['name']
name = name.replace("'", "''")
latitude = sc['gps']['latitude']
longitude = sc['gps']['longitude']
print(f"INSERT INTO public.geofences (name, latitude, longitude, radius, inserted_at, updated_at, cost_per_unit, session_fee, billing_type) VALUES ('{name} Supercharger', {latitude}, {longitude}, 35, '{stamp}', '{stamp}', 0.50, NULL, 'per_kwh');")



Capture the output to a file, imports.txt, and then run this:

cat imports.txt | docker exec -i teslamate-database-1 psql -U PASSWORD

This is for linux, with the suggested docker-compose.yaml - adjust as necessary if you run teslamate in some other way.

NOTE: the database from supercharge.info has no prices, so the above hard-codes a price of 0.50. Also, since I'm in North America, it ignores any locations not in the North America region.

NOTE 2: This worked for me! I have no idea if your database is laid out differently and needs different syntax and/or fields.

NOTE 3: BACK UP YOUR DATABASE BEFORE MUCKING WITH IT!
 
Last edited:
I have noticed that some of the drives on the "Drives" dashboard fail to report a consumption or efficiency.
Here is an example - Most notably on this example are the drive in 2/25 at 10:16 AM and the drive on 2/24 at 11:17 AM.

It seems that the data is there (miles and kWh) but the consumption and efficiency fields are blank.

1709501165254.png


Has anyone else seen this kind of behavior?
Sometimes very short drives fail to report, but these are substantial drives.
 
I saw that, but did not feel like there was a consistency there.
ie: sometimes with the snowflake there are reported consumption and efficiency numbers, and other times there are not.

I also find it disappointing that I get snowflakes (also reduced regeneration symbols in the vehicle) with temperatures in the 50's.
This is Model Y AWD which uses the 4680 battery packs and I think they may be poorer performance with temperature in general.

Can you shed any light on how the 'snowflakes' work?
Is it the vehicle that produces a 'snowflake' which gets conveyed through the API, or does Grafana determine when a snowflake is warranted based on other data?
 
From GitHub:
Those values are now hidden if we know that they are wrong anyway because they could not be determined accurately, e.g. because the trip was too short or because of cold weather (reduced range).
The kWh values are based on the (rated/ideal) range difference per drive. E.g. to get the consumption per 100 km/mi:

rated_range_diff * rated_consumption / distance * 100


As the range is often reduced in cold weather at the beginning of a trip, the 'range_difference' gets distorted, because as the battery gets warmer, we seem to get more range. On many of my cold weather drives, the efficiency was significantly positive, which is only because the 'range' difference was smaller than it should have been.

As I see it, it makes no sense to display the efficiency figures under these conditions. We might as well display random values. However, as it is currently implemented, the values are still displayed for some drives. For example, if there is no more range reduction at the end of a drive. In this case, the drive was probably long enough to warm up the battery, making the difference less significant overall.
However, I don't think it makes sense to display consumption values that are demonstrably and knowingly incorrect. If you disagree, there is always the possibility to modify the existing dashboards.
Edit: and the snowflake comes from Tesla API's two SoC values:
it works like this: The Tesla-API provides a „state of charge“ (% SoC) level and a „usable SoC“ level which might be lower, e.g. when the battery is cold. The snowflake is shown when these two values differ, measured either at the start or at the end of the drive.
 
Last edited:
Thanks for the clarification. I will go to Github and read more about this.

My first thought would be that you want the actual miles driven divided by the actual energy used. If this is distorted by battery behavior, so be it. The reality is that you under performed (or over performed) but you care more about actual performance than ratings.

The miles are the miles (no ambiguity there). Perhaps you are saying that the API does not report actual energy used (and it must be inferred from from the SOC and ratings). If there is no direct way to obtain actual energy used, and this indirect method can be off (hence the snowflake), then I think I am starting to see the argument.

I am fairly new to this, and have a lot to learn. It might be nice if the consumption and efficiency were always shown on the dashboard, and when a 'snowflake' icon occurs, they could be greyed (or similar). Maybe I will explore altering my dashboard to try this.

Meanwhile I will read more about the snowflake and the conditions that cause it.

Thanks again !


edit: Upon additional review, I have observed this -

No snowflake:
  • Consumption and efficiency are always reported unless a drive is trivially short or zero distance, in which case the kWh, consumption, and efficiency fields are all blank. This makes perfect sense.
Has Snowflake:
  • trivially short or zero distance drives report kWh, consumption, and efficiency fields as blank just as with no snowflake.
  • Around half of snowflake drives report normally - kWh, consumption, and efficiencies are fully populated and look plausible
  • The other half of snowflake drives only report kWh, leaving consumption and efficiency blank.
So, it seems to be not as simple as a snowflake inhibiting consumption and efficiency reports.
Half the time snowflakes report normally and the other half they don't. This seems like an inconsistancy.
 
Last edited:
  • Like
Reactions: cwanja
Thanks for the clarification. I will go to Github and read more about this.

My first thought would be that you want the actual miles driven divided by the actual energy used. If this is distorted by battery behavior, so be it. The reality is that you under performed (or over performed) but you care more about actual performance than ratings.

The miles are the miles (no ambiguity there). Perhaps you are saying that the API does not report actual energy used (and it must be inferred from from the SOC and ratings). If there is no direct way to obtain actual energy used, and this indirect method can be off (hence the snowflake), then I think I am starting to see the argument.
The API doesn't publish energy used. This would be a moot point as the car is capable of regenerating energy so you may use energy going up a hill but get some of that when coming back down. A simpler method is just to see how much energy the battery has lost. Obviously with the provision that the car keeps some of that aside when the battery is cold.

edit: Upon additional review, I have observed this -

No snowflake:
  • Consumption and efficiency are always reported unless a drive is trivially short or zero distance, in which case the kWh, consumption, and efficiency fields are all blank. This makes perfect sense.
Has Snowflake:
  • trivially short or zero distance drives report kWh, consumption, and efficiency fields as blank just as with no snowflake.
  • Around half of snowflake drives report normally - kWh, consumption, and efficiencies are fully populated and look plausible
  • The other half of snowflake drives only report kWh, leaving consumption and efficiency blank.
So, it seems to be not as simple as a snowflake inhibiting consumption and efficiency reports.
Half the time snowflakes report normally and the other half they don't. This seems like an inconsistancy.
The snowflake only appears if the car reports a different between State of Charge and Usable State of Charge. This is primarily if the battery is cold.
 
  • Helpful
Reactions: cwanja
Hello,

i have recently traded in my Model to new Model Y. i see 2 cars tabs on teslamate homepage. Under Grafana its still showing my old car data not new one. I have signed out and signed in again in teslamate
How can i delete old car data and have only new car data. I dont want to reset entire teslamate as it will delete all the superchargers info

Please suggest, whether to delete entire data and install login again and import the super chargers data ?