Heating Analytics - Thermodynamic ML Heating Forecasts

jhilkert90-wq · March 4, 2026, 7:31am

I don’t understand how I can add here more sensors. I have added the heat meter of my heat pump (1 for complete house) and the fireplace I trigger with switch.heating_analytics_auxiliary_untracked_heating_active.

My target indoor is 22.6°C. In winter time I only close the blind for each room if room temp is >23.3. If it’s getting then <23.1 they open again to get free heat.
I could change the Solar Correction in tha way that if 20% of the blinds are closed, I change the value to 80%. Is that correct?

The 2/3 of the windows are headed south (I added 160° in the integration). But the 1/3 are headed west. They also get affected by the sun in afternoon/evening.
How can I handle this?
I also cannot add the window area.

One last question: Where can I find the advanced sensors?

In your dashboard I think you use some custom sensors. A lot of entities connot be found in your dashboard.

Sorry a lot of questions

thuemah · March 4, 2026, 8:00am

Hi @jhilkert90,

No need to apologize for the questions at all! This kind of feedback is incredibly valuable, especially as I am constantly tuning the documentation. Let’s go through them one by one:

1. Adding more sensors If you only have one energy meter for the entire house (the heat pump), that’s perfectly fine! You just add that single entity. You don’t need per-room sensors for the integration to work. The fireplace switch is also set up exactly right as an auxiliary source. The system will simply learn a single, highly accurate global model for your whole house based on that one meter.

2. Solar Correction and blinds

I could change the Solar Correction in that way that if 20% of the blinds are closed, I change the value to 80%. Is that correct?

Yes, exactly right! That is a great way to automate it. Just note that if this slider was set too low (or to 0%) while the blinds were actually open during the initial learning phase, the system might have cancelled out much of the initial solar learning. It might be worth resetting the solar learning once your automation is in place, so it can learn the correct impact over a few sunny days.

3. Mixed window orientations (South + West) This is actually great timing. I have a release coming out later today or tomorrow that replaces the single azimuth input with a brand new 2D solar vector system. Instead of configuring one global orientation, the system will independently learn the directional solar coefficient for your house strictly through observation. A room (or a whole house) that gets afternoon sun will automatically adapt its internal vector towards the west without any manual configuration. Note: Because of this update, the Azimuth field is being completely removed from the UI. Your system will transition automatically, but the 4-hour solar learning buffer will be cleared as a side effect since the new vector format is completely different.

4. Window area Good catch! There is no window_area field in the integration anymore — that was removed in a very early version because the system now learns the scale of the impact automatically. I realized the README still mentioned it in a few places, but I have just updated the documentation to remove those stale references. Sorry for the confusion!

5. Advanced sensors & Missing Dashboard entities There are no hidden entities you need to enable. The reason you can’t find some of the “advanced” sensors or entities from the dashboard is that a lot of the rich data actually lives as attributes on the main sensors, rather than as separate entities. You’ll find things like forecast accuracy breakdowns, specific weather data, solar coefficients, and the hourly log there.

To view them in the dashboard: Click on the sensor, click the three dots in the top right corner of the pop-up, and select “Attributes”.
To view everything at once: Go to Developer Tools → States in HA, search for heating_analytics, and click on any sensor to expand its attribute list. (If you are building custom dashboard cards, like the Plotly graphs, you can also extract them directly in YAML using attribute: your_attribute_name).

Regarding the dashboard in the tools folder: I am currently moving away from providing a full, monolithic ready-made dashboard. Instead, I will be publishing individual, modular graph cards (like the Plotly heating demand curve, wind bucket comparisons, etc.) in the tools folder. These are much easier to drop into your existing dashboards and adapt to your specific setup without getting “entity not found” errors.

jhilkert90-wq · March 5, 2026, 2:12pm

Attribute

Daily summary

Windy weather (+39.8 kWh vs last year)

Current model kwh

39,8

Last year model kwh

0

Last year actual kwh



Unbekannt

Reference temperature

Unbekannt

Current temperature

3,2 °C

Temperature delta

Unbekannt

Reference effective wind

Unbekannt

Current effective wind

