Planner: latest planning on continuous mode#26295
Conversation
|
Schau mal, ich dachte an sowas? https://github.com/evcc-io/evcc/pull/26317/changes |
|
Verschieben ist nur nicht richtig bei günstigerem ersten Slot, darum die zusätzliche Prüfung: günstigst |
|
Ahhh, jetzt macht's "klick" bei mir. Natürlich. Die Frage ist ob es überhaupt lohnt das anzupassen- wir sprechen von max. 15min und die aktuelle Lösung gibt etwas mehr Puffer (und ist einfacher). Ich würde dann zu "so lassen" tendieren? |
|
Ja, aber es sind nur ein paar Zeilen. Entweder weglassen, oder nur verschieben wenn der letzte Slot der günstigste ist fände ich begründbar. In der Regel sind die Rand-Slots noch im Rahmen günstiger möglicher Slots, aber nicht immer: da kann es blöde Ausreisser geben, aber das sind fast Grenzfälle. Genau wie es jetzt implementiert ist, ist es sehr konsistent mit dem Ansatz möglichst spät zu laden. Mir gefällt einer der Testfälle noch nicht, das ist redundant geprüft. |
|
|
||
| // shift late if target slot (-1s to get containing slot) is equal or cheaper | ||
| if windowEnd.Before(targetTime) { | ||
| if SlotAt(targetTime.Add(-time.Second), rates).Value <= SlotAt(windowStart, rates).Value { |
There was a problem hiding this comment.
Das -1s ist frickelig und den StartSlot kennst Du ohnehin (bestIndex). Da SlotAt relativ langsam ist (binary search) sollte das nicht verwendet werden.
Lass uns das einfach so lassen wie es ist. Good enough.
There was a problem hiding this comment.
Ah, nicht bedacht! Ich hatte vorher den Ansatz mit der Helper Methode und berechnen des Fensters von hinten nach vorn, aber ich bin bei dir: good enough und gut begründbar. wir starten früh und im Bedarfsfall ist am Ende noch etwas Zeit bis zum Ziel übrig.
2 participants
small adjustments to fine-tune optimized for continuous planning
Follow-up to #24423, depends on #26291.