2 Tarif Mode

[MaStr]

Native Support for low and high tariff zones, like Octopus energy.

[OliJue]

Ich schreibe gerade eine Erweiterung für meinen Stromtarif von Octopus mit zwei Tarifzonen. Bei einem ersten Versuch hat das Laden in der günstigen Tarifzone nicht geklappt.

Zur weiteren Untersuchung habe ich ein wenig Mock Code hinzugefügt:
core.py / def run()

        for h in range(fc_period + 1):
            production[h] = production_forecast[h] * \
               self.production_offset_percent
            consumption[h] = consumption_forecast[h]
            prices[h] = round(price_dict[h], self.round_price_digits)
            # MOCK DATA FOR TESTING PURPOSES, REMOVE IN PRODUCTION
            production[h] = 0
            consumption[h] = 200
            if h < 2:
                prices[h] = 0.1733
            else:
                prices[h] = 0.2734
            # MOCK DATA END

Dies überschreibt den erwarteten Solarertrag mit 0, setzt den Bedarf auf stündlich 200 und stellt die Preise fest auf zwei günstige Stunden und danach nur teure Stunden:

2026-02-20 21:12:00 DEBUG [batcontrol.core] Production Forecast: [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.
0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.]
2026-02-20 21:12:00 DEBUG [batcontrol.core] Consumption Forecast: [200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200.
200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200.
200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200.
200. 200. 200. 200. 200. 200.]
2026-02-20 21:12:00 DEBUG [batcontrol.core] Net Consumption Forecast: [200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200.
200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200.
200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200. 200.
200. 200. 200. 200. 200. 200.]
2026-02-20 21:12:00 DEBUG [batcontrol.core] Prices: [0.1733 0.1733 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734
0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734
0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734
0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734
0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734 0.2734]

Es wird erkannt, dass aktuell in der Batterie weniger ist, als zukünftig gebraucht wird. Trotzdem wird die Ladung nicht gestartet. Das Log zeigt bei der Bewertung folgendes an:

2026-02-20 21:12:00 DEBUG [batcontrol.core] Current interval factorization: elapsed=0.200, remaining=0.800
2026-02-20 21:12:00 DEBUG [batcontrol.logic.logic] Setting soften_price_difference_on_charging to False
2026-02-20 21:12:00 DEBUG [batcontrol.logic.logic] Setting soften_price_difference_on_charging_factor to 5
2026-02-20 21:12:00 DEBUG [batcontrol.logic.logic] Setting round_price_digits to 4
2026-02-20 21:12:00 DEBUG [batcontrol.logic.logic] Setting charge_rate_multiplier to 1.1
2026-02-20 21:12:00 DEBUG [batcontrol.core] Calculating inverter mode...
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] Calculating inverter control settings...
2026-02-20 21:12:00 DEBUG [batcontrol.logic.common] Discharge is NOT 'always allowed' for current capacity: 6113.0 Wh
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] Evaluating next 48 hours until 20:59
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] [Rule] Reserved Energy will be used in the next hours: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47]
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] [Rule] Reserved Energy: 9200.0 Wh. Usable in Battery: 5089.3 Wh
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] [Rule] Discharge forbidden. Stored usable energy 5089.3 Wh <= Reserved energy 9200.0 Wh
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] Discharging is NOT allowed
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] Charging allowed: True
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] Charging is allowed, because SOC is below 89%
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] [Rule] No additional energy required, because stored energy is sufficient.
2026-02-20 21:12:00 DEBUG [batcontrol.logic.common] Charging needed recharge energy is below threshold(100): 0.0 Wh
2026-02-20 21:12:00 DEBUG [batcontrol.logic.default] No additional energy required or possible price found.
2026-02-20 21:12:00 INFO [batcontrol.core] Mode: Avoid Discharging
2026-02-20 21:12:00 DEBUG [batcontrol.inverter.fronius] Fetching fresh time of use configuration from inverter
2026-02-20 21:12:00 DEBUG [batcontrol.inverter.fronius] Sending request to /api/config/timeofuse
2026-02-20 21:12:00 DEBUG [batcontrol.inverter.fronius] Cached time of use configuration
2026-02-20 21:12:00 DEBUG [batcontrol.inverter.fronius] Time of use configuration (ScheduleType and Power) is already identical, skipping update
2026-02-20 21:12:00 INFO [main] Next evaluation at 21:15:00. Sleeping for 179 seconds

