One-time scheduled charging

[MikeBishop]

This might be something to construct outside of TWCManager using the APIs, but @dschuesae's work made me wonder whether it would be possible to send a command that says "Have the car charged to X limit by Y time." Effectively a Charge Now (in that it's a one-off and overrides other policies), but something that doesn't take effect immediately.

I'd think we could generalize the logic from scheduled completion and enable a "Charge Now" that starts sometime in the future.

[ngardiner]

Totally agree, With the scheduled charging refactoring I think it would be quite straightforward to add a list of one-off schedules that take effect at a given date/time and give those precedence. In addition, having an API call providing that function might be very useful for automation - ie if we see a weather condition coming up, queue up a once-off full charge for the day before.

[MikeBishop]

Well, that particular use-case I let Tesla do for me by having a policy that triggers on Storm Watch. 😁 But for those using other EMSes, yes, that's a good scenario.

I have an automation that I can trigger any time the day before a trip; it waits until 5 AM and sends a Charge Now command. But what I actually want is the car to reach 100% around 8:30 when I'm about to leave; if the car is already at 90%, it doesn't need to start that early.

Currently, if I see the charge level is already high from solar, I just don't set that; I wait until I'm up in the morning to do the Charge Now command. But I'd like to just say we're going on a trip, then let it decide when to start in the morning.

[MikeBishop]

Some thoughts on this last night. Here's a rough design of how we could approach this:

• Replace both Charge Now and Scheduled Charging with a queue of upcoming charge times.
• Queue is sorted by the next time a period is scheduled to occur/recur.
• This queue will be managed by the function that currently checks whether we're inside the scheduled period. The function would do the following, likely broken up into helper functions for readability:
  • If the queue is empty, return false.
  • If the first item in the queue is ongoing, return true.
  • If the first item in the queue is in the future, return false.
  • If the first item in the queue is in the past, remove it from the queue, insert the next instance to the queue if it recurs, and restart evaluation.
• Queue items would come in two varieties. They would have most of the same properties as policy objects, except no match criteria. (Latch probably doesn't make sense here either. We'd need to think about any other exceptions here.)
  • Start time + duration, evaluated with the "normal" in-this-period logic that already exists
  • End time + charge limit, converted to a start time with the logic @dschuesae added
• Times would be specified with a modified time struct, unless we can find an object in Python's standard library that serves this purpose. They could be explicit (i.e. a unique date-time instance) by specifying all fields, or a field could be given as a set of acceptable values, with null indicating any value matches. That makes it easy to reflect things that occur on particular days of the week, days of the month, etc. Would need a helper function that can take one of these objects and compute the next time that will match it, for (re)insertion in the queue.
• Charge Now becomes a special case of a scheduled charging instance which begins at the time the command is received and doesn't repeat. Modify it to remove any existing Charge Now objects and insert a new object at the beginning of the queue with start time now, duration as specified by the command. Put a property on this object so that Cancel Charge Now commands can remove the first item in the queue iff it was created by a Charge Now command.
• Would need to update the UI to show multiple Scheduled Charging periods
• The "before" and "after" extension points become equivalent, but should be retained for backward compatibility.

If we're up for such a big change, I would suggest we not begin (or at least, don't merge any of it) until after we've cut a final v1.2.1; this will probably be disruptive in the short term. If we're not up for such a big change, I totally understand.

[MikeBishop]

I was starting to write such a recurrence object as an exercise, when I discovered dateutil already has a recurrence rule class (rrule) that seems like it would cover what we need for that. The format for entering rules isn't terribly friendly, but we might be able to translate something easily enough or just include some good examples.