Tesla API to keep your car awake

mboerma commented 4 years ago

This might be more of a remark or question than an issue. I have my car (An EU 100D Model S model year 2020) in Sentry mode and also have the "keep car awake" settings set for teslausb.

Maybe this is just new to the 2019.40.x firmware, but the USB ports are no longer powered. They only work when I turn on conditioning.

Q1) Do other people also notice this? Q2) Is this new behaviour or was that the case all along for Model S Tesla's? Q3) What does the "Keep Tesla awake" API call do? Q4) Is there any way I can make things work (again)? USB battery? Other settings?

Many thanks!

Radishworks commented 4 years ago

I went back and re-tested several physical USB keyboard, mice and even PlayStation Controllers, I'm sorry to say, I can't get it to work again. When I had it working with the keyboard, 5 min+, I must have been fooled by something else, I was using my phone's timer, maybe the T-App was keeping it alive? Sorry, my bad and my apologies. Anyhow, I did a little more research and there is a ton of posts and videos of mice being used in Teslas, but it appears, by reports that latest updates have disabled them. This is understandable for security reasons. Now I'm wondering if that Mouse Jigglier really works at all anymore, even though the article is from 2020.

Will keep looking for other ways to solve this issue.

marcone commented 4 years ago

It looks like USB keyboards don't work at all with the car. USB mice used to work apparently, but it looks like Tesla disabled that at some point (at least, I'm not seeing a mouse pointer appear onscreen when plugging in a USB mouse).

eddieyee commented 4 years ago

So when the TeslaCam folder becomes unavailable, the car essentially goes to sleep after two minutes, right? How about providing a throwaway TeslaCam folder for the vehicle while the real TeslaCam directory gets synchronized? Alternatively instead of using the sentry mode to keep the car awake, use camp mode?

Radishworks commented 4 years ago

@eddieyee - "... the car essentially goes to sleep after two minutes, right?" Yes, more importantly the USB power shuts down after 2 minutes of getting out of the car, hence shutting down the pi. Creating a throw away directory might help avoiding extra clips when the car is syncing, but it still won't solve the problem of the USB power turning off. RE: Camp mode, problem here is there is no API call that will put the car into Camp Mode, at least not one I've been able to find. General rule is if the Tesla App can't do it there isn't an REST API call for it. Regardless, even if there was a camp mode API call, it would still require your Tesla login password to be on the pi, security risk as mentioned above.

We are all looking for some simple elegant solution, if there is one.

Poncherelly commented 4 years ago

Not an elegant one but having a battery connected to the pi would get to extra time. I don't have my first TESLA yet but was hoping to check to see if there were any fuses powered only while charging. If there was, then I would plug in my dashcam battery pack. While charging (in my garage) the pi would stay powered and transfering. While driving, the battery pack wouldn't pull from the car and wouldn't affect range but the pi would still be plugged in to the data USB port for power if the pack goes dead.

The two unknowns at this time are:

1) There's is a fuse only powered when the car is charging 2) the pi can be powered by the battery pack and if the pack dies can gracefully move to USB power through the data Cable.

Again not ideal, but a thought.

marcone commented 4 years ago

@mboerma is this still a problem with current car firmware? If so, do the USB ports in your car turn on when you open the Tesla app on your phone?

mboerma commented 4 years ago

@marcone I haven't tried for some time. I barely drive the car these days and haven't update the software. I will do so this weekend and see what happens. Anything I need to look at? Settings?

marcone commented 4 years ago

No, just open the app and see if that powers up the USB ports.

mboerma commented 4 years ago

Open the app? There is an app? Or do you mean the Tesla app?

I just did a full update and will put it in the car and see if I can keep the connection alive.

marcone commented 4 years ago

Yes I meant the Tesla app. So basically:

plug something (e.g. the Pi, or a USB powered light) in to one of car's USB ports, so you can see when the port is powered
get out of the car,lock it, and wait for the USB ports to power down
open the Tesla app on your phone
check whether or not the USB ports are now powered

