[FR] Re-implement the old departure timer service to update timers

virtualdj commented 5 months ago

Is your feature request related to a problem? Please describe.

No, there are no real issues. But "resurrecting" the departure timer service, implemented in #352 with the old backend, could allow to stop charging at a specific value (using departureTimers > departureTimersStatus > Min SoC) without polling and also when the VW backend is down, especially at night. See below.

Describe the solution you'd like

Having the deprecated service with commit ab0a2fb back, with its parameters and ability to set a single or repeating timer (using attributes).

Describe alternatives you've considered

At the moment both the timer date and the Min SOC parameter can be set up in the VW app and then enabled/disabled using this integration. However the fact the app and backend handle 3 timers/profiles only doesn't allow many variations, which on the contrary would be possible by using the service and HA automations.

Additional context

When #547 has been opened, I was skeptical about the timer service to be really useful and I voted for a timer on/off being enough.

However, I later found out that there's an useful use case: if you want to stop the charge at night at a specific percentage, say 30%, both the integration and the VW backend must be running and polling the battery percentage to work successfully. It happened to me two times that the battery value hasn't updated at night (due to the VW backend of course) and the automation wasn't able to stop the charge... and I actually charged 100% one time and 54% another (because the value updated with a delay).

The use case, when I would like to charge the battery until it reaches 30%, would be the following:

set the Min SOC value to 30% (with the app it can be set to 0, 10, 20, 30, 40 or 50%)
set a departure timer (for example the number 3) with charging set to True and the weekday to (current weekday + 2)

This triggers the charging immediately and then stops at 30%; an HA automation could then disable the timer to avoid charging the remaining percentage the day after... the wonderful thing is that stopping at the 30% doesn't require the VW backend and it really stops at that value exactly.

The (current weekday + 2) calculations can be done with templates, but setting the date/weekday and SOC requires having the old service back, so that we can set up specific attributes for the 3 timers.

I know this is a hard work, but think about it (with low priority). Maybe most of the work can be recovered from the old code; I see that the API is still there, for example domains/departureTimers/departureTimersStatus/minSOC_pct has the minimum charging percentage and domains/departureTimers/departureTimersStatus/timers/3 has several properties (enabled, climatisation, charging, singleTimer, recurringTimer, preferredChargingTimes) that seem to resemble to the old ones... 🤞

No hurry, no pressure. Just a milestone idea.

stickpin commented 5 months ago

Hi @virtualdj,

Thanks for the detailed info, I will check what can i do... Currently, I am in the middle of the implementation of the "set charging amperage". @ceppa did PR about two weeks ago, I am implementing it based on the existing mechanism and with the frontend select entity, something that I've never done before. I am a backend person, frontend is always a PITA for me. 😆

I think I will release v5.0.0 to the public and after that will start looking into the departure timer service as the v5.1.0 milestone.

Have a great weekend! 😊