Core: Tesla Compontent: The ability to schedule or turn on/of polling to reduce battery drain

[iMartien]

Home Assistant release with the issue:
0.91.4

Last working Home Assistant release (if known):
N/A

Operating environment (Hass.io/Docker/Windows/etc.):
All

Component/platform:

Tesla Component: https://www.home-assistant.io/components/tesla/

Description of problem:
Polling the Tesla API keeps preventing the car to go to sleep, this uses a lot of battery (like 300watts awake vs about 20watts in sleep).

The ability to turn on or off polling via a simple switch or via a schedule gives more control and lets the car go to sleep at night or when polling information is not relevant and save a lot of energy.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

[ghost]

Hey there @zabuldon, mind taking a look at this issue as its been labeled with a integration (tesla) you are listed as a codeowner for? Thanks!

_This is a automatic comment generated by codeowners-mention to help ensure issues and pull requests are seen by the right people._

[JustinAiken]

+1 - would be awesome if there was a a "last updated" sensor and an "update NOW" switch, so you can request state as needed, instead of continually polling and causing vampire drain

[trombonekenny]

Agree! Seeing "last updated" would be nice, as would the ability to "update NOW" manually and control the update frequencies based on other data (location, charge state, etc.)

[tschmidty69]

I would think that an option for turning polling on/off and perhaps 'update now' would be good options if possible. Doing it based on criteria would be something the individual user would need to do I would think, there are too many specific cases people would want and the logic for all of that could be in "user land" so to speak if you had the option to turn polling on/off.

[kdvlr]

I am looking to do something like the iCloud component. Changing the polling based on distance. How does this logic sound? My intent is to have the defaults should work for more than 70% of the population

1. If charging, poll every half hour
2. If location is near home/work/known zones, then reduce polling to every x hour? (x=2 seems reasonable)
3. If location is further out, say 200 miles away, I am not sure if I should optimize for range and reduce polling or have more regular polling because you might be in unfamiliar places.

Also, now that sentry mode can be automatically turned on, does it matter ? Because sentry mode will keep the car on and polling frequency won’t make a difference

[zabuldon]

Hello guys, thanks for your suggestions. Currently I busy with rewriting
library. It would be great if you can open issues in lib bug tracker.

On Sat, 8 Jun 2019, 04:21 kdvlr, [e-mail] wrote:

I am looking to do something like the iCloud component. Changing the
polling based on distance. How does this logic sound? My intent is to have
the defaults should work for more than 70% of the population

1. If charging, poll every half hour
2. If location is near home/work/known zones, then reduce polling to
   every x hour? (x=2 seems reasonable)
3. If location is further out, say 200 miles away, I am not sure if I
   should optimize for range and reduce polling or have more regular polling
   because you might be in unfamiliar places.

Also, now that sentry mode can be automatically turned on, does it matter
? Because sentry mode will keep the car on and polling frequency won’t make
a difference

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/23227?email_source=notifications&email_token=AAJYVEF3HINP262GQVCUDHLPZMCSZA5CNFSM4HHCCZF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHKHYA#issuecomment-500081632,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJYVED6EPO6RBZF5CZVOLLPZMCSZANCNFSM4HHCCZFQ
.

[Phontana]

It would be nice if the Tesla component worked the same as this project: https://github.com/lunars/tesla-apiscraper. From the readme of that project:

One challenge was to implement a reliable sleepmode. If the car is awake, the API keeps it awake, as long as requests occur. Once it falls asleep, parts of the API can be called to check the sleep state without waking up the car, however, when the scraper detects that the car doesn't change Values (not driving, not charging), it increases the Poll interval until the Car falls asleep. Once it's asleep it checks the sleepstate every Minute. This ensures, that the stats don't miss relevant portions of rides when the car was just woken up, an issue some other monitoring implementations suffer from.

[Try2Fly]

Is there any news on this? I think like suggested the teslamate solution is a great way to limit the vampire drain, and still have frequent updates.

Also with the update of Tesla to version 10, new options, like defrost, have become available. @zabuldon do you see a chance to include these?

[zabuldon]

@Phontana @Try2Fly so, I think it not a bog deal to implement something like this, but when Tesla in asleep mode you can't grab any data, so values won't be changed. I'm thinking around something like:

• Add additional "flag" which allows you to wake up a car
• Do not wake up the car until flag set to "true"

Is that enough?

[Phontana]

@zabuldon Does the component wake up a car in its current state?

[zabuldon]

@Phontana yes.

[Phontana]

Then there might be another issue, because it doesn't get any data from my car when it is asleep. It seems it doesn't wake up my car when it's asleep. This is most notable when I restart Home Assistant and the car is asleep, in that case all Tesla component related entities get a default state and don't get updated until the car is awake again (which I have to do manually) and the component is polling data. It also doesn't update during the night, for example, when my car is asleep the entire time. So it appears there is an issue with waking cars up as well.

Regarding your suggested solution: if it is possible to update the flag with a switch or something like that (so it is possible to update this state without restarting Home Assistant), it would be nice.

[iMartien]

When the car is asleep, the component currently doesn’t wake up the car, when the car is awake polling frequently keeps the car from sleeping.

A flag to make the car wake would be great if it actually does wake the car. Automations can be used to enable your own schedule to wake and sleep the car etc.

[zabuldon]

@iMartien ok. Sounds reasonable. I'll take a look in next a few days.

[Try2Fly]

@zabuldon Thanks for looking into this! Indeed a flag to turn on/off the polling of the car would be great. The rest can be achieved through automations.

I do not need to update the data when the car is asleep, as not much should change when asleep.
When I turn on the climate it wakes up the car. I have not tried it through an automation yet.

[alandtse]

@zabuldon Actually, @iMartien is correct. In 0.0.25 I believe I disabled the always force awake command to resolve the massive battery drain people were experiencing. 0.0.26 has been in pypi since March and I finally decided to add a PR to it since the massive HA migration appears to have settled down.

Currently, the the sensors only grab data if the car is already awake. The car can be woken up programmatically by issuing any command which will try to wake the car up to 5 times on an exponentially increasing timer. I just put in a PR to add the update switch that was requested here months ago as that was also in the 0.0.26 teslajsonpy.

EDIT: Corrected the wake up states. Climate commands should also try to wake the car.