Indoor "Feels Like" Temperature and the "Damp Cold" Effect

[nicola-spreafico]

Discussion: Indoor "Feels Like" Temperature and the "Damp Cold" Effect (My Journey)

Hello everyone,

This is not a VT-specific issue, but I'd like to gather some experience from other users.

I'm opening this discussion to share my journey in creating a more accurate indoor perceived temperature sensor, specifically to handle the "damp cold" feeling.

The Problem: "Cold to the Bones"

My core problem is that the real temperature in a room isn't always a good measure of comfort. We've all felt this: 19°C on a dry, sunny day feels comfortable, but 19°C on a humid, rainy day feels significantly colder—that "cold to the bones" feeling.

I've had the VT set to 19° since many weeks, today was the first day of heavy rain, and while the indoor temp was reading 19° as usual, I was a bit colder than usual.

My goal was to create a "feels like" sensor that reflects this, so my thermostat can react.

Attempt 1: The ha-apparent-temperature Integration

My first attempt was to use the popular ha-apparent-temperature integration, using my indoor temperature and humidity sensors.

• Integration Link: https://github.com/Limych/ha-apparent-temperature

This was inspired by various community discussions, like these:

• https://community.home-assistant.io/t/sensor-of-temperature-feels-like/299063
• https://community.home-assistant.io/t/calculating-apparent-feels-like-temperature/370834
• https://community.home-assistant.io/t/heat-index-apparent-temperature-feels-like-temperature/1282

This failed and gave the opposite result.

• Real Temp: 19.9°C
• Real Humidity: 64%
• Apparent Temp: 20.8°C

The integration (correctly, for its purpose) calculated the Heat Index. It assumes high humidity makes it feel hotter by preventing sweat evaporation. This is great for summer, but it's the exact opposite of the winter "damp cold" phenomenon.

Attempt 2: Adding External Wind

I then tried adding my external sensor.weather_station_wind_speed to the ha-apparent-temperature integration.

This did produce a lower value (e.g., 19.2°C real -> 18.7°C perceived). However, this is a major logical flaw.

I was using an external wind sensor to calculate an internal room temperature. The wind isn't blowing in my camera, so the value was just a coincidence.

Attempt 3: A Custom "Damp Cold Penalty" Template

Since no standard meteorological formula applies correctly to indoor comfort, I created my own template sensor.

