Leaderboard

We moved into our new build mid-December 2017 in time to host an extended family Christmas. We are now over 4 years into living in our new home. We have lots of accumulated experience and made a few small tweaks. However, we are delighted about how the house has turned out, and we love living here. There were no material cock-ups, or regrets on design decisions, so we have probably fared a lot better than most new purchasers or self-builders. Maybe a general experiences post should be on the to do list, but what I want to focus on here, and a couple of follow-ups, is a general topic that others on the forum have asked about over the years: that is how our central heating system works in practice, and how I control it. The system as currently implemented is still largely the same as when I first commissioned it, that is a now 5 year-old RPi-based custom control system directly controlling the CH and DHW subsystems. This is a pretty minimal headless system running Node-RED, MySQL and MQTT client for control. The three material changes that I've made since moving in are: I have followed my son and son-in-law in using Home Assistant (HA) for general Home Automation. My server (an RPi4 in an Argon One case) uses an attached Zigbee gateway, and I have a lot of Zigbee devices around the house: switches, relays, light sensors, etc. and I do the typical home automation stuff with these. There are loads of YouTube videos and web articles covering how to implement HA, so please refer to these if you want to learn more. My HA installation includes an MQTT service for use as a connection hub for these IoT devices. I also have another RPi4 acting as an Internet-connected portal / Wireguard gateway/ file-server for caching video snippets from my PoE security cameras. Note that none of my IoT devices directly access the internet, and the only in-bound access into my LAN is via Wireguard tunnelled VPN, and my HTTPS-only blog. All other ports are blocked at the router. Before moving in, we assumed a target internal temperature of 20°C. In practice, we have found this too cold for our (fairly inactive OAP) preference and so we have settled on a minimum control threshold of 22.3°C. As you will see below, because we largely heat during the E7 off-peak window the actual room temperatures have a ~1°C cycle over the day, so the average temperature is about 22.8°C. This hike of 2.8°C increases the number of net heating days since my design heating calcs and the increased delta against external temperatures in turn increases our forecast heating requirement by roughly 18% over our initial 2017 heating estimate. Because our UFH is only in the ground-floor slab, we found that our upper floors were typically 1-2°C cooler than the ground floor in the winter months. We also need more than the 7 off-peak hours of heating in the coldest months, so I have added an electric oil-filled radiator on our 1st-floor landing; HA controls this through a Zigbee smart plug that also reports back on actual energy drawn during the on-time. HA uses MQTT to pass the actual daily energy draw back to the CH control system. This radiator provides enough upper-floor top-up heat, and does so using cheap rate electricity. Note that all servers are directly connected to my Ethernet switch, and the CH/DHW system has all of its critical sensors and output controls directly attached. It can continue to control the CH and DHW subsystems even if the HA system or Internet is offline. There is also no direct user interface to the system, with all logging data is exported to MQTT, and key CH/CHW set-points and configuration are imported likewise. This integration with MQTT, enables user interfacing to be done through the HA Lovelace interface. If there is sufficient interest I can do follow-up posts on some more of the "Boffins Corner" type details on these implementations, or if this turns out to be more of a discussion then it might be better to move this stuff to its own BC topic. However, for the rest of this post I want to focus on the algorithmic and control aspects of the heating system. In terms of inputs and outputs to the control system, these are: There are ~20 DS18B20 1-Wire attached digital thermometers used to instrument pretty much all aspects of the CH / DHW systems. Few are actively used in the control algorithms but were rather added for initial commission, design verification and health checking. Some are also used to monitor and to trip alarms; for example, there is a temperature sensor on the out and return feed for each UFH pipe loop. These were used to do the initial zone balancing. However, the average of the return feeds is used as a good estimate of the aggregate slab temperature. One of the temperature sensors is also embedded in the central hall stud wall to act as a measure of average internal house temperature. There are two flow sensors on the cold feed to my 2 SunAmp DHW storage units to monitor DHW use and to help automate during-day DHW boost. There are 4 240V/20A SSRs used to switch the power to my (2-off) SunAmps, my (1-off) Willis heater, and my (1-off) circulation pump. These and the rest of my 240V household system were wired up and Part P certified by my electrician. These SSRs are switched by a 5V 50mA digital input, and so can be driven from an RPi or similar. (I used a I²C attached MCP23008A multi-port driver to do this, as this can drive 5V 50mA digital inputs, but its input I²C side is compatible with RPi GPIO specs.) There are many ways to "skin this cat", but whichever you choose for your control implementation your system will need to control some 240V/12A devices and take some input temperature sensors. My preference was to directly attach all such critical sensors and outputs. My heating algorithm calculates a daily heating budget in kWh (each midnight) as a simple linear function of the delta between average local forecast temperature for the next 24 hrs and the average hall temperature for the previous 24 hrs. This budget is then adjusted by the following to give an overall daily target which is converted in minutes of Willis on time. heat input from the heater mentioned above. a simple linear function of the delta average hall temperature and the target set-point (currently 22.3°C). This is a feedback term to compensate for systematic over or under heating. I initially calculated the 4 coefficients of the two functions using my design heating calcs and an estimate of the thermal capacity of the interior house fabric within the warm space. After collecting the first year's actual day, I then did a regression fit based on logged actual data to replace the design estimates by empirical values. This was about a 10% adjustment, but to be quite honest the initial values gave quite stable control because of the feedback compensation. The control system runs in one of three modes: No heating is required. Up to 420 mins of heating is required. The start time is set so that heating ends at 7 AM, and the slab is continuously heated during this window. More than 420 mins of heating is required. 420 mins of heating is carried out in the off-peak window. On each hour from 8 AM to 10 PM, if the hall temperature is below the set-point (22.3°C), then an N-minute heating boost is applied, where N is calculated by dividing the surplus heating into the 1-hour heating slots remaining. Here are two history outputs from HA showing some of the logged results. The LH graph is the slab temperature over the last 7 days. The general saw-tooth is identical from my 3-D heat flow modelling discussed in my earlier topic, Modelling the "Chunk" Heating of a Passive Slab. The 7 hr off-peak heating raises overall slab temperature by ~4-5 °C; well within UFH design tolerances, and no need for any HW buffer tank: the slab is the buffer. The RH graph is the hall temperature. Note the days where on-hour boosts were needed. (Also note that the CH system only updates the MQTT temperature data half-hourly, hence the stepped curves.) So the approach is fairly simple, and the system works robustly. ? And here is a screenshot of my HA summary interface, which gives Jan the ability to control everything she needs from her mobile phone or tablet.