3,1

Wind delta

Unbekannt

Reference solar kwh

0

Current solar kwh

0,5

Solar delta

0,5

Zustandsklasse

Messwert

Unit of measurement

kWh

Icon

mdi:chart-timeline-variant

Friendly name

Heating Analytics Model Comparison Day

@thuemah
I’m running now the newest version and reseted the solar values 2 days ago.

Why are here some values “unknown”.

    "aux_coefficients_per_unit": {},
    "learning_buffer_global": {},
    "learning_buffer_aux_per_unit": {},
    "solar_coefficients_per_unit": {},
    "learning_buffer_solar_per_unit": {
      "sensor.wth_heizen2": {
        "5": [],
        "7": [],
        "9": [
          [
            0.08684120480120547,
            -0.06648253790276387,
            0.3780333333333335
          ]
        ],
        "10": [],
        "11": [
          [
            0.11104763051028983,
            -0.14165178774547862,
            0.3530666666666668
          ]
        ],
        "-1": [
          [
            0.09928986930487342,
            0.19074736461133124,
            0.0
          ]
        ],
        "0": [
          [
            0.22809003343481876,
            0.2721750971463094,
            0.18718333333115067
          ]
        ],
        "1": [
          [
            0.338291121833406,
            0.24094306063807622,
            3.6839999999999957
          ]
        ],
        "4": [
          [
            0.11299835284100002,
            0.028675205925148783,
            0.8926666666666666
          ]
        ],
        "6": [
          [
            0.2189504779667815,
            0.004977141415676434,
            1.1250000000000013
          ]
        ],
        "8": [
          [
            0.20859223557273432,
            -0.06253947236256684,
            0.4170000000000005
          ]
        ]
      }
    },
    "unit_modes": {},
    "solar_optimizer_data": {
      "model": {
        "maximize_solar": {
          "150": {
            "30": 50.0
          },
          "180": {
            "30": 50.0
          },
          "210": {
            "20": 50.0
          },
          "90": {
            "10": 100.0
          },
          "120": {
            "20": 100.0
          }
        },
        "insulate": {
          "210": {
            "20": 100.0
          },
          "240": {
            "10": 50.0,
            "0": 100.0
          },
          "90": {
            "0": 100.0
          }
        }
      }
    }
  }
}

I think the model is learning?

thuemah · March 5, 2026, 4:28pm

The “unknown” values in the Model Comparison Day sensor appear because there is no reference data from the equivalent period last year in your system yet. The sensor compares current conditions to the same date/period last year — without that historical baseline, temperature, wind and consumption deltas cannot be calculated.

To fix this, you can import historical weather data from open-meteo covering the past 1–2 years. Make sure to only import dates not already present in your log, and disable model training during the import — this fills in the historical weather context without overwriting your existing learned model.

true (default): imports data into history/graphs AND trains the correlation model — use this for a full cold-start import.
false : imports data into history and graphs ONLY, leaving your existing learned model completely untouched. Set to false when filling in missing historical periods (e.g. weather reference data for the Model Comparison sensor) so that the import does not overwrite correlations your model has already learned from live data.

Regarding solar: the learning buffer is working as expected. Once enough hours accumulate per temperature key, the solar coefficients will be averaged and moved to solar_coefficients_per_unit. Given you reset 2 days ago and this time of year has few solar hours per temperature band, it will take a little time to build up. Looking good so far!

Wasserspiele · March 6, 2026, 9:45am

Just a question I have a combined heating with included hot water supported solar thermal (only for hot water)…

If I’m now using the value from the gas meter would i negativly influence the result?

Should I take the energy consumption from the heating directly? I think in ebusd it’s splitted for warming and hot water.

thuemah · March 6, 2026, 10:44am

Yes, mixing DHW (hot water) into your heating consumption will negatively affect the model. The model is built around space heating demand, which correlates with outdoor temperature, solar gain, and thermal inertia. Domestic hot water demand doesn’t follow those patterns – it’s driven by usage habits instead, and acts as noise from the model’s perspective.

In your case, using the gas meter total would mix space heating + DHW + potentially solar thermal backup, which makes it very hard for the model to learn clean correlations.

