evcc-io
Planner: add continuous strategy (BC)
Fix https://github.com/evcc-io/evcc/issues/24461, fix https://github.com/evcc-io/evcc/issues/24769, fix https://github.com/evcc-io/evcc/issues/24486
SinglePlan / Continuous Window Mode (optimized)
- Creates a single continuous charging window for the required duration.
- Chooses the window with the lowest cost.
- preconditioning can be added at the end.
- Ensures uninterrupted charging.
Cheapest Window / Default Mode (old)
- Uses the cheapest combination of available slots to cover the required duration.
- Slots do not need to be continuous.
Video
Screenshots
Breaking Change
The precondition / late charging feature has moved from plan level to vehicle level. This simplifies our API and UI but means that all plans of a vehicle (static&repeating) use the same precondition option now.
TODOs
- [x] validate performance
- [x] validate results
- [x] validate UI
- [x] validate repeating plans UI (long text)
- [x] validate repeating plans function
- [x] validate integration (soc-based, energy based, plan execution)
- [x] fix tests: mock
- [x] check for persisted plan settings
- [x] fix tests: integration (combobox)
- [x] double-check playwright adaptions
- [x] decide smallSlotDuration/smallGapDuration (and verify)
- [ ] document api changes in
openapi.yaml - [ ] double-check commit (e8fd4c3)
@iseeberg79 thanks for the PR. I dont think this is the right choice UI-wise. Having three knobs there is too cluttered and needs more explanation when we can provide on this small space. The "Late" Option already was a stretch that confused people.
I guess the important question is: Do we really need to have this level of control per plan? The above examples show a loadpoint plan (kWh based). We also have soc-based plans in combination with recurring plans (stored at vehicle level).
Suggestion: Make the "Planner Strategy" (Lade+Timespan? Continuous vs Cheapest?) a top level configuration that applies for all plans of this vehicle/loadpoint. This way we can simplify the actual plan items (lines). I'd see the strategy configuration collapsed by default (text that summarizes current state) and something the user can expand if we wants to make changes. Assumption being, that changing strategy is something you do less often then setting goals.
The drawback is, that the user has less granule control (late charging on Wednesdays, cheapest charging on Sundays). But I'd say this is fine.
As you might have realized, I am NOT a UI designer 😀
I'd love the flexibility in the UI. What about reusing the late toggle for advanced options, defaulting to 0min preconditioning and the option to enable single slot planning?
I agree on "much options" are confusing, keep it simple.
A loadpoint setting would define a planning default which would be a great extension but from my actual point of view it's not flexible enough. But that's relative..
Initially I thought about a loadpoint setting only, but prefer the UI choice at the moment.
Best option with counterparts would be a combination within the planning logic but that's way too complex and never meets anybodies criteria.
I'd love the flexibility in the UI. What about reusing the late toggle for advanced options, defaulting to 0min preconditioning and the option to enable single slot planning?
Interesting idea. Let me think on this.
A loadpoint setting would define a planning default which would be a great extension
I wouldn't want to go the route of having configurable defaults and per item overwrites. That's indeed most flexible but also a hard to understand and visualize mechanism.
I read your comment once more, thought about and absolutely agree, top level configuration of planning strategy that applies to any repeating plan makes sense and simplifies.
What I was thinking about: is it possible and useful to somehow integrate or visualize the loadpoint gap constraints in the UI (preview)? I'd love to try applying some kind of mask for the constraints to get visible (preview level at least). What do you think?
@iseeberg79 can you explain, what you mean with "visualize the loadpoint gap constraints" exactly?
I read your comment once more, thought about and absolutely agree, top level configuration of planning strategy that applies to any repeating plan makes sense and simplifies.
Then let's start with this. That means we need to persist and publish the planContinuous flag on loadpoint level (already done for energy based plans) and on vehicle level (valid for single plan and repeating plans).
I can offer to do the UI part here. I'd likely make this an option that's located near the preview chart so users can see its effect immediately. Since it's similar I'd also like to do this for precondition/late, but lets keep this for a dedicated followup PR to not blow up this one.
I can offer to do the UI part here. I'd likely make this an option that's located near the preview chart so users can see its effect immediately.
That would be cool. I believe I did the required things yesterday? I copied the logic of the precondition so it's available at loadpoint and vehicle already.
@iseeberg79 can you explain, what you mean with "visualize the loadpoint gap constraints" exactly?
Let's perhaps not blow this PR up. Involved you in Slack for a full reference. At this moment just thinking about.
We should probably revert https://github.com/evcc-io/evcc/commit/1ee48a559b83f234e4fc69f959bc203917a84d0b when we merge this one.
I believe I did the required things yesterday?
I've reworked the APIs and storage. Introduced a planStrategy on vehicle and loadpoint level. This also simplifies a lot of function calls and return types where we had to pass these values around previously.
UI changes are next.
Since it's similar I'd also like to do this for precondition/late, but lets keep this for a dedicated followup PR to not blow up this one.
I decided to do this migration here, since we have to touch all the affected places and calls anyways.
We should probably revert https://github.com/evcc-io/evcc/commit/1ee48a559b83f234e4fc69f959bc203917a84d0b when we merge this one.
Really unsure about, wrong direction as important to be able to use cheap slots? Fix forward would be to set 10/15?
I've updated the screenshots above. The plan preview area now has a settings button to show plan strategy details.
@iseeberg79 In my testings (demo.yaml) I noticed that the "continuous" mode picks time slots from the past. Maybe you can check this.
Btw. with the current UI implementation it would be easily possible to not only provide a binary continuous or not option. Now we have enough space for further iterations.
UI looks great, indeed enough space for iterations.
Should passing options already work? Get 404 on /loadpoints/1/plan/strategy - payload correct and included
Ah, got it - other scenario as my demo vehicle is not online. It's not soc based planning at the moment. Could probably provide a fix if ok (semantic correct?)
Last commit should avoid getting plans in the past.
UI is still work in progress. haven't looked at the failing test cases yet but the manual tests I did looked good enough to push :)
UI is still work in progress. haven't looked at the failing test cases yet but the manual tests I did looked good enough to push :)
they do! have done some corrections - hope not to interfere, revert otherwise. Integration needs a new mock case as the precondition is tested and got re-designed.
looks good to me now
Is the missing combobox of "repeating › preview static and repeating plan" intentional? At the moment the combobox is missing and the test got adapted. The preview plan isn't selectable now and shows the next active plan which isn't intended, or? I guess it's part of the "UI in progress"..
I'd like to ask you for a review and/or further adaptions.
Double-checked the changes - preview is intended to show the next plan executed, right? Then I should revert the last commit for the test to represent.
S/durchgängig/kontinuierlich/? Das schöne „pausenlos“ wäre richtig und trotzdem falsch ;)😑
OK.
What about smallGap/smallSlot?
Agreed on: revert to skip small single slot shorter than 10minutes
But change also to to: Allow gaps of <15min (instead of 30/60 minutes) to be more agressive on not-charging during skipped slots by planner. As it's not intended to charge between planner windows if for example up-to three slots have a high cost?
This would break today's "protection function" and is probably too aggressive for some APIs already having trouble on skipping >60m slots in the past? On the other hand a change to 15 is straight forward on slotduration change from 60 to 15 minutes. It will still allow charge at least during one full planner skipped slot (15min duration)?
A change of those should be done in another commit as it's unrelated to changes here?
What about smallGap/smallSlot?
I think we should remove both constants and ignore anything shorter than SlotDuration. But make sure shorter, not shorter or as short as.
Wdyt?
The preview plan isn't selectable now and shows the next active plan which isn't intended, or?
Yes, I removed the manual preview selection intentionally. Users can still preview by enabling/disabling specific plans. There was a lot of code (we'd also have to adapt) surrounding this preview features. Also I did not want two action areas (underlined text + button) so close together, since the user could confuse them to be one control.
Yes, haven't adapted the test cases. I'll review your changes later. Thanks!
If a higher tolerance than slotDuration would be required, it should be shown by the planner UI. That could by done by applying kind of "planner mask" - to stick to showing executable plans only. In a separate PR if really needed.
From my point of view, ready to review. @naltatis if you feel comfortable as well, we could go ahead.
But make sure shorter, not shorter or as short as.
Might the control cycle be relevant? Something like following formula:
remainingWindowDuration + (controlCyleInterval + someProcessingTime) >= slotDuration
It's the reason why 10min would be better than todays 15min or "shorter than slotDuration". Equivalent would be greater than a portion of slotDuration, but ensure to be not lower than "x" for some minimum on very short slotDuration?
Did not follow your progress in the referenced follow-up in detail, yet. So perhaps this thoughts are already outdated and are meanwhile offtopic here.
I think we should remove both constants and ignore anything shorter than SlotDuration. But make sure shorter, not shorter or as short as.
Ist eingebaut.