Error: Invalid Tokens issue even after recreating 5 times

[neocorp]

Is there an existing issue for this?

• [X] I have searched the existing issues

What happened?

Recently I got the form to fill in the tokens for Tesla account and I've followed the guide to generate them.

However, even after creating the tokens for the 5th time, they are not accepted by teslamate. Screenshot added below.

I cannot use the teslamate dashboard now because of this. Would be great if you can help with a resolution.

Thank you!

Expected Behavior

Tokens should just be accepted.

Steps To Reproduce

1. Login to teslamate
2. Generate tokens with tesla_auth from @adriankumpf
3. Use tokens in teslamate UI which fails with Error: Invalid Tokens

Relevant log output

teslamate_1  | 2023-05-24 17:48:43.816 [info] GET /
teslamate_1  | 2023-05-24 17:48:43.819 [info] Sent 302 in 2ms
teslamate_1  | 2023-05-24 17:48:44.099 [info] GET /sign_in
teslamate_1  | 2023-05-24 17:48:44.105 [info] Sent 200 in 5ms
teslamate_1  | 2023-05-24 17:49:02.171 [notice]     :alarm_handler: {:set, {:"Elixir.TeslaMate.Api.unauthorized", :fuse_blown}}
teslamate_1  | 2023-05-24 17:49:02.171 [notice]     :alarm_handler: {:set, {TeslaMate.Vehicles.Vehicle_1_api_error, :fuse_blown}}
teslamate_1  | 2023-05-24 17:49:09.112 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (35.884 ms)
teslamate_1  | 2023-05-24 17:49:10.296 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (37.455 ms)
teslamate_1  | 2023-05-24 17:49:10.703 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (34.940 ms)
teslamate_1  | 2023-05-24 17:49:10.846 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (47.517 ms)
teslamate_1  | 2023-05-24 17:49:11.006 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (33.041 ms)
teslamate_1  | 2023-05-24 17:49:12.803 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (35.013 ms)
teslamate_1  | 2023-05-24 17:51:14.924 [info] GET /sign_in
teslamate_1  | 2023-05-24 17:51:14.932 [info] Sent 200 in 7ms
teslamate_1  | 2023-05-24 17:52:00.952 [info] GET /
teslamate_1  | 2023-05-24 17:52:00.956 [info] Sent 302 in 3ms
teslamate_1  | 2023-05-24 17:52:01.207 [info] GET /sign_in
teslamate_1  | 2023-05-24 17:52:01.216 [info] Sent 200 in 8ms
teslamate_1  | 2023-05-24 17:52:05.203 [info] GET /
teslamate_1  | 2023-05-24 17:52:05.207 [info] Sent 302 in 3ms
teslamate_1  | 2023-05-24 17:52:05.475 [info] GET /sign_in
teslamate_1  | 2023-05-24 17:52:05.479 [info] Sent 200 in 4ms
teslamate_1  | 2023-05-24 17:52:32.991 [warning] Cannot refresh access token: :not_signed_in
teslamate_1  | 2023-05-24 17:53:03.989 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (39.558 ms)
teslamate_1  | 2023-05-24 17:53:16.172 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (42.284 ms)

Screenshots

Additional data

No response

Type of installation

Docker

Version

v1.27.2

[XristMisyris]

I have the same issue.

POST https://auth.tesla.com/oauth2/v3/token -> 403.

I also tried creating a new droplet to get a new IP, but I get the same error.

[cwanja]

@neocorp what are you using for generate tokens? I saw a new version for tesla_auth. Wondering if Tesla updated their token process and invalidated all tokens. Which is not a TeslaMate issue. But a Tesla auth issue.

Unfortunately I am not home to test this theory.

[spacecosmos]

I'm experiencing the same issue. Gives the same error message:

[cmchauvin]

Same issue for me as well. Seems like logging stopped for me suddenly on May 18th and all subsequent attempts to login get the invalid token error.

[BabyYeggie]

