Building My Own Octopus Energy Dashboard
A self-hosted Octopus Energy dashboard that preserves meter readings, tariff evidence and supplier allocations instead of guessing what energy should have cost.
All I wanted was…
to know how much my solar was saving me.
Then it escalated quickly.
That sounds like a simple question until a solar array, battery, import tariff, export tariff, EV charging and half-hourly supplier data all start describing different parts of the same day. I did not set out to build a tariff-evidence engine; I wanted one number I could actually trust.
It is now open source
What started as a local tool for understanding my own Octopus Energy data is now a standalone self-hosted project.
The source is available on GitHub: joakim-home/octopus-energy-history.
The public version is an ASP.NET Core web service backed by SQLite. It includes a Linux/systemd installer, update and uninstall paths, a local administrator login, encrypted supplier credentials, health monitoring and a test suite. It is licensed under AGPL-3.0-only.
Why build another dashboard?
A car, charger, battery, solar array, household meter and supplier each describe a different part of the same event. The useful question is not only “what did energy cost?” but also “which data source established that result?”
That distinction becomes particularly important with Intelligent Octopus Go and four-rate periods. A meter reading does not identify an EV charge. A charging session is not a complete tariff schedule. A low-price-looking half hour is not enough evidence to reprice the whole house.
The dashboard therefore keeps the raw evidence separate and only combines it when the data supports doing so.
Architecture
The current project uses a layered ASP.NET Core design with application, domain and infrastructure projects behind a Razor Pages web interface. SQLite holds raw supplier readings as well as derived daily and monthly views, so the dashboard can retain the original evidence while still giving fast historical analysis.
Supplier tariff metadata, interval allocations and meter readings remain separate records. Four-rate allocation uses supplier-calculated allocation evidence and reconciles it against meter import before those costs are trusted.
If the evidence is missing or inconsistent, pricing fails closed: consumption remains visible but the affected cost is marked unavailable rather than filled in with a convenient guess.
The rule: do not guess the price
The central design rule survived every iteration of the project: do not make uncertain billing data look certain.
That means:
- tariff data describes available rates and agreement context;
- supplier allocations describe how quantities were assigned to tariff bands;
- household meter readings describe import or export;
- EV charging evidence describes charging activity, not automatically household cost;
- issued bills remain separate billing-period evidence.
Public installation
The GitHub version is intended for a small Debian/Ubuntu-style Linux host, VM or LXC. The installer builds a self-contained Linux application, creates a dedicated service account, stores persistent data beneath /var/lib, installs a hardened systemd service and binds the application to localhost by default.
A reverse proxy such as nginx or Caddy can then provide LAN access.
Authentication is enabled by default for public installs. On first use the dashboard creates a single local administrator account, hashes the password with ASP.NET Core's password hasher and rate-limits login attempts.
For a deliberately trusted private LAN, authentication can instead be explicitly disabled with:
OCTOPUS_AUTH_DISABLED=1
That is how I prefer to run my own local instance: the service is not public-facing, so I do not want another login prompt inside my house.
Tested as a service, not just as source code
Before publishing it I tested the full Linux lifecycle in a disposable WSL environment:
- clean install and systemd startup;
- /health readiness;
- update/reinstall while preserving the database and encryption key;
- authentication and cookie persistence across service restart;
- administrator reset with existing-session revocation;
- uninstall while preserving persistent data;
- explicit purge of persistent data.
The current automated suite contains 121 passing tests.
The repository was also stripped of deployment-specific credentials, databases, account identifiers, private hostnames and historical local build artefacts before publication.
Where it stands
This remains a personal/community project rather than an Octopus Energy product or a replacement for an issued bill. Supplier APIs and tariff structures can change, and unsupported or ambiguous data should remain visibly unsupported rather than being silently approximated.
That is also why I released the implementation rather than only screenshots. The interesting part is not the graph colours; it is the chain of evidence behind the number on the graph.
If you run Octopus Energy and enjoy self-hosting, the repository is here: