Ground Source Heat Pump + Underfloor Heating/Cooling as Thermal Battery

[renaatdb]

Hi all,

I would like to share my current EMHASS setup and some initial results using the new thermal battery model.

My goal is to use the thermal mass of the screed and building as an energy storage system instead of only relying on electrical battery storage.

System

• Home Assistant 2026.6
• EMHASS 0.17.7
• Thermia Calibra ground source heat pump
• 160 m² underfloor heating
• Passive cooling through the same geothermal system
• Dynamic electricity prices
• PV installation
• Enphase battery
• Belgium (capacity tariff)

Thermal Battery Setup

The heat pump is configured as Deferrable Load 0 using the thermal battery model.

Current comfort settings:

• Minimum temperature: 22.0°C
• Target temperature: 22.5°C
• Maximum temperature: 25.5°C

The objective is to:

• preheat the house when electricity is cheap or PV production is available
• reduce consumption during expensive periods
• maintain comfort limits
• later apply the same concept to passive floor cooling

Initial Results

After upgrading to EMHASS 0.17.7 and correcting my configuration, both Day-Ahead and MPC optimization are now working correctly.

EMHASS is successfully publishing:

• predicted indoor temperature
• heating demand forecast
• optimized heat pump schedule

The resulting behavior is exactly what I was hoping for:

• indoor temperature slowly drifts toward the minimum comfort limit
• EMHASS schedules heating during favorable periods
• the building is used as a thermal battery
• stored heat is released gradually afterwards

The predicted temperature curve looks realistic and stays within the configured comfort boundaries.

Questions

Current thermal model:

        "def_load_config": [
          {
            "name": "Geothermische Warmtepomp",
            "entity_id": "sensor.emhass_p_deferrable0",
            "thermal_battery": {
              "supply_temperature": 32.0,
              "volume": 11.2,
              "start_temperature": {{ huidige_temp }},
              "min_temperatures": {{ min_temperatures | tojson }},
              "max_temperatures": {{ max_temperatures | tojson }},
              "carnot_efficiency": 0.42,
              "u_value": 0.18,
              "envelope_area": 517,
              "ventilation_rate": 0.15,
              "heated_volume": 572,
              "window_area": 39,
              "shgc": 0.45,
              "thermal_inertia_time_constant": 2.0
            },
            "def_min_on_time": 2,
            "def_min_off_time": 4
          },
          {
            "name": "Vaatwasser",
            "entity_id": "sensor.emhass_p_deferrable1"
          },
          {
            "name": "DHW Boost",
            "entity_id": "sensor.emhass_p_deferrable2",
            "def_min_on_time": 6,
            "def_min_off_time": 8
          },
          {
            "name": "Passieve koeling",
            "entity_id": "sensor.emhass_p_deferrable3",
            "def_min_on_time": 4,
            "def_min_off_time": 2
          }
        ],

The house has:

• Ground source heat pump (Thermia Calibra Cool 7 BW)
• 160 m² underfloor heating/cooling
• Large concrete screed acting as thermal storage
• Heated volume of 572 m³
• Envelope area of 517 m²
• Good insulation (U-value ≈ 0.18)
• Large south-east to south-west glazing area
• Dynamic electricity pricing
• Rooftop PV
• Battery storage (Enphase FlexPhase)

The objective is not only to minimize cost, but also to use the building itself as a thermal battery and shift heat pump operation towards periods with high solar production.
My geothermal heat pump is coupled to 160 m² of underfloor heating embedded in a 7 cm concrete screed. Rather than using a dedicated thermal storage tank, I leverage the thermal inertia of the floor slab and the building envelope as a distributed thermal battery. EMHASS optimizes heating schedules using PV forecasts, dynamic electricity prices, and indoor comfort limits. Excess solar production can therefore be converted into stored thermal energy, reducing grid imports while maintaining occupant comfort.

Next Steps and Future Measurements