My tokens seem to stopped working when a SIGTERM occurred on 5/22 at 23h01.

`2023-05-22 19:06:38.774 [info] Refreshing access token ... 2023-05-22 19:06:39.255 [info] POST https://auth.tesla.com/oauth2/v3/token -> 20 0 (479.284 ms) 2023-05-22 19:06:39.261 [info] Scheduling token refresh in 6 h 2023-05-22 23:01:02.240 [notice] SIGTERM received - shutting down

waiting for postgres at database:5432 2023-05-22 23:01:16.875 [info] Migrations already up 2023-05-22 23:01:24.565 [info] System Info: Erlang/OTP 24 (jit) 2023-05-22 23:01:24.565 [info] Version: 1.27.2 2023-05-22 23:01:25.750 [info] POST https://auth.tesla.com/oauth2/v3/token -> 200 (709.099 ms) 2023-05-22 23:01:25.750 [info] Refreshed api tokens 2023-05-22 23:01:25.762 [info] Scheduling token refresh in 6 h 2023-05-22 23:01:25.770 [info] Running TeslaMateWeb.Endpoint with cowboy 2.9.0 at :::4000 (http) 2023-05-22 23:01:25.774 [info] Access TeslaMateWeb.Endpoint at http://localhost 2023-05-22 23:01:26.069 [info] Starting logger for 'Model 3' 2023-05-22 23:01:26.172 [info] MQTT connection has been established 2023-05-22 23:01:26.366 car_id=1 [info] Start / :asleep 2023-05-23 05:01:25.764 [info] Refreshing access token ... 2023-05-23 05:01:33.770 [error] POST https://auth.tesla.com/oauth2/v3/token -> error: "non-existing domain" (8005.687 ms) 2023-05-23 05:01:33.771 [warning] Token refresh failed: %TeslaApi.Error{ env: nil, message: "non-existing domain", reason: :token_refresh `

[neocorp]

@neocorp what are you using for generate tokens? I saw a new version for tesla_auth. Wondering if Tesla updated their token process and invalidated all tokens. Which is not a TeslaMate issue. But a Tesla auth issue.

Unfortunately I am not home to test this theory.

I've used the latest version of tesla_auth to generate them and this is what I get... this might be Tesla related as they change their APIs time to time so hopefully we'll find out soon

[Snellman-vcc]

I have the same issue.

POST https://auth.tesla.com/oauth2/v3/token -> 403.

I also tried creating a new droplet to get a new IP, but I get the same error.

Same here. I'm hosting teslamate @ Digitalocean and also tried a new host with another IP adress. even in another country. But also get: teslamate_1 | 2023-05-25 11:19:48.724 [error] POST https://auth.tesla.com/oauth2/v3/token -> 403 (27.761 ms)

[prod1uk]

I had the same - couldn't get it working on DigitalOcean. Redeployed into GCP and its now working again.

[creamxsoup]

I can confirm too that my deployment on DO droplet stopped working since 22 May. Token has been refreshing itself with no problem for over 2 years, then suddenly the "Tokens are invalid" error came up with no way of getting through.

Deployed a new instance with restored database on my local machine, has been working fine since. Tesla's API authentication might have blocked DO's IP range as source.

[Carben-dev]

I had the same - couldn't get it working on DigitalOcean. Redeployed into GCP and its now working again.

Same problem with DigitalOcean, resolved after moving to GCP.

[BabyYeggie]

I had the same - couldn't get it working on DigitalOcean. Redeployed into GCP and its now working again.

Same problem with DigitalOcean, resolved after moving to GCP.

What settings are you using in GCP? My E2-micro instance of Postgres seems to be having problems with my 910MB database. Drives are split into small 15 second chunks.

[neocorp]

UPDATE: As some of you already made it working again with GCP. I've moved my setup over to GCP as well and it's all working again. Since this is clearly not a Teslamate issue, I'll close the issue if no objections.

