TerryE

@Gus Potter, both, but definitely saving money in two ways: first in upfront costs during the build: our complete CH system including the UFH pipework in the slab came in at under £4K and that's for a reasonable 4 bed detached house (3 of which have ensuites and they are all decent doubles). The CW and DHW also under £4K. Second in terms of maintenance and running costs, we don't have complex kit like UVCs, Gas boiler or ASHP or. expensive systems like Loxone that require a pricey annual maintenance contract with an approved maintainer. We keep our house at just over 22°C 24×7, and we can only do that because the heating system is optimised for the house. And yes I do get a kick out of the intellectual side of modelling and designing these, and documenting them on the forum for others to follow.

If you think about the heat flow in the house UFH, you have the UFH loops conducting with roughly semi-radial heat-flow so each metre of pipe warms 0.03m³ concrete which then reradiates from the surface into the living space. The rebar mesh improves the conductive spread, so this is a very effective store and radiate system. Your loops are quite long, say around 80m on average and you have 7 in parallel increasing the effective flow cross-section accordingly. If you get the effective power O/P of the ASHP and the average Δt out : return at the main manifold, then you can estimate your average flow rate. Ditto for the Summerhouse. I suspect that with 7 loops your flow vs head is with the tolerances to use a single circulating (?ASHP?) pump and no buffer. Does the SH only have 1 loop? Here it is relying on conductive transfer from the UFH runs to the wood flooring without mechanisms for lateral heat dispersion. Wood isn't a good insulator but it's a lot more of a one than concrete. It's just not going transer the heat from the UFH floor effectively. Without separate pumps, mixers and a LLH the main and SH circuits will see the same pump head and so the flow rate in the SH could also be a lot less than the main house. Given that the SH has an intrinsically low thermal mass, you could realistically heat it "when occupied", shifted maybe 30-60 min say to take out heating lags, so let's say 5×8 hours per week for maybe 6 months a year. I suspect that this is going to be a lot less than the amortised cost of trying to complicate the UFH systems. Though it is probably worth leaving it as-as for basic anti-frost / chill protection and using the heater to lift the temp that extra 8°C or so.

I've posted a couple of related topics in the Boffin's Forum: An Aug 2019 topic: IoT / microcontroller based power switching. And March 2020: Raspberry Pi based CH and HW control. Some of my household services need an availability on a par with external utilities such as our electricity, water supply and sewage: our central heating (CH) and direct hot water (DHW) just need to work and be available without hiccup: losing either of these systems would be a real hassle if the outage was greater than 24hrs. I use a HomeAssistant (HA) system to integrate and to automate other IoT goodies stuff: e.g running various lights and timed appliances, together with a bunch of temperature / humidity and motion sensors, and a few smart button to sequence some of these. However, for reasons discussed in the footnote HA is just too flaky for 24 × 365 service provision of critical services such as CH and DHW. In my view these require a separate dedicated and minimal system to run CH and DHW control. There are many ways to achieve this, but some six years ago I opted to use an RPi3B with battery backup and SSD running a simple Node-RED stack and my own custom code. This has performed flawlessly and non-stop for that time, and it still offers a lot of headroom for me to enhance the system. I would recommend this approach to any other self-builder, if you have some basic programming skills. However I am now about to switch to an Octopus Agile tariff (see this discussion), and this will require some changes that I will discuss in later posts in this topic. One of the fey functional changes to my CH system is that I now use 3 small oil-filled rads to supplement my UFH during the colder winter months. I used to control these from HA using Zigbee Smartplugs, but I can now remove this dependency on HA by switching to Athom Smartplugs with pre-installed Tasmota Firmware, as this will allow me to directly control and to monitor them directly from Node-RED using a couple of HTTP requests direct to each Smartplug. Again, I can provide more details if anyone is interested. Footnote: My View On Why HomeAssistant Is Just Too Flaky To Provide Critical Services When I used to use an RPi to host HA I three had HA+RPi hardware failures that required me to rebuild and reinstall the system. I ended up HA onto a VM hosted under Proxmox (an old laptop upgraded to 8Gb + SSD running closed) and this largely solved these sudden death events. The HA development team uses a monthly update cycle to minimise the delays in getting new functionality in use. This means that new functionality is often not fully test and sometimes introduces breaking changes to an integrations and add-on module, or even another unchanged module which has an interdependence, but this means that any upgrade is game of Russian roulette. At least the Proxmox functions to snapshot and restore VMs are a lifesaver as these take seconds to a minute to do, whereas a HA native restore takes a few hours. If the bug introduced by the upgrade is a subtle one then it might be too late to roll-back to the old version once the symptoms become apparent. For example, before we went on a long spring visit to Greece Jan went round turning off a lot of wall sockets — some of which were Smart plugs, acting as routers in my Zigbee mesh. Logging remotely I could see that most of my Zigbee devices were now unavailable, and the Zigbee HA Integration marked these as dead. No luck in reconnecting them when I got back. The advice on the HA forums for this failure mode was to do a complete clean install, I am annoyed but relaxed about all this because these devices are in the nice-to-have category, because we can always turn on and off lights the old-fashioned way. In principle I could do all of my house automation in HA, but my view HA as serious issues for "production" use.