Based on the observations so far, I will not immediately modify the EMHASS thermal model further. Instead, I want to improve the available measurements and compare model predictions with real thermal storage behaviour.

Sensors being installed

I have already purchased three additional temperature sensors:

1. Underfloor heating collector supply temperature
2. Underfloor heating collector return temperature
3. Floor temperature sensor embedded in the living room floor

The living room was chosen because it is the reference zone for comfort control and receives the highest solar gains.

What will be monitored
Floor thermal storage

The floor temperature sensor will allow me to observe:

• How quickly the screed heats up.
• How long stored heat remains available.
• How much cooling energy is stored during passive cooling.
• The thermal lag between floor temperature and room temperature.

Collector performance

With supply and return temperatures I can calculate:

ΔT (supply-return)

This will indicate:

• When heat is effectively transferred into the floor.
• When passive cooling is removing heat from the building.
• How much thermal energy is being exchanged with the floor.

New monitoring indicators

I plan to create Home Assistant sensors for:

• Collector ΔT
• Floor temperature
• Floor-to-room temperature difference
• Thermal storage state (warm buffer / neutral / cold buffer)

Initially these sensors will be used only for monitoring and trend analysis.

No control actions will be based on them yet.

Validation of the EMHASS thermal model

The main objective is to compare:

• EMHASS predicted temperature (predicted_temp_heater0)
• Actual room temperature
• Floor temperature
• Heat pump operation
• Collector temperatures

This should help determine whether the current thermal model accurately represents the behaviour of a geothermal building with:

• Large thermal mass
• Underfloor heating
• Passive cooling
• Significant solar gains

Possible future integration with EMHASS

If the measurements prove useful, future control logic could take into account:

Heating

• Warm floor + warm room → thermal battery already charged.
• Cold floor + room approaching minimum comfort temperature → allow earlier heating.

Cooling

• Cold floor → sufficient cooling energy already stored.
• Floor temperature approaching dew point → limit passive cooling.

This would effectively use the measured floor thermal state as an additional indicator of available thermal storage.

Current strategy

For now:

• Continue running EMHASS with the current thermal battery configuration.
• Collect several weeks or months of floor and collector temperature data.
• Compare measured behaviour with EMHASS predictions.
• Only then consider adjusting thermal model parameters.

The goal is to move from a purely theoretical thermal model towards a model supported by real measurements of the floor, which is likely the largest thermal battery in this type of geothermal installation.

[RikBast]

Hi,

That looks very nice! Don't you run into infeasible sometimes when min_temp is reached? My experiments with a simple DHW waterpumpboiler Buderus WPT 200.4 AS I run into infeasible when using the thermal_battery and min_temp is approached/reached. I added extra sensors to the boiler as well plus the existing sensor connected to the gasboiler gives me at least a nice temperature profile.

[renaatdb]

Rik,
I am still experimenting.

Part of my code is above (I just modified it a bit).
I am currently not receiving any error messages.
Today it is warm and defferable load0 is 0 (So underfloor heating will not be programmed tomorrow, which seems logical)

I just received the temperature sensors to determine the heat content of my floor package.

My next step will be to primarily measure the temperatures of my floor package. Everything you read here has been translated by AI from Dutch :).

[RikBast]

Hi,

My DHW optimization now shows this:

I loosely based it on the described section in the EMHASS docs https://emhass.readthedocs.io/en/latest/study_cases/dhw_walkthrough.html, let's see if it will run into infeasible at some point. I want to use thermal_battery as I want to use the heat_topology for heating the water with the heatpomp or the gasboiler. I struggle with this because in heat topology p_deferrable0 and p_deferrable1 are reserved for this heat topology setup. I am looking for a way to combine this with normal deferrables.

[renaatdb]

Hi,
Possible solution?

Option A — Recommended: two EMHASS runs

One EMHASS run for his thermal topology:

run 1:

p_deferrable0 = heat pump
p_deferrable1 = gas boiler
thermal_battery = domestic hot water tank

And a second EMHASS run for regular deferrables:

run 2:

p_deferrable0 = dishwasher
p_deferrable1 = washing machine
p_deferrable2 = EV / boiler / etc.

Then he must work with different publish_prefixes, for example:

thermal_p_deferrable0
thermal_p_deferrable1

normal_p_deferrable0
normal_p_deferrable1

This way the names do not clash. Option B — Everything in one run, but strictly reserve numbers

Then it must accept:

p_deferrable0 = heat pump
p_deferrable1 = gas boiler
p_deferrable2 = dishwasher
p_deferrable3 = washing machine
...

And thus give all lists exactly the same order:

def_total_hours
nominal_power_of_deferrable_loads
min_power_of_deferrable_loads
def_load_config

But this is more prone to errors.

Option C — Keep gas boiler outside EMHASS

If the gas boiler is primarily a backup, I would not optimize it as a deferrable load. Then it lets EMHASS only schedule the heat pump, and Home Assistant decides:

if heat pump not enough / too expensive / temperature too low
→ gas boiler as fallback

That is more robust.

[renaatdb]

Hi,
While continuing my implementation, I started wondering if my use case actually fits the current thermal_battery model or if it would eventually be a better fit for heat_topology.

My installation is a ground source heat pump with underfloor heating and passive cooling (Thermia Calibra Cool).

Unlike a DHW tank, I think my system actually contains two different thermal storage masses:

The floor slab (screed + underfloor heating loops), which reacts relatively quickly and stores/release heat or cooling over a few hours.
The building mass (walls, ceilings, furniture, etc.), which reacts much slower and determines the indoor comfort temperature.

The energy flow is therefore something like:
Ground
↓
Heat pump
↓
Floor slab (fast thermal storage)
↓
Building mass (slow thermal storage)
↓
Indoor temperature

At the moment I use:

• thermal_battery for heating (p_deferrable0)
• Passive cooling as a separate deferrable load (p_deferrable3, 50 W circulation pump)

This works, but it makes me wonder if I am modelling the system correctly.

**My question is:

Would heat_topology eventually allow modelling multiple thermal masses (floor + building), or is the intended approach to keep the floor logic outside EMHASS (for example in Home Assistant) and let EMHASS optimize only the building thermal mass?**

In the future I will also install sensors for:

1. underfloor heating supply temperature,
2. return temperature,
3. floor slab temperature.

Those measurements would allow estimating the thermal state of the floor independently from the indoor air temperature.

I'm interested in understanding what the long-term architecture of EMHASS is intended to be for this type of installation.

Thanks!

[RikBast]

All I can say is, try it out.

I have now set-up heat_topology with the same settings as the thermal_battery:

    "sources": [
      {
        "id": "hp",
        "type": "heatpump",
        "supply_temperature": 45,
        "nominal_power": 630,
        "min_power": 450,
        "treat_as_semi_cont": false,                                   
        "carnot_efficiency": 0.1,
        "electric": true,
        "operating_timesteps": 0,                                     
        "cost_track": "electricity"
      },
      {
        "id": "gas",
        "type": "gas",
        "nominal_power": 24000,
        "min_power": 6000,
        "treat_as_semi_cont": false, 
        "efficiency": 0.92,
        "electric": false,
        "operating_timesteps": 0, 
        "cost_track": "gas"
      },
    ],

    "storage": [
      {
        "id": "boiler",
        "volume": 0.2,
        "density": 997,
        "heat_capacity": 4.184,
        "thermal_loss": 0.027,
        "start_temperature": start_temp,
        "min_temperature": ns_min.vals,
        "max_temperature": ns_max.vals,
        "desired_temperatures": ns_des.vals,
        "comfort_sense": "heat",
        "overshoot_temperature": overshoot,
        "penalty_factor": 10
                                               
      }
    ],

    "consumers": [
      {
        "id": "dhw_draw",
        "target": "boiler",
        "type": "profile",
        "profile": ns_draw.vals
      }
    ],

    "flows": [
      { "from": "hp", "to": "boiler" },
      { "from": "gas", "to": "boiler" },
    ],

    "cost_tracks": {
      "electricity": price,
      "gas": [0.257595] * horizon
    },

    "actuator_groups": [
      {
        "flows": [["hp", "boiler"], ["gas", "boiler"]],
        "mutual_exclusion": true
      }
    ]

