Hi,
Sorry if I’m being a noob, but I don’t understand how to test this PR? And yet, reading the docs, it’s exactly what I’m looking for and even better! Can someone help me?
Thanks!
There is a test image called willde71/gladys-test:latest
You can follow this tutorial to test it https://community.gladysassistant.com/t/tutoriel-lancer-une-image-docker-de-test/
test on a different machine than your normal Gladys
I posted a full review of the PR here: https://github.com/GladysAssistant/Gladys/pull/2988#issuecomment-5730802738
It was Fable 5.1 who wrote the message, but I spent 1 hour with him to write it 
Yes, I saw it, thanks for the complete feedback.
I’ll get to it to address the points as soon as possible.
Good evening,
I wanted to test the Thermostat feature (which, by the way, is an excellent idea!).
I therefore installed the image willde71/gladys-test:latest and the container /gladys-thermostat-test is indeed running.
However, I do not find the « Thermostat » integration between « Telegram » and « TP-Link » as mentioned in the message from @Will_71 on February 27. Is this normal?
The image you took isn’t good, the image is: willde71/gladys-test:thermostat
With the image, there is indeed my integration:
@cicoub13 I took the liberty of editing your message because the image you mentioned was incorrect
Hello @Will_71,
Great work! I just tested it with the Saunier Duval external integration. I leave the regulation part to the official application, so the Thermostat integration is used in « Real Thermostat (device regulates) » mode. The configuration is simple and clear, no need to read the documentation, all the settings are clear.
In use, everything works well. Temperature control, thermostat shutdown.
The feature does not allow switching to « programming » mode. Would it be possible to add this? (cf. auto mode proposed by the Saunier Duval integration, top right of the image below)
Okay, thanks for your feedback.
For your auto mode, I’ll first look at the list of corrections in the PR.
Then I’ll see what I can do. What exactly does the auto programming mode consist of?
The auto mode corresponds to the scheduling mode defined in the Saunier Duval application.
@pierre-gilles, I (Claude) have posted a reply on the PR. As soon as it’s OK with you, I’ll start the changes.
Hello,
I wanted to test on a Raspberry Pi 3B+ so I wouldn’t use my production machine.
I get this:
Unable to find image ‹ willde71/gladys-test:thermostat › locally
thermostat: Pulling from willde71/gladys-test
docker: no matching manifest for linux/arm/v7 in the manifest list entries
This is normal because the generated image is not for this architecture
The image is for:
Thanks a lot, the image works on my end. Now I just need to test it!
Yes, that’s what I had understood.
Before your reply, I wiped the SD card and installed 64-bit Bookworm.
The installation is currently in progress.
Thanks @Will_71
@pierre-gilles, so I made progress today based on your feedback on the PR.
The three decisions
Decision 1 — preset and mode on features. Done. Type THERMOSTAT.PRESET in the core, enum schedule/frost/away/eco/night/comfort, off removed from presets. The virtual thermostat carries four features, the external one carries preset alone. The entire t_variable layer removed, with its ownership check, its postDelete and its /state/ route.
A formal discrepancy, to be validated: you suggested last_value_string. It’s impossible — device-feature-categories.md reserves strings for text/select types, and normalizeSupportedOptions rejects them everywhere else. The enum is therefore integer and append-only, like THERMOSTAT_MODE and WATER_HEATER_MODE.
Decision 2 — a single write path. Done. Everything goes through POST /device_feature/:selector/value. The setpoint/, state/:variable_key and apply-schedules routes have disappeared, along with the ownership guard for each. The controller goes from 13 to 9 routes; selectPreset from 5 writes to 1.
Decision 3 — toggle points, attached to the house. Schema done as specified: the three tables, uniqueness per house, primary key on device_id alone, cascades. detachSchedule removed, current/next calculated on the server side.
A divergence on input, to be discussed. Storage remains in points. But the editor has you enter a start and end, converted to points on save. In use on a real installation, point-by-point input proved impractical: a single point colors the entire week, and closing a range requires understanding that you need to place a second one. Netatmo and Tado store points — but their editors manipulate blocks with a start and end, and convert on save. The storage model and the input model are not the same object.
The two small points
Preset bar visible under the banner on a scheduled thermostat ✓
Hold « until the next toggle point » by default, fixed duration if THERMOSTAT_MANUAL_DURATION is set ✓
The bug on external thermostats
Confirmed by reading the code, fixed, not reproduced on hardware. The brand is now preserved and compared instead of being consumed: an identical report remains ours no matter how many times it’s done. A test repeats the same report three times.
Two others from the same family, found during implementation: the stop wrote the setpoint before the mode — a thermostat in COOLING was asked for 7°C; and the window-open listener ignored external thermostats, lacking a switch to look for.
Tomorrow I’ll test this modified version and I’ll make an image available for everyone to test.
Thanks for the feedback @Will_71!
I ran Claude on a big real test session, and it posted all these findings on the PR: https://github.com/GladysAssistant/Gladys/pull/2988#issuecomment-5856669255
I saw thanks, I’m going to ping Claude about it!
Make sure to pass it to Claude Opus 5.5 for correction, it has nothing to do with Opus 5 
Yes, don’t worry, I’m on Opus 5.5… it’s working hard here.
@pierre-gilles, I’ve pushed the fixes.