@JohnMo, sorry but I don't know the details of your house. I can't recall any topic where you've given an overview of your house characteristics, but I suspect from your general posts that it is a well insulated low-energy build with a decent high thermal capacity slab. The summer house is well insulated but everything has extremely low thermal capacity so it going to be very different in terms of its response curves. By way of an example with our Warmslab, the UFH really heats up the concrete in the slab over say 5-7 hour heating period, then the warm floor transfers this heat into the house over the next 18 hours or so. If not identical then at least your main house UFH at least has 50 mm of concrete to act as a thermal buffer and spread the heat across the floor. However it sounds like you don't have any equivalent high-thermal capacity buffer in your summer house so its heating characteristics will be different in terms of ability to absorb and retransmit heat from the UFH loops to the room environment so hence the different in Δt for the two UFH setups. It's going to be hard to match the two systems and drive them from the same ASHP without adding a low loss header extra pump and using the manifold TRV on the main house to drop the circulating water temperature. @Nickfromwales you have a better idea of this sort of stuff.

@SteamyTea. No just my current OVO Simpler Energy - Economy 7 plan to the Octopus Agile Flex one.

@Alan Ambrose Yes, if you ignore December, then the saving for 2023 to date would be 21% just by aggregated tariff reduction, increasing to 26% with a bit of time-shifted load optimisation. In the summer, I don't have that much shiftable load, so any savings are largely because the OVO tariff ignores the daytime excess of demand vs supply. The bills are higher in the winter, but the scope for optimisation is greater. We don't have rooftop PV because the planners were against for our site location, so if we had a battery then it would be battery only. At the moment there isn't a case because Home battery pack prices are still in the £500-1K range per kWh, despite LFP bare pack prices having now dropped to £100 / kWh, so there is still a load of headroom for prices to fall. Secondly, a side-effect of increasing renewable supply is that there is going to be increasing time-of-day price variability in the coming years. So my take for us is: not yet for home battery, but possibly within the next few years.

OK, here are my results based on my Dec-Oct actual OVO reading recorded by my Smart Meter: Dec was a funny month because of the Russian energy squeeze, a triple whammy: Russia; we were still on an old fixed tariff for the first few days, and the short term prices were in panic which OVO were better buffered from. We might get a similar pulse this year but we are on an OVO variable tariff and the markets are better prepared so I have decided to ignore this as a one-off glitch. (Note that the Oct figures are off since it is an extrapolation of the first 20 days, but the heating only started to come on on the 17th so this will rise slightly.) That aside, the Octopus Agile tariff gives overall lower monthly prices than OVO E7, but not hugely so. The main difference is during those May-Sep summer months where the usage profile is pretty flat and we get hit hard by the OVO peak rate. The Red bars are based on historic actuals as-is at the then Octopus Agile price. The Yellow ones are where I had a play with moving some of the time-shiftable load (CH, DHW, cold-fill washing) to cheaper time slots. This did seem to make a small but noticeable improvement, but not earth-shattering. My time shifting algo was just a first cut, and more work is needed here. So all in all, it looks like we'll be shifting to the Octopus Agile tariff in the expectation of modest savings.