In der batcontrol_config.yaml habe ich u.a. folgende Werte:

  min_price_difference: 0.05     # minimum price difference in Euro to justify charging your battery
  min_price_difference_rel: 0.10 # Percentage (in decimal) of the current price to justify charging your battery
                                 #    _rel helps to avoid charging at high prices with less efficiency
  always_allow_discharge_limit: 0.90 # 0.00 to 1.00 above this SOC limit using energy from the battery is always allowed
  max_charging_from_grid_limit: 0.89 # 0.00 to 1.00 charging from the grid is only allowed until this SOC limit
  min_recharge_amount: 100           # in Wh, start & minimum amount of energy to recharge the battery
  charge_rate_multiplier: 1.1 # Increase (>1) calculated charge rate to compensate charge inefficencies.
  soften_price_difference_on_charging: False # enable earlier charging based on a more relaxed calculation
                                             # future_price <= current_price-min_price_difference/soften_price_difference_on_charging_factor
  soften_price_difference_on_charging_factor: 5
  round_price_digits: 4 # round price to n digits after the comma

Weil ich den gesamten Code noch nicht ganz verstanden habe, wäre ich über Tipps dankbar, wie ich den Fehler weiter eingrenzen kann. Oder wie man die Tests besser mit pytest durchführen kann.

[MaStr]

Danke, dass du dich daran versuchst.

Du solltest lokal mit einem venv laufen. Wenn du ./run_tests.sh ausführst, werden alle notwendigen Abhängigkeiten und dann die komplette Serie der Unit Tests ausgeführt.

Zum log schreibe ich gleich noch etwas.

[MaStr]

Ok, du hast in dem Mock einen interessanten Fall erwischt. Verkürze die günstigsten Stunden mal auf eine Stunde. Er lädt immer erst am letzten günstigen Slot bevor es wieder teurer wird.

Wenn das "soften_price" anmachst, würde er schon früher starten zu laden.

Batcontrol arbeitet in der default Logik wie folgt:

Summe Wh der Stunden teurer als jetzt= reserviert.

Ist das Tal bei fallenden Preisen erreicht? Wenn ja, dann schaue ob du current_price (tal) + min-diff slots findest, bilde ein Summe und lade das nach. Das kann zB bei großen Batterien dazu führen, dass nicht genug geladen werden kann. Für den Fall gibt es diesen "soft" Effekt, dann ist das Tal früher da, bzw. weicher abgegrenzt.

[MaStr]

python -m pytest tests/batcontrol/logic/test_default.py::TestDefaultLogic::test_charge_calculation_when_charging_possible -v

Bei Bedarf die Parameter reduzieren um die ganze Klasse zu testen etc.

Unsere logs kannst du aktivieren mit folgenden flags am Ende -s --log-cli-level=DEBUG

[OliJue]

Ah, ja, das mit dem soften_price hatte ich gelesen, aber mit hat der Kontext gefehlt. Ich dachte, dass dies in meinem Fall keine Rolle spielt. Mit der Verkürzung auf eine Stunde legt das System gleich los. Und für später, wenn man mehrere Stunden einen niedrigen Preis hat, macht es vermutlich mehr sinn, immer den soften_price zu aktivieren. Man muss die Ladung ja nicht in einer Stunde reinpressen, wenn es auch über mehrere Stunden verteilt werden kann.
Danke, jetzt kann ich meinen Code weiter testen.

[MaStr]

Ich hab eben noch mal über das mit dem soft_price nachgedacht. Das würde sofort zum Start der low-Zone loslegen. Das wäre ungeschickt, weil dann der standby Verbrauch immer was abknapst.

