PENB Energy Label Approximation is a public application that converts standard apartment operational data into an indicative estimate of energy performance. The goal is not to replace a certified building energy performance certificate, but to provide owners, buyers, or consultants with a quick and defensible basis for further decisions.
Project Overview
The project combines several layers that are often handled separately in similar tools:
- validation of apartment and heating input data,
- working with meteorological data for the given location,
- calibration of a simplified RC model based on actual consumption,
- translating the result into an understandable energy class and reliability commentary,
- public bilingual deployment that can be shared instantly.
The result is not just a calculation. It’s a small product with an input workflow, computational core, report, and operational layer.
Problem
In practice, there is often a gap between what someone needs to know immediately and what a formal audit provides:
- an owner wants to quickly check if consumption matches the apartment’s parameters,
- an investor needs a preliminary screening before deeper due diligence,
- a consultant or portfolio manager seeks a way to prioritize units for further action.
A formal PENB is the right path for legal purposes, but for initial orientation it’s often too slow and expensive. This project was created precisely for situations where a quick, data-driven decision guide is needed.
Solution
Architecture
- Streamlit app as a public interface for entering parameters, calculation, and displaying results.
- Domain core in Python that validates inputs, prepares time series, calibrates the model, and simulates annual energy demand.
- Hybrid weather layer combining WeatherAPI, Open-Meteo, and a fallback mechanism for missing data.
- HTML report that converts the result into a format suitable for sharing or further review.
Design Principles
- Simple input for users, not a simple model at all costs.
- Transparent limitations: the app openly communicates that it provides an indicative estimate.
- Multiple calculation modes: from a quick estimate to more demanding calibration.
- Separation of computational logic from UI to allow independent iteration of the model and presentation.
Application Workflow
The app currently covers five main steps:
- Location – enter the place for which meteorological data is prepared.
- Apartment parameters – area, ceiling height, temperature regime, and heating type.
- Operational data – upload CSV or use sample data, select non-heating months, and estimate hot water usage.
- Calculation – select mode, calibrate the model, and simulate the reference year.
- Result – energy class, qualitative comment, basic metrics, and report export.
This is also important from a product perspective: the user is not exposed to technical model details until the input is properly prepared.
Key Features
- Three calculation modes based on the quality and scope of input data.
- Five logical UI screens guiding the user from input to result.
- Three weather and fallback layers to ensure the app remains robust if one source fails.
- Calibration based on actual consumption, not just static table approximation.
- Output focused on interpretation, not just a number without context.
| Area | Current Status |
|---|---|
| Public access | Yes, via a separate subdomain |
| Language versions | Czech and English |
| Result export | HTML report |
| Calculation modes | Basic, Standard, Advanced |
| Model type | Simplified RC model with calibration |
Deployment and Operations Layer
The project is deployed as a containerized Streamlit app. Importantly, this is not just a local experiment:
- there is a public Czech and English instance,
- it runs in Docker with separate storage and reporting,
- it’s ready for further iterations without needing to rewrite the entire interface,
- UI, domain logic, and reporting layers are clearly separated.
Just as important as the model itself is the fact that the result can be presented publicly and clearly. This makes the project a true case study, not just an internal analytics script.
Important limitations
The app output is an indicative estimate, not an official PENB. That’s why the project emphasizes explaining uncertainty, interpretation recommendations, and a clear distinction between quick screening and formal audit.
Article series on the app’s development
The project is accompanied by an introductory article and a five-part series covering the journey from problem definition through data to deployment:
- EPC from operational data: where estimation ends and decision begins – business and product context of the app.
- PENB Energy Label Approximation – Part 1: Why Waiting for a Formal Audit Isn’t Enough – why an indicative calculation from operational data makes sense.
- PENB Energy Label Approximation – Part 2: Turning Regular Consumption Data into Valid Input – how to prepare data for the model without unnecessary chaos.
- PENB Energy Label Approximation – Part 3: Weather, Heating Season, and the RC Model Without Magic – how weather, calibration, and simulation work together.
- PENB Energy Label Approximation – Part 4: Turning the Calculation into an App for Everyday Users – why UX is as important as the model.
- PENB Energy Label Approximation – Part 5: Deployment, Limitations, and What’s Next – a transparent look at operations, limits, and future direction.