novinky

  • PENB Label Approximation – Part 1: Why Waiting for a Formal Audit Isn’t Enough

    Series: PENB Energy Label Approximation – Lessons from Building a Public Application

    Series goal:
    Describe the project from problem definition through data and modeling to public deployment, highlighting where data science, product thinking, and quality implementation meet.


    Related Parts

    1. Why waiting for a formal audit isn’t enough – when an indicative calculation is more useful than waiting.
    2. How to turn regular consumption into valid input – what needs to be prepared before the model can start.
    3. Weather, heating season, and an RC model without magic – where domain logic meets data.
    4. How to turn a calculation into an app for everyday users – why UX is more than just cosmetics.
    5. Deployment, limitations, and what’s next – what works today and what should come in the next iteration.

    Part 1: Why waiting for a formal audit isn’t enough

    Where the real problem started

    A formal PENB makes sense when you need to meet a legal requirement or need a final document for sale or rental. But most decisions happen earlier.

    People want to know:

    • if their consumption is normal,
    • whether it’s worth investing in apartment improvements,
    • if a specific apartment is suspiciously energy-intensive,
    • whether it makes sense to proceed with deeper analysis.

    At this stage, a formal audit is usually too slow. You need a quick but still defensible signal.


    The hardest part isn’t the calculation, but defining the problem correctly

    Projects like this clearly show the difference between a technically interesting model and a practically useful product.

    The technical question is:

    Can you estimate an apartment’s energy consumption from operational data?

    The product question is different:

    Can you quickly and clearly help someone decide whether it’s worth analyzing their apartment in detail?

    The second question is more important. That’s why this app wasn’t created as a replacement for a certified PENB, but as a tool for initial orientation.


    Why operational data makes sense

    People often don’t have the building’s technical documentation at hand, but they do have:

    • bills and consumption data,
    • basic apartment parameters,
    • information about the heating source,
    • a rough idea of how they use the apartment.

    It’s not a perfect dataset. But it’s a dataset that actually exists. And a good product often starts where data is truly available, not where it would be ideal.


    What such a tool must deliver

    For the app to be useful, it must meet four criteria:

    • be fast, so it helps even before a formal audit,
    • be clear, so the result isn’t just another technical barrier,
    • openly acknowledge limitations, because uncertainty can’t be hidden,
    • be publicly accessible, so the principle can be demonstrated immediately in practice.

    That’s also why the project didn’t end up as just a notebook script. From the start, it was headed toward becoming an application.


    The value for users is in decisions, not just numbers

    The energy class itself is only part of the result.

    The greater value is that the application helps answer practical questions:

    • is it worth continuing with due diligence,
    • is the consumption consistent with the apartment’s parameters,
    • is it appropriate to plan a renovation,
    • is it worth ordering a detailed audit.

    In other words: the project stands out because it turns unclear operational data into an actionable framework for the next step.


    What’s next

    In the next part, I’ll look at why it’s critical for this kind of application to properly prepare input data, how to separate heating from regular usage, and why input validation often matters more than model optimization itself.

  • PENB Label Approximation – Part 4: Turning the Calculation into an App for Everyday Users

    Part 4: Turning a Calculation into an App for Everyday Users

    Why the Right Model Isn’t Enough

    Many technical projects fail not because the model is wrong, but because real users can’t interact with it. For a PENB approximation app, this is especially important since the target audience isn’t just analysts.

    A usable public app must meet three requirements at once:

    • the user must understand what to enter,
    • the system must receive consistent input,
    • the output must be readable even without deep technical knowledge.

    Five Steps Instead of One Overwhelming Screen

    The current interface uses a logical breakdown into several steps: location, apartment, data, calculation, and result. This is important for practical reasons.

    When people see everything at once, it’s easy to lose context. Guiding them step by step increases the chance of correct input.

    This isn’t just a UX rule. It’s also a way to improve the quality of data that ultimately reaches the model.


    The Form as Part of Domain Logic

    A public app shouldn’t just be a thin layer over the backend. In this project, the form actively helps structure the input:

    • guides users to the truly essential information,
    • distinguishes between quick and detailed calculation modes,
    • handles months without heating and hot water right at input,
    • sets the stage for interpreting the result.

    From this perspective, UX is not separate from data science. It’s one of the layers that determines whether the model receives meaningful input.


    The result must be understandable, not just accurate

    The user usually doesn’t need to know all the internal calibration parameters. They need to understand:

    • what energy class the calculation yields,
    • how reliable the estimate is,
    • what the interpretation limits are,
    • what the next logical step is.

    That’s why the output combines the energy class, key metrics, a written comment, and an exportable report. The result serves as a communication artifact, not just a technical intermediate output.


    Bilingualism as a product feature

    An interesting part of the project is that the application isn’t just prepared for local testing. It has both Czech and English language versions. This increases usability for project presentations, sharing with clients, and further development.

    Technically, this means more work. But from a product perspective, it significantly boosts the application’s overall value.


    What’s next

    In the final part, I’ll cover deployment, report export, current project limitations, and what I would expand or refine in the next iteration.

  • EPC from operational data: where estimation ends and decision begins

    EPC from operational data: where estimation ends and decision begins

    The EPC Energy Label Approximation project shows that even without a lengthy manual process, it is possible to obtain a useful first estimate of a flat’s energy performance from operational data. The aim is not to replace the official energy performance certificate, but to offer a fast, understandable and data-driven view of how the property is likely to perform.


    How the application looks in practice

    The first demo shows part of the workflow where the user enters the basic parameters of the apartment, the indoor temperature regime and the type of heating. This is where it becomes clear how important it is to combine technical correctness with simple operation, so that the input to the model is understandable even for the average user.


    Screenshot of the PENB application interface for apartment parameters, indoor temperature and heating system
    Example of the input form for apartment parameters, temperature profile and heating system.

    The second demo focuses on the data layer: uploading a CSV with consumption data, selecting non-heating months and approximating water heating. This is an important point where simple operational data starts to become the basis for a qualified estimate.


    Screenshot of the PENB application interface for uploading consumption data, selecting non-heating months and DHW approximation
    Example of the data part of the application: consumption, non-heating months and DHW model approximation.


    What the project solves

    In practice, the same problem often arises: you have energy consumption, the basic parameters of your apartment and you want to get your bearings quickly.

    • Is the consumption reasonable or is it already suspiciously high?
    • Does it make sense to invest in insulation, window replacement or a change of heating source?
    • How to distinguish an expensive renovation with little impact from an intervention that really helps?

    This is where an indicative calculation makes sense. Instead of waiting for the whole formal process, the user can get the first data signal for further decision making in a short while.


    Added value for the user

    For the owner or tenant of an apartment

    • faster orientation as to whether the consumption corresponds to the size and type of the apartment,
    • a better basis for decisions on savings and renovation,
    • a more comprehensible explanation of why the energy bill looks the way it does.

    For the buyer or investor

    • a quick screening of the property before deeper due diligence,
    • a better estimate of future running costs,
    • an additional argument when negotiating the price or the scope of the investment.

    For a consultant, developer or portfolio manager

    • the ability to prioritise which flats or units to deal with first,
    • clearer communication with the customer,
    • the basis for productising a service that combines a technical estimate with a business recommendation.

    Business value in one sentence

    The main benefit of the project is that it turns unclear operational data into a quickly usable basis for decision-making. This is a value in itself: less guesswork, fewer blind investments and a faster path from question to action.


    How it works for laymen

    Simply put, the application does five things:

    1. It takes basic information about the apartment, heating and energy consumption.
    2. It supplements it with meteorological data for the given locality.
    3. It estimates what part of the consumption is related to heating and what to normal operation.
    4. It uses a thermal model to simulate how the apartment behaves during the year.
    5. It translates the result into an indicative energy class and adds a comment on reliability.

    So the user gets not just a number, but also a framework for interpreting the result.


    A short summary for the slightly advanced

    From a software engineering and data science perspective, the project is interesting in that it combines several layers that are often separate:

    • input validation and UX layer: the form guides the user towards consistent inputs and reduces errors,
    • data layer: historical weather is combined with operational data and fallback mechanisms,
    • domain model: the core is based on a simplified RC model of the thermal behaviour of the building,
    • calibration and simulation: the model adapts to the observed consumption and then estimates the annual profile,
    • reporting: the output is not just a technical calculation, but an interpretation for decision-making,
    • deployment: the public application runs separately on its own subdomain, so it is easily shareable and ready for further iterations.

    In practical terms, this means that the project is not just a one-off script. It is a small product: it has a data model, application logic, a user interface and a deployment.


    Why this approach is interesting

    Similar projects show well that data science is not just about training models. It is often more important to:

    • formulate the problem correctly,
    • choose a reasonably simple model,
    • be able to explain the result to a person who does not need to know the mathematical details,
    • and deliver a solution in a form that can actually be used.

    In other words, a useful project is created where domain knowledge, data work and quality implementation come together.


    Important limitation

    The output of the application is an indicative estimate, not an officially certified EPC. For legal or formal purposes, a standard professional processing is still required. However, for a preliminary analysis, business discussion and prioritisation of further steps, such a tool can have very good added value.


    What to take away from this

    The PENB project shows that even a relatively compact application can have a real practical impact if it:

    • solves a specific problem,
    • returns a clear output,
    • and is deployed in such a way that it is immediately usable.

    If you are interested in how to use a similar principle in your product, service or internal decision making, the application is publicly available here:

© 2026 Michael Princ. All rights reserved.

Built with WordPress