Eventuell muss man doch anhand lademenge / max_charge = slots -1 vorrausschauen für den ladezeitpunkt 🤔

Edit: mit —one-shot kannst du alles einmal durchlaufen lassen ohne im Control Loop in eine Schleife zu hängen.. falls es hilft.

[OliJue]

Ja, das hat noch andere Nebeneffekte. Zum Anfang einer Stunde sieht es von den Laderaten ok aus:

2026-02-20 22:06:53 DEBUG [batcontrol.logic.default] [Rule] Stored usable Energy: 4905.0 , Recharge Energy: 3895.0 Wh
2026-02-20 22:06:53 DEBUG [batcontrol.logic.default] [Rule] Recharge limited by free capacity: 3799.0 Wh
2026-02-20 22:06:53 DEBUG [batcontrol.logic.default] Required recharge energy limited by max. charging limit to 2729.0 Wh
2026-02-20 22:06:53 INFO [batcontrol.logic.default] Get additional energy via grid: 2729.0 Wh
2026-02-20 22:06:53 DEBUG [batcontrol.logic.common] Calculating charge rate: 3082.6030749921565
2026-02-20 22:06:53 DEBUG [batcontrol.logic.common] Adjusted charge rate: 3391 W
2026-02-20 22:06:53 INFO [batcontrol.core] Mode: grid charging. Charge rate : 3391 W

Aber wenn man es zum Ende einer Stunde startet, dann bekommt es fast Schnappatmung :-)

2026-02-20 21:51:00 DEBUG [batcontrol.logic.default] [Rule] Stored usable Energy: 5068.8 , Recharge Energy: 3731.2 Wh
2026-02-20 21:51:00 DEBUG [batcontrol.logic.default] [Rule] Recharge limited by free capacity: 3635.2 Wh
2026-02-20 21:51:00 DEBUG [batcontrol.logic.default] Required recharge energy limited by max. charging limit to 2565.1 Wh
2026-02-20 21:51:00 INFO [batcontrol.logic.default] Get additional energy via grid: 2565.1 Wh
2026-02-20 21:51:00 DEBUG [batcontrol.logic.common] Calculating charge rate: 17100.800000000007
2026-02-20 21:51:00 DEBUG [batcontrol.logic.common] Adjusted charge rate: 18811 W
2026-02-20 21:51:00 INFO [batcontrol.core] Mode: grid charging. Charge rate : 5000 W

Mein twotariffmode fügt sich so gerade gar nicht harmonisch in den gesamten Code ein (bzw. ich habe das noch nicht wirklich verstanden.)

Meine ursprüngliche Idee war es, dass in den Nachtstunden (bei mir sind es 5 Stunden) schön gleichmäßig der Akku gefüllt wird.

[MaStr]

Ne, gleichmäßig laden über alle Stunden tut er nicht. Das passt nicht in die Logik.

Alternativ kann man einen 2 Tarif Logik Modus bauen, der dann die Eigenarten berücksichtigt.

[MaStr]

Mir fällt gerade ein, dass das langsame steige Laden ineffizienter ist als stark mit viel Leistung.
Ich glaube das war in einem Video von Akku Doctor, dass mit zunehmender Leistung zu Ladung und Entladung die Effizienz nach oben geht.

[MaStr]

Lustig, die logs habe ich heute Morgen nicht so wirklich wahrgenommen.. kein mehr GitHub vor  dem ersten Kaffee. Also das Verhalten mit der ansteigenden ChargeRate liegt an charge_rate_multiplier . Dazu gibt es einen Eintrag im Wiki. Vielleicht sollte ich den default mal auf 1.5 anheben. Am 20. Feb. 2026, 22:14 +0100 schrieb OliJue ***@***.***>:

…

