Part 3: Weather, Heating Season, and the RC Model Without Magic
Why Consumption Alone Isn’t Enough
The same energy use can mean something different in January than it does in April. Without the context of weather and season, it’s impossible to reasonably estimate how much energy is actually explained by heating.
That’s why the app isn’t just about uploading a CSV. Alongside operational data, it also adds meteorological context for the specific location.
Hybrid Weather Layer as a Practical Choice
In an ideal world, there would be a single perfect data source, always available and never down. In reality, it’s better to assume that the network, API, or historical data coverage won’t always be perfect.
That’s why the project uses a multi-layered approach:
- recent data comes from WeatherAPI,
- older history is filled in via Open-Meteo,
- and only as a last fallback does it use a synthetic approximation.
This isn’t just a technical detail. It’s an example of how robustness is built into the data layer from the start.
Where the Heating Season Comes In
Energy consumption isn’t homogeneous. Some months are mainly about heating, others reflect regular operation and hot water. If the model doesn’t distinguish this, it starts calibrating the wrong signal.
That’s why the user selects non-heating months in the app, and the system uses them when estimating consumption components. It’s not an unnecessary detail—it’s one of the most important steps in the entire logic.
Why the RC Model
A simplified RC model isn’t interesting because it’s theoretically the most complex. It’s valuable because it offers a reasonable balance between:
- domain interpretability,
- computational simplicity,
- the ability to calibrate with real data.
The model helps translate apartment behavior into a structure you can actually work with. It’s not a “black box,” but an explainable approximation of thermal dynamics.
Multiple Calculation Modes Matter
The app now offers several calculation modes. This matters not just for performance, but also for the nature of available data.
- sometimes a quick estimate is enough,
- other times local optimization makes sense,
- and for more demanding cases, robust calibration is possible.
This is a good example of a product compromise: instead of forcing everyone into one “right” mode, offer several paths based on input quality and user expectations.
What’s Next
In the next part, I’ll move from the calculation core to the user layer: why having the right model isn’t enough, how the interface steps were designed, and why UX is part of technical quality for tools like this.