@BabyYeggie I'm also on E2 micro and it's a real tiny instance. So to make sure it can take the load, I'd suggest you to create a swap on disk, that'll probably resolve your issue. You can do it like this:

sudo fallocate -l 1G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile
echo "/swapfile swap swap defaults 0 0" | sudo tee -a /etc/fstab && sudo reboot

[tomsteenbakkers]

Same problem here. Running also on Digital Ocean. Move it now to a local RaspberryPI.

Teslamate is running OK on a local RaspberryPI and at Transip.

Looks like a specific Digital Ocean problem.

[spacecosmos]

How do people move this to another instance and keeping all the data history? I have a RPI or I can use a Linode server.

[cwanja]

How do people move this to another instance and keeping all the data history? I have a RPI or I can use a Linode server.

Perform a backup and restore.

https://docs.teslamate.org/docs/maintenance/backup_restore

[mikeh2010]

So where are people hosting Teslamate? I've moved it twice and now I'm loosing the will to keep doing it...

[brad07x]

Can confirm the same issue, also hosted on a DigitalOcean droplet. As with others that have posted, the last data I have is from 2023-05-22. Plan to migrate to a local docker host.

Will be interesting to see if anyone discovers or infers why the Tesla API has restricted DigitalOcean's IP ranges.

[Niek]

Same issue with DigitalOcean, they definitely banned the whole IP range... It would be nice if proxy support (HTTP_PROXY and HTTPS_PROXY) was available, for those who don't want to move their install.

Edit: seem like this should work out of the box, but it doesn't: https://github.com/elixir-lang/elixir/blob/7711aa19198fb23d2ccb36b2b4eb9aeb291e8ed5/lib/mix/lib/mix/utils.ex#L739-L745

[devsaider]

i believe that the problem at hand is not related to Tesla itself, but rather with Akamai, the company responsible for their web security

[christopher-wong]

Same issue here - still unresolved as of 06/17/23

[Olen]

I suggest renaming this issue to something like "Teslamate does not work from DigitalOcean" and keeping it open for now - and possibly also add some info to the README. Even if it is not really a teslamate issue, it would be good to inform users that it is a known problem, and that there is no other workaround at the moment than moving teslamate to another hosting provider.

The procedure for moving was as "simple" as

1. Stop the teslamate container on DO-host (docker-compose stop teslamate)
2. Dump the database as described here: https://docs.teslamate.org/docs/maintenance/backup_restore/
3. Stop the teslamate database container on the DO-host (docker-compose stop teslamate_database)
4. Copy the entries from docker-compose.yaml on the DO-host to the new host
5. Copy the backup file to the new host
6. Start the teslamate database container (but not teslamate itself)
7. Restore the backup as described here: https://docs.teslamate.org/docs/maintenance/backup_restore/
8. Start the teslamate container
9. Change DNS-entries etc to point to the new IP
10. Log in on the new instance and add new tokens if needed
11. Ensure that grafana has access to the new database container (my setup use an external grafana instance)

(I can confirm that this fixed the problem for me too).

[olivierbrager]

I think the issue is not only with DigitalOcean. I'm in France and self hosting my server, doesn't work with Free too.

[mcmoyer]

I'm glad this issue was left open because I was also dealing with this same issue. Unfortunately, I went drastic and tried to recreate everything from scratch. Somehow my db backup was corrupted in the process. Once I saw this issue though, I had it up and running on GCP in no time flat. So, I would also suggest adding something about this to the README.

[thomasjungblut]

as for the DNS resolution errors, I've hit something similar when running a pihole on the same machine. You can set the DNS resolver for the container like that:

services:
  teslamate:
    dns:
      - 127.0.0.1 # if that's where your pihole is running
      - 8.8.8.8 # or any other DNS provider
      - 8.8.4.4

[JakobLichterfeld]

No teslamate issue, Tesla block big provider IPs as their API is not a public one. Move to private ip.

[Olen]

Could you please add some info in the frontpage about the blockings (and the errors you might see), so others looking for solutions can find it?