Splitted Charge Plan not paused correctly #11897
Comments
|
Sieht aus als hätte er aus irgendeinem Grund die Lücke ignoriert. Gutes Logfile, danke! |
|
Der Planner hat eine Reihe von Sonderfällen die zu häufiges Abschalten verhindern sollen: // planner was active (any slot, not necessarily previous slot) and charge goal has not yet been met
switch {
case lp.clock.Now().After(planTime) && !planTime.IsZero():
// if the plan did not (entirely) work, we may still be charging beyond plan end- in that case, continue charging
// TODO check when schedule is implemented
lp.log.DEBUG.Println("plan: continuing after target time")
return true
case lp.clock.Now().Before(lp.planSlotEnd) && !lp.planSlotEnd.IsZero():
// don't stop an already running slot if goal was not met
lp.log.DEBUG.Println("plan: continuing until end of slot")
return true
case requiredDuration < smallGapDuration:
lp.log.DEBUG.Printf("plan: continuing for remaining %v", requiredDuration.Round(time.Second))
return true
case lp.clock.Until(planStart) < smallGapDuration:
lp.log.DEBUG.Printf("plan: will re-start shortly, continuing for remaining %v", lp.clock.Until(planStart).Round(time.Second))
return true
}Die |
|
Bessere Log messages in f73e064 |
andig
added
question
Aber es sollte doch erst um 13 Uhr weitergehen. Das ist ja deutlich mehr als 1h. ;-) |
|
Ist für mich nicht erkennbar:
Da steht klar 4:50? |
Also dieser Plan wurde gesetzt: Die Preise waren so: Im Plan-UI wurden mit zwei Slots einer von 3-4 und einer von 13-14 Uhr angezeigt. Leider sind die Slots im Log nicht ersichtlich. Wie kommt er dann während des Ladens drauf, dass es besser ist noch die Stunde von 4-5 Uhr mitzunehmen statt die günstigere Stunde von 13-14 Uhr? |
|
Da war der Plan etwas kürzer als 2 Stunden, also werden 2 Slots geplant. Um 3 begonnen ist OK.
Da gibt es jetzt den Sonderfall dass Der Planer verhält sich so wie geplant. Was hier passiert ist eine Optimierung dass nicht zu oft ein-/ausgeschaltet wird. Die Ladedauer lässt sich leider nicht gut vorhersagen, das kann immer etwas zunehmen oder abnehmen und das ständige ein/aus muss man unterbinden. Er lädt aber trotzdem nur in den günstigsten Stunden. Es kann aber passieren, wie auch in diesem Beispiel, dass er die günstigste Stunde nicht zu 100% nimmt sondern weniger. Mit Trace hat er zumindest früher mal die einzelnen Slots angezeigt. Vielleicht geht das immer noch. |
Das war nur der ursprüngliche Plan. Da der SoC nicht schnell genug abgenommen hat war ein Teil einer dritten Stunde notwendig, und das war von 4:00 - 5:00. Es hätte wohl gereicht um 4:50 einzuschalten. Das macht er aber nicht da er für die 50 Minuten (in einer günstigen Stunde, wenn auch nicht die günstigste) nicht abschaltet. |
|
Wichtig zu wissen ist, dass bei jedem Durchlauf ein neuer Plan erzeugt wird. Ich denke hier ist alles beantwortet? |
Also tatsächlich geladen hat er von 2024/01/27 03:01:06 bis 2024/01/27 05:01:36 also 2h und 30 Sekunden. Geplant war 1h59m5s. Die Abweichung ist also weniger echt gering. Da hätte ich riskiert, dass er:
|
Was meinst du mit "ständigem ein/aus schalten"? Wann würde das passieren und warum ist das schlecht?
Welche Stunden werden als "günstigste Stunden" interpretiert. In meinem Fall hat er also 1h lang in einer Stunde geladen, die teurer war als eine günstigere, die noch gekommen wäre. Und wenn da so Verhalten wirklich so gewünscht ist, dann sollte man das dem User auch im UI transparent machen. Ich bin davon ausgegangen, dass er in den beiden Stunden lädt, die mir angezeigt werden. |
Das würde er nicht tun und gibt Dein Screenshot auch nicht her! |
Leider hab ich das Plan-UI nicht als Screenshot festgehalten.... |
|
Oben ist dein Tibber Screenshot. Der nächste Slot ist der nächstbilligste. Hier ist alles ok. |
Der billiste ist um 13 Uhr. Warum wird der nicht gewählt? |
|
Wird er doch 🙄. Aber die eine Stunde reicht nicht, also brauchts noch einen Slot. Long Story short: der Planner funktioniert perfekt. |
Das dachte er. Aber es hat halt doch gereicht. Er hat aum 13 gar nicht erst gestartet weil er vorher schon voll geladen hatte. |
|
Ist Dir ein leeres Auto lieber? Es ist halt eine Schätzung wie schnell geladen wird. Die Batterien sind nicht-linear... |
Describe the bug
Last night I had a splitted charge plan to due the dynamic prices from tibber: "From 3-4 und 13-14 -> Target SoC 80% to be reached at 17:45"
At 4 o'clock charging was not paused but continued until the Target SoC of 80% was reached.
Steps to reproduce
Configuration details
Log details
What type of operating system are you running?
Docker container
Version
0.123.8
The text was updated successfully, but these errors were encountered: