TeslaMate [megathread]

[goRt]

I've got a similar problem to Roy, but the opposite. I did a factory reset on the car, and TeslaMate recorded the location in Fremont. This ruins the "visited" map. Is there a way of removing this bogus location entry?

View attachment 624534

Backup the database, edit the SQL load statements in the backup and then restore the backup - only for the brave

 

[dakaix]

Basically because my current DB is messed up and it'd be easier to start again from Jan 21 than sort out all the spurious entries. I tried editing the YML. but the data is still there somehow. As was when I did a re-install. so must be missing something.

Idiot proof instructions on starting again welcome

Okay no worries, your best bet here then would be to wipe Teslamate and re-install... the two commands are below.

Beware: The command below will delete your all docker containers detailed in your "docker-compose.yml" (e.g. Teslamate, Teslamate Agile etc) . Do not run this if you hold any intention of recovering that data in future!

docker-compose rm -s

Reinstall & Upgrade:

docker-compose pull
docker-compose up

 

[dakaix]

I've got a similar problem to Roy, but the opposite. I did a factory reset on the car, and TeslaMate recorded the location in Fremont. This ruins the "visited" map. Is there a way of removing this bogus location entry?

That should be a relatively easy fix, as @goRt says it's simply a matter of removing the erroneous positions from the Postgres database. I assume you already know the date/time when these were recorded?

1. Backup your current Teslamate database, just in-case you make a mistake.
   

   docker-compose exec -T database pg_dump -U teslamate teslamate > ~/teslamate_db_backup.sql

2. Login to the Postgres container and open a CLI to interact with the database:
   

   docker-compose exec database psql teslamate teslamate

3. Run the command below, it will return all of the stored position data which is outside of a 13 degree longitudinal range (-11 to +2) - this should be anything outside British Isles.
   

   SELECT id,date,latitude,longitude FROM positions WHERE 'longitude' NOT BETWEEN -11 and 2;

4. This will return a table showing the number of matching records. You can sanity check this to confirm there isn't any unexpected data there (pop the lat/long into Google Maps and it'll confirm where that was!).
   
   If you want to delete one specific entry, you can run this command and pass in the appropriate "id" number where I have "xxxx":
   

   DELETE FROM positions WHERE 'id' = xxxx;

   Or if you're confident the results were correct, you can remove all of those entries in one go:
   

   DELETE FROM positions WHERE 'longitude' NOT BETWEEN -11 and 2;

5. Quit from the database by running:
   

   \q

 

[w3zly]

I've got a similar problem to Roy, but the opposite. I did a factory reset on the car, and TeslaMate recorded the location in Fremont. This ruins the "visited" map. Is there a way of removing this bogus location entry?

View attachment 624534

have you tried this: Manually fixing data | TeslaMate

 

[rotor2k]

have you tried this: Manually fixing data | TeslaMate

Thank you, that looks like just the ticket!

 

[rotor2k]

That should be a relatively easy fix, as @goRt says it's simply a matter of removing the erroneous positions from the Postgres database. I assume you already know the date/time when these were recorded?

1. Backup your current Teslamate database, just in-case you make a mistake.
   

   docker-compose exec -T database pg_dump -U teslamate teslamate > ~/teslamate_db_backup.sql

2. Login to the Postgres container and open a CLI to interact with the database:
   

   docker-compose exec database psql teslamate teslamate

3. Run the command below, it will return all of the stored position data which is outside of a 13 degree longitudinal range (-11 to +2) - this should be anything outside British Isles.
   

   SELECT id,date,latitude,longitude FROM positions WHERE 'longitude' NOT BETWEEN -11 and 2;

4. This will return a table showing the number of matching records. You can sanity check this to confirm there isn't any unexpected data there (pop the lat/long into Google Maps and it'll confirm where that was!).
   
   If you want to delete one specific entry, you can run this command and pass in the appropriate "id" number where I have "xxxx":
   

   DELETE FROM positions WHERE 'id' = xxxx;

   Or if you're confident the results were correct, you can remove all of those entries in one go:
   

   DELETE FROM positions WHERE 'longitude' NOT BETWEEN -11 and 2;

5. Quit from the database by running:
   

   \q

Absolutely amazing, all fixed now. Thank you so much for the incredibly detailed instructions!!

 

[CMc1]

Has anyone managed to get this iOS Widget setup with Teslamate yet? I've always wanted something elegant that's quick and easy to see the status of my Tesla, and this looks to be perfect!

Looks like it’s been done;

Got it working with Teslamate! I've pushed the Docker image but haven't pushed the code and documentation yet, will do that later today.

For those who want to try it before then, you can use this image Docker Hub. It requires an environment variable which should be the same as the one for teslamate; MQTT_HOST.

The endpoints this exposes is /cars for finding the car id you want to use for the widget, and /car/1 for the data for that car.

Example for docker-composer.yaml:

teslamate_mqtt_api:
image: thomaslandro/teslamate-mqtt-api:latest
container_name: teslamate_mqtt_api
restart: always
environment:
- MQTT_HOST=mosquitto
ports:
- 3040:3000

You should then be able to follow the instructions in TeslaData-Widget, and set the APIurl to YOUR_HOST:3040/car/1.

Source for the Teslamate MQTT API docker image: teslamate-mqtt-api.

This simply just exposes every MQTT datapoint from Teslamate into a json endpoint, but with a couple of tweaks for the widget.

 