Radishworks commented 4 years ago

I ended up solving the keeping the car awake this way: I run my own cloud server software that the TeslaCam Pi dumps the videos to using rclone. When my cloud server code detects new videos getting copied from the TeslaCam Pi, the cloud server sends via the Tesla API a set_sentry_mode ON, wake_up, then set_sentry_mode OFF, (not sure I need the wake_up). This keeps happening once every minute until the cloud server stops detecting new videos arriving from the TeslaCam Pi. This seems to work keeping the car awake to let all the videos copy, and keeps Tesla login credentials off the TeslaCam. I also have several extra security checks to make sure the GPS location of the car is in the garage before Tesla API signals to mess with sentry mode. A more complex solution, but it seems to work well.

mboerma commented 4 years ago

Thanks, @Radishworks. That repetitive sending of calls might help. Opening the Tesla app (sending a wake_up message) did to work. I need to test it again further tomorrow. The car has been in covid mode, parked on the street for some time. I don't have the luxury of a garage and a fixed parking spot. Last year it did work until a newer firmware messed it up. Even with sentry mode on it turned of the USB port (probably because it could not find the Tesla folder to store the sentry videos on when TeslaUSB was uploading the clips).

Radishworks commented 4 years ago

@mboerma. As far as I can tell the wake_up API call does nothing. It seems to be the set_sentry_mode ON/OFF, like a "ping", that seems to reset the 2 minute sleep timer in the car.

The other thing being discussed is the Tesla App waking the car when opened. From what I can gather the App is doing something well outside the REST API to wake the car to prep it for a quick summon. Sorta makes sense since the App can summon the car those are some much higher risk than honking the horn. Not something a REST API really should be allowed to do.

marcone commented 4 years ago

@mboerma I've added some code to the tesla_api.py script to test a possible new method of keeping the car awake. Please give it a try: (assuming you've already configured tesla_api)

sudo -i
/root/bin/tesla_api.py streaming_ping

should hopefully turn on the USB ports for 2 minutes. To see if it can keep them on longer, do something like:

sudo -i
while true
do
  /root/bin/tesla_api.py streaming_ping
  sleep 90
done

and see if it is able to keep the car on for, say, 15 minutes, or however long you feel like testing. It seems to work for my 2018 S, but I'd be interesting to see if it works for you (and whoever else wants to try it)

mboerma commented 4 years ago

Just checking. By configuring the tesla_api you mean setting the values in the config file for export tesla_email= etc. ? I have been using those from the start.

Did a full upgrade with /root/bin/setup-teslausb upgrade.

(Did get an error at the end /tmp/setup-teslausb: line 237: /boot/cmdline.txt: Read-only file system Tried is again after doing

/root/bin/remountfs_rw

Still the same.)

When doing

sudo -i
/root/bin/tesla_api.py streaming_ping

I get

Traceback (most recent call last):
  File "/root/bin/tesla_api.py", line 547, in <module>
    main()
  File "/root/bin/tesla_api.py", line 527, in main
    function = globals()[args.function]
KeyError: 'streaming_ping'

(Running 2020.12.11.1 on the model year 2020 Model S.)

mboerma commented 4 years ago

@marcone Line 547 states something about the VIN number. I checked it in the config. It is correct.

mboerma commented 4 years ago

Ok. Reinstalled it and reconfigured. I'm using email and password for the API. That does not seem to work. I get:

Unable to perform Tesla API functions: no credentials or token.

Also setting the two tokens did not help.

marcone commented 4 years ago

Looks like I made a mistake somewhere. Setup is supposed to make tesla_api.py create the credentials file where it keeps the access token, but it doesn't. You can try specifying email/password on the command line (should only be needed once), like so:

/root/bin/tesla_api.py --email <tesla email> --password <tesla password> list_vehicles

mboerma commented 4 years ago

I got a couple of <Response [101]>

