TerryE

@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.

In my topic Modelling the "Chunk" Heating of a Passive Slab, I discussed how I used a heat flow model to predict how my MBC WarmSlab heated by UFH + Willis heater would perform. What I wanted to do in this post is to provide a “6 years on” retrospective of how the house and slab have performed as built based on actual data that I’ve logged during this period, and to provide some general conclusions. In this, I assumed 15 mm UFH pipework, but we actually used 16mm PEX-Al-PEX pipework with an internal diameter of ~13mm. At a nominal flow rate of 1 m/s, say, my three pipe loops in parallel have an aggregate flow rate of 0.4l/s or 1.4 m³/hr. At this flow, a 3kW (2.88 kW measured) heater will raise this stream temperature by 1.7 °C. However, when I commissioned the system, I found setting the Gunfoss manifold pump at a high setting (roughly equivalent to this flow rate) gave a very noticeable circulation noise in the adjacent toilet, so I tried the pump on its lower settings and found that the flow was almost inaudible on lowest one with in to return delta at the manifold still only about 5°C, so I stayed with this. The actual as measured delta for two loops of 4.9°C and the third slightly shorter loop of 4.1°C (close enough not to bother balancing the flows out). This corresponds to an actual flow nearer to 0.4 m/s or 0.56 m³/hr by volume. When scaled to adjust for this lower flow rate, the actual measured temperature profiles are pretty close to those modelled. I measured the actual Willis heater’s heat input as 2.88kW. In analysing the actual slab heating rates, I found that this raises the overall slab temperature by some 0.45 °C / hour after the initial start up. Plugging typical specific heat and density figures for the concrete, this is empirically equivalent to heating 25 tonne of concrete (Cmass = Ewillis/ΔT/SIconcrete = 2.88*3600/0.45/0.9 kg), or 10.6 m³ concrete by volume (23000/2400 m³). In the case where the Willis provides heating for the full 7 hour off-peak window (just over 20 kWh), at the end of this heating period the flow input to the slab is +9 °C above the initial slab temperature and the flow return is +4.4 °C. The temperature of the concrete immediately in contact with the pipe will follow this same gradient, with this temperature excess decaying radially away from the pipe centres. By the end of this heating window at the slab surface, there is barely a noticeable difference in the measured temperature of the floor above the out and return UFH pipe runs (perhaps 1°C). These temperatures and gradients are also comfortably within the reinforced concrete’s design parameters. As soon as the Willis is turned off, the internal temperature gradients start to flatten and any unevenness redistributed across the slab; the rebar reinforcing has a thermal conductivity 60 × that of concrete and this accelerates this, so that within an hour or so of the heating turning off, the overall slab is left about 3.1 °C warmer than at the heating start time (actually about 10% less than this, as the slab has already started to dump heat into airspace). In my original modelling topic, I mentioned that my passive slab has ~73m² of concrete 0.1m thick (~ 17½ tonne of concrete with another ~10 tonne of perimeter beams, cross bracing and steel rebar, with the UFH runs laid in 3 × ~100m long standard “doubled back” spirals (common to most UFH designs) on ~150mm centres and roughly 50 mm below the slab surface. (Actually only 75% of the slab is covered by the UFH runs, because of the need to avoid proximity to ring beams, partition walls, areas under fitted cupboard areas, etc..) Nonetheless, this empirical 25 tonne figure is still consistent with the total volumetric 27½ total estimate if we assume that the rebar is effective at spreading heat through the wider slab over this multiple hour timescale. In conclusion, based on this modelling and observation: First recall our context: our house is near passive in class with a lot of internal specific heat capacity. We only need about 1kW overall heater input in the coldest winter months to maintain overall heat balance, e.g. either by a resistive heater such as a Willis or an ASHP. IMO, there are two extreme approaches to house heating: (i) “agile” tracking of occupancy patterns so the living spaces are only heated when and where occupied; (ii) a 24×7 constant comfortable temperature everywhere within the living space. Our warm slab design is very much optimised for this second case, and our slab supplier did a good job in designing an UFH layout to match the slab characteristics to this The slab is covered in “doubled back” spirals with each loop using up a full 100m roll spaced on roughly 150 - 200 centres (and avoiding partition walls and cupboarded areas) so that each heats roughly 15 - 20 m² slab. In our case three loops were enough, and there was no advantage in trying to squeeze in a fourth. Our 3 loops will happily take up 3 kW heat input. Circulation speeds between ⅓ - 1 m/s seem to work well, with the only real difference being the slower the flow speed, the higher the delta between in and return temperatures. The slab does just as its trade name suggests: it can be treated as a huge low temperature thermal store, but because of its extremely high thermal inertia, one that is not rapidly responsive to heat input. In our case, a heat input of 3 kW input will only raise the slab temperature by 1°C over a couple of hours, and radiating 1kW will drop the slab by only 1°C over roughly six hours. In a true passive class house, one key to heating economy is the high level of thermal insulation coupled with a substantial internal heat capacity. Trying to drive such a house in an agile manner is a fruitless exercise, so forget the traditional having room-specific thermostat control; forget having traditional time-of-day heat profiles. It is far easier to treat all ground-floor rooms as a single thermal zone to be kept at a roughly constant temperature. In my view, using a resistive heating approach (such as a Wills heater) as well as an ASHP can both work well. In this second case something like the 5kW Panasonic Aquarea ASHP would be a good fit as it uses a modulated inverter compressor so it can heat the slab directly without needing a buffer tank. The choice is a trade-off between running costs vs. installation costs. In our case, switching from a Willis to this type of ASHP would save me about £600 p.a, in electricity cost, so I would really need to do the install for a net £ 3-4K to make the investment case feasible. However I would like to defer this discussion to a separate thread because there are other issues that such an approach would need to address.

We pretty much need two threads here covering the use cases of: The likes of me, @MikeSharp01, etc. who have (near) passive-class houses with only limited heating requirements of say 20-40 kWh heat input / day during winter months. Here a 5-8 kW range ASHP would be more than adequate. Here a typical warm slab where the heating loops are embedded in a min 75mm concrete + other concrete ribbing and structural beams can easily soak up 5kW heat, say, at a ~10 °C delta between average slab and circulating water. Also remember we only need an average of 1-2 kW input over the day. In this specific usecase the buffer tank is functionally redundant, and really only required for insulation templates optimised for typical house installations. My RPi-based control system which computes daily heating requirements based on external weather forecast and actual average house temperature, and schedules heating blocks during the 24hr period to input this into the slab works well here. More legacy installations such as @oranjeboom's, which IIRC is a reasonably efficient extension on a more traditional house. His heating calcs in this case are even more complicated by the (lack of) EWI and there are all sorts of wrinkles here that need addressing. I suggest that we keep this topic to orangeboom's issues and discuss these warmslab / passive templates on a separate thread.

We are in a similar position, in that I am now probably spending about £700-£800 p.a. excess by using the Willis heater at a CoP of 1 rather than an ASHP which should give a CoP of ~4 at 30 °C. In our case we need about ~30 kWh heating during winter months and I can spread this over the day so I could probably get away with a 5 or 6 kW heat output unit, though these are quite difficult to source. We also pre-laid our in/out heating pipe to the pad where we would place our ASHP. Like you, I see no point in having a water buffer tank as I don't have the groundfloor space to house it, and we already have a 70 tonne buffer warm slab. I would rather directly circulate through the slab or poss via a PHE. I would also prefer to directly drive the ASHP with my own on demand rather than have my control system fight some fancy predictive ASHP CS that is optimised for a conventional house. You need to be aware of planning issues here as you only get a planning consent waiver if the system is installed by an MSCE registered installer who would probably be unwilling to install a config that you want. Lots of complexities and gotchas here. And picking up @joth's point 👍. In my case I would use my existing calibrated slab model the measured out to the slab vs return flow temps to calculate the actual heat input from the ASHP and do a decent block during E7 overnight plus a couple of extra say 2hr heating chunks during the day (if needed) at a ~30°C output set point. It doesn't really matter if I am ±20% on any day-by-day basis as this only causes maybe an extra ¼°C or so ripple on the overall house temperature. My job over winter is to research all of this and make a call on the way I am going here.

Do the cut and fill calcs. If you are digging out 10s of m³ of sub soil then it has to go somewhere. You need to calculate the final levels to make sure the profiles make sense. Also remember that you want to keep topsoil on top In your garden areas, so you might need to strip off and heap topsoil before spreading the subsoil. If you have a large plot and existing gradients then you might be able to lose the excess on site by terracing. But also remembered that your site might not be able to carry the excess. Check your planning submission site levels, street scenes etc. You might need to run the gauntlet of PP changes / risking running foul of P Enforcement, if they decide you are raising levels unacceptably. It might just be cheaper in the end to pay for off site removal. We didn't have a basement, but had to drop a large part of our site by about 0.6m to achieve roof lines, etc. That was about 20 × large truck loads. Luckily a farmer in our village was doing culvert backfill and took it all, so a 10min round trip and no dumping costs.

We have an MBC twinwall with 300mm blown cellulosic filler between panelvent on outside and coated OSB3 racking on inside, with battened out service cavity inside that. We use 2 × 110 foulwater piping for through-slab main ducts, but we added then added our other penetration ducts after the racking out was done, and most after filler was blown. We use a standard process which my wife and I did ourselves (not one to delegate): We decided on the placement and o.d. of each duct depending on the requirement e.g. external lights, satellite cable, ... these varied from 20-40mm. I then used a 60mm × 15mm masonry bit to drill a pilot hole in-to-out and then used the appropriate hole cutter inside and out to right-size the opening by pulling the masonry bit back to on the opposite side to give clearance for the cutter but other than that, returned the bit as a through guice to avoid losing the hole. I then cut a piece of the correct o.d. abs pipe to about 100mm longer than the hole, and notched on end with a multi-tool to form a simple cutter. This pipe could then be slid over the bit, then hand twisted / pushed to core the hole through the insulation using the 60mm bit as a centre guide. Once through, each pipe was taped to the panelling and siliconed to seal, then multitooled to leave a ~10mm flange. Once the cable / service was in place, the pipe void was foamed and siliconed to make air and moisture tight. The whole process once practiced took about 30 mins per service opening.