Thanks for sharing this blueprint — it was the spark that made me build a virtual MRT (Mean Radiant Temperature) sensor to better reflect perceived room temperature.
In my setup, just using air temperature wasn’t telling the whole comfort story. MRT captures how warm/cold the room feels due to surfaces and solar effects. I wrapped this into a blueprint that:
computes MRT and optional operative temperature,
supports KNX exposure (DPT 9.001) if you want it on the bus,
prefers dedicated weather sensors (PirateWeather for me) but falls back to the weather entity (Started with met.no) and finally a heuristic,
optionally uses a global radiation sensor (W/m², OpenMeteo for me) for better solar coupling.
TL;DR: Is this blueprint supposed to keep the thermostat’s target set to the calculated base_adaptive_comfort_temp value when the space is “occupied”? If so, how can I tweak that value?
Let me first apologize to the world for being an American that grew up with Fahrenheit and so many other terrible units of measurement. I blame our forefathers. Please look past that. I tried to convert to °C as often as possible for my target audience.
@msinhore@SuprBadass I’ve implemented the Fahrenheit fork of this earlier this week. You may have seen a couple of issues I posted on the repo. After tweaking those things, I think the automation is “working” as it was meant to be. But if it is, then it is not working how I expected it to… so I wanted to post here to see if my expectations are too high and if there are any suggested methods of reaching my goals.
The automation is keeping the house in the low 70’s°F (21-22°C), which feels too hot, especially given mild outdoor temperatures 69°F (20.56°C). I have it set to Category III (3) mode and expected the “wider comfort band” to allow for the temperature to swing towards the lower limit in the winter and the higher limit in the summer.
I was sweating overnight… it wanted to heat my house to 71°F–72°F (21.67-22.22°C)… it was probably in the 50’s (10-15°C) outside. I’d rather a 67°F (19.44°C) target in that case… that would be plenty warm.
But come summer (meaning, ANYTHING OTHER THAN WINTER in Texas) when I flip the switch to COOL mode, I don’t want it 67°F (19.44°C) in my house… well, I’d love that; but I can’t afford that. That’s the benefit of using an adaptive algorithm like this.
I either need to:
Find a way to tweak this automation to NOT set my thermostat’s target to the base_adaptive_comfort_temp but instead allow it to drift within the comfort_tolerance “band”. I guess that would mean setting the thermostat’s target temp at the comfort_temp_min when in HEAT mode or set to comfort_temp_max when in COOL mode. I’m sure there’s something wrong with that logic, too.
OR
tweak the algorithm to decide that the base_adaptive_comfort_temp should be ~67–68°F (19.44–20.00°C) in my example above. I’m afraid to start messing with equations I don’t understand, though. It might work today; but in a week or two when Texas Winter is over (ok, maybe a month or two) and I turn on COOL mode, will my tweaked equation still be ideal? If it’s 96°F (35.56°C) outside, I’d want the inside to be about 78°F (25.56°C), as an example… The rest of the family might like 74–76°F (23.33–24.44°C) though.
AI is “helping” me interpret the blueprint, and it output this second opinion request for me earlier today. I’ll be lazy and just paste it below since it does a pretty good job of summarizing my bitching.
I’m a week into using Home Assistant, and I’m on 2026.1.3 running on a 2GB Raspberry Pi 4B. I’ve been playing with this blueprint for the past few days. My HVAC system is Ecobee (two thermostats), triggered through SmartThings given that it seems Home Assistant can no longer directly integrate directly. My weather data comes from my personal weather station, and room occupancy comes from Ecobee room sensors. I use helpers to average the temperature around the home for the different areas I’m monitoring. I use two separate instances of the blueprint - one for each side of the house - and have two separate learning and delay variables.
Things I’ve noticed:
The blueprint syntax for triggers is out of date: trigger/platform vs triggers/trigger. I don’t know if this is one of the causes of the issues I discuss below.
The blueprint does not seem to gather current state when it restarts after you make a parameter change. For example, my doors are open when I change a parameter: The blueprint runs as if everything is closed, so the heating turns on until after I trigger a door open/close event.
I could not get the pause logic to work at all when using a helper that contains a ‘door’ binary_sensor that amalgamates all the doors I want to track. The state will only change from off to on, and vice versa, if all of the states are either on or off. Couple this with 1) regarding state, and nothing triggers even if the doors are open when the blueprint starts.
Despite running two separate variables for learning persistence, I’ve noticed that the blueprint appears to be writing identical values to both variables at the same time. I expected changes I make to one side of the house to not be reflected in the other; meaning that I would have thought one thermostat would work differently than the other based on the manual overrides I make.
If anyone has any comments or advice for me, I’d appreciate it. All in, I think this blueprint is very well thought out.
I’m replying to myself. I fixed the dual sensor issue after learning a bit of yaml. I have had to edit the base blueprint to send the learning sensor id as a parameter to the set_variable trigger. I duplicated the listener for set_variable (et al.) and created two sensors, one for each zone of my house. Using the sensor id passed in the event, I used the trigger logic to only process messages for the specific sensor, and now the automation maintains two separate sets of parameters for the zones. It was a learning experience. The pause logic is still a bit suspect, so I added logic into the pause handler to ensure the Ecobee is turned off in both zones. The automation itself is running beautifully now, and I’m already convinced this will save me a bunch of money. I hope these rambling updates help somebody along the way.
That’s the benefit of using an adaptive algorithm like this.