First time it became unresponsive. Now it seems to work. Sort of: To wake the vehicle up I have to use the Tesla app and turn on Sentry Mode. Previously this would help to wake it up but it would die after two minutes or something. Now if I use the ping loop it stays on. I do need to keep Sentry mode set to on in the Tesla app. Otherwise it dies.

mboerma commented 4 years ago

Oops. Something happened:

the archiveloop.log showed this:

Sun 17 May 20:58:18 CEST 2020: Unmounting /mnt/music...
umount: /mnt/music: target is busy.
Sun 17 May 20:58:18 CEST 2020: Failed to unmount /mnt/music, trying lazy unmount.
Sun 17 May 20:58:18 CEST 2020: lazily unmounted /mnt/music
Sun 17 May 20:58:18 CEST 2020: Finished copying music.
Sun 17 May 20:58:18 CEST 2020: unmounting /mnt/archive
Sun 17 May 20:58:18 CEST 2020: Connecting usb to host...
Sun 17 May 20:58:18 CEST 2020: Connected usb to host.
Sun 17 May 20:58:18 CEST 2020: Waiting for archive to be unreachable...
Sun 17 May 20:58:29 CEST 2020: Sleeping before retry...
Sun 17 May 20:58:30 CEST 2020: Retrying...
Sun 17 May 20:58:35 CEST 2020: Sleeping before retry...
Sun 17 May 20:58:36 CEST 2020: Retrying...

In the console where the ping loop was running I got all sorts of errors. The first being:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 159, in _new_conn
    (self._dns_host, self.port), self.timeout, **extra_kw)
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 57, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/lib/python3.7/socket.py", line 748, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Temporary failure in name resolution

This might be the reason:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='owner-api.teslamotors.com', port=443): Max retries exceeded with url: /api/1/vehicles/65237113565248638/wake_up (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0xb5ecb9b0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))

And then it continued with <Response [101]>. And I killed the loop.

mboerma commented 4 years ago

I now also tried without the streaming ping. It seems that when keeping the sentry mode on in the Tesla app the USB ports stay powered. This wasn't the case wit previous firmware. It keeps copying the new music I added to give it something to do.

marcone commented 4 years ago

OK, fixed the tesla_api setup issue. @mboerma to make sure I correctly understand your findings, can you confirm:

opening the Tesla app does not turn on the USB ports of your car?
running tesla_api.py stream_ping does not turn on the USB ports of your car either?
the only thing that turns on your car's USB ports is to turn on sentry mode?
with current car firmware, teslausb is able to keep the car's USB powered by turning on sentry mode?

mboerma commented 4 years ago

@marcone

opening the Tesla app does not turn on the USB ports of your car?

Correct. Just tried again. Open the Tesla app on my iPhone. I see "Waking Up". Pi0 doesn't start.

running tesla_api.py stream_ping does not turn on the USB ports of your car either?

Correct.

the only thing that turns on your car's USB ports is to turn on sentry mode?

Yes. It also did before. But after 2 minutes they turned off.

with current car firmware, teslausb is able to keep the car's USB powered by turning on sentry mode?

Correct. I tested it turning Sentry Mode on in the Tesla App and after 30 seconds the Pi0 was reachable and stayed on for more then 2 minutes. It only stopped when I turned Sentry Mode off in the app.

mboerma commented 4 years ago

@marcone But it seems teslausb doesn't turn on the sentry mode anymore, correct?

marcone commented 4 years ago

@marcone But it seems teslausb doesn't turn on the sentry mode anymore, correct?

Nothing should have changed in that regard. You can check the archiveloop log to see if it's trying to enable it. (it will say something like "Temporarily enabling Sentry Mode")

mboerma commented 4 years ago

@marcone No, the archiveloop.log doesn't mention that or anything with "sentry". This was a fresh install last weekend with the latest image with full update.

marcone commented 4 years ago

Does /root/bin/tesla_api.py exists?

mboerma commented 4 years ago

Yes.

marcone commented 4 years ago

Are there any other messages regarding tesla_api in the archiveloop log? Because archiveloop pretty much just checks whether /root/bin/tesla_api.py exists, and if so, it uses it to turn on Sentry if isn't already on, and to turn it back off afterwards.

