Open source · Swiss ZEV & vZEV · self-hosted · AGPL-3.0
Import the load curves, split the solar between participants per 15-minute interval, price it against your tariffs, send a QR-bill invoice. I wrote it to bill my own ZEV, and put it out in case it is useful for yours.
Energy balance · demo community · Q3 2026
The same split the billing engine performs — min(production, consumption) per 15-minute interval — is what every invoice line is derived from.
What it does
Billing a ZEV is easy for one month. It gets harder when last year's tariff still has to exist, when someone who moved out in March has to be billed for March, and when the invoice has to be something a neighbour accepts without asking for the spreadsheet behind it.
The formats Swiss utilities actually send, plus whatever your own meter exports.
Each interval is priced with the tariff version that was valid at that timestamp. Nothing is averaged over the month.
Invoices render as PDF/A-3b with a QR-bill payment slip, and move through draft, approved, sent, paid. Cancelling keeps the document and its number rather than deleting the row. Annual statements and participation contracts come out of the same renderer, and every issued version is kept as it was sent.
Admins, ZEV owners and participants each get their own view of the same data. Assignments between participants and metering points carry validity dates, so someone moving out on 15 March is billed to 15 March.
Estimates savings, payback, ROI and NPV for a planned community. If you already run one, it can prefill from its participants and measured self-consumption.
Screenshots
From the demo community that ships with the project, seeded with one command.
Each period shows the action it needs, so you start on the work instead of going looking for it. The period that is still collecting data just says so.
Production, consumption, self-consumption and grid exchange for the selected period, with a Sankey diagram tracing every kWh from producer to participant. Filter by participant or change the resolution down to the interval.
Every invoice for the period with its metering completeness, status, total and PDF state, plus batch actions for the steps you would otherwise repeat once per household.
A tariff is a series of versions, each with its own bands and validity window. An invoice raised last year still prices at last year's rate, and the chart shows when each change took effect.
Quick start
Pick the one that matches where you want it to live. All three pull prebuilt images from GHCR.
Starts the stack and seeds a full community — participants, meters, tariffs and readings — so there is something to look at.
# clone, then: scripts/start-demo-environment.sh # → http://localhost:8080 # admin@openzev.local / admin1234
The full stack — frontend, API, Celery worker and beat, PostgreSQL and Redis — with no demo data.
docker compose up -d --build # frontend :8080 # api :8001 docker compose down
The chart deploys frontend, backend, worker and beat into your cluster with an Ingress and a media PVC. Bring your own PostgreSQL and Redis.
helm repo add openzev \ https://splattner.github.io/openzev helm repo update helm install openzev openzev/openzev \ -n openzev --create-namespace
Under it
I built OpenZEV to run my own ZEV, and I share it as-is, with no warranty. It suits people who enjoy running their own stack. Check your imports, your tariffs and your invoices before they reach a participant: responsibility for what the numbers say stays with you.
It is also built with a lot of AI assistance, down to the specs, ADRs and user documentation. Some choices will look unconventional to an experienced team. That is the trade I made: the project is optimised for learning, experimentation and running one real ZEV, rather than for enterprise process.