If ebusd splits warming and hot water separately, use only the space heating value. That will give the model the cleanest possible signal to work with.

The solar thermal for hot water is also worth noting: since it offsets DHW demand rather than space heating, it won’t interact with the solar irradiation correction in the model anyway – so you’re not losing anything by excluding DHW entirely.

thuemah · March 6, 2026, 2:43pm

v1.2.4 — Recommended Update

A few under-the-hood corrections landed in v1.2.4 that are worth updating for.

The most significant is a fix to the thermal inertia kernel — the Gaussian weighting function has been replaced with a causal exponential decay, which correctly reflects how building thermal mass actually behaves. The practical effect is that effective temperature estimates are no longer biased toward historical observations, so inertia recommendations from calibrate_inertia now map directly to the coordinator’s runtime model.

The solar learning buffer was also corrected — a partitioning bug meant the jump-start threshold was effectively never reached in normal operation, leaving cold-start solar coefficients uninitialized longer than intended.

No configuration changes required. Existing setups will benefit automatically after updating.

elRadix · March 6, 2026, 8:45pm

It would be nice to integrate the functionality when to start and stop heating based on thermal inertia as per example below
A binary sensor for example and use an automation to trigger my heatpump of course based on the weather situation.

ebozonne · March 6, 2026, 10:20pm

Maybe interesting to compare results of thermal mass values, but then why replicate SmartHRT? If you feel that this ML is a better learning process you can still inject the RC value in SmartHRT and use it with the learning process of SmartHRT disabled…

elRadix · March 7, 2026, 9:58am

It was just a idea—a feature request, really.

I completely agree that managing two separate systems would make debugging a nightmare. The value I see isn’t in building a parallel system, but in creating a single, unified system that learns from ML patterns and handles everything.

The ML model would analyse historical usage and temperature data to understand your home’s unique thermal behaviour. It would learn precisely how long it takes to heat up or cool down based on real-world patterns.

With that deep understanding, the system then autonomously manages all the actions—using ML patterns to trigger actions like turning the heating on or off at exactly the right time, or dynamically adjusting the temperature offset based on current conditions and usage patterns.

By having just one system in control, you remove complexity and potential conflicts. It’s a seamless, intelligent solution that simply learns from patterns and acts. No guesswork, no two systems to debug—just smarter automation.

thuemah · March 7, 2026, 10:26am

@elRadix — the “one unified system” idea is genuinely appealing, and the instinct behind it is sound. The challenge is a specific architectural one: when the ML model both learns from consumption data and controls the heating that produces that data, the training signal becomes a function of the model’s own past decisions. A small systematic error gets fed back into the next learning cycle. Over time this can cause the learned coefficients to drift in ways that are very hard to diagnose, because the “ground truth” the model is learning from is no longer the building’s natural thermodynamics — it’s partly the model’s own behaviour.

The closest you can get to that unified vision without that problem is the feedforward pattern: the forecast output drives an external controller (EMHASS, Node-RED, or your own automation), which handles the on/off decisions, while the analytics layer keeps learning from observed consumption independently. From a user perspective it functions like one system — the separation is an implementation detail, not something you interact with.

Two different kinds of thermal inertia
@ebozonne raises a good point about RC values, but it’s worth clarifying what τ means in each context. The τ that Heating Analytics identifies is the building’s heat loss inertia — how long it takes for a change in outdoor temperature to affect the building’s energy demand. What SmartHRT and similar tools calculate is the heating system’s recovery inertia — how long it takes your radiators or floor to raise indoor temperature after heating starts. These are related, but they are not the same RC-circuit, and they diverge significantly for heavy hydronic floor heating systems where the slab itself adds a second thermal lag on top of the building envelope. Swapping these values between systems would require knowing the building’s thermal capacitance directly, which in turn requires high-resolution indoor temperature logging rather than just energy consumption data.

The data is already available
For those who want to build predictive pre-heating or demand-shifting automations today, the hourly 7-day projection is accessible via the heating_analytics.get_forecast service call. It returns the building’s expected energy demand hour by hour as a response variable — clean input for EMHASS, Node-RED, or any custom automation.

