# Smart plug programmer **URL:** \ **Category:** Demande de fonctionnalités\ **Created:** [October 17, 2026, 4:11pm UTC](https://community.gladysassistant.com/t/programmateur-de-prise/11335 "2026-10-17T16:11:31Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Steph38230](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/s/3e96dc/32.png) [@Steph38230](https://community.gladysassistant.com/u/Steph38230)\ **Post date:** [October 17, 2026, 4:11pm UTC](https://community.gladysassistant.com/t/programmateur-de-prise/11335/1 "2026-10-17T16:11:31Z")
Based on the new thermostat, which is great for programming much more easily than with scenes, would it be possible to create a « Programmer » type variant? Like the thermostat, a weekly programming but with just 2 operating modes « On / Off ». Currently, to trigger timed outlet activations, you can do it through scenes, but it’s very tedious if there are multiple activations at different times, so programming would be great ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/7/0/7032494fd9f16ca6061ef5da899f6efd23396924.png) ---
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [October 17, 2026, 4:26pm UTC](https://community.gladysassistant.com/t/programmateur-de-prise/11335/2 "2026-10-17T16:26:41Z")
I took the liberty of moving your topic to feature requests 😉 And I voted for it 😇 ---
**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\ **Post date:** [October 17, 2026, 4:43pm UTC](https://community.gladysassistant.com/t/programmateur-de-prise/11335/3 "2026-10-17T16:43:24Z")
This isn’t a schedule like the thermostat, but I have a PR in progress to do roughly the same thing in a scene. ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/4/d/4dcd8256615031e245c7af7408ac620779861e3c.png) > > > \## Scenes: add a "time ranges" scheduled trigger > > Today, driving a device from… a weekly planning requires two scenes: one to > turn it on, one to turn it off, each with its own scheduled trigger, kept in > sync by hand. This PR adds a \`time-range\` scheduler type so a whole planning > lives in a single scene. > > \### The trigger > > A new \*\*Time ranges\*\* option in the scheduled trigger. You configure a list of > ranges (\`start\` → \`end\`, "HH:mm") and the days of the week they apply to. The > scene runs at the \*\*start\*\* and at the \*\*end\*\* of every range, and the trigger > tells the scene which boundary fired. > > \- A range is active from its start (included) to its end (excluded), so two > consecutive ranges (\`10:00 → 12:00\` then \`12:00 → 14:00\`) never report the > same minute twice. > \- Ranges crossing midnight are supported (\`22:00 → 06:00\`). The days of the > week always apply to the \*\*start\*\* of the range: configured on monday, that > range runs from monday 22:00 to tuesday 06:00. > \- A range whose start equals its end covers nothing and is never scheduled. > \- Ranges are sorted in the editor, and a new one is no longer pre-filled. > > \### The condition > > A new \*\*\`scene.in-time-range\`\*\* action, meant to sit in an \`If… Then… Else\` > block: "then" is the inside of the planning, "else" is the outside. One scene, > one device, on at the start of every range and off at the end. > > When the scene was started by one of its own time-range jobs, the condition > trusts the boundary carried by the trigger instead of re-computing it — a job > firing exactly at the end of a range could otherwise still be seen as "inside" > a few milliseconds later. Started any other way (manually, by another trigger, > by another scene), the state is computed from the ranges of the scene's > time-range triggers. The scene selector check matters here: \`scene.start\` hands > a child scene a clone of the scope, so without it a called scene would answer > for the ranges of its caller. > > \### Resume on startup > > Jobs are scheduled for the future only, so a boundary crossed while Gladys was > down is never replayed: a pool pump stopped by a power cut would stay off for > the rest of the range, and one left on would keep running long after the range > ended. > > With the optional \*\*resume on startup\*\* checkbox, the scene is executed once at > startup with \`range\_event = 'resume'\` and \`in\_range\` telling whether we are > currently inside the planning. The scene re-applies the wanted state itself — > Gladys does not know which device it drives, so re-applying is both simpler and > safer than guessing. The resume runs \*\*once per boot\*\*: \`init()\` also runs when > the user changes the timezone in the settings, and re-applying the planning > then would run these scenes again for no reason. > > \image > > \image > > \### Checklist > > \- \[x\] Tests pass: \`cd server && npm run coverage\` (Codecov requires 100% coverage on changed lines) and Cypress (\`npm run cypress:run\`) if the UI changed > \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`) > \- \[x\] No undocumented breaking change > > > > > \## Summary by CodeRabbit > > \## New Features > \- Added time-range scheduling for scenes with configurable weekdays, start/end times, overnight ranges, and optional startup resumption. > \- Added an “In time range” condition for scene actions. > \- Added localized English, German, and French labels, guidance, and menu scrolling controls. > > \## Bug Fixes > \- Improved validation for invalid times, empty schedules, and identical start/end times. > \- Improved handling of overlapping and adjacent ranges. > \- Preserved edits made while a scene save is in progress. ---
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [October 18, 2026, 7:46am UTC](https://community.gladysassistant.com/t/programmateur-de-prise/11335/4 "2026-10-18T07:46:19Z")
Oh yes, it will work out!