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:
-
Be able to see and control all the system from a central UI graphical interface.
-
Be able to measure and control temperatures in front and back zones of home.
-
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).
-
Be able to set different temperature set point (or even programs) for each room radiator.
-
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.
-
The thermostat should have an easy to use interface to arm or disarm the system or to stablish temp setpoints for rooms.
-
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).
