Vampire drain/losses are high again

[insaneoctane]

The link he gave said they were “ a community of developers who are reverse engineering Tesla’s API”. And “Is this API official? Absolutely not. These endpoints are the result of reverse engineering Tesla’s mobile applications and vehicle software”. So yes I put this in the category of third party crap, not official Tesla software, and certainly not something being used as Tesla intended for the car to manage itself.

And @insaneoctane, you said you’re using this to run a script that tells you if the car is awake or asleep. This sounds to me like it’s communicating with the car even though you say it’s not.

This is actually getting exhausting! No it's not communicating with the car. The API endpoint is "https://owner-api.teslamotors.com/api/1/vehicles" and lists my vehicles FROM TESLA and their state. It doesn't ping the car. It does, however, let me see if the car is online or asleep.

 

[SoManyM3s]

So then for a lot of people, they're losing more miles per day then they're driving, if this is a normal drain. You will absolutely no savings if that's the case, maybe even more expensive then a gas car. I'll see what happens when I get a new car. I was hoping on low vampire drain since I'll only have 120v for the next year

 

[bedoig]

This is actually getting exhausting! No it's not communicating with the car. The API endpoint is "https://owner-api.teslamotors.com/api/1/vehicles" and lists my vehicles FROM TESLA and their state. It doesn't ping the car. It does, however, let me see if the car is online or asleep.

I don't think he understands what an API is. You don't expose anything you don't meant to have interacted with.

 

[darth_vad3r]

This is actually getting exhausting! No it's not communicating with the car. The API endpoint is "https://owner-api.teslamotors.com/api/1/vehicles" and lists my vehicles FROM TESLA and their state. It doesn't ping the car. It does, however, let me see if the car is online or asleep.

Do we know for certain that Tesla’s servers don’t contact the car for an update once the API has received a request? I don’t mean to suggest it does this for any request, just that the fact “something” has queried server may have a side effect on the server then later deciding to contact the car. How often do you run your script?

Unless you park in a Faraday cage, you can’t stop Tesla from talking to your car.

 

[insaneoctane]

Do we know for certain that Tesla’s servers don’t contact the car for an update once the API has received a request?

Yes. They do not.

 

[darth_vad3r]

Yes. They do not.

How do you know?

You also didn’t say how often you are running the script.

 

[darth_vad3r]

Yes. They do not.

How do you know?

You also didn’t say how often you are running the script.

Still curious about this. Looking for a technical answer hopefully involving some time stamps in the returned JSON that show that some car data stays ‘stale’ no matter how frequently you poll the server. Does “vehicle_state” response time stamp update each time or no? It appears to be in Unix time plus 3 digits for milliseconds.

 

[insaneoctane]

Still curious about this. Looking for a technical answer hopefully involving some time stamps in the returned JSON that show that some car data stays ‘stale’ no matter how frequently you poll the server. Does “vehicle_state” response time stamp update each time or no? It appears to be in Unix time plus 3 digits for milliseconds.

Feel free to read up on the API threads on this forum. There are many. The Tesla servers do not show 'stale', sorry. A simple test that I've personally performed many times is to ping the Tesla server when your car is sitting in your garage and asleep and see what it does. I've found that Tesla's servers correctly identity my vehicle as asleep (sometimes it's 'offline') and it doesn't ever wake it doing so. By the way, my algorithms for checking the car status have never impacted the range in the 14 months I've been doing it. I've only noticed the high range loss at work in the most recent firmwares, hence this thread. Maybe now we can put to bed the assumption that asking Tesla's servers if your car is awake is the culprit here?

FWIW I just got the new 20.4.1 firmware, so I'll see if it makes any difference this week.

 

[AltLogic]

Left my car outside for 8 days. Arrived in the morning when it was cool. Closed the app on my phone. Opened the app on the eighth day from across the country during the cool morning. I lost 2 miles of range. Arrived at my car in the hot afternoon. It was 1 mile higher than when I left it 8 days prior. Sentry mode was off. Overheat protection was off.

 

[darth_vad3r]

Left my car outside for 8 days. Arrived in the morning when it was cool. Closed the app on my phone. Opened the app on the eighth day from across the country during the cool morning. I lost 2 miles of range. Arrived at my car in the hot afternoon. It was 1 mile higher than when I left it 8 days prior. Sentry mode was off. Overheat protection was off.

#VampireGain

 

[darth_vad3r]

I've been losing 10 to 14 miles while sitting in the parking lot at work. Yesterday I got to work with 194 miles of range and leave with 182

• Cabin overheat is disabled
• Sentry mode is disabled
• Car is actually asleep (verified via API)
• Don't use TeslaFi
• Temps are not too hot (70s to 80s)
• Parked 6- 8 hours
• No accessories plugged in

Anyone else seeing this? My car is now on 2019.20.1 and I've been seeing this for a couple firmwares. 12 mi in 6 hours is 2 MPH loss (while asleep!). This is approximately 3 kWh in 6 hours = 500W/hour.