On hydronic systems
I want to be straightforward here: I have limited real-world data from hydronic floor heating installations, and there are genuine modeling challenges specific to that setup that the current model isn’t tuned for. Floor heating has a physical self-regulation effect — when room temperature approaches the floor surface temperature, heat transfer drops to near zero regardless of what the heat pump is doing. That creates noise in the energy data that looks nothing like split-AC or direct electric systems. COP variance across outdoor temperatures is a separate complication on top of that.

I’d genuinely like to develop the model’s prediction capability for hydronic systems, but I’d want to do it together with someone who has such a system and is willing to share logs and iterate. If that’s you, feel free to reach out.

elRadix · March 7, 2026, 1:17pm

Thanks for the detailed explanation—that makes perfect sense. Hydronic systems definitely have different dynamics, and I understand the challenge with limited real-world data.

I might be able to help with that.

I manage three different Daikin heating systems, each with a unique setup, and I’m already monitoring them all through Home Assistant. Using the HACS Remote Access integration, I’ve centralized data from three separate Home Assistant installations into one main system, where I use Heating Analytics to monitor performance across all three.

Here is what I have running:

New build (2023) – Full underfloor heating throughout the house, powered by a Daikin 8 kW EPRA08EAV3
Renovated home – Underfloor heating on the ground floor, fan coils in the bedrooms, powered by a Daikin 11 kW ERLA11DAV3
Renovated home – Fan coils in every room, powered by a Daikin 12 kW EPRA12EAV3

If it would help improve the ML models for hydronic systems, I’m happy to give you access to my central Home Assistant instance so you can pull logs and real-world data from all three setups. It might give you the variety of data you need to better tune the model for floor heating and mixed systems.

Let me know if that would be useful and we can arrange access,. send me a private message.

thuemah · March 7, 2026, 2:36pm

Thank you — this is exactly the kind of dataset that’s been missing, and having all three systems available is more valuable than any single installation would be.

A few things worth thinking through before we set anything up:

Read-only access is all that’s needed. If the HACS Remote Access integration is already running, it likely already exposes the live entity data I’d need — the question is whether the right entities are being forwarded: hourly energy consumption for space heating, outdoor temperature, actual indoor temperature (not just setpoint), and flow/return water temperatures for the hydronic circuits.

The DHW separation matters more than it might seem. Daikin Altherma systems share the compressor between space heating and domestic hot water. If those cycles aren’t separated in the data, the model will see inflated energy consumption on high hot-water days and learn the wrong heat-loss coefficient for the building. Worth thinking through how that’s currently logged and whether space heating energy can be isolated cleanly.

On indoor temperature: houses where the setpoint is held stable across the season are the easiest to model from. That doesn’t disqualify the others, but I’d want to know upfront about any scheduled setbacks, holiday modes, or manual adjustments that are part of normal operation.

When you’ve had a chance to think through the DHW question and what a clean technical handoff would look like, feel free to send me a message directly.

chintito4ever · March 8, 2026, 3:57am

My heating system uses both Gas (Furnace) and Electricity (Blower), I have dedicated gas consumption sensor for the furnace, is there any possibility to add it in the heating analysis?

thuemah · March 8, 2026, 6:34am

Yes, absolutely! The cleanest and most analytically sound approach is to treat the furnace as one single heating unit based purely on your gas consumption, and simply ignore the electricity used by the blower. The electric blower is just moving air; its actual thermal energy contribution is negligible compared to the gas combustion.
If you have “electric backup” heating on the same unit you should consider combining them as one kwh sensor before adding it to heating_analytics.

How to add it to the integration: heating_analytics requires a cumulative energy sensor in kWh. How we set this up depends on what your current gas sensor reports:

If your gas sensor reports in kWh: You are good to go! Just add it directly as a heating unit.
If it reports in Volume (m³ or ft³) or MJ: We just need to create a quick conversion helper. You can do this entirely in the Home Assistant UI without touching any configuration files:
1. Go to Settings → Devices & Services → Helpers.
2. Click Create Helper → Template → Template a sensor.
3. Use a simple formula to convert volume to kWh (e.g., for m³: {{ states('sensor.your_gas_meter') | float(0) * 10.55 }}).
4. Set Unit of Measurement to kWh, Device Class to Energy, and State Class to Total_increasing.