template:
  - sensor:
      - name: casa_p0_camera_ambiente_temperature_apparent
        unique_id: casa_p0_camera_ambiente_temperature_apparent
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement
        state: >
          {#--- Load source sensors ---#}
          {% set real_temp = states('sensor.casa_p0_camera_ambiente_temperature') | float(0) %}
          {% set real_humidity = states('sensor.casa_p0_camera_ambiente_humidity') | float(0) %}
          
          {#--- Damp Cold Settings ---#}
          {# Below what temperature do we start feeling "damp cold"? #}
          {% set temp_threshold = 22.0 %}
          
          {# Above what humidity do we start feeling "damp cold"? #}
          {% set humidity_threshold = 60.0 %} {# <-- The source of the problem #}
          
          {# This factor controls how strong the penalty is. #}
          {# (e.g., 63.4% humidity -> (63.4 - 60) * 0.15 = 0.51°C penalty) #}
          {% set penalty_factor = 0.15 %}

          {#--- Calculation Logic ---#}
          {% if real_temp < temp_threshold and real_humidity > humidity_threshold %}
            
            {# Calculate the penalty based on humidity above the threshold #}
            {% set penalty = (real_humidity - humidity_threshold) * penalty_factor %}
            
            {# Apply the penalty to the real temperature #}
            {{ (real_temp - penalty) | round(2) }}
          
          {% else %}
            {# If not in "damp cold" state, perceived is same as real #}
            {{ real_temp | round(2) }}
          {% endif %}

This worked at first. With 63.4% humidity, it was above the 60% threshold and correctly gave me 18.7°C.

This also failed. The next day, the humidity dropped to 59%. Because this was below my hard-coded humidity_threshold of 60%, the sensor reverted to the real temperature. But I still felt cold. My feeling was correct, but my sensor was wrong. This "on/off" threshold logic was too simple and arbitrary.

The Final Solution: The Scientific Approach (ASHRAE 55)

My search continued, and I finally found the correct, formal approach: the Indoor Thermal Comfort Tool, which implements the ANSI/ASHRAE Standard 55.

• Integration Link: https://community.home-assistant.io/t/indoor-thermal-comfort-tool/901623

This integration doesn't guess. It calculates scientific metrics (PMV, PPD, SET) based on six parameters:

1. Air Temperature (Ta) - I have this
2. Relative Humidity (RH) - I have this
3. Mean Radiant Temperature (MRT) - I left this blank (optional)
4. Air Velocity (Va) - I left this blank (optional)
5. Metabolic Rate (Met): I created an input_number helper for this. (1.1 = typing at a computer)
6. Clothing Level (Clo): I created an input_number helper for this. (1.0 = wearing a sweatshirt/fleece)

By correctly setting my clothing level to 1.0 (for a sweatshirt), the model immediately gave me scientifically valid data that matched my perception.

This is the result:

• Real Temp: 18.6°C
• PMV (Predicted Mean Vote): -0.78. This scientifically confirms my feeling of "slightly cold". (The ideal comfort range is -0.5 to +0.5).
• TS (Thermal Sensation): "Cold".

The Perfect Sensor for my Thermostat

The PMV value is the key. I created one final sensor to translate this complex model into a simple °C value for my thermostat, using the formula: Apparent Temp = Real Temp + PMV.

This is the definitive sensor I am now using:

template:
  - sensor:
      - name: "Casa P0 Camera Apparent Temp ASHRAE"
        unique_id: casa_p0_camera_ambiente_apparent_temp_ashrae
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement
        state: >
          {# Load the source sensors #}
          {% set real_temp = states('sensor.casa_p0_camera_ambiente_temperature') | float(0) %}
          {% set pmv = states('sensor.casa_p0_camera_ambiente_thermal_comfort_pmv') | float(0) %}
          
          {# Add the PMV (which is negative) to the real temp #}
          {{ (real_temp + pmv) | round(1) }}

The Final Result:

• Real Temp: 18.6°C
• PMV: -0.78
• Final "Feels Like" Temp: 18.6 + (-0.78) = 17.8°C

How do you handle comfort? Are any of you using PMV to drive your thermostats?

[jmcollin78]

Excellent post. Thank you for posting. This will solve some questions I was not able to answer.

[sleveille4]

hi,

you may want to check this integration:
https://github.com/dolezsa/thermal_comfort

it does contain several comfort index, i think one is aimed at winter comfort and might be the graal you are looking for :)

[nicola-spreafico]

Thank @sleveille4, I actually forgot to include this in my original post, but I had seen it already during my discoveries.

I evaluated it before settling on the ASHRAE tool, but it didn't solve this specific "indoor damp cold" problem. Here is why:

1. The Humidity Paradox (Evaporation vs. Conduction)

This is the main culprit.

• Meteorological (Heat Index/Humidex): These formulas are designed for summer safety. They focus on Evaporative Cooling. They assume high humidity prevents sweat from evaporating, trapping heat.
  • Result at 19°C: It sees 60% humidity and calculates that it feels warmer than dry air. This is the opposite of reality in winter.
• Physiological (ASHRAE/PMV): This model focuses on Heat Balance. At 19°C, the body isn't sweating; it's trying to conserve heat. High humidity increases the thermal conductivity of the air (and clothing), drawing heat away from the body.
  • Result at 19°C: It correctly calculates a negative heat balance -> Colder sensation.

2. The Wind Dependency

• Meteorological (Wind Chill): To calculate cold sensation, standard formulas rely almost entirely on air velocity to strip away the boundary layer of heat on your skin.
  • The Problem: Indoors, with windows closed, air velocity is near zero. Wind Chill formulas effectively turn off or revert to ambient temperature.
• Physiological (ASHRAE/PMV): It calculates heat loss via radiation and natural convection even in still air. It knows you can lose heat to a cold room even without a draft.

3. The "Black Box" of Insulation

• Meteorological: Weather formulas assume a "standard person" dressed "appropriately for the season." It's a guess.
• Physiological: The ASHRAE model allows me to explicitly define Clothing (Clo) and Activity (Met).
  • It calculates: ("Heat Produced by Typing" - "Heat Lost through a Sweatshirt").
  • This distinction is vital. Sitting still in a t-shirt (0.5 Clo) vs. a sweatshirt (1.0 Clo) changes the perceived temperature by over 1°C, which weather formulas simply cannot see.

[sleveille4]

nice, so i decided to give this approach a try this weekend (plus it's a rather cold one here in brittany france)

so i installed the thermal comfort add-on: https://github.com/1iverea9er/Indoor-Thermal-Comfort

then i created 2 MET and 2 CLO input numbers (1 of each for regular rooms, 1 of each for bedrooms)

i found this PDF with MET and CLO tables (pages 5 & 6): https://ierga.com/hr/wp-content/uploads/sites/2/2017/10/ASHRAE-55-2013.pdf

i then created an entry for each room in the add-on, then created one "corrected temperature" sensor (used UI template sensor) per room

ex:
{{states('sensor.capteur_bureau_temperature') | float(0) + states('sensor.tc_bureau_pmv') | float(0) | round(1)}}

with sensor.capteur_bureau_temperature being the room temp and sensor.tc_bureau_pmv being the correction factor given by the add-on

then i replaced the T° sensor in the VTs by the corrected sensor.

i'll report back after testing, but something doesn't look right (after +- 1h):

the PMV values look really harsh, especially for the bedrooms (chambre1 & 2) wich use their own CLO and MET

from what i see in HA (cf. my screenshot) & how i feel after a few hours in this modification, it looks like using the SET sensor instead of creating a room temp + pmv would be better, and the "sensation" sensor is giving weird results

[nicola-spreafico]

This is what I am understanding, which may be wrong considering i'm still learning this topic.

The Standard Effective Temperature (SET) is deceptive. Unlike a "Wind Chill" (which lowers the temp), SET often calculates a value higher than the air temperature in winter conditions, because it accounts for the heat your body produces (Met) and the heat trapped by your clothes (Clo).

Real Temp 19°C. If you are dressed warmly (Clo 1.0) and active (Met 1.1), your SET might be 20.5°C.
If you feed 20.5°C to your thermostat (set to 19°C), the thermostat thinks "It's hot enough" and turns off the heating.

The Real Temp + PMV formula works because it does the opposite: if you feel cold (Negative PMV), it lowers the sensor reading (e.g., 19 + (-1) = 18°C), forcing the thermostat to work harder to compensate.

Looking at your Salon: Real Temp: 19.2°C | SET: 22.1°C

If you use the SET sensor for your thermostat (assuming you want 19°C or 20°C), the thermostat will see "22.1°C", think "It's tropical in here!", and never turn on the heating. You will be cold, but the thermostat will think you are hot.

You correctly noted that Chambre 2 gives a crazy corrected temp of 12.9°C (PMV -4.5). Your Bedroom settings:

• Temp: 16.9°C (Chilly)
• MET: 0.7 (This means "Sleeping" / Lying down motionless).
• CLO: 0.96 (This means "Sweatshirt and pants").

The model sees a person lying motionless (producing almost zero body heat - 0.7 Met) in a cold room (16.9°C) wearing only a sweatshirt (0.96 Clo). The model correctly predicts that this person is entering hypothermia (PMV -4.5).

If MET is 0.7 (sleeping), you are likely under a duvet/blanket during winter. A duvet provides insulation:

• Light Duvet: ~2.0 Clo
• Heavy Duvet: ~3.0 to 4.0 Clo

If you change the Bedrooms CLO slider to 2.5 or 3.0, the PMV will instantly jump back to a normal range (e.g., -0.5), and your "Corrected Temp" will go from 12.9°C back up to something like 16.0°C.

[sleveille4]

thanks, i adapted CLO value for bedrooms and it's indeed better.

it might be good to add a warning about this as i wouldn't be surprise other end up in my situation with a low CLO value for bedrooms :)

the "sensation" sensors still feels off to me, but that might come down to personal taste

[jmcollin78]

Integrated in documentation V8 (in additions.md)

[s1mpleman]

This has been great thanks for sharing it. Working fine for me and because they're input numbers I can adjust the clothing values for under covers on a night in bedrooms which is very handy to lower heating requirements.

I found this blueprint to calculate a virtual MRT which may help. Just set it up this morning and so far seems to be working fine. I input the input_number for MRT it calculates into the indoor comfort value for MRT.

I'm using the illuminance integration to get the W/m3 value it requires and Pirate Weather for the rest.

Illuminance Integration

Mean Radiant Temperature Blueprint

EDIT: MRT Blueprint now an integration

[fhaust]

Some remarks after checking out all of the above:

According to "the source" (https://comfort.cbe.berkeley.edu/) SET is really the value to use. You can play around with the values on the page there.

From what I understand (and there are some informed assumptions about statistics in there), the "Predicted Mean Vote" (PMV) value is more about hitting the temperature the average human is most comfortable at. It is not a temperature offset.

The tool there seems to assume that the average human is pretty comfortable at 25°C SET and still most humans are still comfortable at 24°C, so that's what I set my VT at to save some energy.

The source also specifically mentions that this model breaks down when trying to model sleeping in a bed:

Limits of Applicability: This standard is only applicable to healthy individuals. This standard does not apply to occupants: a) whose clothing insulation exceed 1.5 clo; b) whose clothing is highly impermeable; or c) who are sleeping, reclining in contact with bedding, or able to adjust blankets or bedding.

Let's see how this plays out tomorrow.

[sleveille4]

the approach i tried at using SET was kinda "reversed".

i set the rooms at what I felt "comfortable" in their intended use situation , then adjusted CLO / MET as to have SET read 25°C.

then i used SET as the sensor for VT, it kinda worked for one room, but not for the others that were supposed to have the same CLO / MET, so i couldn't find a common set of MET / CLO, which made no sense.

hence why i went back to the PMV offset, with a better (overkill maybe ?) PMV computation.
this makes more sense as i do have 1 set of MET / CLO for regular rooms (office, kitchen, living room etc...), another for the bedrooms and a last one for the shower

and so far (2 weeks) it really feels like it's working, as i no longer have a "cold" nor "warm" feeling in any room, whatever the weather is (and we experienced various ones in the last 2 weeks).

in my current setup, it seems i reached the end of the config, the last entity to fine tune is my calculation of the w/m2 based on my solar panels output, it's likely a bit off, but the winter weather is clearly not the best to get a proper result

[s1mpleman]

I've been using the Operative Temperature from Virtual_MRT for a few weeks now. It took some tweaking and measuring my rooms to get the calculations better. I found that some of the preset's we're not good for me after reading the documentation a few times. I calculated all my room wall area's and outside area's to get better percentage figures for the Exterior Envelope Ratio, and Window Share and it's made the integration much better. I don't really feel cold just using this value so it seems to be working fine for my setup.

I originally tried just the Indoor Comfort Tool with the SET temperature but it never worked quite right.

I was using the PMV method above, with indoor comfort tool, before, but not really feeding it a decent enough MRT. So I've set up a little test now to see which is better as that originally left me warmer that I thought it needed to be and I seem to be using more gas just using the Operative Temperature from Virtual_MRT.

My CLO and MET values are similarly distributed, my walkways and kitchen have higher than my office and livingroom. Bedrooms are the highest.

• Operative Test: That's Virtual MRT Operative Temperature with the PMV included as an offset.
• Indoor Test: That's Indoor Comforts PMV Value, Fed MRT with Virtual_MRT's MRT Value and included with the current average room temperature.
• Operative: Just Virtual MRT's actual operative temperature.
• Average: Just the average air temperature.

Be interesting to see how they all respond.

[sleveille4]

interesting.

are you using the "radiant" setting of virtual MRT and gave it a heater surface temperature that is real?

because it seems when i tested that despite the "throttle" setting set in, the activation of the heaters made operative T° jump quite high, and when reaching the target T°, overshoot it, so it shutoff the heater, which instantly dropped "operative T°" below the Target T°.

you can guess the rest, fast oscillation of operative T° around the target, and thus fast opening / closing of the TRVs

i tried to alleviate this behavior by filtering the operative temperature with averaged median value (tried from 5 to 30m), it didn't worked as then the median operative never reached the Target, but the actual temp skyrocketed

[s1mpleman]

interesting.

are you using the "radiant" setting of virtual MRT and gave it a heater surface temperature that is real?

because it seems when i tested that despite the "throttle" setting set in, the activation of the heaters made operative T° jump quite high, and when reaching the target T°, overshoot it, so it shutoff the heater, which instantly dropped "operative T°" below the Target T°.

you can guess the rest, fast oscillation of operative T° around the target, and thus fast opening / closing of the TRVs

i tried to alleviate this behavior by filtering the operative temperature with averaged median value (tried from 5 to 30m), it didn't worked as then the median operative never reached the Target, but the actual temp skyrocketed

I had the same yeah, and I am in a slightly different position because I don't use VT climate I use a template climate now. My underlying are wiser trv, and the "heating" state that wiser uses follows the boiler on time with demand so the operative temperature would cycle as well.

I fixed it by making my own template sensor that stays on for a minimum of 20 minutes after the "heating" state ends. This is attached to my template climate so it shows heating, there or about, the time the radiator is actually hot.

This alleviated that issue quite well, although I presume it's why I use more gas using operative as I don't think it's totally fixed.

I also had to play about with the smoothing value and yeah I set the value for target surface heat although the default was pretty close to my radiators. I got the temperature from a infrared temp sensor pointed at my radiators. I presumed that radiant heat wouldn't run as short as the valve opening/closing and I got a smoother operative temperature and less overshoots.

The below is from one of my template climates with the longer heating state and operative temperature and it sits around the correct temperature now. You can still see it though, the operative drops as soon as that heating state goes off it's just a little closer to reality now with me extending that state.

Below is the wiser trv it's controlling with the "actual" heating state. The target jumps because of my adjustments from the template to get the room to temperature.

[s1mpleman]

Funnily enough Indoor comfort and PMV, even with using that MRT temperature from Virtual MRT, doesn't seem as affected by the cycling. I do still have the 20 minute heating state though. I may end up switching back to that over operative.