Tesla_apy.pi failing to install from fresh installation
TarkUK opened this issue · 45 comments
Describe the problem
Fresh install of Tesla USB
in the teslausb_setup_variable.conf i have the below entered
export TESLA_EMAIL=
export TESLA_PASSWORD=
export TESLA_REFRESH_TOKEN=
export TESLA_WAKE_MODE=stream
i copy the conf file over to the sd card and insert in to the PI and power up. looking at the logs tesla_apy.pi fails to install or run
Device
Raspberry Pi 4
OS Image
Prebuilt TeslaUSB image
Car Model
Model X
USB connection
Center console
Logs
Thu 26 Oct 14:03:26 BST 2023 : configure: Installing tesla_api.py
Thu 26 Oct 14:03:26 BST 2023 : Downloaded /root/bin/tesla_api.py ...
Thu 26 Oct 14:03:39 BST 2023 : configure: Failed to mount /mutable
Thu 26 Oct 14:05:31 BST 2023 : configure: tesla_api.py setup failed
if i ssh into the PI the mount is there
Additional information
No response
export TESLA_EMAIL=
export TESLA_PASSWORD=
These are no longer used.
export TESLA_REFRESH_TOKEN=
Did you actually put a refresh token there? Because the above isn't going to work. Please follow the documentation in the config file.
export TESLA_WAKE_MODE=stream
You don't need to specify this as it's the default.
Hello
i did put the refresh token there in addition to the other fields.
the reason i have tried the above is the Tesla Mod X is not staying awake
i have tried export TESLA_WAKE_MODE=stream, and have tried the same but with sentry
looking at the diagnostic logs its adds a line Not Keep Tesla Awake so i am a bit stuck hence reading the other post here that suggests adding Tesla Email / Passoword.
At the moment my car does not stay away hence not mounting the drive to record
event with only the token added with nothing else, tesla_apy.py still fails if that makes a difference
Something seems wrong with the refresh token then. Make sure to put it in quotes, and don't break it up into multiple lines. It should all be on one (long) line.
After TeslaUSB installs tesla_api.py it tries to list the vehicles on the account using the provided refresh token. If that fails, you will get the "configure: tesla_api.py setup failed" message.
You could try the following:
sudo -i
source bin/envsetup.sh
echo $TESLA_REFRESH_TOKEN
Verify that what it prints matches the refresh token you generated.
Then run bin/tesla_api.py list_vehicles and see if/how that fails.
will give that a shot now
with the quote are you specifing this " at the start and the end
just done a fresh install still get the error during setup however after all is done i have run the command you specified and it does output the details of my car
should i do another fresh install but the the quoation marks " start and end "
Single quotes are usually better e.g.
export TESLA_REFRESH_TOKEN='eyJhbGciOiJ........2F1dGgyL3YzL3Rva2'
(the real token will be much longer, probably over a thousand characters)
oh, and you shouldn't need to do a fresh install every time. You can just reboot and it should resume/retry installation.
so if i do
sudo -i
source bin/envsetup.sh
echo $TESLA_REFRESH_TOKEN
Then run bin/tesla_api.py list_vehicles
and the output i get is my car, am i correct in assuming that its working ?
Yes
ok will looks like its working will go and plug in to car and see how it goes
thank you for all your help, will let you know what happens
Plugged the Pi in to the car and waited for it to boot and the recording icon to appear on the screen which it did.
Went away for dinner, came back to the car with out the keys say 15min later and the Pi was powered off, got the keys walked to the car and it woke up went in to the car and the PI was booting up, Car reported 1 sentry event however when i go in to the app there is no event recorded
It's not clear to me whether you took the car to go to dinner or left the car at home while you went away.
In any case, TeslaUSB only uses the Tesla API to keep the car awake during archiving. When Sentry mode is enabled, the car itself should keep the USB ports powered, and therefore the Pi should be on as long as Sentry mode is on.
Hi Sorry
i should have said the car was parked at home with Sentry active
had dinner came back to car and the PI was powered off
What model year is your Model X?
2020
Hmm, I don't understand what's going on then. The car should keep the USB port powered while Sentry is on (because without power even a regular USB drive wouldn't work), and yours apparently doesn't. That is unrelated to using tesla_api.py to keep the car awake during archiving.
Defintly a very strange one unless something has been introduced in the latest tesla update to the car
so if i do
sudo -i source bin/envsetup.sh echo $TESLA_REFRESH_TOKEN Then run bin/tesla_api.py list_vehicles
and the output i get is my car, am i correct in assuming that its working ?
this is what I get :-( when I do the commands from top
root@teslausb:~# bin/tesla_api.py list_vehicles
Traceback (most recent call last):
File "/root/bin/tesla_api.py", line 596, in
main()
File "/root/bin/tesla_api.py", line 572, in main
_get_id()
File "/root/bin/tesla_api.py", line 185, in _get_id
result = list_vehicles()
File "/root/bin/tesla_api.py", line 269, in list_vehicles
return _execute_request(base_url, None, None, False)
File "/root/bin/tesla_api.py", line 78, in _execute_request
json_response = _rest_request(url, method, data)
File "/root/bin/tesla_api.py", line 105, in _rest_request
'Authorization': 'Bearer {}'.format(_get_api_token()),
File "/root/bin/tesla_api.py", line 163, in _get_api_token
tesla.refresh_token()
File "/usr/local/lib/python3.9/dist-packages/teslapy/init.py", line 249, in refresh_token
super(Tesla, self).refresh_token(token_url, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/requests_oauthlib/oauth2_session.py", line 452, in refresh_token
self.token = self._client.parse_request_body_response(r.text, scope=self.scope)
File "/usr/local/lib/python3.9/dist-packages/oauthlib/oauth2/rfc6749/clients/base.py", line 427, in parse_request_body_response
self.token = parse_token_response(body, scope=scope)
File "/usr/local/lib/python3.9/dist-packages/oauthlib/oauth2/rfc6749/parameters.py", line 441, in parse_token_response
validate_token_parameters(params)
File "/usr/local/lib/python3.9/dist-packages/oauthlib/oauth2/rfc6749/parameters.py", line 448, in validate_token_parameters
raise_from_error(params.get('error'), params)
File "/usr/local/lib/python3.9/dist-packages/oauthlib/oauth2/rfc6749/errors.py", line 399, in raise_from_error
raise cls(**kwargs)
oauthlib.oauth2.rfc6749.errors.LoginRequired: (login_required) Login required
did you add the token refresh in to the setup file
yes ,
export TESLA_REFRESH_TOKEN='eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp....snip.....emrhH-hyGw'
I use MFA on my account will this be a problem ?
and afterwards I started the bin/setup-teslausb , reboot to bring it into running config
on my line i used these quotation marks "
then did a fresh install
I saw a comment to use singe quotes but will give it a try
yes true but i used " before i saw that comment but it worked
same result :-(
im see this line in the diagnostics
Fri 27 Oct 13:18:47 BST 2023: Failed to contact car using Tesla API, retrying in 5s...
no other line after that as i suspect the PI looses power
Another update, so i have remove the Tesla_api comments in the setup file and moved to Tesla FI API,
ran the install and i can see the wake call within Tesla FI web portal so its working, however after about 5 min the Pi Powers off even with Sentry being turned on.
not sure if this normal behaviour or not
ran the install and i can see the wake call within Tesla FI web portal so its working, however after about 5 min the Pi Powers off even with Sentry being turned on.
not sure if this normal behaviour or not
No, when Sentry mode is on the car is supposed to keep the USB ports powered. As I mentioned before, that's independent of using tesla_api.py to keep the car awake during archiving.
Really don't know what the problem is, has to be a software issue with the tesla not sure if anyone else with a X is having the same
@TarkUK What firmware version is your Model X current running?
Also, for $ 'n giggles, try performing a soft-rest of your Model X (hold both scroll wheels until screen blacks out).
Finally, you are connecting your Pi like so: Tesla Glovebox USB-A -> USB-A to USB-C cable -> RPi USB-C port. No separate power connection.
As a side note (nothing to do with your issue), I've noticed my Model S on 2023.27.7 now goes to sleep after 12-15 minutes of park/idle, despite a 3rd-party service like TeslaFi polling away every second. The constant polling used to be enough to keep the car awake. I'm wondering if Tesla's made some changes recently, as they prepare for an official launch of their 3rd-party API support (which is currently under testing). With all that said, I'm going to have to make an update to the TeslaFi implementation to use the full 'wake_up' command to keep the car alive. I ran a private test version of that last night and it proved to be working well. Better even, since the car tends to go to sleep on the avg. 5 minutes after archive ends; before it could take as much as 30 minutes.
I am running 2023.32.9
I have tried soft reset make no difference and I have the pi directly connected to the car but I have also tried a backup battery pack and while that keeps the Pi alive the port in the car just stops over time
What is your car's state of charge?
Always above 20% currently st 87
Try using another USB-A to USB-C cable. I'm wondering if the port is shutting down from over-drawing, because you have one of those cheap/early USB-A to -C cable without the 56k pull-up resistor. Speculation, but worth a shot.
Must have tried 6 usb cables. Whichbone you recommend from amazon
Just ordered one comes Tuesday
Actually, before you go swapping cable, try using a simple USB Stick and see if that works without any issues (e.g. not powered off and captures recordings). If that fails too, then it definitely the car, which you should flag for service.
btw, this is the one I use: https://www.amazon.com/dp/B0BVQSC9PC?psc=1&ref=ppx_yo2ov_dt_b_product_details
Hi I'm now encountering a similar issue. TeslaUSB working fine however the car no longer says awake. When I ran this command:
bin/tesla_api.py list_vehicles, it returned the error:
Thu 08 Feb 08:26:30 CDT 2024: {
"error": "token expired (401)"
I went ahead and created a new Refresh Token and ensured I set it up correctly (with single quotes), then ran these commands:
sudo -i
source bin/envsetup.sh
echo $TESLA_REFRESH_TOKEN
The output correctly returned my new Refresh Token, however when I again run bin/tesla_api.py list_vehicles, I still get the "token expired (401)" error.
Has anyone resolved this?
@marcone the issue may be a bit more complicated. Opened a new bug ticket for Tesla API access failing with token refresh. Seems they changed the Tesla API.
bin/tesla_api.py list_vehicles, it returned the error:
This should work again for now. I did have to delete /mutable/cache.json and /mutable/tesla_api.json, and create a new refresh token. Something like this:
sudo -i
source bin/envsetup.sh
rm /mutable/cache.json /mutable/tesla_api.json
export TESLA_REFRESH_TOKEN='<new token goes here>'
/root/bin/tesla_api.py list_vehicles
bin/tesla_api.py list_vehicles, it returned the error:
This should work again for now. I did have to delete /mutable/cache.json and /mutable/tesla_api.json, and create a new refresh token. Something like this:
sudo -i source bin/envsetup.sh rm /mutable/cache.json /mutable/tesla_api.json export TESLA_REFRESH_TOKEN='<new token goes here>' /root/bin/tesla_api.py list_vehicles
I tried this and it fixed the issue for me. It's keeping the car awake, even after a reboot.
EDIT:
The fix is temporary. After a few reboots (or a few days) it stops working again. Error is the "token expired (401)" error.
I found a way to fix the Tesla API from failing to keep the car awake from the token expiring and not refreshing.
It's a hack, but it does the job.
in /root/bin/awake_start
find the function ping (line 11)
Change it from this:
function ping {
while true
do
if [[ ( -n "${TESLA_REFRESH_TOKEN:+x}" ) ]]
# Use Tesla API to keep car awake
then
if timeout 10 /root/bin/tesla_api.py streaming_ping
then
sleep 90
else
log "Failed to contact car using Tesla API, retrying in 5s..."
sleep 5
fi
fi
to this:
function ping {
while true
do
if [[ ( -n "${TESLA_REFRESH_TOKEN:+x}" ) ]]
# Use Tesla API to keep car awake
then
if timeout 10 /root/bin/tesla_api.py streaming_ping
then
sleep 90
else
log "Failed to contact car using Tesla API, retrying in 5s..."
sleep 5
log "Clearing cache.json and tesla_api.json..."
rm /mutable/cache.json /mutable/tesla_api.json
fi
fi
Now if the API call fails, it deletes the cached value - Tesla_API.py picks up on this and picks up a fresh token. Car will now stay awake and back up all the files.
Log output. Note the car stayed awake for 30+ minutes to finish the archiving (it's also charging):
Fri 9 Aug 11:51:10 PDT 2024: made all links for /tmp/snapshots/snap-000482
Fri 9 Aug 12:08:37 PDT 2024: Archive is reachable.
Fri 9 Aug 12:08:37 PDT 2024: Trying to set time...
Fri 9 Aug 12:08:37 PDT 2024: Time adjusted by 0.198245 seconds after 0.200000 seconds
Fri 9 Aug 12:08:37 PDT 2024: Starting background task to keep car awake.
Fri 9 Aug 12:08:38 PDT 2024: Failed to contact car using Tesla API, retrying in 5s...
Fri 9 Aug 12:08:43 PDT 2024: Clearing cache.json and tesla_api.json...
Fri 9 Aug 12:08:57 PDT 2024: taking snapshot of cam disk in /backingfiles/snapshots/snap-000483
Fri 9 Aug 12:08:59 PDT 2024: took snapshot
Fri 9 Aug 12:08:59 PDT 2024: comparing new snapshot with /backingfiles/snapshots/snap-000482/snap.bin
Fri 9 Aug 12:08:59 PDT 2024: making links for /tmp/snapshots/snap-000483, retargeted to /backingfiles/snapshots/snap-000483/mnt
Fri 9 Aug 12:09:22 PDT 2024: made all links for /tmp/snapshots/snap-000483
Fri 9 Aug 12:09:22 PDT 2024: low space, deleting /backingfiles/snapshots/snap-000439
Fri 9 Aug 12:09:24 PDT 2024: low space, deleting /backingfiles/snapshots/snap-000440
Fri 9 Aug 12:09:25 PDT 2024: Archiving...
Fri 9 Aug 12:09:25 PDT 2024: Ensuring cam archive is mounted...
Fri 9 Aug 12:09:25 PDT 2024: Mounting /mnt/archive...
Fri 9 Aug 12:09:27 PDT 2024: Mounted /mnt/archive.
Fri 9 Aug 12:09:27 PDT 2024: Ensured cam archive is mounted.
Fri 9 Aug 12:09:27 PDT 2024: Ensuring music archive is mounted...
Fri 9 Aug 12:09:27 PDT 2024: Mounting /mnt/musicarchive...
Fri 9 Aug 12:09:28 PDT 2024: Mounted /mnt/musicarchive.
Fri 9 Aug 12:09:28 PDT 2024: Ensured music archive is mounted.
Fri 9 Aug 12:09:28 PDT 2024: Checking saved folder count...
Fri 9 Aug 12:09:29 PDT 2024: There are 0 event folder(s) with 224 file(s) and 0 track mode file(s) to move. 2 short recording(s) will be skipped.
Fri 9 Aug 12:09:29 PDT 2024: Starting recording archiving
Fri 9 Aug 12:09:29 PDT 2024: Archiving 224 file(s) starting at Fri 9 Aug 12:09:29 PDT 2024
Fri 9 Aug 12:38:31 PDT 2024: Archiving completed successfully. Archived 224 files in 29m2s
Fri 9 Aug 12:38:31 PDT 2024: cleaning cam mount
Fri 9 Aug 12:38:31 PDT 2024: Ensuring cam file is mounted...
Fri 9 Aug 12:38:31 PDT 2024: Disconnecting usb from host...
Fri 9 Aug 12:38:32 PDT 2024: Running fsck on /backingfiles/cam_disk.bin...
Fri 9 Aug 12:38:32 PDT 2024: | fsck from util-linux 2.33.1
Fri 9 Aug 12:38:33 PDT 2024: | fsck.fat 4.1 (2017-01-24)
Fri 9 Aug 12:38:33 PDT 2024: | 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Fri 9 Aug 12:38:33 PDT 2024: | Automatically removing dirty bit.
Fri 9 Aug 12:38:33 PDT 2024: | Long filename fragment "2024-06-24_08" found outside a LFN sequence.
Fri 9 Aug 12:38:33 PDT 2024: | (Maybe the start bit is missing on the last fragment)
Fri 9 Aug 12:38:33 PDT 2024: | Not auto-correcting this.
Fri 9 Aug 12:38:33 PDT 2024: | Long filename fragment "2024-05-20_16" found outside a LFN sequence.
Fri 9 Aug 12:38:33 PDT 2024: | (Maybe the start bit is missing on the last fragment)
Fri 9 Aug 12:38:33 PDT 2024: | Not auto-correcting this.
Fri 9 Aug 12:38:33 PDT 2024: | Performing changes.
Fri 9 Aug 12:38:33 PDT 2024: | /dev/loop1p1: 1896 files, 1507592/2096607 clusters
Fri 9 Aug 12:38:33 PDT 2024: Finished fsck on /backingfiles/cam_disk.bin.
Fri 9 Aug 12:38:33 PDT 2024: Running fsck on /backingfiles/music_disk.bin...
Fri 9 Aug 12:38:33 PDT 2024: | fsck from util-linux 2.33.1
Fri 9 Aug 12:38:35 PDT 2024: | fsck.fat 4.1 (2017-01-24)
Fri 9 Aug 12:38:35 PDT 2024: | /dev/loop1p1: 3797 files, 905728/5261546 clusters
Fri 9 Aug 12:38:35 PDT 2024: Finished fsck on /backingfiles/music_disk.bin.
Fri 9 Aug 12:38:35 PDT 2024: Disconnected usb from host.
Fri 9 Aug 12:38:35 PDT 2024: Mounting /mnt/cam...
mount: /mnt/cam: failed to setup loop device for /backingfiles/cam_disk.bin.
Fri 9 Aug 12:38:36 PDT 2024: Failed to mount /mnt/cam.
Fri 9 Aug 12:38:36 PDT 2024: Sleeping before retry ...
Fri 9 Aug 12:38:37 PDT 2024: Retrying (1) 'ensure_mountpoint_is_mounted /mnt/cam' ...
Fri 9 Aug 12:38:37 PDT 2024: Mounting /mnt/cam...
Fri 9 Aug 12:38:37 PDT 2024: Mounted /mnt/cam.
Fri 9 Aug 12:38:37 PDT 2024: Ensured cam file is mounted.
Fri 9 Aug 12:38:38 PDT 2024: Trimming free space in /mnt/cam, which has 1493 extents
Fri 9 Aug 12:38:38 PDT 2024: Trim complete, image now has 1420 extents
Fri 9 Aug 12:38:38 PDT 2024: Unmounting /mnt/cam...
Fri 9 Aug 12:38:38 PDT 2024: Unmounted /mnt/cam.
Fri 9 Aug 12:38:38 PDT 2024: done cleaning cam mount
Fri 9 Aug 12:38:38 PDT 2024: Finished archiving.
Fri 9 Aug 12:38:38 PDT 2024: Copying music...
Fri 9 Aug 12:38:38 PDT 2024: Starting music sync...
Fri 9 Aug 12:38:38 PDT 2024: Ensuring music backing file is mounted...
Fri 9 Aug 12:38:38 PDT 2024: Disconnecting usb from host...
Fri 9 Aug 12:38:38 PDT 2024: Disconnected usb from host.
Fri 9 Aug 12:38:38 PDT 2024: Mounting /mnt/music...
mount: /mnt/music: failed to setup loop device for /backingfiles/music_disk.bin.
Fri 9 Aug 12:38:39 PDT 2024: Failed to mount /mnt/music.
Fri 9 Aug 12:38:39 PDT 2024: Sleeping before retry ...
Fri 9 Aug 12:38:40 PDT 2024: Retrying (1) 'ensure_mountpoint_is_mounted /mnt/music' ...
Fri 9 Aug 12:38:40 PDT 2024: Mounting /mnt/music...
mount: /mnt/music: failed to setup loop device for /backingfiles/music_disk.bin.
Fri 9 Aug 12:38:40 PDT 2024: Failed to mount /mnt/music.
Fri 9 Aug 12:38:40 PDT 2024: Sleeping before retry ...
Fri 9 Aug 12:38:41 PDT 2024: Retrying (2) 'ensure_mountpoint_is_mounted /mnt/music' ...
Fri 9 Aug 12:38:41 PDT 2024: Mounting /mnt/music...
Fri 9 Aug 12:38:41 PDT 2024: Mounted /mnt/music.
Fri 9 Aug 12:38:41 PDT 2024: Ensured music drive is mounted.
Fri 9 Aug 12:38:41 PDT 2024: Syncing music from archive...
Fri 9 Aug 12:39:08 PDT 2024: Copied 0 music file(s), deleted 0, skipped 3456 previously-copied files, and encountered 0 errors.
Fri 9 Aug 12:39:08 PDT 2024: Trimming free space in /mnt/music, which has 36 extents
Fri 9 Aug 12:39:08 PDT 2024: Trim complete, image now has 36 extents
Fri 9 Aug 12:39:08 PDT 2024: Unmounting /mnt/music...
Fri 9 Aug 12:39:08 PDT 2024: Unmounted /mnt/music.
Fri 9 Aug 12:39:08 PDT 2024: Finished copying music.
Fri 9 Aug 12:39:08 PDT 2024: unmounting /mnt/archive
Fri 9 Aug 12:39:08 PDT 2024: Truncating log...
Fri 9 Aug 12:39:08 PDT 2024: Stopping wake car background task.
Fri 9 Aug 12:39:08 PDT 2024: Connecting usb to host...
Fri 9 Aug 12:39:08 PDT 2024: Connected usb to host.
Fri 9 Aug 12:39:14 PDT 2024: Waiting for archive to be unreachable...