Multi zone heating

I’m looking at rigging my 16 zone underfloor heating to OpenHab. This will be my first venture into OH and Smart controls beyond a few ESP8266 devices connected to my Alexa.

I already have 10 thermostats scattered around the house. I intend replacing those with a custom device. Removing the existing thermostat and using the 2 core wire that is in the walls I intend to provide 12v AC over those wires to a device measuring occupancy, temperature and humidity, setpoint ( knob as it does away with the need for a display ) and heat demand button. Sensor readings will be passed back to a central hub using a DigiMesh network running on XBEE S2C’s. This sorts out several things in my book … power at the sensor point and RF paths back to the central controller.

The heating can be controlled from the distribution manifolds via the zone actuators. I’ll be building a multizone controller with an output for each zone actuator, one for the boiler pump, one for the recirc pump and a potential free contact for the boiler heat demand. An on board arm processor will allow me to set this up and run it as a standalone unit should the network fail. The arm will run heat demand and set-point control for each zone. I’ll have USB serial IO in to it as well as being able to communicate over the mesh through an access point.

What’s important is the ability to cluster zones together with some sort of hierarchical control system, house occupied, heat on, guest bedrooms occupied etc, timer controlled, occupancy controlled and outside climate compensated.

Can anyone see any problems with my room ‘stat sensor’ approach?

Does anyone know of a pre-existing ‘smart’ multizone controller that achieves the above?

and if not …

is anyone else interested in a zone controller and room sensors ( making 5 or 10 is as much work as 1 or to 2! )

1 Like

This sounds similar to what I would like to do - there will be multiple people in the house with very different schedules, and each having their own “zones” which they will need individual control over.

I was thinking of using ESP8266 devices (either custom-built, or the Sonoff as they’re mains powered) to control a valve for each radiator/room (I likely won’t have a central manifold), and then a separate ESP8266 with an OLED, rotary encoder, DHT22, PIR etc which can be mounted elsewhere in the room to provide input and feedback.

I don’t have much more useful input now, but I’m certainly going to be following this closely!

I should really do a write-up of my project for the community, as more and more people seem to be doing more or less what I did. It’ll be ready anytime soon ! I promise…

I choose to not have physical control. For a floor heating, the thermal inertia is such that what you really need is a good scheduler. Having a “heat now” button for each zone won’t do any good if you have to wait for 1h for the room to actually start heating and 2-3h for it to gain 1°C. :wink:

Same goes for presence detection; unless it is smartphone-based (so you know when someone is “home” and can heat their bedroom as soon as they get home, not when they go to sleep.)

You seem to be used to completely different hardware/software than I am… So I can’t really help you there. (Is it really using 12V AC ? Never saw that before.)

When (if?) I do a write-up of my project, I’ll try to remember to link it here.

[Edit : Here it is !]

12v ac - lower voltage drops at the remote point and having a voltage rectifier at the endpoint means the end user can’t wire it the wrong way round … it’s simpler

Heat now button … may not be immediate with UFH but it could be used to extend the heating cycle on a zone … or for anything else in that zone such as a light switch, no point in wasting the connectivity.

Occupancy, similarly may not be immediately useful for UFH but it does give access to occupancy so could be used for alarms or other functions.

With a bit of intelligence one can interpret occupancy against the heating set on the central system and tell the administrator that a schedule may be too long, too short, on on wrong days etc.

I’m fascinated by this, as I’m installing 4 or 5 zones of underfloor heating in our new build. There are SO many permutations of configurations that you could do, and I’ve given it a lot of thought so far and almost arrived at a final plan.

My thought process started off wanting to replicate the functionality of a traditional heating controller, then when you realise the point of a well-designed UFH system which is properly balanced, that goes right out the window.

