Ignoring the internal temperatures

@Timbones @mjr I thought you might be interested in this situation which happens a lot in our house during the shoulder months.

The family throw all the doors and windows open and the internal temperature falls quite a bit - apparently down to 18 °C in this case from the more typical 21 °C. In fact in this case the heat pump’s internal sensor got up to 22.5 °C because the “machine room” is getting a fair bit of sunshine at the start of the day.

Later, as it starts to cool down, they (sometimes) shut the house up and the solar gain warms us up again. With all the other things happening in the house, such as cooking it can even get up to 25 °C where the heat pump internal sensor is situated (see the purple line around 19:00).

The blue line is in a room at the back of the house which doesn’t have much activity so you can see it’s much more stable (with a lot of weird spikiness I’m ignoring).

Given this excitement you can probably see why I’m a bit wary of leaning on the idea of there being a single “indoor” temperature which is why I was reticent about adding it to the MMSP heat pump app. I don’t think it’d help anyone to start adding even more temperatures in the app though!

I’m assuming you are seeing different behaviours. I’d be interested to see them if you are willing to share.


My “plant room” is the airing cupboard at the top of the stairs, and is considerably hotter than anywhere else in the house. So, I don’t use the RoomTemperatureZone1 reading as it’s not representative. [There’s also no room left in the cupboard for airing any washing, but that’s not important]

Instead I have 5 wireless thermometers that are continuously read by an old Pi under the stairs. This gives me a reasonably good average for the whole house. One of the bedrooms is south-facing, occupied all day, and has several heat sources, so is much warmer than the rest of the house, but is countered by a couple rooms on the north end that are naturally cooler than the others [I don’t do micro-zoning].

When there’s no solar gain going on, and the heat pump is the primary source, then the room temperatures are typically within 1 degree of the average (black line). The lounge (orange line) is usually close to the average; the room stat that controls the heating is also in the lounge.

I use this average temperature to “turn off” the heat pump when the house is deemed warm enough, overriding the room stat. (I’ve documented the issues with my room stat elsewhere)

Family members opening windows and doors as soon as the sun comes out is a challenge for any heating system. I find myself turning it off manually at the room stat, and then having to leap out of bed early the next morning when I remember I’ve not turned it back again.

It does seem daft to be heating the house in the morning on days which are going to become warm out anyway. I do have forecast temperatures in my system, so I could try predicting it, but not sure it’s worthwhile. Since I’ve [just] gotten onto RHI, which will more than cover running costs, I try not to worry about it so much.

1 Like

Here’s a couple of things I do that you might find interesting then @Timbones

def isPlentyWarmEnough(calculationMoment: datetime.datetime, deviceInfos: DeviceInfos) -> Optional[str]:

    first = deviceInfos[0]
    last = deviceInfos[-1]

    lastTemperature = EffectiveTemperature.apparentTemp(calculationMoment)

    if lastTemperature > TemperatureThresholds.noHeatingRequired(calculationMoment, deviceInfos):
        return "It's " + str(lastTemperature) + " °C so we don't need heating"

    firstTemperature = EffectiveTemperature.apparentTemp(LastTimeStamp.lastTimeStampInUTC(first))

    # We really need a prediction of how hot it's going to be, but we can get an idea by seeing how it's warming now

    timeDelta = (LastTimeStamp.lastTimeStampInUTC(last) - LastTimeStamp.lastTimeStampInUTC(first)).total_seconds()
    if timeDelta <= 0:
        logging.debug("We can't tell how the temperature is changing")
        return None

    temperatureDelta = lastTemperature - firstTemperature

    temperatureChangeRate = round(3600 * temperatureDelta / timeDelta, 2)

    if lastTemperature > 5:
        if temperatureChangeRate > 1:
            logging.debug("It's " + str(lastTemperature) + " °C and it's getting warmer at " + str(temperatureChangeRate) + " °C per hour so we don't need heating")

and also this:

def isPlentySunnyEnough(calculationMoment: datetime.datetime, deviceInfos: DeviceInfos) -> bool:

    solarReading = EmonCMS.getFeedValue(1, calculationMoment)
    solarPowerInWatts = solarReading["value"]

    lastTemperature = EffectiveTemperature.apparentTemp(calculationMoment)

    if lastTemperature > 10 and solarPowerInWatts > 800:
        logging.debug("It's " + str(lastTemperature) + " °C and the solar power is producing " + str(solarPowerInWatts) + "W so it's sunny enough to not need heating")
        return True

    if lastTemperature > 7 and solarPowerInWatts > 1200:
        logging.debug("It's " + str(lastTemperature) + " °C and the solar power is producing " + str(solarPowerInWatts) + "W so it's sunny enough to not need heating")
        return True

    logging.debug("Solar power is producing " + str(solarPowerInWatts) + "W")
    return False

Which is some pretty troubling “magic numbers” to be seeing in code!

However, it gives you that “ooh, it seems to be getting warmer, let’s stop worrying about heating” without trying to get too much into a prediction. If it ends up getting warmer, but not warm enough (say those clouds roll in) then the temperatureChangeRate will drop and it’ll allow the heat pump come on.

I created that when I spotted the thing you mentioned, those mornings when it’s warming rapidly and it would be obvious to a human that it’s futile to be heating the house.

I’m still willing to let it heat the house if it’s actually chilly right now.

Arguably the isPlentySunnyEnough is just a proxy for insolation and I should pull my finger out and get a proper formula for it.

1 Like

I think my Pi overrides the room controller at 4am and takes back control if anyone has been setting things manually, but I can’t remember if it’s ever happened in reality yet. People use the room controller less, now that the Pi has a choice of dashboards (web and hardware).


So here’s a sunny spring day on my system. There’s probably two effects going on. Firstly, RoomTemperatureZone1 is taken in the central stairwell, away from any radiators or windows, so it’s pretty stable. Secondly, it’s basically what my algorithm is aiming to hold steady anyway. BoxTemperature is on the Pi in a corner room, with an IMO-oversized radiator but also fairly exposed to some cold winds.

Also, no-one here is throwing windows open until it’s well above 20°!

1 Like

I’m trying something new, which is to compute the weather compensated temperature using the forecast temperature, about 2 hours in the future (using data from OpenWeatherMap.com).
{See simple script in this thread to fetch the data via their API}

My rationale is thus:

  1. when the future temperature is going to be significantly warmer, the heat pump will work towards a lower temperature with improved CoP
  2. when the future temperature is going to be significantly cooler, ramp up the flow temperature while the ambient temperature is warm, again improving CoP

Compare red line in the chart below, calculated from the forecast temperature, to the orange line, calculated from the current temperature. It’s generally lower in the morning, and higher in the evening.

Bottom of the chart shows the OutdoorTemperature supplied by a sensor on the external HP unit, and the actual RecordedTemperature from the local weather station. Note how the OutdoorTemp is coarse to the nearest degree, and has local dips similar to what MyForest was seeing in this thread, directly related to when the HP was running. I much prefer using the smoother, more precise readings from the weather station (from the future!). (I also factor in the effective temperature, but that’s another topic).

It’s been cold and snowy up here today, so not sure how this would work on a nice spring day. For my next trick, I need to figure out how to delay the start of the heating in the morning, like some “Smart” room stats can do. Basically, have it start as late as possible while still getting the house up to a comfortable level. Better if there’s sun on the panels by then too. I was kinda hoping that suppressing the flow temps would do this for me for free.


If you’re using melcloud, you get some forecasts in the device data anyway. That’s all I’m using, looking at the forecasts for “now” and “later” (the first two forecast periods of 4, I think). It’s fairly crude but seems to work well enough. I expect your OpenWeatherMap reading will do even better.

Fools seldom differ, so I’m doing something similar to your rationale. I’m pretty sure it helps, but I didn’t do anything like a controlled experiment because it costs money to deliberately do it wrong!


Ah, I might be able to help with that. If you look at my scripts you’ll see a calculationMoment parameter on the methods. That allows me to time-travel and see how the algorithm felt about something at a different time. Notably it means I don’t log all the debug because I can go back in time and ask it “what were you thinking!?”

It actually allows me to travel forward in time too, but that’s a bit harder because the data isn’t available for all the streams and you have to work out how to answer the future requests. It does allow me to have unit tests that say things like “make sure you turn on the shower at a sensible time when there is daylight savings” or “ensure you turn on if it gets really cold”.

Anyway, the bit where it really helps is when you change the algorithm and then you can ask “how would this new algorithm have handled last Tuesday?” So that frees me up to experiment without paying anything except for my time. Which is invaluable and irreplaceable. Oh.

1 Like