OliJue left a comment (MaStr/batcontrol#136) Ja, das hat noch andere Nebeneffekte. Zum Anfang einer Stunde sieht es von den Laderaten ok aus: > 2026-02-20 22:06:53 DEBUG [batcontrol.logic.default] [Rule] Stored usable Energy: 4905.0 , Recharge Energy: 3895.0 Wh > 2026-02-20 22:06:53 DEBUG [batcontrol.logic.default] [Rule] Recharge limited by free capacity: 3799.0 Wh > 2026-02-20 22:06:53 DEBUG [batcontrol.logic.default] Required recharge energy limited by max. charging limit to 2729.0 Wh > 2026-02-20 22:06:53 INFO [batcontrol.logic.default] Get additional energy via grid: 2729.0 Wh > 2026-02-20 22:06:53 DEBUG [batcontrol.logic.common] Calculating charge rate: 3082.6030749921565 > 2026-02-20 22:06:53 DEBUG [batcontrol.logic.common] Adjusted charge rate: 3391 W > 2026-02-20 22:06:53 INFO [batcontrol.core] Mode: grid charging. Charge rate : 3391 W Aber wenn man es zum Ende einer Stunde startet, dann bekommt es fast Schnappatmung :-) > 2026-02-20 21:51:00 DEBUG [batcontrol.logic.default] [Rule] Stored usable Energy: 5068.8 , Recharge Energy: 3731.2 Wh > 2026-02-20 21:51:00 DEBUG [batcontrol.logic.default] [Rule] Recharge limited by free capacity: 3635.2 Wh > 2026-02-20 21:51:00 DEBUG [batcontrol.logic.default] Required recharge energy limited by max. charging limit to 2565.1 Wh > 2026-02-20 21:51:00 INFO [batcontrol.logic.default] Get additional energy via grid: 2565.1 Wh > 2026-02-20 21:51:00 DEBUG [batcontrol.logic.common] Calculating charge rate: 17100.800000000007 > 2026-02-20 21:51:00 DEBUG [batcontrol.logic.common] Adjusted charge rate: 18811 W > 2026-02-20 21:51:00 INFO [batcontrol.core] Mode: grid charging. Charge rate : 5000 W Mein twotariffmode fügt sich so gerade gar nicht harmonisch in den gesamten Code ein (bzw. ich habe das noch nicht wirklich verstanden.) Meine ursprüngliche Idee war es, dass in den Nachtstunden (bei mir sind es 5 Stunden) schön gleichmäßig der Akku gefüllt wird. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[OliJue]

Mit soften_price_difference_on_charging: enabled und max_grid_charge_rate: 1800 hatte ich letzte Nacht einen Verlauf, wie ich ihn mir vorgestellt habe: 3,9 h kontinuierliches Laden, 1,1h Akku gesperrt (immer noch in der günstigen Preiszone) und danach freigegeben.
Ich mache mal einen Pull Request.

[MaStr]

Wenn du magst, könntest du deine Änderung noch gegen den folgenden Branch testen: copilot/update-logic-charge-rate-calculation

Das ändert den Ladealgorythmus (wenn aktiviert) so ab, dass

• Ausgerechnet wird ob mit dem maximalen LadePower (-Verlust) eine Stunde nicht reicht, dann
• überträgt er den Rest auf die vorhergehende Stunde dabeu muss
• die Preisdifferenz aber immernoch min_price_diff / 2 sein.

Alledings berücksichtigt die Änderung nur, dass man den Ladeslot vom Tal erweitert auf einen Slot vor dem Tag. Das entspricht vermutlich auch nicht deinem Wunsch.. sollte aber dazu führen, dass er früher startet zu laden. Das ist eine Alternative zum "soften_price" Setting.

[OliJue]

Das kann ich gerne mal prüfen.

Ich hatte in meinem Programmcode schon eine kleine Doku reingeschrieben:
Option A) Wie verteile ich die Ladung über möglichst die ganze Zeit => (soften: true + maximale Ladeleistung runter)
Option B) Akku erst zum Ende möglichst mit hoher Ladeleistung laden => soften: false

Für Option B könnte gut die Branch passen, falls ein Slot nicht ausreichend wäre.

Frage zur neuen Branch: verteilt er auf maximal 2 Slots, oder kann die neue Funktion auch auf 3, 4, ... n Slots verteilen?