mboerma commented 4 years ago

Sun 17 May 21:17:43 CEST 2020: Starting archiveloop...
Sun 17 May 21:17:44 CEST 2020: taking snapshot of cam disk in /backingfiles/snapshots/snap-000002
Sun 17 May 21:17:47 CEST 2020: took snapshot
Sun 17 May 21:17:47 CEST 2020: comparing new snapshot with /backingfiles/snapshots/snap-000001/snap.bin
Sun 17 May 21:17:47 CEST 2020: new snapshot is identical to previous one, discarding
Sun 17 May 21:17:48 CEST 2020: Running fsck on /backingfiles/cam_disk.bin...
Sun 17 May 21:17:49 CEST 2020: | fsck from util-linux 2.33.1
Sun 17 May 21:17:51 CEST 2020: | fsck.fat 4.1 (2017-01-24)
Sun 17 May 21:17:51 CEST 2020: | Long filename fragment "2020-05-20_08" found outside a LFN sequence.
Sun 17 May 21:17:51 CEST 2020: |   (Maybe the start bit is missing on the last fragment)
Sun 17 May 21:17:51 CEST 2020: |   Not auto-correcting this.
Sun 17 May 21:17:51 CEST 2020: | Long filename fragment "2020-05-17_21" found outside a LFN sequence.
Sun 17 May 21:17:51 CEST 2020: |   (Maybe the start bit is missing on the last fragment)
Sun 17 May 21:17:51 CEST 2020: |   Not auto-correcting this.
Sun 17 May 21:17:51 CEST 2020: | /dev/loop0p1: 291 files, 326195/1080824 clusters
Sun 17 May 21:17:52 CEST 2020: Finished fsck on /backingfiles/cam_disk.bin.
Sun 17 May 21:17:52 CEST 2020: Running fsck on /backingfiles/music_disk.bin...
Sun 17 May 21:17:52 CEST 2020: | fsck from util-linux 2.33.1
Sun 17 May 21:17:54 CEST 2020: | fsck.fat 4.1 (2017-01-24)
Sun 17 May 21:17:54 CEST 2020: | /dev/loop0p1: 70 files, 65058/2521967 clusters
Sun 17 May 21:17:54 CEST 2020: Finished fsck on /backingfiles/music_disk.bin.
Sun 17 May 21:17:59 CEST 2020: Connecting usb to host...
Sun 17 May 21:17:59 CEST 2020: Connected usb to host.
Sun 17 May 21:18:00 CEST 2020: Waiting for archive to be reachable...
Sun 17 May 22:15:48 CEST 2020: waiting up to 90 seconds for idle interval
Sun 17 May 22:15:52 CEST 2020: write in progress
Sun 17 May 22:15:53 CEST 2020: no longer writing, wrote 17199104
Sun 17 May 22:16:00 CEST 2020: no writes seen in the last 5 seconds
Sun 17 May 22:16:00 CEST 2020: taking snapshot of cam disk in /backingfiles/snapshots/snap-000002
Sun 17 May 22:16:03 CEST 2020: took snapshot
Sun 17 May 22:16:04 CEST 2020: comparing new snapshot with /backingfiles/snapshots/snap-000001/snap.bin
Sun 17 May 22:16:05 CEST 2020: making links for /tmp/snapshots/snap-000002, retargeted to /backingfiles/snapshots/snap-000002/mnt
Sun 17 May 22:16:09 CEST 2020: made all links for /tmp/snapshots/snap-000002
Sun 17 May 22:36:24 CEST 2020: Archive is reachable.
Sun 17 May 22:36:24 CEST 2020: Waiting for time to be set by ntpd...
Sun 17 May 22:36:50 CEST 2020: Time still not set, attempting to force it
Thu 21 May 13:49:45 CEST 2020: taking snapshot of cam disk in /backingfiles/snapshots/snap-000002
Thu 21 May 13:49:49 CEST 2020: took snapshot
Thu 21 May 13:49:51 CEST 2020: comparing new snapshot with /backingfiles/snapshots/snap-000001/snap.bin
Thu 21 May 13:49:51 CEST 2020: making links for /tmp/snapshots/snap-000002, retargeted to /backingfiles/snapshots/snap-000002/mnt
Thu 21 May 13:49:55 CEST 2020: made all links for /tmp/snapshots/snap-000002
Thu 21 May 13:49:55 CEST 2020: Disconnecting usb from host...
Thu 21 May 13:49:55 CEST 2020: Disconnected usb from host.
Thu 21 May 13:49:55 CEST 2020: Running fsck on /backingfiles/cam_disk.bin...
Thu 21 May 13:49:56 CEST 2020: | fsck from util-linux 2.33.1
Thu 21 May 13:49:57 CEST 2020: | fsck.fat 4.1 (2017-01-24)
Thu 21 May 13:49:57 CEST 2020: | 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Thu 21 May 13:49:57 CEST 2020: |  Automatically removing dirty bit.
Thu 21 May 13:49:57 CEST 2020: | Long filename fragment "2020-05-20_08" found outside a LFN sequence.
Thu 21 May 13:49:57 CEST 2020: |   (Maybe the start bit is missing on the last fragment)
Thu 21 May 13:49:57 CEST 2020: |   Not auto-correcting this.
Thu 21 May 13:49:57 CEST 2020: | Long filename fragment "2020-05-17_21" found outside a LFN sequence.
Thu 21 May 13:49:57 CEST 2020: |   (Maybe the start bit is missing on the last fragment)
Thu 21 May 13:49:57 CEST 2020: |   Not auto-correcting this.
Thu 21 May 13:49:57 CEST 2020: | Performing changes.
Thu 21 May 13:49:57 CEST 2020: | /dev/loop1p1: 291 files, 326495/1080824 clusters
Thu 21 May 13:49:57 CEST 2020: Finished fsck on /backingfiles/cam_disk.bin.
Thu 21 May 13:49:57 CEST 2020: Running fsck on /backingfiles/music_disk.bin...
Thu 21 May 13:49:57 CEST 2020: | fsck from util-linux 2.33.1
Thu 21 May 13:49:59 CEST 2020: | fsck.fat 4.1 (2017-01-24)
Thu 21 May 13:49:59 CEST 2020: | /dev/loop1p1: 70 files, 65058/2521967 clusters
Thu 21 May 13:49:59 CEST 2020: Finished fsck on /backingfiles/music_disk.bin.
Thu 21 May 13:49:59 CEST 2020: Archiving...
Thu 21 May 13:49:59 CEST 2020: Ensuring cam archive is mounted...
Thu 21 May 13:49:59 CEST 2020: Mounting /mnt/archive...
Thu 21 May 13:50:02 CEST 2020: Mounted /mnt/archive.
Thu 21 May 13:50:02 CEST 2020: Ensured cam archive is mounted.
Thu 21 May 13:50:02 CEST 2020: Ensuring music archive is mounted...
Thu 21 May 13:50:02 CEST 2020: Mounting /mnt/musicarchive...
Thu 21 May 13:50:04 CEST 2020: Mounted /mnt/musicarchive.
Thu 21 May 13:50:04 CEST 2020: Ensured music archive is mounted.
Thu 21 May 13:50:04 CEST 2020: Checking saved folder count...
Thu 21 May 13:50:04 CEST 2020: Ensuring cam file is mounted...
Thu 21 May 13:50:04 CEST 2020: Mounting /mnt/cam...
Thu 21 May 13:50:04 CEST 2020: Mounted /mnt/cam.
Thu 21 May 13:50:04 CEST 2020: Ensured cam file is mounted.
Thu 21 May 13:50:05 CEST 2020: There are 1 event folder(s) with 43 file(s) to move.
Thu 21 May 13:50:05 CEST 2020: Starting recording archiving: 1 event folder(s) with 43 file(s)
Thu 21 May 13:50:06 CEST 2020: Sending IFTTT message for moved files.
Thu 21 May 13:50:24 CEST 2020: Moving clips to archive...
Thu 21 May 13:50:25 CEST 2020: Creating output directory 'SavedClips/2020-05-21_10-33-54'
Thu 21 May 13:50:46 CEST 2020: Moving 'SavedClips/2020-05-21_10-33-54/2020-05-21_10-22-33-back.mp4'

