Hoy, quería en una escena configurar un tiempo de espera dependiente del nivel de mi depósito y enviarme un mensaje informándome de este tiempo de espera. La evolución de la acción « Esperar » me permite hacer mi cálculo, pero no puedo hacer lo mismo en « Enviar un mensaje ». Y aunque fuera posible, me molestaría tener que escribir dos veces la misma fórmula.
La solución, por supuesto, es definir un dispositivo MQTT, luego en la escena poner mi fórmula en una acción « Controlar un dispositivo », luego usar una acción « Recuperar el último estado » para usarla en « Esperar » y en « Enviar un mensaje ».
Pero en realidad, es laborioso
Encontraría muy práctico tener una acción, quizás llamada « Definir una variable », para definir un valor simple o calculado, luego encontrarlo después en todas las acciones que aceptan una variable.
Se vería así:
Hace unos años @pierre-gilles no estaba necesariamente a favor, pero Gladys ha evolucionado mucho desde entonces.
Dado el número de personas que tienen esta necesidad, creo que es legítimo volver a plantear la pregunta.
Otra ventaja de esta función es que evita que una « variable » en MQTT se utilice en varias escenas y provoque incoherencias (debido a un error del usuario).
¿Ah? Ni siquiera me acuerdo
Quizás tenía mis razones en ese momento, pero es cierto que las escenas han evolucionado mucho desde entonces, ¡no me sorprende tener esta acción en las escenas!
Hola, ¿es posible ahora?
Mi objetivo sería medir la diferencia de temperatura y, en función del resultado positivo o negativo, realizar una acción u otra
¡Hola, actualmente no, hay que crear una variable permanente en la integración MQTT y puedes usarla en las escenas!
Ya está desarrollado:
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.
Probado y aprobado, ¡salirá en la próxima versión de Gladys!
mutmut
14 Agosto, 2026 15:08
7
¡genial!
¡Exacto!
Cierro este post porque la funcionalidad ya está disponible en Gladys Assistant 4.86:
Salut à tous !
Super heureux de sortir Gladys Assistant 4.86.
C’est simple, c’est la plus grosse version depuis le début du projet, avec 68 PR fusionnées en une semaine
