Planning my heating system control for Home... Opinions wellcome

I have already comented about it here.
But now I have a more clear idea of what I want and possible solutions.
I would try to explain what is my goal and how I am trying to solve it.
Opinions are greatly wellcome, at a logical/functional level and at hardware solution too.

First the needs:

My home has a central heating system, with a relay at the entry that activates or deactivate the valve that controls the heating of the whole home. It can just be opened or close, no more control about it.

The central heating valve has a measurement of diferential temperature and flow, so they calculate heat consumption and bill you acordingly.

Now it has a manual thermostat to select the temperature at which it opens or closes. It is all in the living room (I know, very bad design, but cheap and that is why the constructor used it).

Main rooms in the home have radiators with a mechanic thermostatic valve. You can select aproximately at what temperature it has to open or close. Other radiators (at hall, toilets…) do not have a thermostatic valve. I maintain the valve semi closed in them.

Radiators are mounted in paralell: you can close one of them and the others remain operational (at least radiators in main rooms, I am not sure about the others).

Some of the rooms (living room, kitchen and main bedroom) are in the front of the home, oriented to south, where temperature is higher.
The other rooms are at the back, oriented to north where the temperature may be much lower (I think there may be 5 ºC differences).

The problem:

As it is now, if you adjust the the set temperature at the living room to a reasonable temperature, like 21 or 22 ºC, it closes heating too early and back rooms stay quite cold.
If you adjust a higher temperature, even trying to adjust radiator thermostatic valve to lower temperatures, it consumes a lot and you fell hot at front rooms, while back rooms are not so well heated.

I have tried a thermostat with two sensing devices, one for the front and one for the back, you can program it and it keeps main valve open as long as one of the zone remains bellow set point.

It works better, but programming it is cumbersome, and it tends too keep front side too warm, and it is difficult to adjust back zone to keep it warm.
Using it and letting it programmed, produces too much consumption.

Kids now have grown up, and have their own time tables, so one may need to keep the room at confort temperature while the other room is empty all the morning and it should be kept at night temperature.

So I am planning to provide a better solution with a more intelligent system and easier to program or adjust, using openHAB to have easy access to a control interface, and electronic valves to control the radiators and be able to see if they are heating or closed, and set temperature setpoint independently.

The goals:

So the goals for the heating solution would be:

  1. Be able to see and control all the system from a central UI graphical interface.

  2. Be able to measure and control temperatures in front and back zones of home.

  3. Be able to disarm all the system from one point, putting it in winter mode or summer mode when leaving home for several days (or when the central heating is itself disarmed).

  4. Be able to set different temperature set point (or even programs) for each room radiator.

  5. Sometimes user in a room would like to change the temperature from comfort to eco or to other temperature for a time (until next program change) and should be able to do it easily from the radiator, with no need of phone or PC.

  6. The thermostat should have an easy to use interface to arm or disarm the system or to stablish temp setpoints for rooms.

  7. Even having the ability tooperate and see everything from a central UI interface (this is openHAB role) the system should be as independent as possible of it. radiators and its controller should keep working and following the program even when the openHAB controller is down (for this, the messages should be processed at the central thermostat level too, and radiators controllers should respond to arm/disarm system messages on their own).

Of course I want it to be:

  • Low cost. Not paying 200€ for each electronic valve.
  • Not tied to a cloud or hardware solution vendor.
  • Keep all private and do not publish anything to internet.
  • Not dependent on internet services or even on internet working at all.

This is the list of whishes, my letter to Santa Claus/three Kings.

My hardware solution proposal:

