-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
API scopes?
Team,
Looking at the Tesla APIs I noticed different authorization scopes.
This allows you to define what an external integration is allowed/not-allowed to do. Summery of scopes:
- user_data: user contact, profile, referral info
- vehicle_device_data: vehicle data, location, service info etc.
- vehicle_cmds: add/remove driver, access camera, unlock, wakeup, remote start
- vehicle_charging_cmds:start/stop charging
From a security perspective I only want an application to have READ access, not being able to unlock, start, etc.
Question: is there a way to setup teslamate in a way where it only uses the vehicle_device_data scope?
Team,
Looking at the Tesla APIs I noticed different authorization scopes.
This allows you to define what an external integration is allowed/not-allowed to do. Summery of scopes:
- user_data: user contact, profile, referral info
- vehicle_device_data: vehicle data, location, service info etc.
- vehicle_cmds: add/remove driver, access camera, unlock, wakeup, remote start
- vehicle_charging_cmds:start/stop charging
From a security perspective I only want an application to have READ access, not being able to unlock, start, etc.
Question: is there a way to setup teslamate in a way where it only uses the vehicle_device_data scope?
No, Teslamate doesn't currently use the public APIs that have scopes.
spooksman
Member
Did this work for you?so now.. revert back to the original code in .yaml
will it be kept same for any further updates after move to teslamateorg?
For current products control is gated by the key type. Teslamate can use the read-only key. Sadly (and for no good reason) most products want read-write access.
As an example Teslafi will accept either key and if you provide a read-write key it will provide some control features.
Just to close this out - with much troubleshooting help from init6, we were unable to resolve using software methods.
A fresh install on my 3B+ would work but once the backup was restored it would stop again.
I used a pi CM4 lite I had available to set up a new install and the backup worked successfully and all smooth sailing again.
Some sort of a hardware fault that was only presenting once my historical data was introduced (regardless of storage medium).
pulling image shows I already have an updated image.
Code:
Status: Image is up to date for teslamate/teslamate:latest
docker.io/teslamate/teslamate:latestfollowing is what worked for me, it is connected to the car, but I guess I am lost the data since my car update (2 weeks ago until today).
use the following command to pull the different branch
Code:
docker pull teslamate/teslamate:edge
docker compose up -dMy incomplete understanding is that all of the tools (e.g. tesla_auth) generate streaming only keys and that you have to provide your credentials to get a key to send commands. My original post was "wrong" because products use either your credentials (which they claim to keep safe or discard) or a key.
goRt
Active Member
Currently there's only a single key which provides read and write capabilities, telsamate chooses not to use them
I write my own automations using the tesla_auth generated key and refreshing with my own routine
goRt
Active Member
Honestly, just wondering what kind of automation can be done other than just pulling stats and watch them on the dashboards.
goRt
Active Member
Loads of documentation here
My (very) bad. This is really a shame but at least if your key is exposed it's not like your Tesla account is exposed. Still pranks like opening the hatch, unlocking the doors, interrupting charging or running the HVAC at some extreme set-point are annoying at best.
I have been running teslamate since probably Feb 2023, and it appeared to capture all the data real well. I run it on a synology using docker, and I checked today and it auto-updates and is at the current version.
The issue I'm facing is that on 11/11/23 I took the car for it's furthest drive ever, nearly 600 miles round trip, charging 4 times enroute, which were actually my only times I've used a supercharger. When I went to look at the data, the drives don't show up, the charging sessions don't show up, and the "visited" dashboard in teslamate doesn't have that long drive depicted anywhere. Is this data lost forever? So far other than the install on docker, which was easy by following a guide, is the only experience I have with digging into it. I found some threads on terminating drives, and such, but the command don't seem to be based on my synology docker type install. Wondering if anyone can give me insight into what the chances are that my data can be displayable from that long trip, or some commands I may try to figure out the drive ID numbers or whatever to see if they even exist in the db.
Anything is appreciated.
The issue I'm facing is that on 11/11/23 I took the car for it's furthest drive ever, nearly 600 miles round trip, charging 4 times enroute, which were actually my only times I've used a supercharger. When I went to look at the data, the drives don't show up, the charging sessions don't show up, and the "visited" dashboard in teslamate doesn't have that long drive depicted anywhere. Is this data lost forever? So far other than the install on docker, which was easy by following a guide, is the only experience I have with digging into it. I found some threads on terminating drives, and such, but the command don't seem to be based on my synology docker type install. Wondering if anyone can give me insight into what the chances are that my data can be displayable from that long trip, or some commands I may try to figure out the drive ID numbers or whatever to see if they even exist in the db.
Anything is appreciated.
is the only drive missing is the 11/11?
is the data is pulled and saved as of 11/21?
Similar threads