This is the Archiveloop log when I arrived today and it connected to the wifi. After this it died. Sentry Mode is set to off.

Not sure why this formatting is so bad. Sorry.

marcone commented 4 years ago

(for large block quotes, you'll want to use triple-backtick instead of single-backtick)

Can you also check whether /root/bin/tesla_api.py is executable, i.e. what does ls -l /root/bin/tesla_api.py say? Because that's actually what archiveloop checks: whether it exists and is executable:

    log "Starting recording archiving: $DIR_COUNT event folder(s) with $FILE_COUNT file(s)"

    /root/bin/send-push-message "TeslaUSB:" "Archiving $DIR_COUNT event folder(s) with $FILE_COUNT file(s) starting at $(date)"

    # Ensure Sentry Mode is enabled before archiving
    declare is_sentry_mode_enabled
    if [ -x /root/bin/tesla_api.py ]
    then
        is_sentry_mode_enabled=$(/root/bin/tesla_api.py is_sentry_mode_enabled | tr '[:upper:]' '[:lower:]')
        if [ "false" = "${is_sentry_mode_enabled}" ]
        then
            log "Temporarily enabling Sentry Mode to power the RPi while archive job completes..."
            /root/bin/tesla_api.py enable_sentry_mode &>> ${LOG_FILE}
        fi
    fi

Also, try running /root/bin/tesla_api.py is_sentry_mode_enabled manually and see what it says.

mboerma commented 4 years ago

Can you also check whether /root/bin/tesla_api.py is executable, i.e. what does ls -l /root/bin/tesla_api.py say?

-rwxr-xr-x 1 root root 20644 May 17 12:17 /root/bin/tesla_api.py

Also, try running /root/bin/tesla_api.py is_sentry_mode_enabled manually and see what it says.

Thu 21 May 18:04:15 CEST 2020: {
  "response": null,
  "error": "https://mothership-ownerapi.prd.sjc.vnet:5678/vehicles/<REMOVED>/user_command/vehicle_state?slow_query_time=15 => operation_timedout with 10s timeout for txid `<REMOVED>`",
  "error_description": ""
}

I removed two parts. Not sure if they are to be shared.

(It is enabled by the way, manually, otherwise it would die.)

marcone commented 4 years ago

Looks like there's some problem on Tesla's side. You can run /root/bin/tesla_api.py --debug is_sentry_mode_enabled to maybe get some more info, but it looks like tesla_api.py is able to contact the tesla API service and make the request, but then the tesla server has an issue contacting some other service and reports that error back to tesla_api.py.

mboerma commented 4 years ago

That comes back with this:

Thu 21 May 20:05:15 CEST 2020: Loading mutable data from disk...
Thu 21 May 20:05:15 CEST 2020: Calling is_sentry_mode_enabled()...
Thu 21 May 20:05:15 CEST 2020: Attempting to wake up Vehicle (ID:<REMOVED>)
Thu 21 May 20:05:15 CEST 2020: Sending POST Request: https://owner-api.teslamotors.com/api/1/vehicles/<REMOVED>/wake_up; Data: {}
Thu 21 May 20:05:24 CEST 2020: {
  "response": {
    "id": <REMOVED>,
    "user_id": <REMOVED>,
    "vehicle_id": <REMOVED>,
    "vin": "<REMOVED>",
    "display_name": "<REMOVED>",
    "option_codes": "AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0",
    "color": null,
    "tokens": [
      "<REMOVED>",
      "<REMOVED>"
    ],
    "state": "online",
    "in_service": false,
    "id_s": "<REMOVED>",
    "calendar_enabled": true,
    "api_version": 7,
    "backseat_token": null,
    "backseat_token_updated_at": null
  }
}
Thu 21 May 20:05:24 CEST 2020: Vehicle (ID:<REMOVED>) is Online
Thu 21 May 20:05:24 CEST 2020: Sending GET Request: https://owner-api.teslamotors.com/api/1/vehicles/<REMOVED>/data_request/vehicle_state; Data: {}
Thu 21 May 20:05:36 CEST 2020: {
  "response": null,
  "error": "https://mothership-ownerapi.prd.sjc.vnet:5678/vehicles/<REMOVED>/user_command/vehicle_state?slow_query_time=15 => operation_timedout with 10s timeout for txid `<REMOVED>`",
  "error_description": ""
}
Thu 21 May 20:05:36 CEST 2020: {
  "response": null,
  "error": "https://mothership-ownerapi.prd.sjc.vnet:5678/vehicles/<REMOVED>/user_command/vehicle_state?slow_query_time=15 => operation_timedout with 10s timeout for txid `<REMOVED>`",
  "error_description": ""
}

marcone commented 4 years ago

that shows tesla_api.py successfully communicating with Tesla to "wake up" the car (at that point it's not really "on", but it's "online" and ready to be further interacted with), but then after that it fails to get the vehicle state due to what looks like some kind of backend error.

mboerma commented 4 years ago

Just tried it again now. Now it finished without error and ends with:

True

mboerma commented 4 years ago

@marcone I have been testing this now for the last week. The big improvement is that even with the latest firmware, 2020.16.2.1 e99c70ff, the Sentry mode is turned on by teslausb and the Pi0 keeps working. (The USB ports stay powered.). On the other hand Sentry mode is not turned off when copying is done. This is the last part of the archiveloop.log I get every time. Any idea?

Wed 27 May 16:02:42 CEST 2020: no longer writing, wrote 65372160
Wed 27 May 16:02:49 CEST 2020: no writes seen in the last 5 seconds
Wed 27 May 16:02:49 CEST 2020: taking snapshot of cam disk in /backingfiles/snapshots/snap-000002
Wed 27 May 16:02:55 CEST 2020: took snapshot
Wed 27 May 16:02:56 CEST 2020: comparing new snapshot with /backingfiles/snapshots/snap-000001/snap.bin
Wed 27 May 16:02:57 CEST 2020: making links for /tmp/snapshots/snap-000002, retargeted to /backingfiles/snapshots/snap-000002/mnt
Wed 27 May 16:03:05 CEST 2020: made all links for /tmp/snapshots/snap-000002

marcone commented 4 years ago

Can you post the entire log, or at least more of it? After the copying is done, there should be a bit about it trying to disable (or not) Sentry mode again.

mboerma commented 4 years ago

It was too long to post, but no mention of Sentry mode being set on of off.

I simply give up. And let it go for some time. It works sometimes. And sometimes it doesn't. I've tried many, many different setups (software and hardware). I'm willing to stay a guinea pig if you think of something new, @marcone. Thanks for all the effort and time.

marcone commented 4 years ago

If there's no mention of Sentry on or off, and given that you have it correctly configured to try and use Sentry mode to keep the car awake (since it works sometimes) then that would seem to indicate that when it doesn't work, it's due to errors encountered when using the Tesla API. I'll improve the logging for that so that at least it's clear that Sentry is not being turned on due to errors.

mboerma commented 4 years ago

Nope. No mention. And it works sometimes and sometimes it doesn't.

RichieB2B commented 4 years ago

I'm having the same issue. Model S75D from 2018 (MCU2) with firmware 2020.16.2.1. Sentry mode is not keeping TeslaUSB awake. Nor does TeslaFi polling the car.

I tried several API endpoints but was now able to find any that boots TeslaUSB.

I find this all a bit strange: during Sentry mode data is supposed to be written to the USB drive, right? So how can it power down the USB ports? Makes no sense to me..

root@teslausb:/mutable# /root/bin/tesla_api.py --debug is_sentry_mode_enabled
Thu 11 Jun 23:31:37 CEST 2020: Loading mutable data from disk...
Thu 11 Jun 23:31:37 CEST 2020: Calling is_sentry_mode_enabled()...
Thu 11 Jun 23:31:37 CEST 2020: Attempting to wake up Vehicle (ID:<removed>)
Thu 11 Jun 23:31:37 CEST 2020: Sending POST Request: https://owner-api.teslamotors.com/api/1/vehicles/<removed>/wake_up; Data: {}
Thu 11 Jun 23:31:47 CEST 2020: {
  "response": {
    "id": <removed>,
    "user_id": <removed>,
    "vehicle_id": <removed>,
    "vin": "<removed>",
    "display_name": "Fedora",
    "option_codes": "AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0",
    "color": null,
    "tokens": [
      "<removed>",
      "<removed>"
    ],
    "state": "online",
    "in_service": false,
    "id_s": "<removed>",
    "calendar_enabled": true,
    "api_version": 8,
    "backseat_token": null,
    "backseat_token_updated_at": null
  }
}
Thu 11 Jun 23:31:47 CEST 2020: Vehicle (ID:<removed>) is Online
Thu 11 Jun 23:31:47 CEST 2020: Sending GET Request: https://owner-api.teslamotors.com/api/1/vehicles/<removed>/data_request/vehicle_state; Data: {}
Thu 11 Jun 23:31:57 CEST 2020: {
  "response": null,
  "error": "vehicle unavailable: {:error=>\"{\\\"error\\\": \\\"timeout\\\"}\"}",
  "error_description": ""
}
Thu 11 Jun 23:31:57 CEST 2020: {
  "response": null,
  "error": "vehicle unavailable: {:error=>\"{\\\"error\\\": \\\"timeout\\\"}\"}",
  "error_description": ""
}

RichieB2B commented 4 years ago

This is interesting! Minutes after I wrote the above I received a firmware update. I am now on 2020.20.12 and the polling of TeslaFi did keep TeslaUSB running all night (Sentry mode was off). I turned on TeslaFi sleep mode (stops the polling) and the car went to sleep (TeslaUSB down). I turned on Sentry Mode using the Tesla app and TeslaUSB stays up!

So it must have been a fluke with firmware 2020.16.2.1 and certain cars.

@mboerma Do you see the same thing?

mboerma commented 4 years ago

@RichieB2B The timeout error is something on the Tesla backend. I came and went with the same firmware. I'm still on 2020.16.2.1 which was an improvement in some ways. But it is just very inconsistent in behaviour. I've tried all the tricks even the one Tesla engineers took me through while sitting in the car and deep rebooting the whole thing.

RichieB2B commented 4 years ago

I just realised that by the time the 2020.20.12 was done installing the TeslaUSB was done archiving. So it presented itself to the car again as USB storage. This could be the reason it stayed awake all night. Might not be fixed in 2020.20.12 after all. I'll report back tonight when some fresh sentry clips need to be archived..

RichieB2B commented 4 years ago

After coming home TeslaUSB enabled Sentry mode and it stayed up for 11 minutes. The archiving was done in 9 minutes (as reported via pushover). TeslaUSB disabled Sentry mode and the USB power was cut 2 minutes later. Seems to work ok for me now.

mboerma commented 4 years ago

Sounds good. It worked like this for a couple of times. But then it went back to the behavior of the 2019 firmwares.

RichieB2B commented 4 years ago

It looks like the problem is back today: Pi0 only stays awake for 2 minutes after returning home. :-(

miles267 commented 4 years ago

Just found this thread. Is there a fix for this yet? Am noticing my car is going to sleep before attempting to sync at home.

RichieB2B commented 4 years ago

Recent firmware fixed this for me. With 2020.32 and up Sentry mode has kept TeslaUSB awake like it should.

marcone / teslausb

Tesla API to keep your car awake #384