Tesla does not sleep with default polling interval

[tobbensoft]

Home Assistant release with the issue: 0.104.0b5 (all)

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

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

Integration: Tesla

Description of problem:

When integration is active with default polling interval my car never sleeps. (Model 3 LR with with firmware 2019.40.50.7 ad132c7)

If the update interval is 11 minutes (660seconds) or more the car is able to sleep. (Needs behavior confirmation with other models/firmware's)
Exactly what the requirements are for the car to go to sleep is unknown, but if the polling time is under 11 minutes it never sleeps.

Other Tesla integrations/app have implemented schedules when different polling rates/types should be active in combination with delay's after last active mode (!idle)

Below is my thoughts of how this could be solved. (Without knowing about what is suitable in regards to the code)

• Show/log state in HA
• Solution for scheduling polling interval/type, Automation? Integration config flow?
• Handle back off to let the car sleep. When it sleeps, it works correctly and does not wake it up. So
  standard polling could be restored when asleep state is detected to aid in early detection changed state)
• Delay between active states -> try to sleep (Time) so it doesn't try to sleep when making short stops.
• Scheduled sleep polling on/off - If we should do nothing in the scheduled sleep timeframe or continue to do the "https://owner-api.teslamotors.com/api/1/vehicles" request

[probot-home-assistant]

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

[alandtse]

If you want to test out different algorithms, you can use the update switch to see what works (admittedly, we don't directly expose the online state so you'd have to look at the logs for attempted wake_ups; probably will expose the online sensor in the next set of PRs).

Five minutes used to be enough to allow my Model S and Model 3 to sleep, but perhaps we need to bump the default config up to 660 as you proposed. Since other apps are out there, I assume someone on the internet has documented the sleep threshold and we can just adopt that without experimentation.

[tobbensoft]

@alandtse thanks for your reply.

Including some information about sleepstates below

https://support.teslafi.com/knowledge-bases/2/articles/161-my-vehicle-is-not-sleeping
https://support.teslafi.com/knowledge-bases/2/articles/640-enabling-sleep-settings-to-limit-vampire-loss
http://visibletesla.com/Documentation/pages/SleepMode.html

But as it's depending on the installed firmware it should have a high level approach so we can handle all use cases and future changes from Tesla.

One solution to make it easier to automate around could be to be able to combine the update switch with on the fly configuring/toggle of the update interval..

To make it easy for users, what if we have a switch that we can toggle the integration to use to a aggressive interval (300 sec) or a more relaxed (660 sec) that is configurable from the config flow page?

We probably will need a documentation update ;)

[alandtse]

I'm not sure a switch is appropriate since it's going to be hard to know what someone considers aggressive/conservative. The default used to allow sleeping while also giving reasonable updates. The default should replicate that behavior generally. If people want to be more aggressive they should set their own settings. Part of the reason we have to be conservative is that there are real costs if the vampire drain is too high. Yes, I agree updating the documentation to explain this is important.

The purpose of the update switch was specifically to allow automations to control it. For example, I have an automation that stops updates if I haven't charged it for 24 hours (since I'm reliably charging at home and only wouldn't if I'm traveling). You could do it for airports, etc.

[tobbensoft]

When the online state is exposed (and hopefully shift_state to detect driving) , I think most needs are solvable with a automation in combination with the update switch.

[alandtse]

When the online state is exposed (and hopefully shift_state to detect driving) , I think most needs are solvable with a automation in combination with the update switch.

Anyone who wants to play around, see here to expose state and the shift_state.