Planner: grouped planning, cost tolerant by iseeberg79 · Pull Request #24289 · evcc-io/evcc

iseeberg79 · 2025-10-09T21:59:51Z

Choose time windows instead of single slots, cost-optimized. Avoid short charge durations to protect devices in case of short slot durations. The optimization uses a constant (InterruptionPenaltyPercent) to define when it's valid to fragment charging windows to reduce total costs. Other optimizations are also possible. It respects preconditioning and actually sorts windows by:

    // 1. Lower cost (primary)
    // 2. Longer duration (secondary - for hardware protection)
    // 3. Later start time (tertiary)

It defines also new tests as the logic for choosen slots changed a lot.
Additionally I've added some statistics to clarify usage of "penalty" and added a selector to limit fragmented charging by a maximum charging windows contraint.

It has been created using Claude.

TODO:

agree on algorithm and used percentage for optimization

Screenshot:

grouped planning

iseeberg79 · 2025-10-09T22:28:53Z

@andig adapted planner for small slot duration

revert shorter implementation

andig · 2025-10-11T09:02:08Z

+
+	firstSlot := plan[0]
+	slotDuration := firstSlot.End.Sub(firstSlot.Start)
+	assert.True(t, slotDuration <= time.Hour, "first slot should be at most 60min")


Das ergibt keinen Sinn. Bei Stundenslots ist das immer der Fall.

andig · 2025-10-11T09:05:32Z

