Native heating management

[jgcb00]

Ok, there’s still a technical arbitration to be made and that’s it.

So, we want an On-Off switch in addition to the fact that it’s thermostatic, except that the head doesn’t have a switch, so it must be a fake switch that sets a default value (5 degrees for example) and when you reactivate the switch, you restore the old value that the head had or potentially a new one that was pushed for the scenes.

This requires a kind of memory, which is not crazy.

Otherwise, I propose the following operation:

• A numerical variable for the desired temperature
• If this variable is modified, we check that the heating is on to publish it
• If the heating is off, we only change the value within Gladys
• If the heating is turned on, we push the value that is in Gladys
• If we turn off the heating, we push a value that has been set by default.

I think I have covered all cases, I don’t know if it’s very clear!
I would appreciate an opinion from an expert (@pierre-gilles?) on how you would technically solve this problem?

[pierre-gilles]

Do we really want this behavior? I find it complicated, and above all it creates a « false behavior » that the user will not understand.

I think Gladys should just mimic what happens in real life, so that it is clear to the user.

If the thermostatic head does not manage On/Off, we should not put On/Off in Gladys in my opinion.

If the user wants to set 5°C to « turn off » his head, he can do it in Gladys, but I think it is not up to Gladys to perform magical behaviors with fixed values like that, right?

[Tlse-vins]

@pierre-gilles

If the user wants to set 5°C to “turn off” his head, he can do it in Gladys, but I think it’s not up to Gladys to make magical behaviors with fixed values like that, right?

Yes, I agree with that.
If you don’t want heating, you lower the temperature to the minimum. That’s logical behavior.

[VonOx]

There’s something important that hasn’t been addressed: regulation.

[lmilcent]

As usual, it will need to be clarified in the U

Personally, when it’s not done to the extreme, I like to have buttons (on/off in our case) « disabled » with a message (like a tooltip) that explains that it’s not supported by my connected head.

[Terdious]

In this case, couldn’t the user do it themselves with a fake device and a scene? That would be closer to reality… for that, the value injection would need to happen in the scenes at the same time. And in the documentation, we could provide concrete examples of implementation (the request for scene classification in folders would be ideal too ^^)

[Terdious]

Absolutely @VonOx ^^
But from what I understood from the conversation, it was here to start the project with the simplest approach and add regulation in a future PR, right?

[jgcb00]

Hello everyone,

@pierre-gilles

Do we really want this functionality? I find it complicated, and above all it creates a « false behavior » that the user won’t understand.

In theory, yes I agree that it’s not ideal, it’s a bit redundant etc…
In practice, there are many scenarios where it is essential. Everything related to heating interruption / heating resumption, it is necessary to be able to retrieve the old regime which will certainly have a different value depending on the cases…

@VonOx

There’s something that seems important to me and hasn’t been addressed, the regulation.

Yes, as @Terdious says, the idea would be to do it in a second batch but if there are motivated developers to do everything directly then why not integrate it directly!
@VonOx do you care about this feature in the first batch of features?

[Will_71]

Bonjour tout le monde,

I haven’t yet integrated my heating into Gladys, for now I’m just starting with Gladys and I don’t have all the elements I would need to integrate all my home automation, and at the same time it’s not easy to break an existing system that works for another solution but I’m progressing slowly. In the meantime, I can show you how I did it in my current system Domoticz, if it can give you ideas.

First, I have a virtual switch (fake device) for the heating mode (WINTER / SUMMER)

If SUMMER mode, then the heating is off
If WINTER mode then I activate the heating

Then I have a NetAtmo thermostat, whose relay is directly connected to my pellet stove. In Domoticz I retrieve 4 pieces of information:

• Operating mode => allows to manage the operation of the heating of my whole house (pellet stove and electric radiator) according to a scheduling mode, an away mode and an antifreeze mode
  

  

• Relay status => allows to know if the thermostat relay is active or not (you can execute scenes eventually depending on the status)
  

  

• Temperature read by the thermostat
  

  

• Setpoint temperature
  

  

I wrote a Python script that allows to query the NetAtrmo API and display the data in Gladys if it can interest someone. I just miss the display of the mode because there is no MQTT fake device that can display text, or then I didn’t find how to do it.

The heating of my stove is therefore managed directly by the NetAtmo thermostat and I just read the data in Domoticz.

Then in each room I have an electric heating with a pilot wire (controlled with a QUBINO module in ZWAVE)

For each room I have created several fake devices:

• Operating mode => manual or automatic
  

  
  
  In manual mode, there is another fake device that allows to control the radiator
  In automatic mode, I have a scene that checks the status of my general thermostat, if for example I am in scheduling mode and the setpoint temperature is above a certain value then I allow the individual heating of each room