I am proposing a two strand approach:

  1. Setup / balancing. Traditionally, you’d see balancing as a one-off - part of commissioning the UFH. Different zones heat up at different rates, and also in some spaces you need a higher temperature to offset more drafts, etc. However, to add to this complexity, the calibration needs to change throughout the year, because in cold weather the colder rooms take relatively longer to heat up than the warmer rooms, than they do in warm weather.

    So, strand 1 = use automation for continual monitoring, calibration, and learning about the heat profiles of the zones within building.

  2. Day-to-day control. Surely a well-designed heating system never needs adjustment? This is my theory - the problem with Nest and modern IoT heating controllers is that they are based on an old-fashioned principle, which is that you need to make the house extra warm when it’s cold outside. Surely a modern heating system provides consistent, comfortable temperature at all times.

    First part of day-to-day use is reducing energy. So, working out the optimum time to stop and start heating throughout the day, e.g. with UFH, lower the temp by a few degrees at 8pm, then raise it at 4am ready for 8am wake-up. Or possibly it’s more efficient to maintain the temperature constantly throughout the night - depends on the outside weather and the building etc.

    Second part of day-to-day is making sure it’s warm enough at the right times. This means either having a “boost” / “extend” button, OR having “profiles” (like “eco” mode, “comfort” mode, etc…) Also this can involve presence sensing (although with UFH with longer heating periods, perhaps this is a manually set item like “I’m away for the whole weekend”). Finally, this could even involve basic time scheduling, although that seems very old-fashioned now, because we are more interested in the system being intelligent in some way.

Sorry for the lack of detail - I’m pre-planning at the moment. I’ve spoken with another openHAB user about this, and they have a good way of doing it using “profiles” like eco, comfort, etc., and using feedback from sensors to simply turn on and off manifold flows accordingly.

Anyway, this can be extremely complicated when you start to factor-in pre-heating zones at different rates, adjusting for warmth perception, and balancing zones so the whole building feels a natural temperature. So my suggestion (mainly to myself!) is to start thinking that you want to use automation to simply maintain comfortable temperature at all times. Then, after this is achieved, bring in additional intelligence where needed.

Like your thinking hazymat. I was considering adding manifold input temperature and zone outflow temperatures to look at zone balancing but not sure if that’s the way to go. Certainly monitoring the temperature feedback loop is a good plan. The only zone actuators I have been able to find are all ‘on/off’ types with about a 3 minute response time. Thought a proportional valve would work better to be able to self balance but haven’t found any … yet. Could rig a servo drive but that is getting complicated.

( found a proportional valve but at £50 a unit … ouch )

Nice idea about the 12V AC and rectifier. I’ll keep it in mind ! :slight_smile:
For the heat now button, so long as you (and other users) know how it will work, it will be fine.

@hazymat, I think you are overthinking it (the first point). Just have your installer calibrate it how he normally does it, so that you have a sane baseline. Then, have one PID-controller for each zone, which will give you at all time a percentage value ; feed that to your valves and it’ll be fine. That of course requires proportional valves…
Heck even a simple on/off works fine here at home (I’d really like to have a PID though.)

Basically, hide all the complexity behind these 3 P, I and D numbers.

From my usage, I’ve found that the only day-to-day controls we need are presence switches (they are manual for now) that change the schedule. We basically never change a setpoint. But we have tweaked the schedule a lot.

Since I had some free time this evening, I wrote a text about my system !

Further to my comment about proportional valves … I found this on another forum

Blockquote Both thermal actuators and motorised valves are embarassingly inefficient (4-5W consumption per valve all the time they are on). … If you have 7 zones on for say 3hrs/day on average in the heating season that’s 19kWh/yr just to run your valves.

With the 1w valves that I have, 5 months or so of heating 5 hours a day, say 8 zones it’s only 6 kw/hr per year to run the valves which at my current price is less than a pound. Certainly doesn’t make £50 valves a value proposition over £16 ones especially if I get a pseudo P(wm)ID loop running.

Hi…how much would running an efficient rad on a schedule save compared to running the same rad on a regular TRV? Plus the system will have to work harder if rads are left cold most of the day.
I’ve not done any research and there may well be real world stats that show there are savings to be made within a reasonable time frame, but I’m a little sceptical. Particuarly as there is always better technology just around the corner.

pcb assembly