Oil Use

An Eccentric Anomaly: Ed Davies's Blog

Oops, wrote this post in February but forgot to actually, you know, post it!

My recent Heating Requirements Revisited post looked at the relationship between the heating requirement based on a model using the outside temperature and the wind speed compared to the measured boiler run time. However, the boiler run time is measured somewhat indirectly and might be dependent on other factors so it's worth taking a quick look at its accuracy.

I can't assume that the boiler is running iff my software is calling for heat. Occasionally on cold nights the living room thermostat has called for heat even when the Raspberry Pi hasn't yet. More significantly, the boiler thermostat limits the CH water temperature even when the house is not up to temperature so, even though the Pi is calling for heat and the circulation pump is distributing residual heat, the boiler isn't running. This short cycling of the boiler happens a lot when the CH water is up to temperature but the house hasn't warmed up yet.

Without getting silly invasive, perhaps the best way to see what's going on would be to measure the power consumption of the boiler itself (maybe with something like this Shelly device) as that would make it easy to distinguish the three states: off, circulation pump running but boiler not running and both pump and boiler on.

However, those weren't around when I started this game and it's one thing to add a Wi-Fi-controlled switch in parallel with the existing thermostat as I've done, another to break circuits and add new parts in line in a rental property so I use a more indirect method. I have a temperature sensor attached to the flow pipe on the radiator in my study. Some code, boiler.py, looks at this temperature and, particularly, its rate of change to work out if the boiler is running or not.

A separate bit of code, oil-use.py, takes the output from boiler.py and adds up the number of seconds the boiler has been running, adds 1000 seconds per day to approximate hot water heating then multiplies by a scale factor to convert that to an estimate of litres of oil used.

I can run this in a few different ways. The simplest is just from the command line with specified start and end datetimes to see roughly how much oil was used in that period. Then there's a cron job on my Pi which runs at 05:10 each day to work out the oil used since the last time the tank was filled and post the results to the MQTT server.

10  5    *   *   *   /home/mqtt/projects/mqtt_utils/analysis/oil-use.py -s 2021-01-29T12:50 -t oil/use/estimate

When I get a new oil delivery I just edit the start date in the crontab. I have notifications set up to alert me when oil is getting low. It's nominally a 1000 litre tank (I think) but there's a bit more usable at the bottom but you'd rather not be relying on that.

    {   "topic": "oil/use/estimate",
        "comment": "Oil burned since date set in crontab command estimated from boiler run time",
        "timeout": 87000,
        "zones": [
            { "lower": 800, "upper": 900, "state": "alert", "message": "Oil a bit low" },
            { "lower": 900,               "state": "alarm", "message": "Oil very low" }
        ],
        "units": "litres",
        "axis": 1,
        "axisLabel": "Estimated oil burned since fill"
    },

So, how accurate is this? It's hard to say, the best I can think of is to compare the estimated amount used during periods with the oil deliveries at the ends of those periods, filling the tank back to full. The command oil-use.py --deliveries, after a bit of editing, gives the following:

Start End Delivery Estimate Error Months
2018-03-21 2018-09-25 875 849.7 -2.9% ..MAMJJAS...
2018-09-25 2019-01-09 910 952.3 +4.6% .........OND
2019-01-09 2019-05-06 996 1088.9 +9.3% JFMA........
2019-05-06 2019-12-11 1048 1211.4 +15.6% ....MJJASOND
2019-12-11 2020-04-01 1004 1150.1 +14.6% JFM........D
2020-04-01 2020-10-19 806 947.5 +17.6% ...AMJJASO..
2020-10-19 2021-01-29 902 975.7 +8.2% J........OND

Hmmm, OK but I had hoped the errors would be a bit more consistent.

I'm thinking it's to do with double counting where there are some days when the space heating is off at the time the DHW is heated so adding 1000 seconds is valid whereas other days the heating is on when the DHW is heated so the time is already counted. Still, you'd expect that to happen more in the winter than the summer but the second and third biggest errors shown above are in diametrically opposite periods of the year so it's all a bit of a puzzle.