[dakaix]

PSA: If you have your TeslaMate hosted on an external cloud server please check that you're not directly exposing your installation to the internet. The "Shodan.io" search engine crawls the internet looking for open services, and you can see from the results below that there are ~90 installs that are leaking their MQTT data (including vehicle location, door lock & sentry mode status) to anyone who fancies a look!

teslamate - Shodan Search

If you install TeslaMate on a Cloud Server (AWS, Google Cloud Platform, Digital Ocean etc) or are exposing your home install, please at minimum implement user authentication on your TeslaMate & Grafana containers and be careful not to expose other ports through the firewall. See the Github thread below as a starting point:
Feature request: add basic auth for Grafana (port 3000) access · Issue #77 · adriankumpf/teslamate

 

[spooksman]

I did indeed! In my case deleting the cron job and recreating it seemed to do the trick, although even to this day I get the odd day where I end up with multiple backup files for the same night on Google!

The story starts here: TeslaMate update

Thanks to both you and @DaveW this is now working again. No idea what was wrong, and initially deleting and recreating didn't fix the issue. However I deleted again and set the backup to GDrive to a later time (4 am) with

* 4 * * * /home/pi/tmbackup/tmbackup.sh

and it's all working.

We'll see how it goes...

 

[DaveW]

Thanks to both you and @DaveW this is now working again. No idea what was wrong, and initially deleting and recreating didn't fix the issue. However I deleted again and set the backup to GDrive to a later time (4 am) with

* 4 * * * /home/pi/tmbackup/tmbackup.sh

and it's all working.

We'll see how it goes...

Noticed mine had stopped working on my Digital Ocean install, recreated it and it’s fine now, very odd how cron just seems to stop working

 

[DaveW]

1.21.1 released:
Release v1.21.1 · adriankumpf/teslamate

 

[Blokie]

How do I update to the new version? I stopped and started teslamate docker but no change (still showing 1.21.0), so pulled updates (docker-compose pull) and stopped/started teslamate and still on 1.21.0.....

 

[Medved_77]

How do I update to the new version? I stopped and started teslamate docker but no change (still showing 1.21.0), so pulled updates (docker-compose pull) and stopped/started teslamate and still on 1.21.0.....

docker-compose down
docker-compose pull
docker-compose up -d
docker-compose restart

Not sure if the last step is actually necessary but it's more of a habit I've formed when doing any updates with docker.

 

[uncleiven]

I have tried to setup Teslamate following this guide...

TeslaMate Setup - Tesla Spot

Everything works fine but I can't browse to my teslamate domain (teslamate.xxxxx.com).
I get a 404 error.
I can ping it ok.

I can also browse to the grafana domain just fine.

Any ideas?

 

[uncleiven]

Fixed it, just deleted and fired up a new server and it's working fine

 

[Roy W.]

How do I update to the new version? I stopped and started teslamate docker but no change (still showing 1.21.0), so pulled updates (docker-compose pull) and stopped/started teslamate and still on 1.21.0.....

I suggest you bookmark the TeslaMate docs, I’ve found them very useful.

Upgrading to a new version | TeslaMate

 

[uncleiven]

Looking to add the iOS widget now I have got Teslamate working... would someone kindly be able to give me the laymen's steps please

 

[DaveW]

Had an interesting one today and I think I've found a possible issue with uploading to Google Drive which means setting things up slightly differently, I'll try and find some time tonight to test it and document it.

In short, I noticed my backup hadn't worked overnight again, I tried running manually and got the following:

"Failed to create file system for "gdriveOTeslaMate": couldn't find root directory ID: googleapi: Error 403: Rate Limit Exceeded, rateLimitExceeded"

Following some googling this morning, one possible explanation of this is that because we are using a shared/universal ID (we skip the step in the rclone setup to use a client ID) you sometimes get rate limited, depending on how much data is being uploaded on the shared/universal ID

I'll re-run through the setup of rclone later and document how to create the ID and see how it gets on, might go some way to explaining why these sometimes fail to upload.

 

[Medved_77]

Had an interesting one today and I think I've found a possible issue with uploading to Google Drive which means setting things up slightly differently, I'll try and find some time tonight to test it and document it.

In short, I noticed my backup hadn't worked overnight again, I tried running manually and got the following:

"Failed to create file system for "gdriveOTeslaMate": couldn't find root directory ID: googleapi: Error 403: Rate Limit Exceeded, rateLimitExceeded"

Following some googling this morning, one possible explanation of this is that because we are using a shared/universal ID (we skip the step in the rclone setup to use a client ID) you sometimes get rate limited, depending on how much data is being uploaded on the shared/universal ID

I'll re-run through the setup of rclone later and document how to create the ID and see how it gets on, might go some way to explaining why these sometimes fail to upload.

Any reason you're choosing to back up the TeslaMate data and not just a snapshot of the server? Wondered if the latter may be easier given the inbuilt tools that many of the cloud hosting providers have.

 

[DaveW]

Looking to add the iOS widget now I have got Teslamate working... would someone kindly be able to give me the laymen's steps please

Probably best in the other thread about this @uncleiven - but in short, add the details to your docker-compose.yml (adding your own custom API key), docker-compose up -d to get it to install

Install the scriptable app on your device, then navigate to iCloud storage, find the Scriptable folder, copy the .js and the tesla_data folder in there and then add the URL to the parameters.js file.

Give the instructions a follow and let us know if you get stuck.