Speadsheet WEEKNUM() by default starts on Sun with week 1 starting on the first Sunday in the year, in this case the 1st. I initially extended back into 2022 but this caused a bump back to 52 in the previous year. So I arbitrarily did at cut-of at "0" which started on Christmas Day 2022. The current system is going to have to go through some phase change (using Tony Seba's phrase) because of the inexorable encrosion of non-baseload renewables. Getting businesses and a reasonable fraction of the end-consumer base onto tariffs which encourage time shifting helps to remove peaker generation capacity.

Here is the graph for the Octopus tariff. It's essentially the same unit pricing except it goes back into 2022. I've only included the 2023 weeks:

Yup and OVO are charging me 19p for off-peak. EDF are taking the futures risk here or laying them off on their wholesale suppliers via fixed N-day ahead contracts -- which is why these prices can be fixed. As @S2D2 says, Octopus have an equivalent Cosy tariff. With the Agile tariff they pass their half-hourly supplier costs straight onto the customer, albeit with a built-in handling mark-up. The customer takes the risk, so the prices can peak at a lot higher than these fixed tariffs, but they should be less overall, especially if you time-shift demand to the cheaper half-hour slots.

Most tariffs require the provider to do ToD and within each quarter price levelling based on futures forecasting. This involves risk and this risk must be factored into any price-to-consumer calcs. I am happy to "self-insure" on such forecasting, as I have the cash floats to do so. I haven't done the sums yet either, but I have enough data now. Watch this space. 🙂

I've done the 1st cut of two Perl scripts. (Sorry. I know Perl ain't too fashionable these days, but it's the first productivity scripting language that I learnt about 30 years ago, and I still prefer it for this sort of quick and dirty stuff than Python, JS, PHP, etc.) The first downloads the half hourly price data for the current Octopus Agile Tariff into a MySQL (actually MariaDB) table. I've written this so I can add extra days of price data from time to time. My meter is in GSP band B. The second does some analysis of the downloaded to do aggregated views. I can upload to my public files server if anyone is interested. Anyway, here are a couple of analysis cuts taken by importing the CSV data into Google Calc and exporting the charts to GIF: This shows how the average (ex VAT) pricing reflects the typical "Duck Curve". Incidentally my current Ovo E7 rates are 18.12p and 29.21p per kWh so a lot more overall. This second analysis is derived by sorting the half hourly price slots low to high, and this underlines the price advantage you can get if you can do load time-shifting across the day. For example at the moment I heat my slab during the E7 off-peak window, even though bunching the heating overnight gives a residual about a 1°C ripple on the room temp, but we live with this because doing so works at 40% cheaper than using peak rate. However I could just as easily use any N hours and also spread them through the day to flatten the ripple. We also need to schedule where practical cooking and use of cold file whitegoods outside that expensive 3-6PM high demand period and preferably use 10PM - 4AM in the winter or 11AM-2PM in the summer for peak use. Because I've got my actuals usage by half-hour for the last 5 years, I can do some "what-if"s to get an estimate of what switching to a flexible time-day-strategy will save us. PS. code: "AGILE-FLEX-22-11-25" brand: "OCTOPUS_ENERGY", direction: "IMPORT" display_name: "Agile Octopus", full_name: "Agile Octopus November 2022 v1" description: "With Agile Octopus, you get access to half-hourly energy prices, tied to wholesale prices \ : and updated daily. The unit rate is capped at 100p/kWh (including VAT)." available_from: "2022-11-25T00:00:00Z", available_to: N/A, term: N/A links: {"href: "https://api.octopus.energy/v1/products/AGILE-FLEX-22-11-25/", method: "GET", rel: "self"} code: "AGILE-FLEX-BB-23-02-08" brand: "BULB", direction: "IMPORT" display_name: "Agile Octopus", full_name: "Agile Octopus February 2023 v1" description: "With Agile Octopus, you get access to half-hourly energy prices, tied to wholesale prices \ and updated daily. The unit rate is capped at 100p/kWh (including VAT)." available_from: "2023-02-08T00:00:00Z", available_to: N/A, term: N/A links: {"href: "https://api.octopus.energy/v1/products/AGILE-FLEX-BB-23-02-08/", method: "GET", rel: "self"} It looks like I pulled down the wrong tariff. The AGILE-FLEX-BB-23-02-08 tariff is actually the flexible tariff for ex-Bulb customers; AGILE-FLEX-22-11-25 is the current Octopus one. Both are unrestricted, green, variable, monthly in-arrears, consumer tariffs. Hopefully their pricing is the same or very similar, but let me redo this analysis.

I've done the Perl script that downloads the prices since the start of the current Agile Tariff in March for a given Grid supply point. (You can lookup the GSP for your MPAN.) I'll dump this into a SQL table and mod the script so that it only requests new data from the last dump. Lots of fun analysis to follow. 🤔

AFAIK the OVO portal doesn't have a publicly available RESTful API for you to be able to download the sort of detailed half-hourly usage analysis that you can view online through their portal. However the portal's user interface makes heavy use of Javascript (JS ) scripts to do the webpage renders, and these in turn make internal JSON callbacks to the OVO server to fetch the data. I reverse-engineered this internal JSON API using a Chromium browser and its webtools window, so that I could automate downloading this usage data and aggregating store it in a database. I have now collected 5 years of this data. I wrote earlier versions in Python and Perl, but I now only maintain a JS script version that runs as part of my NodeRED system used to control my CH, DHW and temperature logging. If anyone is interested in doing the same, I can share my script and NodeRED flow, and if you have NodeRED running on an RPi or equiv, then you should be able to use this pretty much as-is. Alternatively if you know enough Javascript and MySQL to read and understand what I am doing, then you could recode this into your favourite scripting language. I am also considering switching to an Octopus Agile Import tariff, so what I want to do over the next few months is to benchmark my current OVO plan vs Octopus Agile to see if there is an overall benefits case for our doing this. Luckily Octopus do make their Energy API publicly available here. I plan to do a similar download exercise for Octopus Agile half hourly prices, as well as some what-ifs based on having this day-ahead data available. For example my CH algorithm also works day-ahead and computes how many hours of 3kW Willis heating the in-slab UFH to keep the house within planned set points. Using an example 360 minute heating requirement, I currently schedule this during the 7-hour E7 cheap rate window (from 1-7AM), but I could just as easily use the cheapest 12 half hour slots during the day. I could also switch some heating to my (remotely controlled) oil-filled rads, turning them on during the cheapest half-hour slots. Ditto for scheduling our SunAmps. Also because the price dips tend to follow low-demand periods, e.g. prices between 0-4 AM are often a few pence per kWh or negative, we could also reschedule time-settable devices such as dish and cloths washing to use these cheap windows (ours are electrically heated cold-fill so are quite power intensive when heating). We seem to have around ⅓ kWh / hr base load in the house from electronic devices, fridges etc. Another what-if game to play is what would the cost benefits of adding say a 6kW battery to shift all use to these extremely cheap priced half-hour slots, but that's a separate topic in its own right. I suspect that we aren't there yet but soon. 😊

I use an old Lenovo laptop for the same purpose, though I did add extra 4GB ram and replaced the HDD with SSD (l moved the old HDD to external to use as a backup device). The advantage of the closed laptop is that it has built-in UPS. I run Proxmox which hosts a Home Assistant VM and 6 LXC containers. I still use an RPi3 for my CH, DHW and temperature logging system. This is configured as a headless NodeRED system. My 2 RPi4s are currently unused, so whilst I am interested in the RPi5, I don't have a use for one currently.

BTW, I discussed how I got the 7ΔtA figure in one of my blog posts, A Little Aside On Radiance. When there is only a relatively small delta, say less than 5°C, there is little convection, so maybe 80% + of the heat is actually radiative, and there is standard physics law for this that includes an adjustment factor called the emissivity. This is a fraction that will 0.9 or so for non-reflecting surfaces, so the 7 number is a good ballpark, but remember the Δt is measure for average floor surface temperature over the day relative to the room temperature.

No. You are partially correct in that heat loss through the slab is really dependent on the average slab temp and not the room temperature, but the slab will pass about 7ΔtA W into the living space, so by example if you have a 100m2 slab and need 24 kWh of daily heat input, say, to keep the house in thermal balance, then this is an average 1000W so the slab needs to be roughly 1.4 °C warmer than room temp across the day to do this, and you should add this 1.4 into this term, but given that this is a small delta and the estimate is ballpark, then it's just easier to use room temperature. The average slab temperature can be very different to the boiler / heater flow output. (See my blog posts on this.) Also because of this sort of simplification, this spreadsheet really only works if you have a (near) passive class build (i.e EPC A class). In this sort of build, there is also no way a flow temp of even 35°C is suitable for this type of house as you'd end up with a 1:10 on/off cycling of your boiler / ASHP.

Yup, certainly for dwell time -- I'd need to check the code to see how long -- really just enough to allow the heat in the 50mm or so of the concrete near to the UFH pipe to disperse and along the pipe. By 8AM onwards the rate of slab cooling is pretty proportional to the Δt between the slab and room temps. The decay is a lot faster 7-8AM, but I suspect that is because heat is being drawn down mostly through the rebar from the 150mm slab area where the UFH loops run into the deeper cross and ring beams. I also circulate the UFH for 8 mins before the hour every hour just to help even out any solar gain warming, etc., and I use the average return temp at the end of the 8 min period as a precise measure of the average slab temp.

I have been logging temperature data from a dozen probes across the system: hall temp, the outs and returns from the slab, the willis, etc. ever since we started using the CH system after we moved in in late 2017. I have started an exercise to mine this data in order to calibrate a simple heating model which gives a reasonable fit to actual house performance. Take an example, the current heating algo computes the predicted heating time, and when the external temperature is low, this is invariably more than 7 hours, so this first 7 hours is dumped in during the E7 off-peak window , with any remaining heat only added if the internal hall temperature fall below a preset (~22°C). This sometimes doesn't happen if the hall was slightly warmer than average at the midnight rollover. So I have a bunch of days where the external temp was ~5 °C and the house was only heated from 0-7 UTC. I can average these out to get a typical house response curve for this initial condition. Ditto when the external temp was ~10°C, say, though in this case I need to group by actual heat input. as the CH system is on for less than 7 hrs. Also in warmer periods, the unheated slab still typically hovers at about half a degree cooler than the hall; this is because the ground is at ~10 °C below the slab, so there are still heat losses to ground, this set of reading can give me an estimate of these. Anyway, I'll crank the numbers over this next week or so, and the next post here will be on what I've found. One quick spoiler: my actual overall heat losses are about 50% more than what the simple JSH approach predicts. So the as-built house is only low energy rather than true passive-class: we need ~20-25 kWh daily top-up in the peak winter months instead of 10 kWh or so, but this is still many factors less than a typical 2018 house of our size.

We put up posts and strung a thick rope between them using brass fittings. Looked nice, didn't really obscure the view and did the job. Just whip the rope ends to look nice.

I've had the same one for 45 years. Still think that I am a lucky chappy. 🤣

@andyscotland that's a really interesting link, so now bookmarked. If we do decide to install an ASHP as per my recent How an MBC WarmSlab Has Actually Performed based on 6 Years Data post, we would go for a bufferless Panasonic which is well matched to our low energy house. Most standard installers won't touch this, because they don't understand how passive-class houses work. Our problem isn't complying with the BRegs re noise etc., it is getting MCS design sign-off, if we want to do this under "permitted development". Thanks.

@FuerteStu, with this type of house, yes you can put a manual thermostat on the wall, but don't connect it to anything! Let's say your better half is feeling a bit chilly and cranks the stat up by 5° just before going to bed. Well at ½°C / hr, it will be hours before you even notice any difference; by the time you do, the slab will be too hot and the rooms will carry getting warmer for hours, and there will be nothing that you can do about it short of throwing windows and doors open. An analogy: think of a canal boat vs. a little skiff with outboard. The first is far more fuel efficient per tonne of payload carried, whilst the second is "agile"; however, canal boat can't respond to the tiller the same way that the skiff does. We just set our house a to 22.4 °C average setpoint. Because our heating is done overnight, there is a time-of-day ripple of ±½°C on this: never too hot and never too cold, so always comfortable. Last winter I dropped this to 21 °C to do my bit on fuel economy, but I also bought a cheap free-standing oil-filled radiator and put it in our living room. 20 mins on a low setting when we felt cold was enough to turn the room toasty. Having something like this would give your wife the control that she likes over her sitting space.

@SteamyTea Nick, the more I think about your comment, the more I like it. 🤩 Just think of a warm slab as a 20 tonne (or whatever yours is) storage heater under your feet. Don't worry out the internals; it just works. You can stick 1,2,3, ... kW into it, and it will soak up the energy, and then slowly radiate the heat back into the internal airspace. I feel another modelling exercise and post coming on.

@SteamyTea, I agree with what you say, however storage heaters are an old technology that is implicitly accepted as "doing what the name says". This isn't the case with the warm slab construction technique. We've got all exterior walls, floor, roof with a ≤ 0.12 U-value; MVHR and airtight to ~0.5 ACH. Inside this insulated skin; we have a 20+ tonne slab that acts as storage heater, and it works just as you say storage heaters work. The internal fabric of the building also adds to the thermal capacity. We can keep our house at a comfortable temperature 24×4, 365 days a year, using a very simple control system. We still get members here with builds that cry out for this approach, but they end up going with base slab, 200 mm EPS or equiv and UFH loops over a membrane clipped to this, then a thin say 40-50mm unreinforced self-leveling skim because that's what their architect has specified. The single integrated reinforced slab with embedded UFH and an external insulation jacket is cheaper and simpler to build if you have a trained and competent construction crew. "I want per room zones". "I want to be able to heat up my house rapidly when I come home so I need a thin UFH layer." All a mistake, IMO. Our build has far less running cost than a typical build where each room's temperature yo-yos around, and there is all sorts of control complexity trying keep decent thermal control.