Today, in a scene I wanted to configure a waiting time depending on the level of my tank and send myself a message informing me of that waiting time. The way the « Wait » action has evolved lets me do the calculation there, but I can’t do the same in « Send a message ». And even if it were possible, I’d be annoyed to have to write the same formula twice.
The solution, of course, is to define an MQTT device, then in the scene put my formula in a « Control a device » action, then use a « Retrieve the last state » action to use it in « Wait » and in « Send a message ».
But in reality, it’s tedious
I would find it very convenient to have an action, perhaps named « Set a variable », to define a simple or calculated value, then retrieve it later in all actions that accept a variable.
It would look like this :
A few years ago @pierre-gilles wasn’t necessarily in favor, but Gladys has evolved a lot since then.
Given the number of people who have this need, I think it’s legitimate to ask the question again.
Another benefit of this feature is that it prevents a « variable » in MQTT from being used in multiple scenes and causing inconsistencies (because of a user error).
Ah? I don’t even remember
I might have had my reasons at the time, but indeed the scenes have evolved a lot since then, it doesn’t bother me to have this action in the scenes!
Hello, has it become possible since then?
My goal would be to create a temperature difference, and depending on whether the result is positive or negative, I would take one action or another.
Hello, currently no — you need to create a permanent variable in the MQTT integration and you can use it in scenes!
It’s developed:
master ← claude/dazzling-archimedes-sqfxn8
ouvert 02:20AM - 14 Aug 26 UTC
### Description
Adds a new scene action **"Set a variable"** (`variable.set`) w… hich lets a scene define a value once — either a simple text or a computed formula — and re-use it in every following action.
Until now, the only way to compute a value once and use it in several actions was to create a permanent MQTT variable device, write to it with "Control a device", then read it back with "Get device value". As described on the forum, that workaround is tedious and leaks state between scenes.
**How it works**
The action stores its result in the scene scope under its own action path, exactly like the actions that already expose variables. It is therefore available in the next actions as `{{1.0.value}}` — the coordinates of the action, followed by `.value` — and shows up automatically in the `{{` variable picker of every action that accepts variables.
Two value types are supported, following the same *Simple / Computed* tab pattern as the "Wait" action:
- **Text** — a Handlebars template rendered against the scene scope, so it can itself contain other variables.
- **Computed** — a formula rendered against the scene scope, then evaluated by the restricted mathjs instance used by the other scene formulas.
Both modes fail closed: the scene aborts with `VARIABLE_VALUE_NOT_A_NUMBER` if the formula cannot be evaluated or does not return a finite number, with `VARIABLE_TEXT_NOT_VALID` if the text template cannot be compiled, and with `VARIABLE_VALUE_AMBIGUOUS` if an action carries both a `text` and an `evaluate_value`.
An optional **variable name** can be given; it is only a display label, shown in the variable picker of the following actions (`3.1. Waiting time` instead of a bare path).
**Verified in the UI**
Checked locally in demo mode: the new card shows the description, the "Variable name" field, the Text/Computed tabs and the value input; after setting a variable named "Waiting time" in group 3, typing `{{` in a following "Send Message" action offers `3.1. Waiting time` in the picker. Switching between the Text and Computed tabs clears the value of the other tab, in the stored action and in the displayed field.
**Changes**
Server:
- new `ACTIONS.VARIABLE.SET` constant and its implementation in `scene.actions.js`
- `name` allowed in the scene action Joi schema (display name of the variable, only used by the scene editor)
- the action is exposed in the MCP `scene.create` Zod schema, so the AI can use it too, with a `refine()` enforcing that `text` and `evaluate_value` are mutually exclusive
- new tests in `server/test/lib/scene/actions/scene.action.setVariable.test.js` covering text, empty text, nested variables, computed values, re-use in a later action, and every abort path
Front:
- new `SetVariable` scene action card
- registered in the action list, the action icons map and the variable-renaming logic (`VARIABLES_ATTRIBUTES_IN_ACTION`), so `text` / `evaluate_value` references are rewritten when actions are moved
- `time.delay` added to that same map: the "Wait" action stores its computed duration in `evaluate_value` but had no entry, so reordering action groups left a wait formula pointing at the old coordinates. Pre-existing, but on the main path of this feature (compute a duration into a variable, then use it in "Wait")
- the editor hints which claimed "Get device value" was the only way to define a variable now mention this action as well, in English, French and German
- English, French and German translations
**Known design choice:** the selected tab is derived from which field is set, not persisted — same as the existing "Wait" and "Set device value" actions (`computed: props.action.evaluate_value !== undefined`). So selecting "Computed", typing nothing and saving stores neither field and shows the "Text" tab on reload. It only affects an action the user never filled in; persisting an explicit mode would add a field to the action schema and diverge from those two actions. Happy to add a `value_type` field instead if you'd prefer it explicit.
## Forum
Forum: https://community.gladysassistant.com/t/scenes-pouvoir-creer-une-variable-ponctuelle/9505
### 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
`npm run coverage` passes on the full server suite; Codecov reports 100% patch coverage. `npm run compare-translations`, `npm run eslint`, `npm run prettier-check` and `npm run build` pass on the front. Cypress was not run locally (its binary is not installable in this environment) but passes in CI; the two existing scene specs select action types by label text, which this change does not alter.
## Summary by CodeRabbit
* **New Features**
* Added a scene action for defining reusable variables.
* Supports text values, variable interpolation, and computed numeric expressions.
* Variables can be reused in later scene actions.
* Added localized interface text in English, French, and German.
* **Bug Fixes**
* Invalid, ambiguous, or non-numeric variable values now stop scene processing with clear errors.
* **Tests**
* Added coverage for text, interpolation, calculations, reuse, validation, and invalid values.
Tested and approved, it will be included in the next version of Gladys!
mutmut
August 14, 2026, 3:08pm
7
top!
Exactly!
I’m closing this post because the feature is available in Gladys Assistant 4.86:
Hi everyone!
Super excited to release Gladys Assistant 4.86.
It’s simple, it’s the biggest version since the start of the project, with 68 PRs merged in one week