After stuying and looking for alternatives and seeing prices, I have opted for this solution (which I need to implement yet, as I have only made some test and proof of concepts):

  • Eqiva EQ3 smart TRV for the electronic valves, based on bluetooth BLE. They provide a phone apps that you can use for changing almost everything, besides their own buttons and hardware interface. It can be used as a last resort for changing options not accesible with bluetooth (some functions are not implemented in the current drivers of opensource software, I don’t know if they are accessible or not through BLE). Yo can set confort/eco temperature, change the temperature (at the radiator ausing a knob and using bluetooth) and stablish a program (you can do it only using the app or the radiator hardware). I know they are not the more robust or best solution, zigbee would be better, but they are quite cheap and provide enough functionality. Zigbee is more complex and more expensive.
    My main concern with this valves is that you cannot change the program from bluetooth (a TASMOTA driver limitation, probably)
  • Radiator controllers/gateways. As the radiators are bluetooth, to access them via IP network you need a gateway near them (with zigbee it would be the same). I will put one in the back zone to cover all rooms. I have tried TASMOTA on an ESP32 and it works, it can propagate messages from serveral bluetooth radiators nearby, to the IP network. You can use it as a Zigbee node too, so it should be possible to use zigbee valves instead with a similar solution. I will integrate a BME280 to measures temperature and humidity (preassure too, fro the same price) and publish it to the IP net.
  • Thermostat controller. At the living room, I will put another TASMOTA/ESP32 with a relay in order to control central heating an disarm heating when not needed in any room. It will do the function of radiator controller too, for the radiators in the front part, and integreate another temperature sensor. The same but with the added functionality of controlling the heating valve.
    It will be usefull to add buttons or a touch screen to radiator controllers and thermostat controller in order to have easy access to main functions with no need of phone or PC.
  • MQTT broker based in mosquito to coordinate all MQTT messages (I think MQTT would be much better solution than HTTP or similar point to point system). I have it install in my central openWRT router, as any way all the home network depends on the router: if the router fails, all devices will be isolated and moving the broker to other point won’t provide a more robust system.
  • OpenHAB a user UI from where you can see everything and control it. I have made some tests and I can access the EQ3 valve status and control them. I have still some things to solve, but nothing that seems imposible, just a matter of learning. For now I have it in a docker install in my NAS. May be in the future I should move it to a small independent device similar to a RPi in order to keep it more accesible (with a touch screen) and robust (NAS is a bit clogged and sometimes it hangs).

Logical/functional operation

Once decided the hardware and phisical layer, I have to decide how all the system should work.

This is the idea that I have of how it should work. For now I don’t know how to do all of this tasks (automating some control tasks in TASMOTA controllers) so may be I would have to put it in openHAB using rules, but let us see how it should work.

  • The thermostatic valve can be operated locally, change the setpoint, change the program to run in automatic mode, or change from confort (high temp) to eco (low temp) mode until the next program time stop, or put in manual mode or disabled them in winter mode (valve closed) or summer mode (valve opened completly to consume the less in summer when the heating is completly off).
    These valves publish they state through BLE in a message that contains much of the info, but not all.
    They don’t have temperature sensors, so they don’t pusblish the temperature in the radiator, only the current setpoint temperature. They don’t publish if the are in eco or comfort mode (you can derive it from the setpoint temperature) and the mode (auto or manual) and the valve position (0 to 100%). You cannot change the program or get the program they are following (probably a limitation of TASMOTA driver, and due to TASMOTA not being paired with the valve and only using bluetooth beacons).
    You cannot control the valve position directly (and probably you shouldn’t, let me assume the internal algorithm makes a good job at trying to keep the setpoint temperature).

  • Radiator controllers: they are mainly a gateway between the BLE and IP networks, they will receive state messages from the assigned BLE valves and pusblish the state though MQTT topics. They expose MQTT topics in order to be able to control some aspects of the valve remotly, and direct that commands to the valve.
    Through them you can:
    ** change the mode of operation (auto to follow the internal program or manual to keep a stablished temperature).
    ** stablish the setpoint temperature (until next program change in auto mode).
    ** change the comfor/eco temperatures.
    ** disable the valve working, putting it to OFF (fully closed in winter mode) or ON (fully opened in summer mode).
    ** You cannot operate the valve directly (only closed or completly opened) or change to comfort or eco mode (may be a TASMOTA bug, the documentation says you can, but the valve returns invalid command). You cannot change the program.
    One task the controller should be able to do by its own is deactivate the valves when the system is disarmed. It should be suscribed to the disarms MQTT message and when received, it should put all the assigned valves to mode manual and then send an valve off or on command (depending if disarm is in winter or summer mode). The integrated controller in the thermostat would do the same thing.
    Radiator controllers integrate sensor and just pusblish temperature, humidity and presure values through MQTT topics.

  • Thermostat. It would have some additional task.
    ** open or close the relay that controls the central heating exposing a MQTT command to do that (and ideally having a buttom or interface to do that).
    ** Publish the state of the relay heating delay (and changes)
    ** Have a button or interface element for arm/disarm (winter or summer) the whole system. They will send a global MQTT command that would be follower for all the controllers.
    ** listen for changes in the state of the radiators valve, and if all valves are closed, open the relay to disable central heating.

  • OpenHAB station. Its mission would be merely to display and collect info from the system. And to provide interface elements to command the system remotly. Ideally no control tasks should be performed by openHAB. So the system should be as independent as possible and reliable (if it is correctly programmed, of course).

