Add enable_wake_on_start option to Tesla#33035
Conversation
probot-home-assistant
Bot
added
has-tests
integration: tesla
|
Wait, do options need to be documented? |
|
Should we extend the update listener for this new option? Do we need to reload the whole integration on option change, since we pass the option to the library instance connect method? |
|
No I don't thinks so, this option only impacts the first time the integration is loaded. Once the integration is loaded, it doesn't do anything further so changing it after running doesn't do anything until the next time HA restarts. |
|
That's why we should reload the config entry. That would apply it without need for restart. |
|
I don't think you're understanding what this option does. It doesn't matter if the effect of the option applies only on the next restart because it only impacts behavior on that next restart. It configures whether the integration will wake up every vehicle on HA restart. Given how often HA is updated and needs to be restarted, users may not want to always wake up their vehicles as a Tesla takes over 24 hours of non-activity to go into lower power mode. For example, if they are parked at an airport, they may want to restart HA or update HA without potentially draining the battery of their car they need to drive home. There is a real money cost to users to continuously wake up their vehicles when they are sleeping. We should provide the option to minimize that cost. |
|
Why is it limited to waking up (or not) on home assistant restart? What is it that causes the potential wake up in the code? |
|
It is limited to HA startup because it results in the entities starting as Unavailable. Some users may not want to see that. Once a vehicle wakes up naturally because of someone driving the car or opening the door, the information is automatically refreshed. I don't understand your second question. There's a forced wake up command in the API. On HA restart, it's not sent if the option is enabled. If the option is disabled, it is sent. |
|
What code is responsible for the wake up command get sent? On So should we rename the option? |
|
Yes, the The option isn't available when a user initially sets up the integration because the options flow aren't shown on initial setup. The default behavior in that case is to not wake any vehicles which is what the integration currently does without this option at all. What do you mean "edit the entity registry"? That forces a reload of the entity? I don't think that's documented anywhere that users would know that's happening. I'm not opposed to renaming the option, I just don't think users would understand the "edit the registry" point., "Force cars awake on startup" seems to be a natural description of what happens if you enable the option. |
|
There's a reload of the corresponding config entry if a user disables an entity. |
|
For the specific entity type or for the entire integration? Again, if you have a name you'd prefer I can put it in. If you think it's better to not provide this option to users, I can also close it. I was just trying to respond to a user request but frankly I don't care about this option. |
|
The config entry is reloaded, if a user disables an entity, and the config entry supports unloading. I don't have any good suggestions at the moment. Names are hard. |
|
The default is to not wake on start right? |
Never-mind, answered my own question. |
|
Testing this now |
|
Confirmed it did not wake the car when not enabled. |
4 participants
Proposed change
Add an option for users to decide whether the Tesla component should wake up all cars on Home Assistant startup. This allows a user to choose whether cars should continue to sleep (and not update information) or to wake up the cars potentially interrupting long term hibernation and increasing vampire drain. Users who need to restart Home Assistant while their cars are parked away from charging (e.g., airports) would benefit with this option.
Type of change
Example entry for
configuration.yaml:Additional information
Checklist
black --fast homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.The integration reached or maintains the following Integration Quality Scale: