Feature description
After purchasing my connected thermostat, I noticed that Gladys does not yet support native heating management:
Vote today so that this is the case before the end of winter 
From what I understand, the votes wonât change anything as long as there is no one available or no developer equipped, regardless of the number of voters
Cf:
https://community.gladysassistant.com/t/ajout-enceinte-sonos/5504/5?u=spenceur
Perhaps we can discuss this elsewhere, but if the votes have a huge interest: this gives the community an indication of what is requested/not requested.
Personally, when I develop a new feature, I take the list of features linked to the core, I sort by vote, and I develop the most requested one. Itâs not a golden rule, of course sometimes I also develop less requested features that I consider important according to my judgment.
In any case, historically over the past year, I have developed the 30 most requested features (see archive: [Archive] Demande de fonctionnalités - Gladys Assistant community)
In the case of integrations, I already answered you @spenceur in another topic.
By the way, maybe the line is thin between core development and integration development, but this issue (native heating management) is clearly a core development, itâs not an integration!
There is no need for hardware for this feature request.
Otherwise, @lmilcent if you want this issue to move forward, 90% of the work here is functional specification.
I think youâre used to it, I do it for every feature request, but you will have to do:
- Study of the different heating solutions (we will make a development that will be the same regardless of the integrations, not just Zigbee)
- Functional specifications: what do we want?
- Mockups: What will it look like?
- Finally, the development
In short, writing code will be the last 10%.
If you donât feel like doing all this, unless someone else looks into it, personally there are dozens of other requests more voted than this one so it may take a long time before I get to this feature 
(Several years? 
)
Edit: Example of spec/mockups: Multi-utilisateurs - #6 par pierre-gilles
Having purchased 2 EnOcean thermostatic heads about 2 years ago, with one still in a drawer and the other installed but used in disconnected mode, I always have in mind to have a complete heating management system under Gladys.
I wouldnât mind looking into it for development, but the specifications I have in mind are quite complete/complex. Knowing that I have great difficulty in finding (a lot of) time at the moment. Iâm afraid Iâll spend another winter with my old system ^^
As @pierre-gilles says, Iâm already available to discuss these specifications.
For my part, broadly speaking, I already saw a « Declaration of your heating » system.
-
That is to say a link between the thermostatic equipment, the radiator valves or the central valve (Iâm thinking of my case) with temperature sensors.
-
Each valve is coupled with its sensor(s).
-
A system of setpoints for each valve/sensor pair.
-
Exceeding the threshold on a sensor connected to a valve would trigger the request on the valve or stop it.
-
Of course, the visual management of a schedule.
-
Not forgetting a possible coupling of the valves with the window sensors, if you open a door/window in the room where there is a valve, you stop it to avoid heating unnecessarily.
-
Similarly, if the house is empty, you can decide to turn off the heating, with a delay ⊠.. to be seen ⊠or start remotely when a user arrives or decidesâŠ
Thanks for your responses. Like @Jean-Philippe, Iâm still struggling to find some headspace at the moment, but that doesnât stop me from starting something. Together, weâll be able to create a complete deliverable to facilitate development.
Itâs true that I hadnât identified that it was mostly about specs, but that makes it easier to roll out the development afterwards!
In the meantime, @Jean-Philippe, I think thereâs node-red, which can allow you to tinker until itâs supported. I havenât tried it yet, I couldnât say if it works 
To be continued, Iâll start a working version as soon as I can. Donât hesitate to propose information, complete, proofread, give your scenarios, etc.
Functional specification
As a Gladys user, I want to be able to control my heating. To do this, I see a few possibilities:
- Via a calendar, or static programming
- Via a calendar with priority to sensors
- Manually, via a kind of thermostat or central control
- Automatically, using other sensors
1. Via a calendar
A « calendar » type interface over a week allows you to choose from what time to what time the heating is on or off, with an additional heating setpoint.
Example:
- Monday: 21°C from 7am to 9am, off from 9am to 5pm, 19°C from 5pm to 9pm, 17°C from 9pm to 7am.
- Tuesday: etc. until Sunday
2. Via a calendar with priority to sensors
The calendar interface is always active, but if a scene changes the setpoint temperatures, then it will take priority. As soon as this setpoint temperature is removed or the heating is turned off, it is the calendar that takes over again.
Example:
- The calendar heats every day between 6am and 9am and between 4pm and 9pm. During the day, the heating is off.
- A scene detects my presence at 9am (#telework) and turns on the heating by increasing the setpoint temperature. Despite the deactivation scheduled in the calendar, it is the scene that keeps control of the heating.
- At 5pm, the scene turns off the heating and sends a signal to Gladys to « take over » and let the calendar run its course.
3. Manually
A thermostat on the dashboard allows you to control the heating temperature per room. No automation is present here, it is the user who chooses via Gladys how they want to heat their different rooms.
If a physical thermostat is added to Gladys, it can be used linked or instead of the one displayed on the dashboard. It will always be the priority to the physical thermostat.
If the heating management calendar is in use, but the user changes the thermostat via the dashboard, then it is the user who has control instead. A small warning message (in info mode) may remind that the calendar (or a scene) was managing the setpoint temperature.
4. Automatically (WIP)
What is the best solution to use external sensors in a practical way and not through 25,000 scenes, a bit of calendar, etc.?
TODO
A link between the thermostatic equipment, the radiator valves or the central valve (I am thinking of my case) with temperature sensors.
Each valve is coupled with its sensor(s).
A system of setpoints for each valve/sensor pair.
Exceeding the threshold on a sensor connected to a valve would trigger the request on the valve or stop it.
Finally, of course, the visual management of a schedule.
Not forgetting a possible coupling of the valves with the window sensors, if a door/window is opened in the room where there is a valve, it is stopped to avoid heating in vain.
In the same way, if the house is empty, you can decide to turn off the heating, with a delay ⊠⊠to be seen ⊠or start remotely when a user arrives or decides âŠ
Excellent description!
If I may, I would like to see the possibility of suspending the use of programming for a longer period (not heating during the summer even if we have a âč cold snap âș) and a scheduled reactivation (I am away/traveling all week but reactivate the heating programming on Friday at 3 p.m.).
⊠And another practical feature is « heat for X more hours » and conversely « do not heat for X hours » because « I have guests who will stay but I risk forgetting to turn off the heating when going to bed » (or no longer knowing how to do it) and « afternoon shopping, no need to heat for 2 hours » (real, felt 8 p.m.).
Hello @lmilcent,
This is very interesting, but as @pierre-gilles says, it must work regardless of the integration.
For my part, I have Z-wave Qubino ZMNHJD1 modules for underfloor electric heating, the towel warmer, and others, not yet installed, for convectors. I also have programmable inertia radiators, which will be integrated into Gladys if Z-wave becomes functional.
Everything that is used has been working with Domoticz for several years.
The fact that I cannot manage the heating is THE reason why I am not switching to Gladys PlusâŠ
Thanks for your feedback @gaetanb76, indeed there is still work to be done to complete this description and take most use cases into account.
For my part, in the meantime, I bought Zigbee connected heads, which I control with Zigbee2MQTT and Node-Red. I encountered many difficulties and spent a lot of time on it, I will update my main post to modify it according to my feedback afterwards
I just started integrating my valves https://ubiwizz.com/l-offre-produits-ubiwizz/9636-vanne-thermostatique-enocean.html into my enOcean integration (not merged with Gladys yet).
And in my case, they can natively interface with window opening sensors and an external temperature sensor if you donât want to use the internal sensor.
Overall, native management of heating that handles all cases without errors, as indicated by @gaetanb76, can be quite complex to write, but I do think it would be a factor in Gladys adoption, heating in a home is one of the major levers for home automation.
I think that once I can manage my valves, I will make it static and let my box manage the setpoints, until I automate it too, but no urgency in the meantime 
Great, I wanted to look into EnOcean for my home automation, especially for their battery-free buttons!
But given the Zigbee giant, I was leaning towards the more widely supported option.
Looking forward to your v1 in Gladys 
Hello, Iâm coming back to the charge because it would indeed be great as an integration. So, itâs about defining the functional specification.
For me, the notion of heating must be specific to a room.
There are two types of heating:
- Simple On/Off
- Thermostatic heads
Thermostatic head
In the case of thermostatic heads, they have a temperature sensor and take care of reaching this room temperature themselves. You just need to be able to transmit this value to them.
I think this is the simplest use case and one that already covers 80% of all usersâ needs, I think.
Integration from a calendar can be done with scenes since 4.8
You can manage based on people present in the house, etc⊠In short, there are already many things you can do.
For thermostatic heads, the remaining task is to be able to modify the temperature value from the Dashboard. To do this, I envisioned a design similar to this:
On/Off heating
The question of On/Off heating is more complex.
Ideally, it would be possible to create a link between a temperature sensor and the switch with automatic turn-on and automatic turn-off around the target value.
I think that just having a target value meets the feature request in Gladys to have virtual variables. Because clearly, this would be the case for this value.
This would allow transforming any On/Off heating into a thermostatic head and thus be controlled in the same way.
Going further
- Introduce a notion of priority in changes,
- general on/off switch for the whole house, for certain rooms, etc⊠(the use of virtual variables, with which we interact in scenes).
- Being able to say in a scene turn off the heating of this room instead of declaring each heating one by one (same again a virtual variable)
Thatâs it, have I correctly summarized the desired features?
This doesnât seem to be a huge task for the Core integration of thermostatic heads, there will be some work on the Zigbee2Mqtt side and other integrations, I think.
On the other hand, the integration of On/Off seems more complicated, especially if at some point we canât get the information from the temperature sensor and the room overheatsâŠ
Feel free to comment or reflect.
Thanks, thatâs very well summarized. After my experience this winter, I confirm your reflection on thermostatic heads and the possibility of coupling them with an external temperature sensor to the head. It was one of the ideas I abandoned with NodeRed.
We need to think about being able to adjust the refresh rate (or temperature check), because itâs not something to do every 10 seconds but rather every 10 minutes, given the inertia.
Another point, the possibility of a manual setpoint on the head or on Gladys that takes priority over the programming.
This is how our Moes heads work, called « temporary manual ». It takes your new temperature condition until the next programming cycle.
Example: 18°C programmed between 8:00 PM and 6:00 AM. If at 9:00 PM I ask the connected head or Gladys via the dashboard (or Telegram) to switch to 21°C, it will be applied until 6:00 AM.
Yes, I see, after that I think we should make a list of features from the most important to the least important and we will already be happy if we can do the basic things in it but letâs go for the more advanced features.
So there is the feature you just described, there is also the ability to turn on/off the heating easily because I was thinking of a case.
If I open the window then turn off the heating. In these cases, we are interested in not changing the desired temperature value to easily return to normal mode.
Alright, letâs move forward since it seems thereâs not much hesitation.
First Need: Thermostatic heads
Integrations:
- On Zigbee2Mqtt, this corresponds to the topics:
occupied_heating_setpointorcurrent_heating_setpointof the devices - Does anyone have a Z-Wave thermostatic head so we can understand how to integrate it?
After:
- Each room can have a heating On or heating Off state to avoid changing the temperature and losing the temperature that may have been decided in one of the scenes.
(eg: Every morning from 8 am to 10 am heats to 20 degrees If a window is opened, turn off the heating. When it closes, it puts the old temperature (so turns the heating back on)).
This translates to in the scenes:
- An action to set the heating temperature of a room and this is reflected on the different heaters in the room
- An action to turn the heating of a room on/off
- A condition: If the heating of a room is not turned on
On the dashboard:
- A switch for the room heating
- A counter to set the desired temperature in the room.
I think these are the 5 most fundamental needs and from that we can start building something more and more interesting. Any opinions?
@lmilcent small question, the case where you add one or two degrees manually on your radiator, has that happened to you often?
In Gladys I think it would be naturally managed by setting the temperature to 18 degrees, a user modifies it directly on the valve, the next time there is a temperature set in the scenes, it puts the value defined in the scene. Would that work as a mode of operation?
Yes, in almost all my rooms!
So far, I have nothing to say!
@pierre-gilles does this level of detail for the functional specifications suffice for you? Do you want more details?
@jgcb00 Your last message is very good, however, I think that once you agree on everything, it would be great to have a « summary » message with the total spec in a reasonably sized message, with the same organization you did, thatâs very good:
Dashboard
âŠ
Scenes
âŠ
Integrations
âŠ
Thanks for looking into this, itâs very simple but what you do is the bulk of the development Coding is just the last meter, itâs just technical, itâs very simple.