andig
commented
7 months ago Sieht aus als hätte er aus irgendeinem Grund die Lücke ignoriert. Gutes Logfile, danke!
Closed BeckerWdf closed 7 months ago
andig
commented
7 months ago Sieht aus als hätte er aus irgendeinem Grund die Lücke ignoriert. Gutes Logfile, danke!
andig
commented
7 months ago 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 smallGapDuration ist aktuell 1h- deshalb wird zwischen 4:00 und 4:50 nicht mehr abgeschaltet. Änderung eingeführt in https://github.com/evcc-io/evcc/pull/7419. Da müsst ihr Euch einig werden ;)
/cc @Hofyyy @schenlap
andig
commented
7 months ago Bessere Log messages in https://github.com/evcc-io/evcc/commit/f73e064e9d707beb001b4986d52d1663301ac44c
BeckerWdf
commented
7 months ago Die
smallGapDurationist aktuell 1h- deshalb wird zwischen 4:00 und 4:50 nicht mehr abgeschaltet. Änderung eingeführt in #7419. Da müsst ihr Euch einig werden ;)
Aber es sollte doch erst um 13 Uhr weitergehen. Das ist ja deutlich mehr als 1h. ;-)
andig
commented
7 months ago Ist für mich nicht erkennbar:
plan: charge 1h9m40s starting at 2024-01-27 04:50:20 +0100 CET until 2024-01-27 17:45:00 +0100 CET (power: 11040W, avg cost: 0.233)
Da steht klar 4:50?
BeckerWdf
commented
7 months ago Ist für mich nicht erkennbar:
plan: charge 1h9m40s starting at 2024-01-27 04:50:20 +0100 CET until 2024-01-27 17:45:00 +0100 CET (power: 11040W, avg cost: 0.233)
Da steht klar 4:50?
Also dieser Plan wurde gesetzt:
smarthome-evcc-1 | [site ] DEBUG 2024/01/26 20:03:47 set db:1 plan soc: 80 @ 2024-01-27 17:45:00 +0100 CET
smarthome-evcc-1 | [site ] DEBUG 2024/01/26 20:03:56 ----
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 charge power: 0W
smarthome-evcc-1 | [site ] DEBUG 2024/01/26 20:03:56 pv power: 0W
smarthome-evcc-1 | [site ] DEBUG 2024/01/26 20:03:56 grid power: 2345W
smarthome-evcc-1 | [site ] DEBUG 2024/01/26 20:03:56 site power: 2345W
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 charge voltages: [235 233 238]V
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 detected connected phases: 3p
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 charge currents: [0 0 0]A
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 charge total import: 2738.879kWh
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 charger status: B
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 plan: charge 1h59m5s starting at 2024-01-27 03:00:55 +0100 CET until 2024-01-27 17:45:00 +0100 CET (power: 11040W, avg cost: 0.234)
smarthome-evcc-1 | [lp-1 ] DEBUG 2024/01/26 20:03:56 pv charge current: 0A = 0A + -3.4A (2345W @ 3p)
smarthome-evcc-1 | [site ] DEBUG 2024/01/26 20:04:06 ----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?
schenlap
commented
7 months ago 03:00:56 plan: charge 1h59m5s starting at 2024-01-27 03:00:57
Da war der Plan etwas kürzer als 2 Stunden, also werden 2 Slots geplant. Um 3 begonnen ist OK.
04:00:06 plan: charge 1h9m40s
Da gibt es jetzt den Sonderfall dass
a) die zuvor geschätzte Ladezeit überschritten wird. Nach 1h laden bleiben noch immer 1h9min Rest. Es muss daher ein dritter Slot verwendet werden.
b) zuvor schon geladen wurde und daher der nächstgünstige Slot (welcher eigentlich erst später aktiviert werden müsste) eingeschaltet bleibt. Das wird auch in der Log-Meldung angezeigt (will re-start shortly, continuing for remaining 50m13s).
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. Wenn man die ganzen Sonderfälle rausnehmen würde dann wäre er vielleicht um 14:00 noch nicht ganz fertig gewesen (sieht man in Log nicht) und hätte auch nach 14:00 noch laden müssen, da wäre der Preis aber einiges höher gewesen. Ich würde da am Verhalten nichts ändern.
Mit Trace hat er zumindest früher mal die einzelnen Slots angezeigt. Vielleicht geht das immer noch.
schenlap
commented
7 months ago Aber es sollte doch erst um 13 Uhr weitergehen. Das ist ja deutlich mehr als 1h. ;-)
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.
andig
commented
7 months ago Wichtig zu wissen ist, dass bei jedem Durchlauf ein neuer Plan erzeugt wird. Ich denke hier ist alles beantwortet?
BeckerWdf
commented
7 months ago Das war nur der ursprüngliche Plan. Da der SoC nicht schnell genug abgenommen hat du meinst zugenommen oder? 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.
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:
um 14:00 noch nicht ganz fertig gewesen wäre und auch nach 14:00 noch laden müssen, da wäre der Preis aber einiges höher gewesen.
BeckerWdf
commented
7 months ago 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.
Was meinst du mit "ständigem ein/aus schalten"? Wann würde das passieren und warum ist das schlecht?
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.
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.
andig
commented
7 months ago In meinem Fall hat er also 1h lang in einer Stunde geladen, die teurer war als eine günstigere, die noch gekommen wäre.
Das würde er nicht tun und gibt Dein Screenshot auch nicht her!
BeckerWdf
commented
7 months ago In meinem Fall hat er also 1h lang in einer Stunde geladen, die teurer war als eine günstigere, die noch gekommen wäre.
Das würde er nicht tun und gibt Dein Screenshot auch nicht her!
Leider hab ich das Plan-UI nicht als Screenshot festgehalten....
andig
commented
7 months ago Oben ist dein Tibber Screenshot. Der nächste Slot ist der nächstbilligste. Hier ist alles ok.
BeckerWdf
commented
7 months ago 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?
andig
commented
7 months ago Wird er doch 🙄. Aber die eine Stunde reicht nicht, also brauchts noch einen Slot. Long Story short: der Planner funktioniert perfekt.
BeckerWdf
commented
7 months ago 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.
andig
commented
7 months ago 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