With this result:

I am missing in the graph: min and max temperatures, desired temperatures. Desired temperatures are not respected, same goes for overshoot.

The normal thermal_battery gives me a better prediction in my opinion:

[renaatdb]

New config:
{# ================================================================== #}
{# DEFERRABLE LOADS #}
{# ================================================================== #}
{# [0] Geothermische Warmtepomp #}
{# [1] Vaatwasser #}
{# [2] DHW Boost #}
{# [3] Passieve Koeling #}
{# ================================================================== #}

    "def_total_hours": [
      {{ wp_uren }},
      {{ dw_uren }},
      {{ boiler_uren }},
      {{ koel_uren }}
    ],

    "def_current_state": [
      false,
      {{ dw_is_running | tojson }},
      false,
      {{ passief_koelen_actief | tojson }}
    ],

    "set_deferrable_load_single_constant": [
      false,
      false,
      true,
      false
    ],

    "treat_deferrable_load_as_semi_cont": [
      true,
      false,
      false,
      true
    ],

    "nominal_power_of_deferrable_loads": [2200, 1200, 3000, 50],
    "min_power_of_deferrable_loads": [1200, 500, 3000, 20],



    "def_load_config": [
      {
        "name": "Geothermische Warmtepomp",
        "entity_id": "sensor.emhass_p_deferrable0",
        "thermal_battery": {
          "sense": "heat",
          "supply_temperature": 32.0,
          "volume": 11.2,
          "start_temperature": {{ huidige_temp }},
          "indoor_target_temperature": {{ target_temp }},
          "desired_temperatures": {{ desired_temperatures | tojson }},
          "min_temperatures": {{ min_temperatures | tojson }},
          "max_temperatures": {{ max_temperatures | tojson }},
          "overshoot_temperature": {{ max_temp }},
          "penalty_factor": 10,
          "carnot_efficiency": 0.42,
          "u_value": 0.18,
          "envelope_area": 517,
          "ventilation_rate": 0.15,
          "heated_volume": 572,
          "window_area": 39,
          "shgc": 0.45,
          "thermal_inertia_time_constant": 2.0
        },
        "def_min_on_time": 2,
        "def_min_off_time": 4
      },
      {
        "name": "Vaatwasser",
        "entity_id": "sensor.emhass_p_deferrable1"
      },
      {
        "name": "DHW Boost",
        "entity_id": "sensor.emhass_p_deferrable2",
        "def_min_on_time": 6,
        "def_min_off_time": 8
      },
      {
        "name": "Passieve koeling",
        "entity_id": "sensor.emhass_p_deferrable3",
        "def_min_on_time": 4,
        "def_min_off_time": 2,
        "thermal_config": {
          "heating_rate": 0.05,
          "cooling_constant": 0.0008,
          "start_temperature": {{ vloer_temp }},
          "desired_temperatures": {{ vloer_desired_temperatures | tojson }},
          "min_temperatures": {{ vloer_min_temperatures | tojson }},
          "max_temperatures": {{ vloer_max_temperatures | tojson }},
          "sense": "cool",
          "penalty_factor": 1.0
        }
      }
    ],

[renaatdb]

I think I have narrowed the problem down a bit more.

My system is a Thermia Calibra ground source heat pump with passive cooling.

Unlike active cooling, the compressor is OFF.
Only the circulation pumps are running (about 50 W electrical power).

However, thermally the system removes much more heat from the building through the boreholes (probably around 1–3 kW of cooling capacity).

The optimisation works, but the thermal model seems to stop cooling much too early.

For example:

• Indoor temperature: about 26.8°C
• Target cooling temperature: 23.5°C
• Maximum comfort temperature: 27.5°C
• The optimisation predicts almost no additional cooling although the house is still much warmer than the target.

The predicted_temp_heater3 curve is almost a straight line, suggesting that enabling P_deferrable3 has almost no thermal effect.

My question is therefore:

Does the current thermal model assume that the electrical power of the deferrable load is proportional to the thermal power?

If so, passive geothermal cooling would be difficult to model because only about 50 W electrical power is consumed while several kW of cooling are delivered.

Or is there another parameter that should represent the actual cooling capacity instead of the electrical consumption?
I looked further into the EMHASS thermal model formula.

From the documentation, the thermal effect depends on:

P_def / P_def_nom

In my passive cooling case:

• P_deferrable3 = 50 W
• nominal_power_of_deferrable_loads[3] = 50 W

So EMHASS should see the passive cooling pump as running at 100% nominal power.

This means the issue is probably not that EMHASS treats the system as only 50 W thermal power. Instead, the key parameter seems to be heating_rate: the temperature change per hour when the deferrable load runs at nominal power.

My system is passive geothermal cooling: compressor OFF, circulation pump ON, using the cold borehole/brine circuit. So the electrical power is only about 50 W, but the thermal cooling effect is much larger.

Question:

For passive cooling, should I calibrate heating_rate to the measured cooling effect in °C/hour while the pump is running, regardless of the 50 W electrical power?

Also, I noticed that with min_temperatures and max_temperatures, EMHASS seems to let the temperature float inside the comfort band and does not try to cool towards the desired temperature. Is this expected behavior?

In my case, indoor temperature is about 26.5°C, desired cooling target is around 23–23.5°C, max comfort is 27.5°C, but EMHASS often stops passive cooling because the prediction stays below max comfort.

Would the correct approach be to increase penalty_factor and calibrate heating_rate, or is thermal_config not intended to behave like a cooling thermal battery?

[renaatdb]

    "def_load_config": [
      {
        "name": "Geothermische Warmtepomp",
        "entity_id": "sensor.emhass_p_deferrable0",
        "thermal_battery": {
          "sense": "heat",
          "supply_temperature": 32.0,
          "volume": 11.2,
          "start_temperature": {{ huidige_temp }},
          "indoor_target_temperature": {{ target_temp }},
          "desired_temperatures": {{ desired_temperatures | tojson }},
          "min_temperatures": {{ min_temperatures | tojson }},
          "max_temperatures": {{ max_temperatures | tojson }},
          "overshoot_temperature": {{ max_temp }},
          "penalty_factor": 10,
          "carnot_efficiency": 0.42,
          "u_value": 0.18,
          "envelope_area": 517,
          "ventilation_rate": 0.15,
          "heated_volume": 572,
          "window_area": 39,
          "shgc": 0.45,
          "thermal_inertia_time_constant": 2.0
        },
        "def_min_on_time": 2,
        "def_min_off_time": 4
      },
      {
        "name": "Vaatwasser",
        "entity_id": "sensor.emhass_p_deferrable1"
      },
      {
        "name": "DHW Boost",
        "entity_id": "sensor.emhass_p_deferrable2",
        "def_min_on_time": 6,
        "def_min_off_time": 8
      },
      {
        "name": "Passieve koeling",
        "entity_id": "sensor.emhass_p_deferrable3",
        "def_min_on_time": 4,
        "def_min_off_time": 2,
        "thermal_config": {
          "heating_rate": 0.20,
          "cooling_constant": 0.0008,
          "start_temperature": {{ vloer_temp }},
          "desired_temperatures": {{ vloer_desired_temperatures | tojson }},
          "min_temperatures": {{ vloer_min_temperatures | tojson }},
          "max_temperatures": {{ vloer_max_temperatures | tojson }},
          "overshoot_temperature": 23,
          "sense": "cool",
          "penalty_factor": 20.0
        }
      }

[renaatdb]

Hi,

I did some more testing with the thermal_config for a passive cooling load (sense: "cool").

My setup:

Ground source heat pump (Thermia Calibra Cool 7)
Passive cooling (only circulation pumps, about 50 W)
EMHASS 0.17.8

I noticed something interesting.

"desired_temperatures": [...21.8...],
"overshoot_temperature": 27.5,
"heating_rate": 0.05,
"penalty_factor": 1.0

EMHASS scheduled almost no cooling.

"heating_rate": 0.20,
"penalty_factor": 20.0,
"overshoot_temperature": 23.0

the optimizer suddenly keeps the passive cooling running until the predicted temperature reaches about 23°C.
Changing overshoot_temperature to 22.0°C makes EMHASS continue cooling until approximately 22°C.

So it looks as if overshoot_temperature is effectively acting as the stopping threshold for cooling, while desired_temperatures is not really driving the optimization in the way I expected.

Is this the intended behaviour?

If so, could you explain the intended difference between:

desired_temperatures
overshoot_temperature

when sense="cool" is used?

For passive cooling this distinction is not obvious from the documentation.

Also, what is the recommended value for heating_rate when using passive cooling (ground loop circulation only)? Since there is no compressor power involved, I'm not sure how this parameter should be interpreted.

[renaatdb]

Should thermal_config (sense="cool") and thermal_battery (sense="heat") be coupled when they represent the same building? Currently they seem to evolve independently, resulting in two different predicted indoor temperatures for the same house. Is this intentional, or should both models share a common thermal state?

[renaatdb]

Additional context after further testing:

My system is a ground-source heat pump with underfloor heating and passive cooling. Physically it is one shared thermal mass: the same floor loops and building buffer are used for both heating and passive cooling.

I tested two modelling approaches:

1. One combined deferrable load for the physical heat pump/floor system.
   This looks conceptually correct, but in my setup it either resulted in all deferrable powers staying at 0, or the MPC becoming infeasible.

2. Two virtual deferrable loads:

   • def0 = heating with thermal_battery, sense: "heat"
   • def3 = passive cooling with thermal_config, sense: "cool"
     Then Home Assistant merges both signals into one physical Thermia heat pump control.

This second approach currently works better, but it does not really model one shared floor/building thermal state. Heating and cooling are treated as two separate virtual thermal models.

Related issues/PRs seem relevant:

• [Feature Request] thermal_battery config: use distinct source temperature for ground-sourced heatpumps #801: ground-source heat pump COP should use source/brine temperature, not outdoor air temperature
• feat: heat_topology graph model for hybrid heating (multi-source thermal storage) #862: heat_topology / shared thermal tanks
• fix(thermal): compute cooling demand for thermal_battery sense=cool (#994) #996: thermal_battery sense: "cool" fix

My main question is:

Can EMHASS currently model one physical underfloor heating/cooling system as one shared thermal state that can both heat and cool?

Or is the recommended pattern to model heating and cooling as two virtual deferrable loads and merge them later in Home Assistant?

[renaatdb]

Hi, a short update after further testing on EMHASS 0.18.3.

I am now collecting real measurements from my Thermia ground-source heat pump and the building. One behaviour is becoming very clear.

On sunny days the indoor temperature can already be at or above the 23.0°C target and rising because of solar gains, while thermal_battery still schedules active underfloor heating during the PV surplus period. The predicted temperature then rises toward roughly 25°C. In reality the Thermia itself often remains in standby because no heating is required.

This raises two questions:

1. How are solar gains currently taken into account by thermal_battery when pv_power_forecast, window_area and shgc are provided? Is PV production used as a proxy for solar radiation, and does the model account for window orientation/shading?
2. Is there a recommended way to prevent active preheating when the indoor temperature is already at/above target and sufficient solar heat gain is expected, while still allowing the building to be used as a thermal battery on colder/cloudy days?

A related question from my earlier posts remains: can heating and passive cooling of the same underfloor system share one thermal state, or are two independent thermal models still the recommended approach?

I can provide plots comparing predicted_temp_heater0, actual indoor temperature, actual heat-pump power and floor/collector temperatures if useful.

[renaatdb]

Update: automatic thermal learning from Home Assistant measurements

I have continued working on the calibration problem for my Thermia Calibra ground-source heat pump with underfloor heating and passive cooling.

Instead of manually guessing thermal parameters, I am now collecting real measurements in Home Assistant first. The learning system separates three operating states:

• active heating
• passive cooling
• free thermal response, with no active heating or cooling

For each measurement window I record indoor temperature, outdoor temperature, duration, indoor temperature change, and the relevant system state. Interrupted or low-quality windows are rejected before they enter the learning archive.

I also changed my PV measurement setup. The PV installation is now split according to the real roof orientations and microinverter groups:

• 12 east-facing microinverters
• 20 south-west-facing microinverters

Both real PV powers are recorded separately during every thermal measurement. This is important in my house because solar gain is significant due to large east- and south-facing glazing. The east side is also affected by tree shading, especially in autumn and winter.

The current learning chain is:

measure -> classify -> quality filter -> learn natural building response and solar influence -> isolate heating/cooling effect -> validate -> derive EMHASS thermal parameters

There is also a persistent learning archive and a model monitor. The idea is that individual measurements should not immediately change anything. Measurements are stored, checked, compared over time, and only later used to derive candidate parameters.

For clarity: nothing is currently written automatically back to EMHASS or to the heat pump. This is still observation and calibration work only.

A few first usable examples from the archive:

• Passive cooling period: outdoor temperature about 25.3 degC, measured indoor response about -0.176 degC/h, PV East about 449 W, PV South-West about 789 W.
• Free thermal response period: outdoor temperature about 21.1 degC, measured indoor response about -0.037 degC/h, PV East about 35 W, PV South-West about 61 W.

These are individual observations, not calibrated parameters yet. They are useful because they show that passive cooling periods and free-response periods can be separated and compared, but I still need more data before deriving stable values for EMHASS.

The longer-term goal is to learn the natural building response first, including outdoor temperature and solar influence, and only then isolate the actual effect of active heating or passive cooling. After validation, this should hopefully give better estimates for parameters such as heating rate, cooling response and heat loss behaviour for a slow underfloor heating/cooling system.

I would be very interested to hear from other EMHASS users who have tried to calibrate thermal parameters from real Home Assistant data. In particular:

• Do you use free-response periods to estimate the natural cooling/heating drift of the building?
• Do you separately analyse active heating and passive/active cooling periods?
• How do you deal with slow underfloor heating where the room response lags far behind the heat pump or floor loop activity?
• Have you found a reliable method to include solar gains, orientation and shading when tuning EMHASS thermal parameters?

Any experience or comparison from similar slow thermal-mass systems would be very useful.

[borisvettorato]

I have been working on a rc based self learning model, but have been getting mixed results. Sometimes its mean absolute error only .3 degrees of in a day, but sometimes almost .8. but i am waiting on the heating season to really start testing. I am using a air to water heat pump and i have underfloor heating, but also radiators

[renaatdb]

Small update on the thermal model: excess solar/internal gains being lost from the predicted indoor temperature calculation have been reproduced locally on EMHASS 0.18.5.

A proposed fix with regression tests is available in draft PR #1193, related to issue #1139. The relevant local tests pass, but the change has not been applied to my live installation and is awaiting review.