Did this get fixed with the latest firmware? I noticed people more recently saying they've seen improvements in vampire drain. Perhaps with 20.x, 20.4? Not sure.

I've also had a chance to test the API myself. There is a limited set of API calls that do not appear to require interaction with the vehicle (essentially just *one* vehicle-related one, "/vehicles" with 2 variants, and then a few other auth-related ones), but the vast majority of the API -- anything that queries more detailed state information from the vehicle -- definitely involves communication between the Tesla server and the vehicle after you initiate contact with the Tesla server.

It would have been more clear if you had made this distinction explicitly. None of the API references online seem to get into this detail.

You could have saved some back and forth by just stating which API call doesn't communicate with the vehicle, and which do.

If you query the overall vehicle with "/vehicles", you get back limited info such as "online", "asleep", or "offline" (** see below!). That one specific API call does not appear to disrupt the vehicle, yet it COULD still actually in fact trigger communication with the vehicle. If you use practically any of the other many API calls referenced in the online references, it does want to communicate with the vehicle to report the current data.

To be clear, yes, the API user never communicates directly with the car, but after you query the server for certain state, the server appears to have to query the car to get that up to date state. If the car is offline those API calls fail. If the car is asleep, it has to be awoken for those API calls to work.

**Presumably there is also some limited communication even whilst asleep such that the server knows if the car is "asleep" or "offline" ... so even querying this overall state API doesn't guarantee that the server doesn't ping the car to ask it what's up (in a way that can keep it "asleep", yet still requiring the car to respond ... otherwise it would be seen as "offline", right?).

This is the "vehicles" API that doesn't awaken the car: Vehicles (two variants, one lists all vehicles, one just the one id you specify). The info provided is limited:

{
  "response": {
    "id": 12345678901234567,
    "vehicle_id": 1234567890,
    "vin": "5YJSA11111111111",
    "display_name": "Nikola 2.0",
    "option_codes": "MDLS,RENA,AF02,APF1,APH2,APPB,AU01,BC0R,BP00,BR00,BS00,CDM0,CH05,PBCW,CW00,DCF0,DRLH,DSH7,DV4W,FG02,FR04,HP00,IDBA,IX01,LP01,ME02,MI01,PF01,PI01,PK00,PS01,PX00,PX4D,QTVB,RFP2,SC01,SP00,SR01,SU01,TM00,TP03,TR00,UTAB,WTAS,X001,X003,X007,X011,X013,X021,X024,X027,X028,X031,X037,X040,X044,YFFC,COUS",
    "color": null,
    "tokens": ["abcdef1234567890", "1234567890abcdef"],
    "state": "online",
    "in_service": false,
    "id_s": "12345678901234567",
    "calendar_enabled": true,
    "api_version": 4,
    "backseat_token": null,
    "backseat_token_updated_at": null
  }
}

Any of these API calls appear to require the vehicle to be awake and respond to the server to pass you back the requested information:

• drive_state
• climate_state
• charge_state
• gui_settings
• vehicle_state
• vehicle_config

 

[darth_vad3r]

Feel free to read up on the API threads on this forum. There are many. The Tesla servers do not show 'stale', sorry. A simple test that I've personally performed many times is to ping the Tesla server when your car is sitting in your garage and asleep and see what it does. I've found that Tesla's servers correctly identity my vehicle as asleep (sometimes it's 'offline') and it doesn't ever wake it doing so. By the way, my algorithms for checking the car status have never impacted the range in the 14 months I've been doing it. I've only noticed the high range loss at work in the most recent firmwares, hence this thread. Maybe now we can put to bed the assumption that asking Tesla's servers if your car is awake is the culprit here?

FWIW I just got the new 20.4.1 firmware, so I'll see if it makes any difference this week.

OK, so I agree with it not ever waking it (with the ONE specific "vehicles" API call) ... BUT ... it knows if it is asleep or offline, right? How does it know this? There MUST be some communication while asleep to determine if it's still asleep or if it's gone offline completely. See post above.

 

[mswlogo]

My vampire drain has been fantastic. I Charged like on a Friday and didn't use the car until Tuesday and it had dropped like 2 miles of range. And I always move the charge limit down after a charge because I hate when it tries to re-top off the battery.

I hope it does better this winter. It was awful last winter.

 

[darth_vad3r]

My vampire drain has been fantastic. I Charged like on a Friday and didn't use the car until Tuesday and it had dropped like 2 miles of range. And I always move the charge limit down after a charge because I hate when it tries to re-top off the battery.

I hope it does better this winter. It was awful last winter.

Fantastic since ?

 

[mswlogo]

Fantastic since ?

It's been good since April-ish? Since it didn't drop below around 60F. Don't know how much is relate to temps.

BTW I have also tried to form a habit to shut HVAC OFF Every time I leave the car.

Even when it's sleeping good, every time I go into the car to put something in it or take something out the Heat or AC would start up unnecessarily. It always thinks you are preparing to leave. So now I shut HVAC Off.

