Once it’s been implemented in Gladys, the request will be closed.
Here is a first image for those who want to test.
For now, you can only control a switch (outlet), the pilot wire will come later. And there are still many things to see.
Looking forward to your feedback
willde71/gladys-test:thermostat
Great, I’ll finally be able to redo my scenes without it being too much of a hassle, fingers crossed
It’s a beta version, so there are still some things to fix. My goal is to have it available in Gladys before next winter
@pierre-gilles, the PR
I just updated the image for those who want to test.
docker pull willde71/gladys-test:thermostat
Hello!
I’ve hesitated several times to write this message or not, not entirely convinced whether it’s necessary to do something or not. But deep down, I remain convinced that yes, there is something to propose.
We recently introduced additional information on the Core Gladys side for the concept of Thermostat (to manage real thermostat devices, with mode and state). This evolution proposed by @Will_71 is very interesting. And I think we have something to do to link these previous modifications and this new display. I tried the image of @Will_71, unfortunately it cannot work yet really with a real Thermostat, or at least, not the one I have at home: the elements controlled by the thermostat are directly linked to the thermostat. There is no « third-party switch ».
What would be interesting would be to be able to retrieve:
- the display part by being able to define, as is the case today, the different sensors, the modes, etc.
- the scheduling managed by Gladys: we have nothing native that would allow controlling a real device that has its own scheduler: so it could make complete sense
- the different modes
and connect them to a real thermostat.
In short, today for example what prevents connecting a real thermostat to this proposal is all the heuristic management + the switch. A real thermostat already manages it. You define its threshold, its operating mode, and it is the one that manages the activation or not of the heating (it’s not a different inter).
We are not far from being able to offer a nicer display for real thermostats thanks to this PR. To what extent can we make an effort to make this really the case? I can provide more context of the real device available to me if necessary.
Thank you
For now, it’s a first version that meets a need for me, and the main goal here wasn’t to connect it to a « real » thermostat, but to have a fully autonomous virtual thermostat in Gladys. Currently, I manage all my electric radiators in NodeRed, otherwise there are too many scenes to manage.
I had put a test image but I didn’t get any test feedback, so I continued in that direction.
I also plan to be able to control a fil pilote radiator in a future version.
After that, I’m not against it, your reasoning is justified. Why not in a 2nd version.
After that, I’m happy for you to write everything you want to implement and I’ll work on it.
Actually, your PR is already close to being able to handle a real thermostat.
The difference is that heuristic management on a « real thermostat » is native to the device: so there’s no need to control it via Gladys. Therefore, the notion of a switch also becomes obsolete. You need to introduce the notion of « endpoint » (threshold, target comfort temperature) + rely on the « State » feature to know if you are in the process of heating, off, or cooling.
After all, the rest is to be kept: the mode (a feature to connect as you do for the temperature) and the entire « comfort temperature programming » part (which would then act on the endpoint feature).
I can also take a look at your PR and contribute to it
yes you can
I’m jumping into the discussion, I agree with @Sescandell and I think it should be part of the first development. I also thought it was possible to manage a thermostat with this new widget 
I’m on it
@Sescandell, I added a new parameter that allows you to define the type of thermostat (virtual or real)
Then, you can find all the thermostats in the list below
I’ll push to GitHub and rebuild an image by tonight so you can test it.
I’ll let you know when the image is ready.
It’s been pushed to the PR. The image is being built, count 15 minutes for it to be available.
Looking forward to your feedback @Sescandell
Hello @Will_71
Nice 
It’s rather promising. I was able to configure the real thermostat and get something .
I only observe two issues:
In « no schedule » mode, the « Off » button does not actually turn off:
This sets the target to 7°C but the device is not actually off (Mode == off).
Same with the scheduling mode and off mode on the affected range: it sets to 7°
Finally, a small detail, on the thermostat page, the target with a real device does not position itself:
Super cool, thanks 
Okay, thanks for your feedback. I’ll fix that by tomorrow.
@Sescandell, image currently being updated
Hello @Will_71
The reported issues are fine. From what I’ve tested, everything is OK, I love it! Excellent!
I have a question, it might be a very personal opinion: I’m wondering about the orientation of the Gauge:
I have the impression that we are no longer used to seeing the - / + buttons « at the bottom » but on the right. In short, the gauge would deserve a 90° clockwise rotation. In short, I would expect something like this (but with the texts in the correct direction of course 
):
OK, once everything is OK for you, I’ll have to manage a pilot wire on the virtual side.
Regarding the gauge orientation, it’s really a personal choice.
Yes, it’s true that we see a lot of thermostats like you mentioned, but I prefer to have the + button at the top to increase and the - button at the bottom.
And I see an advantage on mobile: it’s easier if the buttons are on the same side when you scroll on your phone with one hand.
After that, we’ll see what everyone thinks.