Aujourd’hui, je voulais dans une scène configurer un temps d’attente dépendant du niveau de ma cuve et m’envoyer un message m’informant de ce temps d’attente. L’évolution de l’action « Attendre » me permet d’y faire mon calcul, mais je ne peux pas faire de même dans « Envoyer un message ». Et même si c’était possible, ça m’embêterait de devoir écrire deux fois la même formule.
La solution bien sûr, c’est de définir un appareil MQTT, puis dans la scène de mettre ma formule dans une action « Contrôler un appareil », puis d’utiliser une action « Récupérer le dernier état » pour m’en servir dans « Attendre » et dans « Envoyer un message ».
Mais en vrai, c’est laborieux
Je trouverais très pratique d’avoir une action, peut-être nommée « Définir une variable », pour définir une valeur simple ou calculée, puis la retrouver ensuite dans toutes les actions qui acceptent une variable.
Ça ressemblerait à ça :
Il y a quelques années @pierre-gilles n’était pas forcément pour, mais Gladys a énormément évolué depuis.
Au vu du nombre de personne qui a ce besoin, je trouve ça légitime de poser à nouveau la question.
L’autre apport de cette fonctionnalité, c’est qu’elle évite qu’une « variable » dans MQTT soit utilisée dans plusieurs scènes et que ça provoque des incohérences (à cause d’une erreur de l’utilisateur).
Ah ? je me rappelle même plus
J’avais peut-être mes raisons à l’époque, mais effectivement les scènes ont beaucoup évolué depuis, ça me choque pas d’avoir cette action dans les scènes !
Bonjour est ce que c’est devenu possible depuis ?
Mon objectif serait de faire une différence de température et en fonction du résultat positif ou négatif je ferais tel ou tel action
Hello, actuellement non il faut créer une variable permanente dans l’intégration MQTT et tu peux l’utiliser dans les scènes !
C’est développé :
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.
Testé et approuvé, ça partira dans la prochaine version de Gladys !
top !
Exact !
Je ferme ce post car la fonctionnalité est disponible dans 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