• Regulation type => hysteresis or PID
  

  
  
  Hysteresis => this is an on-off regulation with 1 start-up value and another for the stop. For example I start the heating at 18°C and I stop at 20°C
  PID => this is a more complex regulation (proportional, integral, derivative), to summarize it’s a closed-loop control system that aims to smooth the temperature (or whatever you want to control)
  
  

• Manual command => if the mode is set to manual then I can select the operating mode of the room radiator (OFF, antifreeze, eco, comfort…)
  

  

• Thermostat => which allows to define the setpoint temperature of the room
  

  

• Temperature sensor
  

  
  
  Here I use a Xiaomi Aqara Zigbee sensor to read the room temperature and compare it with the value of the virtual thermostat.

So if the setpoint value is higher than the current temperature, and also depending on the general thermostat and the manual or automatic operating mode, I control the radiator in comfort mode otherwise in Eco.

For my part, what is missing in Gladys to achieve a heating function, is a thermostat fake device, a fake device type multi-position switch, not only ON/OFF, with the possibility to define a text for each switch position. After that for me everything else can be managed by scenes except the PID regulation which is quite complex. For the general thermostat, I use a NetAtmo thermostat because I can control it remotely and if my home automation system fails I can always control it physically, but for the integration in Gladys we could imagine a thermostat fake device that allows to set a setpoint value. Then with the calendar and a scene come to control the thermostat automatically according to what we will have defined.

[jgcb00]

Hello everyone,
so I’m coming back to the topic following the release of Gladys 4.9

From what I understand from all our discussions, there’s for the moment only one thing left to agree on: how we want to present this in the dashboard?
Do we want a slider like the brightness control?
Or a thermostat somewhat like this, increasing in 0.5-degree increments?

@jgcb00

On the development side to support devices

• For Zigbee2MQTT we need to support the device topics: occupied_heating_setpoint or current_heating_setpoint
• Still no idea for Z-Wave (and relates to the Z-Wave migration topic)

To enable/disable winter/summer heating -\u003e activating/deactivating scenes or setting the temperature to 5 degrees
To enable/disable all heaters in a room -\u003e fake scene switch that pushes a fixed value to the room’s radiators (We could potentially improve this in the future with a general thermostat for the room)
Controlling heating by schedule -\u003e doable with scenes
Control of an on-off heater with a room temperature -\u003e already doable with scenes, a fake device, and a temperature sensor in the room

Did I forget any use cases we haven’t decided on?

[pierre-gilles]

@jgcb00 Could you make a design proposal on Whimsical ( https://whimsical.com/ ) to recap everything that needs to be developed? (Both the dashboard and the scenes)

Put together a proposal, and then we can iterate on it

[jgcb00]

Ok, which feature are you using to do that?

[pierre-gilles]

Wireframe!

[Tlse-vins]

Do you have a template file for the dashboard boxes?
With the height of the « box name » section

[pierre-gilles]

No need to be pixel perfect (that’s not the idea behind Whimsical, it’s not Figma), the idea is just to make a mockup / functional spec

[jgcb00]

Here’s what I see for the moment
Left side in the scenes, right side in the dashboard

[pierre-gilles]

If it’s that simple, even better!

That said, do we want to do « device by device » (which could be a good start at first), or do we want to offer controls rather by room? (which could come in a separate box later on)

In any case, I’m in favor of keeping things simple to start, and what you’re proposing is really pretty good!

[jgcb00]

@pierre-gilles

Where do we want to offer commands per room instead?

Yes I had the same thought, but for me object groups are another topic, no? You might want to create an object group with the lamp plug and the ceiling lamp to always turn them on together, so do we want to restrict that to heating only?

I think the best trade-off on this point would be to be able to create an object group in a scene very easily like this:

or every change in the value of a type can be propagated to another object of the same type.
What do you think? And this is a big core feature of Gladys

[jgcb00]

or we can do everything in a single block in the scenes, which allows displaying only the devices that are compatible with each other

[pierre-gilles]

@jgcb00

Yes I had the same thought, but for me object groups are another topic, right?

We’ll see, we’re not obliged to always make it generic; sometimes a custom one for a device type can be good too!

Typically Home Assistant has components like that (the one on the right for heating):

It could be a custom box in Gladys, or we could select a list of heating-type devices to control those devices in a single box, without it necessarily being an object group management.

Anyway, in any case, the first step is the two components you propose @jgcb00. This kind of component is a layer on top to provide a UX that’s as practical to use on a daily basis