Design in resilience.
i.e. don’t design a megasystem, design a simplistic self contained system that the fancy stuff can add value to.
e.g. a self contained thermostat can run a minimal system by wire.
You’d choose one that allows (but does not require) remote access via wireless or whatever.
Now you can introduce the mega-wotsit “as well as” that takes account of other temp sensors or window openings etc. and adjusts the basic 'stat for the desired results.

I’ll second @rossko57’s suggestion. A home automation system is going to be more reliable and fail gracefully when some of the smarts are pushed out to the edges. OH will primarily be coordinating between devices and setting desired states (e.g. I want the room to be 68 °F) rather than implementing all the low level stuff.

So to start focus on making this whole system operable in a self contained manner. It needs to, at a minimum, keep the rooms at the desired temps even when everything else is offline. You don’t want it to get stuck ON or OFF just because the network is down while you are not home.

As you build the self contained system consider what information it needs to expose and how to control it. It might be as simple as the thermometer readings and being able to set the target temps. Or you can make it more complex with sleep modes and boost modes and stuff like that. It’s up to you, just be sure to design it in a way that should OH or Mosquitto or even the IP network goes offline the heating system will still operate in a reasonable fail safe mode (e.g. maybe it won’t switch between sleep and occupied mode while everything is offline but it won’t over or under heat the rooms either, maintaining the most recent temp setpoints).

MQTT is a good choice for the interface between the heating system and OH. One thing to be careful of with MQTT though is avoiding infinite loops. You will probably need to do that by having two topics for each control. One to publish the current state and another for something external (e.g. openHAB) to publish a command to change the current state (e.g. set a new setpoint).

Everything up to this point is completely independent of OH (unless you choose to implement the heating system as a separate stand alone OH instance and don’t plan on integrating other home automation stuff, see HestiaPi for an example central HVAC thermosat built using openHAB).

Once you have the interface straightened out the OH side will be relatively easy I think. You’ll need to create the Things to connect to the MQTT topics. Link Items to the Channels of those Things. The Item will represent the current state and provide the ability to control the devices through commands. Once you have the Items you can see if you need to customize or build a UI Widget to allow control. There are a number of heating control widgets on the Marketplace that can be used as examples. Finally (or at the same time you are working on the UI) you’ll need to code the rules that implement the automation that openHAB will provide.

I can’t offer much in terms of specific hardware and the like. A lot of OH users will recommend running it on a separate device for reliability and ease in recovering from failures. Once you do have the hardware we can offer lots of specific help getting it integrated with OH where needed.

1 Like

Well that is my idea: to let the thermostat and radiator controllers operate in their own, and to keep it as simple as possible (to begin with).

But I could not think of a more simple system that the explained one in order to be able to have independent heating in each room.

The thermostat device running tasmota would be wired to the relay that opens or closes the whole heating system. It is in an accesible wall in the living room, so it will be easy to directly interact with it (that would need some button and/or a touch screen a screen to display basic info would be great too).

Instead of centralizing all the control in the openHAB node (which runs in a NAS with many other things and it is not as reliable) the controllers should just send messages and respond apropiatly to messages in the net.

For example: if somebody disarms the heating system in the thermostat, it just opens the relay contact and sends a mqtt topic advertising it. The radiator controllers (one of them running in the same ESP32 in the thermostat but operaing as if were an independent controller) should listen (be suscribed to ) the message and put the radiators that it has assigned to mode manual and close the valves.

That could be done in openHAB, but I think it would be less reliable. OpenHab just would listen the disarm meassage and update the interface. And it can have a disarm button too to be able to disarm it from the interface, that just have to send the MQTT command to the thermostat, which would do the same as it were disarmed locally.

The only problem is that right now I don’t know how to do that control in the TASMOTA side (probably with berry language or more simply with rules). I have tested with openHAB rules, and know how to do that in openHAB (more or less). May be I have to keep it in openHAB for start and improve later for a more independent and reliable system.

Having a sensor temperature in each room would be probably better, but I think the temperarure in each zone would be about the same and don’t want to have too many gadgets to operate and maintain.
If needed I allways could them later and the system design would be about the same, just with more gadgets.

