Page 1 of 1

very multi-zone setup

PostPosted: Mon Dec 19, 2016 11:53 am
by antst
I am "modernising" heating in my house.
And, practically, I put on every heater controllable valve (MAX!) and in some rooms additional MAX! thermostats.

I've read through forum and I know why it is not recommended stand-alone OTGW operation.
But I am in doubts how to arrange multi-zone then. In this case, I am talking about something like 9 zones.

I have OT thermostat in living room (4 heaters, controllable valves to be installed). And very often I need to heat somewhere else (like babies rooms at night) and wasting energy on heating of a lot of other areas seems to be unreasonable. Or when I work at night, I need to heat my study, but not the rest. Or I want to preheat older daughter bathroom at 6:55, so when she goes there at 7:00, it is nice and cozy, but I don't need to heat the rest of the house yet (aside of the kitchen).
And there are more complicated scenarios involving all kinds of sensors, which goes beyond schedule on thermostat.

So, I guess I will need to override control setpoint one way or another, once I have open valves outside living room (which are controlled by changing setpoint on them or associated thermostats), even if living room does not require more heating.

But then next question which comes is control algorithm. Is there anything published on those? I would prefer to not spend another year trying to come up with my own reasonable algorithm which is comfortable and economic.

Re: very multi-zone setup

PostPosted: Tue Dec 20, 2016 7:56 pm
by mike7
I didn't find such algorithm. I'm using similar setup in my country cottage, my algorithm is simple and not economic but is suitable for my needs.
First - you can't control one zone with both systems OT thermostat and MAX!. I have OT thermostat installed in the "coldest" room in which MAX! valves are opened all time, so all others zones controlled by MAX! system. If I don't need heating in the "coldest" room but others I switch control to the MAX! and control OT setpoint based on empirical algorithm based on outside temperature, difference between target and current room temperature and valve opening level. You could simply add "boost" factor for example...

To monitor MAX! system I'm using arduino with RF-22 based on thus I have real-time state of the MAX! valves and can use MAX! software or control the Cube.

OT and MAX! part of the system are integrated with Node-RED on Raspberry-pi.
If you need any details I'll be happy to share

Re: very multi-zone setup

PostPosted: Tue Dec 20, 2016 9:42 pm
by antst
Actually, I am going to use both MAX! and OT thermostat in living room, but!
I am going to feed to valves temperature and room setpoint from OT thermostat (the same way as they would get it from MAX! wall thermostat). There is no problem with this.

In my case, I am going to get rid of MAX! Cube altogether.

RPi is a "brain" of everything. for communication with MAX! devices - nanoCUL. For communication with OTGW - I added ESP8266 to OTGW and do it via WIFi.
On software side I am using at the moment FHEM (OTGW via OTM/MQTT, with few changes into OTM code to subscribe to more topics).

It is all doable. One way or another. But my biggest concern is algorithm. I will try to reverse engineer what Honeywell is using, but maybe there are better ones.

Re: very multi-zone setup

PostPosted: Tue Dec 20, 2016 11:02 pm
by Hrvoje123

We are start up and working on that kind of algorithm but currently did not do any work on Opentherm. However, your biggest problem will be to have all needed information on one place where you will be able to decide if you need heating for any of zones and if yes you need to trigger boiler (if at least one zone needs heating). Algorithm for OT should be independent of zones, you could be using outside temperature and/or return temperature of water and based on that increase/decrease heating demand from boiler. Regards, Hrvoje

Re: very multi-zone setup

PostPosted: Wed Dec 28, 2016 11:09 am
by antst
To have everything in one place isn't a big deal. I am leaning toward writing separate daemon which receives all information via MQTT and does all the calculations.

In this case, for every zone I have
1) current temperature
2) setpoint
3) valves position

plus I have outside temperature and return water temperature.
This must be more than enough. It can (must!) also be self-learning, to anticipate heat loss depending on the situation.
Ideally, one can also take an average change of those over some previous interval, like 10 min or so, to make corrections depending on gradients.

In theory it is all doable, and not that far from my area of expertise, the only problem is a time :(

Re: very multi-zone setup

PostPosted: Fri Oct 13, 2017 11:48 am
by antst
If somebody has interest, I finally found some time and made setup for multizone control.

I have number of zones, where primary data (zone setpoint and current zone temperature) is provided by MAX! wall thermostats. And now my code, according to that data and taking into account outside temperature, calculates CS for OTGW. Control set point calculation is based on heating curve from Honeywell thermostats (a bit of reverse engineering involved), although I added few additional parameters to the heating curve (as I found that basic Honewell control was not ideal for me even for single-zone setup) + I also have additional parameters per zone (simple reason: every zone might have different heat loss capability).

All in all, now all my thermostats provide me with data by MQTT and my little code calculates control setpoint for OTGW. And it all works like a charm.

Next step is to integrate it into ESP8266 together with transparent bridge. So data will go directly to OTGW bridge bypassing central controller, reducing number of points of failure.

Re: very multi-zone setup

PostPosted: Fri Oct 13, 2017 11:57 am
by antst
This implementation is still rudimentary from my point of view, as I want to extend it with "heating response" calculations (which will be indirect measure of room volume and heat loss capability) and "granted heat-up time" (which means that is zone setpoint is increased, I want zone to be heated up to the point in X minutes on average), but this comes later, once I have a bit more time.