MIN and DEFAULT scan interval

[llluis]

Hey @alandtse, I was looking into your home-assistant dev and found this: alandtse/home-assistant@ee73d56

I like this change. May I suggest something I'm running currently with good results (however, I did it hardcoded):

• Pass the 2 values to teslajsonpy (min and default scan interval)
• Make teslajsonpy.controller.update_interval a per car setting
• Expose a switch to home-assistant to switch between the two

This way, automations would change the polling interval instead of disabling it.
3 automations are enough to control this switch to allow the car to sleep as well do a fast polling inbetween.

I'm running with min = 60 and default = 900 and it's working really good. After a 15min idle time, polling is reduced from min to default. It returns to min when car awakes from sleep or it's not idle anymore.

Point me to a branch and I can try to implement and submit the pull request.
Thanks!

[alandtse]

Please note I'm currently testing a branch that does this in the controller so automations won't be necessary. The issue is testing the values to make sure it wont' cause issues for the larger population.

[llluis]

Great, thanks. Will test it when available.

[alandtse]

If you wanted to test it while I'm working on it, it's the PR #57 combined with my HA branch. I'm using a 660 as the sleep timeout, but might go to a 900 as you suggest.

[llluis]

Great. I didn't notice the PR was in progress and you were adding more stuff.

Note that for calculate_next_interval, you must also check charging, climate and sentry. If any of those is on, you cannot try to sleep. Just being in P in not enough.

[alandtse]

For each item beyond sentry, can you explain how you know it won't sleep? Is it based on testing or some documentation you've seen?

I just want to make sure we only add conditions that are verified.

[tobbensoft]

During my testing I'm seeing that Sentry/Charging prohibits sleep as @llluis mentions.

The only one I have not tested (but sounds logical) is climate on.. Never had that running for any period of time.

[llluis]

Unfortunately, there’s no documentation. Just experience.
Any climate mode (dog, camp, manual, cabin overheat) prevents the car from sleeping.
Sentry is known to do that.
And charging there’s not much sense in sleep during it.

Those are the ones I can identify.

According to “internet knowledge”, if the car reports null instead of P in shift state is because it wants to sleep. But this can change with future firmwares.

[llluis]

(I already had climate running for 1h30 and car didn’t sleep. :-) )

[alandtse]

Ok, latest build in #57 ignores trying to sleep on charging and climate on. The null for shift_state isn't accurate because as you noted, sentry, climate, or charging override the null.

[alandtse]

By the way, the adaptive behavior is already merged in to HA. Let me know if you're not seeing it.