Sign in to view

 	assert.Equal(t, simplePlan, plan, "expected simple plan")
 }

 func TestPrecondition(t *testing.T) {


Funktionieren diese Tests auch mit dem alten Planner? Falls ja wäre es schön die alten Tests stehen zu lassen und nur weitere hinzu zu fügen. Haben die Änderungen mit Slot Bundling überhaupt etwas zu tun?

habe die alten Testfälle wiederhergestellt, es brauchte zwei Korrekturen:

bezüglich der Verschiebung in einem Zeitfenster (m.E. vernachlässigbar, daher angepasst)

Berücksichtigung von slotDuration statt time.Hour, die im erweiterten Testfall nötig wird

Durch die Aufteilung kann die neue Logik gegen die alten Tests geprüft werden, und die Neuen sind klar getrennt.

andig · 2025-10-11T09:06:02Z

+}
+
+// TestPreconditionLimiting verifies that precondition is limited to required duration
+func TestPreconditionLimiting(t *testing.T) {


Dito- unabhängiger PR?

andig · 2025-10-11T09:08:29Z

+	// Applied as percentage of average cost - fragmentation only occurs if it saves more than this
+	//
+	// Special values:
+	// - 0.00: No penalty, pure cost optimization (maximum fragmentation, not recommended)


This is the current behavior. All existing tests should pass?

yes, they do - checking against the new behaviour needs adaption as it's currently taking a prepared test scenario to validate the penality. Needs double checking.

andig · 2025-10-11T09:10:25Z

+	// MaxChargingWindows limits the number of separate charging windows
+	// This protects hardware (contactors, battery management) from excessive switching cycles
+	// Recommended: 2-4 windows for most use cases
+	MaxChargingWindows = 3


Number of windows only makes sense relative to total length of session. Why shouldn't we interrupt a 10h session 10 times if it helps?

if you interrupt it 10 times, it might be because of the prices up-down in quarters. Yes, you have 10h session length but if you interrupt it 2 times per hour at beginning of the session. Wanted?

10 1-hour windows found be fine for me. 10 15min windows wouldn't be. But may that's subjective. Still, 3 gaps for a 45min plan out of 1:15 total time (i.e. on-off-on-off-on) is not a good plan.

really difficult, either adapt the percentage or a maximum. I agree setting 3 is not optimal but may be kind of sweet-spot. I like the idea of a slider for the percentage, using this makes maximum slots obsolete.

It was to ensure pauses of short slots aren't causing trouble for the hardware as they might happen in extreme situations.

We could skip the constant or go for a formula instead (duration / windows count > x) for security. Let's discuss.

andig · 2025-10-11T09:14:18Z

+
+		// Costs are essentially equal - prefer longer duration for hardware protection
+		// This reduces fragmentation when costs are identical
+		if a.duration > b.duration {


Isn't this condition already part of the cost comparison if gaps have penalties?

andig · 2025-10-11T09:15:07Z

+	var bestCandidate *planCandidate
+
+	// Strategy 1: Try single continuous window first (best for hardware)
+	for i := range windows {


Is this needed? 1 windows seems like a special case of N windows.

andig · 2025-10-11T09:16:30Z

+		}
+
+		if overlaps {
+			continue


Overlap heisst ja nicht, dass es nicht dennoch Zeit zu Anfang oder Ende hinzu fügen könnte- ist das korrekt?

requires early end / late start adaption only

andig · 2025-10-11T14:34:56Z

+
+// generateChargingWindows creates all possible continuous charging windows
+// AND individual slots as single-slot windows
+func (t *Planner) generateChargingWindows(slots api.Rates) []chargingWindow {


Bei 2 Tagen Forcast sind das wieviele Kombinationen (48h*4)?

jeffborg · 2025-10-12T23:34:42Z

Can I add if during solar hours it's not really start/stopping usually will be ramp up (slot) and ramp down (back to solar) so no hardware wear and tear. (Also in Australia on amber so forecasts are almost meaningless and should be taken as a super rough guide so it's very often evcc will just start the plan now because the current price slot is cheaper than the forecast-ed prices)

iseeberg79 · 2025-10-14T15:14:56Z

Could look like

(Three is not count of windows in a plan, just random)

Optimizing the cost-optimized slots to use minor charge windows recursively, verifying that single window strategy is never cheaper.

andig · 2025-10-14T16:18:02Z

Make "min. Abstand" a "Continuity"/"Kontinuität"? Not a fixed value but a cost parameter?

iseeberg79 · 2025-10-14T16:42:38Z

Not self explaining, yet? It's not really related to any cost function. It just defines how many slots between elements of plan are allowed to kept free (minimum)

andig · 2025-10-14T18:10:13Z

It‘s irrelevant how long the gap is when you have many gaps. I think we want low number of gaps, ie. Continuity.

iseeberg79 · 2025-10-15T00:34:36Z

superseeded by #24423

iseeberg79 added 3 commits October 9, 2025 23:45

grouped planning, cost tolerant

5fbc1c4

grouped planning

make linter happy

7fff63b

make linter even more happy

0601f59

andig added the enhancement New feature or request label Oct 10, 2025

andig reviewed Oct 10, 2025

View reviewed changes

Comment thread core/planner/planner_test.go Outdated

iseeberg79 added 6 commits October 10, 2025 22:34

limit windows

4fa7ef1

revert shorter implementation

adding tests

e05d3c2

better comment

7abeffa

statistics

8a7c9d1

add QUARTER_HOUR to planner

836fbd0

fix regression on test

a7eb6ca

andig reviewed Oct 11, 2025

View reviewed changes

iseeberg79 added 7 commits October 11, 2025 11:50

restore old test file

b6e04ea

requires early end / late start adaption only

adapt using slotduration

f228ddf

corrections to pass old tests

f2d4183

recreate specific bundling tests

fc1b7d3

minor

2370f1e

remove explanation

883492b

happy linter

500b353

andig reviewed Oct 11, 2025

View reviewed changes

optimize

c71080f

iseeberg79 added 5 commits October 14, 2025 16:29

fix and add tests

6568b88

UI integration

e4412d9

remove old tests

34c7631

translate comments

0d779de

ensure a single windows is never cheaper as optimized solution

c7c096e

This comment has been minimized.

Sign in to view

iseeberg79 closed this Oct 15, 2025

Uh oh!

Conversation

iseeberg79 commented Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iseeberg79 commented Oct 9, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

Uh oh!

iseeberg79 Oct 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andig Oct 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jeffborg commented Oct 12, 2025

Uh oh!

iseeberg79 commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andig commented Oct 14, 2025

Uh oh!

iseeberg79 commented Oct 14, 2025

Uh oh!

andig commented Oct 14, 2025

Uh oh!

This comment has been minimized.

iseeberg79 commented Oct 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

iseeberg79 commented Oct 9, 2025 •

edited

Loading

iseeberg79 Oct 11, 2025 •

edited

Loading

andig Oct 11, 2025 •

edited

Loading

iseeberg79 commented Oct 14, 2025 •

edited

Loading