Developer
Independent engineering project
Limassol Hotel Battery Dispatch
A testable Django service for deterministic 15-minute photovoltaic, load, tariff, and battery dispatch reporting.
Scroll to inspect the full diagram →
PV / load / storage / gridArchitecture abstraction
The problem
Represent a defensible weekly battery-dispatch slice with transparent assumptions and a report that can be regenerated locally.
System architecture
- A Django service with thin views and separate load, tariff, solar, dispatch, pipeline, and reporting services.
- One deterministic representative week at 15-minute intervals.
- SQLite persistence for input time-series points and derived dispatch rows.
- A greedy, explainable policy that prioritises solar-to-load, then charging, discharge, import, and curtailment.
Engineering decisions
- Prefer a transparent greedy policy over presenting the project as mathematical optimisation.
- Keep a deterministic solar fallback for local execution while clearly labelling its purpose.
- Track derived dispatch data separately so it can be regenerated from source inputs.
Testing and verification
- Django system checks and tests for dispatch, reporting, and views.
- Deterministic bootstrap of 672 fifteen-minute intervals.
Limitations
- The hotel load is synthetic and deterministic, not measured site data.
- The policy is not a full optimiser and does not model grid charging.
What I would improve next
- Compare controlled grid charging against the simple solar-only policy.
- Add versioned report snapshots and clearer finance-facing outputs.