thuemah · March 8, 2026, 10:53am

Heating Analytics v1.2.6 introduces an architectural update to resolve modeling inaccuracies specific to air-to-water heat pumps. (Note: This replaces the briefly released v1.2.5 to correct a data migration issue).

Addressing DHW Power Diversion Air-to-water heat pumps frequently divert power to produce Domestic Hot Water (DHW). Because DHW production contributes zero heat to the ambient room, including this consumption data artificially inflates the learned thermal coefficients. Previously, attempting to filter these cycles by setting the unit to “Off” resulted in a systematic upward drift in the model due to thermostat hysteresis.

To resolve this, v1.2.6 introduces a dedicated MODE_DHW. When active, it explicitly instructs the model that the space-heating contribution during these cycles is zero. This approach maintains a stable baseline without the data drift caused by omitting cycles.

To automate this state change, the release includes a new blueprint (heat_pump_mode_sync.yaml). To implement this, map your heat pump’s gross energy consumption sensor and operation mode sensor (Heating / DHW / Defrost) directly to the Heating Analytics mode helper using the blueprint. (Note: Defrost is handled transparently by preserving the current mode).

Additional Fixes

Fixed a storage bug affecting users running multiple instances of the integration. (Includes a safe data migration path for existing users).
Corrected solar screen transmittance calculations to prevent a downward bias when screens are fully closed. Existing learned solar coefficients will converge to corrected values automatically over a few weeks of sunny weather.
Fixed a config flow issue denying the configuration of empty optional fields.

romal · March 10, 2026, 7:02pm

Hi,

I installed it and had it running for some days. I’m not quite sure what to make of it.

Our house is nearly passive. We have a Vaillant Recovair, a Vaillant Arotherm heat pump, solar thermal, a 320 liter water tank, and solar power with a sg-ready coupling.

But happy to investigate new technologies to optimize our energy consumption.

thuemah · March 10, 2026, 7:36pm

Thanks for testing — your setup is a good one to stress-test the integration against: near-passive insulation, solar, and a 320L DHW tank all interact with the model in non-trivial ways.

A quick note on the UI: the top-level sensor state only shows a summary. The underlying thermodynamic calculations, correlation matrices, and data points are in the sensor attributes — accessible via the sensor’s detail view or Developer Tools → States.

Two things worth configuring before you let it run:

DHW Mode — With a 320L tank on your Vaillant pump, you need to enable MODE_DHW (see v1.2.6 release notes). Without it, the energy used for water heating gets attributed to space heating, which inflates the learned thermal coefficients.
Thermal Inertia — Passive houses have high thermal mass and slow heat loss dynamics. Set thermal inertia to 12 hours as a starting point.

Run it for 2–3 weeks with those settings in place. Once enough weather data has been collected, you can call the calibrate_inertia service in Home Assistant — the engine will analyse your historical data and recommend the correct inertia value for your specific house.

romal · March 10, 2026, 7:52pm

Hi,

the inertia profile I already set to 12 hours. I’m not sure about gust.

DHW Mode: I tried to install your blueprint, but stopped as I was missing the helper. Do you have to create it manually? Which type does it need? And then where to configure this helper in the integration? Or does it need to have a specific name?

thuemah · March 10, 2026, 8:19pm

Great call on setting the inertia to 12 hours! For “gust”, you can just leave it at the default setting for now.
Regarding the DHW mode and the missing helper: I completely understand why you got stuck! You don’t need to create the helper manually.
To fix this, go to the integration’s configuration and enable the toggle called “Show Cooling Modes”.
I apologize for the confusing name—it’s a legacy issue. Even though it sounds like it’s only for AC/cooling, enabling this switch is what actually unlocks the DHW mode and automatically generates the helper entity required for the blueprint.
Once you toggle that on, the blueprint should work exactly as intended. Let me know if you still run into any issues!