I really wish they had an Option for HVAC to stay off unless the Car is in Drive.

 

[darth_vad3r]

It's been good since April-ish? Since it didn't drop below around 60F. Don't know how much is relate to temps.

BTW I have also tried to form a habit to shut HVAC OFF Every time I leave the car.

Even when it's sleeping good, every time I go into the car to put something in it or take something out the Heat or AC would start up unnecessarily. It always thinks you are preparing to leave. So now I shut HVAC Off.

I really wish they had an Option for HVAC to stay off unless the Car is in Drive.

Hmm, so you don't want the AC to come on when you just open the door because you are not going to drive ... that's probably an uncommon use case. I don't know how much HVAC running for 30s is going to be a big deal on drain. Even if it's 1 kW, for 1 minute that is only 16.67 Wh ... that's tiny. The impact of waking your car up from sleep and it staying awake for however long before going back to sleep is probably larger.

I do sometimes consciously turn HVAC off though. Sometimes turn AC off for last few minutes of drive to get rid of moisture, then before leaving car turn HVAC off completely ... then when I get back into car AC isn't on either. If I need AC I'd hopefully remember to precondition the car actually so it's nice and cool when I get in.

So maybe instead of turning HVAC all the way off every time you stop/get out, you can just turn the AC off a couple minutes before stopping.

 

[nvx1977]

OK, so I agree with it not ever waking it (with the ONE specific "vehicles" API call) ... BUT ... it knows if it is asleep or offline, right? How does it know this? There MUST be some communication while asleep to determine if it's still asleep or if it's gone offline completely. See post above.

A while back I called the endpoints quite a bit while writing a webapp that allowed me to charge my car in time intervals. While testing the app, I noticed that the "vehicles" GET call does not wake the car. As for how the Tesla server knows the sleep state, my assumption is that the car communicates to the server just before it sleeps. Or the server guesses based on last communication duration.

If you want the vehicle details info, you have to call the wake endpoint first. This was also another way I noticed when the car was asleep or not. If vehicle details call ever failed, you knew the car was asleep and you would need to re-wake it. This is exactly the same mechanism in the app when the bottom banner says "waking vehicle." It can't get vehicle details until the car is awake and communicating with the server.

 

[darth_vad3r]

A while back I called the endpoints quite a bit while writing a webapp that allowed me to charge my car in time intervals. While testing the app, I noticed that the "vehicles" GET call does not wake the car.

We agree on this.

As for how the Tesla server knows the sleep state, my assumption is that the car communicates to the server just before it sleeps. Or the server guesses based on last communication duration.

This does not explain how the Tesla server knows if the car is "offline" vs "asleep"

If you want the vehicle details info, you have to call the wake endpoint first. This was also another way I noticed when the car was asleep or not. If vehicle details call ever failed, you knew the car was asleep and you would need to re-wake it.

No, if it fails it could be asleep OR offline.

This is exactly the same mechanism in the app when the bottom banner says "waking vehicle." It can't get vehicle details until the car is awake and communicating with the server.

No, it's not exactly the same ... sometimes the car is asleep and it can be awoken, sometimes the car is offline and it doesn't actually respond (this is when you see "waking up" spinning icon forever. If you use the API you can tell if it's asleep or offline and can predict that trying to wakeup the offline car is not going to work

 

[darth_vad3r]

As for how the Tesla server knows the sleep state, my assumption is that the car communicates to the server just before it sleeps. Or the server guesses based on last communication duration.

Thinking about this a bit ... the car MUST be able to communicate with the Tesla Server while it is asleep. If it could not, how could it respond to the wake up command?

So the car can go to sleep, THEN tell the server "I'm asleep". Maybe it does so every X minutes .. "I'm still asleep", or the Tesla server queries it periodically "Are you still asleep?", "Yup" = asleep, "Nope" = online (would probably know this from some direct communication from the vehicle anyways), and <no response> = offline.

 

[mswlogo]

Hmm, so you don't want the AC to come on when you just open the door because you are not going to drive ... that's probably an uncommon use case. I don't know how much HVAC running for 30s is going to be a big deal on drain. Even if it's 1 kW, for 1 minute that is only 16.67 Wh ... that's tiny. The impact of waking your car up from sleep and it staying awake for however long before going back to sleep is probably larger.

I do sometimes consciously turn HVAC off though. Sometimes turn AC off for last few minutes of drive to get rid of moisture, then before leaving car turn HVAC off completely ... then when I get back into car AC isn't on either. If I need AC I'd hopefully remember to precondition the car actually so it's nice and cool when I get in.

So maybe instead of turning HVAC all the way off every time you stop/get out, you can just turn the AC off a couple minutes before stopping.

It's quicker to turn the whole thing off and on. Just hold fan for off and tap for on. Feels a whole lot longer than 30s.
Also many times in the morning, I don't need to turn it on at all. I turn it on when I feel I need it.
Easier to confirm by ear that it's completely off too.