Kwame Sellick-Cole
← All projects
CourseworkCollaborative project

Thermally constrained home battery controller

A price-driven controller with thermal protection for a simulated 13.5 kWh home battery, built around explicit physical constraints and the automated tests that check them.

Context
TU/e coursework (4EM30) · Feb–Mar 2026
Role
Collaborative project, team of two
Tools
Python, pytest, GitLab CI, Sphinx
  • Python
  • pytest
  • Control
  • Thermal modelling
  • Software testing

Problem

A home battery can shift energy in time: charge when electricity is relatively cheap and discharge when it is relatively expensive. Charging and discharging also heat the battery, so a controller has to respect thermal limits as well as capacity and power limits. The project simulates such a system hour by hour and requires every physical and logical constraint to hold.

My contribution

A collaborative project in a team of two. My responsibilities were:

  • the battery class (energy dynamics, power limits, state of charge) and its tests;
  • the controller module, implementing the two-threshold policy, and its tests;
  • the thermal dynamics, derating and critical shutdown in the battery and controller classes;
  • the tables of physical and logical constraints that the tests are built from;
  • the test and coverage scripts.

My teammate added further thermal and controller test cases and extended the test documentation. The forecasting and plotting modules and the example script came with the course template.

Approach

Battery. 13.5 kWh capacity, 5 kW maximum charge and 10 kW maximum discharge, with charge and discharge efficiencies of 0.94 and 0.95. Efficiency losses heat the battery (thermal mass 5 × 10⁴ J/K), and Newton cooling to ambient removes heat (4 W/K).

Thermal protection. Each hour, the battery computes a derated power limit so that the step cannot take it above 50 °C. If it ever reaches 55 °C, the controller forces it idle.

Controller. It compares the current price with the demand-weighted average of the next 24 hours of recorded prices, giving a relative price θ. That sets two target states of charge: the battery charges up to the lower target when θ is low, discharges down to the upper target when θ is high, and idles in between.

Testing. We listed every constraint the model must respect, from state of charge staying within 0–100% and never charging and discharging at once, to power staying within the derated limits and idling at the critical temperature. Each constraint became one or more tests: 79 in total (19 battery, 42 controller, 18 forecast). They run in GitLab CI, and the documentation is built with Sphinx.

The battery and controller modules have 100% line coverage and the forecast module 93%. This shows that every line runs under test and behaves as specified. It does not show that the model or its parameters represent a real battery.

Results

Simulation over 1,343 hours of recorded price, demand and weather data from 6 January to early March 2025. The results come from the project's example script, revised so the simulation runs through the tested battery and controller classes and updates the battery temperature each hour.

  • The battery charged in 220 hours, discharged in 137 and idled in 986.
  • Its temperature ranged from −2.6 °C, idle in winter air, to 50.0 °C. It reached the derating limit but never went above it, and the derated limit decided the power in 19 hours.
Figure 1. Control policy check. State of charge at the end of each hour against relative price, coloured by mode. Charging hours end on the charge target (dashed) and discharging hours on the discharge target (dotted), unless a power limit stopped them short. This confirms the controller follows the designed policy.
Figure 2. Four simulated days. Price, state of charge and battery temperature, 18–21 January 2025. The battery charges in price dips and discharges into evening peaks; each hard charge or discharge heats it, and derating holds it at the 50 °C limit.

Limitations

  • No savings against a baseline were calculated: the simulation does not account for household demand served or energy bought and sold, so it makes no claim about profitability.
  • The price forecast uses the actual next 24 hours of recorded prices, which assumes perfect foresight.
  • Parameters are typical values, not measurements of a specific battery, and the thermal model uses a one-hour explicit time step.