The problem with traditional energy systems
Traditional energy systems often lack flexibility, transparency and accessibility for small-scale producers and consumers. People who could take part in producing or sharing energy have few simple tools for doing it, or for seeing where energy goes.
Electric Trees works in this area. Its public site describes solar for apartment renters and flat-rate EV charging. The platform in this case study is the management system: a web application for setting up companies, configuring virtual energy grids, tracking usage and handling top-ups.
That combination is harder than it first appears. Every company and grid can be set up differently, several types of user need different permissions, and any record of energy or money has to stay accurate even when many things happen at once.
What we knew before we built
No before-and-after baseline is published for this project, so this page does not offer an improvement figure. What can be stated is what the system had to support.
- 3
- User roles to separate: admin, company and end user
- 2
- Services on the company's public site: apartment solar and flat-rate EV charging
- 1
- Normalized MySQL schema to hold companies, grids, panels and transactions
That set three requirements for the work. The data model had to cope with many different company and grid setups. Each role had to see and do only what belonged to it. And energy top-ups had to stay accurate when they happened at the same time.
The approach we chose
We built a full-stack web application on Python and Django, with a modular architecture organized around its three roles:
- Admin. Oversight of the platform and the people using it.
- Company. Creating a company, adding energy grids and managing how energy is distributed.
- End user. Tracking energy usage and buying top-ups.
A company's path through the platform runs in four steps:
- Create. A user sets up their own company on the platform.
- Configure. They add virtual grids and panels, and define how these connect.
- Track. Energy usage is calculated and reported on dashboards.
- Top up. Users buy and manage energy top-ups through protected database transactions.
What we built
Our contribution was the full-stack application: the architecture, backend, database and HTML and CSS interface.
Energy grid models
We built models to represent grids, panels and their interconnections, which allows energy resources to be allocated dynamically rather than fixed in advance.
Company creation and management
Users can create their own companies, add energy grids and manage how energy is distributed across them.
Usage tracking
Real-time energy usage calculation feeds reporting dashboards, so that users can see how energy is being consumed.
Protected top-up transactions
Energy top-ups run through Django ORM and database transactions, so that a purchase either completes in full or does not happen at all.
A normalized database
The MySQL schema was normalized to protect data integrity, support growth and keep queries performing well. REST APIs and Django's role-based authentication sit on top of it.
Any record of energy or money has to stay correct, even when two things happen at the same moment.
The guardrails around energy data
Usage and top-up records affect what people pay and what they can draw on. Protecting those records was built into the platform rather than added afterwards.
- Atomic transactions. Top-ups use Django's atomic transactions, so that a partly completed purchase cannot be left behind.
- Database locking. Locking prevents race conditions when simultaneous top-ups affect the same data.
- Fine-grained access. Django's authentication system and custom middleware control what each role can do.
- Separated roles. Admin, company and end-user permissions are kept distinct.
- Data integrity. A normalized schema reduces duplicated data that could otherwise fall out of step.
What was reported
The project delivered a platform for creating companies, configuring grids, tracking usage and handling top-ups. The effects below are what the project team reported; none of them is a measured result:
- Transparency. Decentralized energy networks can be created and managed in a visible, accountable way.
- Operations. Energy usage monitoring and transaction processes were reported to be more streamlined.
- Scale. The platform was reported to handle multiple company and user profiles reliably. No load figures are published here.
- Future work. The design lays the groundwork for IoT-based monitoring and analytics, which is a possible next step and not a shipped feature.
What stays hard
Three challenges shaped this work, and any team building a platform like this should plan for them. Each came with a specific solution.
- Complex grid modelling. Companies and grids come in many configurations, so the model has to adapt. We used modular database entities that allow dynamic relationships between grids, panels and users.
- Role-based access control. Different types of user need different permissions, down to individual actions. We used Django's authentication system with custom middleware for fine-grained control.
- Transaction consistency. Simultaneous top-ups can corrupt a balance if nothing prevents it. We used Django's atomic transactions and database locking to prevent race conditions.