If the whole network goes down (no wifi connection) you won’t be able to disarm the whole system from the thermostat. But you can disarm the thermostat (no more heating) and then close all radiators by hand (they can be operated locally) or even from the controllers if I add a button there to do that.

Each contoller would control its zone, so even if the IP network is down it will keep working the radiators with the previous programmed mode.
Indeed the program ir in the radiator valves and they operate independently. You allwayc can set the temperature or change mode or even close them in them.

The only problem is that you cannot program the radiators remotly, thruoug bluetooth.
Not a limitation in the valve implementation of bluetooth drivers (as the app they provide is able to program the valves from its interface) but probably a limitation of the TASMOTA driver right now.

So if I want to program it easily from openHAB valves sould be put to manual mode and driven by the controllers following a predefined program that sets the setpoint temperature at each moment.
But for now I think I will program them and let them work in auto mode to start with.

May be people in TASMOTA implement new functionality soon, it seems that EQ3 TRV were a recent addition.

I suggest a self standing integrated wireless control system that comprises i) a main thermostat to directly control your main incoming heating valve, and ii) has electronic thermostatic valve heads on the radiators.

My own heating is based on such a system from tado°. The system functions independently of openHAB, but is fully integrated into openHAB via the tado° binding.

The advantage of this is that you get a properly engineered control system, that the wife can use, without having to program the arcana of PID control etc. into OH. Basically I leave all that stuff to the tado system, and I just use OH to monitor the status and eventually override the temperature setpoint (target) values.

For your application I would suggest the following tado° equipment…

  1. One “Starter Kit”. The kit is available in either ‘wired’ or ‘wireless’ versions. The ‘wired’ kit has a Hub and a Thermostat that you connect directly to the existing house wiring that switches your main inlet valve. The ‘wireless’ kit has a Hub, a Receiver that connects to the existing house wiring, and a Thermostat which you can locate freely (wireless with battery) anywhere in your flat.
  2. As many “Smart Radiator Thermostats” as you need. The tado radiator thermostat heads come with adapter fittings so that they can replace most brands of existing mechanical radiator thermostat heads.

The way the system works is as follows:

  • You set a time / temperature program on the main thermostat.
  • You set a time / temperature program on each radiator thermostat.
  • The system will turn on/off the main heating inlet valve whenever either the main thermostat or one of the radiator thermostats is asking for heat. And if all are happy, then the main heating valve is off.

Additional advantages are a) you get a remote app to control the system from anywhere, b) you can do geo-fenciing to turn off/on when you (your phone) leaves or goes home, c) it has open-window detection whereby you can (optionally) turn off the heating if you are ventilating the room.

The integration into openHAB allows you to monitor and override the settings as (for my example) in the sitemaps below…

1 Like

^
And PS the thermostats measure the room humidity as well.

Thank you, I see you propose a similar aproach but using commercial Tado devices.
The difference seem to be mainly that the temperature use to control the valve seems to be read from the sensor in the room and not internally in the valve.
That can be more acurate, but forces you use temperature sensors in each room if you want acurate results and independent control of each room.

Of course it would be way more simple to get it working and have a professional look.

My concerns about using TAdo or other commercial available system is that they use an app that usually needs cloud services online, and sends a lot of info about your home.

EQ3 valves and their application don’t use internet and they have open window detection too.

The price of TAdo valves is much higher: you can get EQ3 for 20€, TAdo costs bout 80.
And you need the gateway (hub) (may be too of them) a sensor for each room…

I have 5 thermostatic valves, and there are 4 more radiators with no valve at all, that may be need being equiped in the future.

If I want to integrate some other thing like a motion or smoke detector, I cannot, you have to buy another equipment (and take care of its batteries). In tasmota you can add easily more sensors, buttons or whatever to the same point.
Of course it would take much more effort to implement and won’t be as good looking (well, may be I end buying a m5stack with esp32 in order to have an integrated rechargable battery, nice looking case and an integrated screen an few buttons).

But your experience and layout would help me to think about how the logic implementation.
Thank you.

May be it can be circunvented using openHAB to control everything. Bu

If you have some C++ programming skills and like Tasmota firmware, there is no need to wait till Tasmota developers implement the function you want. It is actually quite easy to make your own extension to Tasmota firmware and benefit of what Tasmota offers in terms of easy configurability. Recently I redesign my Home Automation heating system and successfully used this approach. I made some repositories explaining how to start making own drivers with Tasmota. Some other example there is for Home Assistant, it maybe still useful for openHAB users.