HTTP request: calculation of value sent

jean_bruder · August 13, 2025, 8:15pm

Good evening,

I don’t know how to « cast » the result which seems to be sent as a string, whereas a numeric value is expected in the following case:

Your help would be appreciated, thank you in advance,
Have a nice evening,
Jean

pierre-gilles · August 14, 2025, 6:53am

Hi @jean_bruder

Indeed, it’s not possible to do what you’re doing; you need to break down the calculation and the sending of the JSON.

You can change the state of a sensor to a « calculated » value in « Control a device ».
Then, you can inject this calculated value into a JSON like you do here.

jean_bruder · August 14, 2025, 8:03am

Hello @pierre-gilles

I don’t know how to apply your answer to my scene: the value calculated to be sent via HTTP/POST comes from an operation on a value received via HTTP/GET to which a value is added/removed, and must be in numeric format. How can I use the calculated value of a device?

Thanks,
Jean

pierre-gilles · August 15, 2025, 1:53pm

You can use a virtual device (MQTT integration) that serves as a « buffer » for the final value that you then send over HTTP.

jean_bruder · August 11, 2026, 4:49pm

Good evening @pierre-gilles

I’m taking advantage of the current good mood on the forum and the developers who keep innovating to dig up old requests I didn’t manage to complete …

Do you think it’s still impossible to apply a calculation to a sent value, because it could really simplify a lot of use cases: we could make a GET request, then a POST in interactive response

Looking forward to your reply,

Have a nice evening,

Jean

pierre-gilles · August 14, 2026, 8:26am

Hi @jean_bruder

Well, I’m going to answer you differently from what you expect: I don’t think we should add the calculation in the « HTTP Request » block, because everything you describe is already possible today

First, the « why not »: the body of an HTTP request is free text. It can be JSON, XML, form-urlencoded, anything. If we started evaluating calculations in it, Gladys would have to guess which part of the text is a formula and which part is content to be sent as-is, with the risk of breaking perfectly valid bodies in the process. That would mean inventing a special syntax, documenting it, maintaining it… whereas separating « I calculate » and « I send » remains clearer, and also allows you to reuse the calculated value elsewhere in the scene.

And above all: the GET then calculate then POST, you can already do it, without new functionality.

What was missing in your scene last year is simply that the response from an HTTP request is exposed as a scene variable. You do your GET, you click once on « Try » so that Gladys discovers the keys of the response, and you can then reinject them with {{ in all the following blocks, including in a second HTTP call. Concretely:

HTTP Request (GET): you retrieve your value, e.g. data.temperature
Control a device: your virtual device (MQTT integration), « Calculated » tab: {{ data.temperature }} + 2
Retrieve the last state of this same device: you get a clean numerical variable
HTTP Request (POST): you inject this variable into your JSON with {{

It works, and it even has a nice side effect: your calculated value becomes a real sensor, with history and graphs.

But I understand you, the buffer device is a bit heavy when the value is not meant to be historized.

So, good news: a new « Set a variable » action is coming

github.com/GladysAssistant/Gladys

feat(scene): add a "Set a variable" action (#2863)

master ← claude/dazzling-archimedes-sqfxn8

ouvert 02:20AM - 14 Aug 26 UTC

Pierre-Gilles

+656 -36

### 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.

It will allow you to set a value once, either text or a calculation (Calculated tab, e.g. {{ data.temperature }} + 2), give it a name, and reuse it in all subsequent actions in the scene. No need to create a permanent MQTT device, no need for the « Retrieve the last state » block. Your scene will become:

HTTP Request (GET)
Set a variable « Value to send », Calculated tab: {{ data.temperature }} + 2
HTTP Request (POST) with {{ to inject your variable in the body

Three blocks, each with a clear role, and the calculation remains in the block intended for it. It’s exactly your use case

jean_bruder · August 14, 2026, 11:44am

@pierre-gilles Thank you, thank you, thank you, thank you

jean_bruder · August 14, 2026, 5:01pm

Good evening @pierre-gilles,

No rush to reply

I have a question about the calculation and what it returns: is it indeed a numeric integer value that is the result of this calculation:

Because, in the log, I have this error:

Gladys | 2026-08-14T18:55:03+0200 scene.executeActions.js:42 (executeAction) Error: Parse error on line 1:
Gladys | …{{1.0.else.0.0.value}}}
Gladys | -----------------------^
Gladys | Expecting ‹ CLOSE ›, ‹ OPEN_SEXPR ›, ‹ ID ›, ‹ STRING ›, ‹ NUMBER ›, ‹ BOOLEAN ›, ‹ UNDEFINED ›, ‹ NULL ›, ‹ DATA ›, got ‹ CLOSE_UNESCAPED ›
Gladys | at Parser.parseError (/src/server/node_modules/handlebars/lib/handlebars/compiler/parser.js:199:11)
Gladys | at Parser.parse (/src/server/node_modules/handlebars/lib/handlebars/compiler/parser.js:251:22)
Gladys | at parseWithoutProcessing (/src/server/node_modules/handlebars/lib/handlebars/compiler/base.js:28:20)
Gladys | at HandlebarsEnvironment.parse (/src/server/node_modules/handlebars/lib/handlebars/compiler/base.js:34:13)
Gladys | at compileInput (/src/server/node_modules/handlebars/lib/handlebars/compiler/compiler.js:532:19)
Gladys | at ret (/src/server/node_modules/handlebars/lib/handlebars/compiler/compiler.js:546:18)
Gladys | at Object.http.request (/src/server/lib/scene/scene.actions.js:572:11)
Gladys | at executeAction (/src/server/lib/scene/scene.executeActions.js:34:37)
Gladys | at /src/server/lib/scene/scene.executeActions.js:75:15
Gladys | at tryCatcher (/src/server/node_modules/bluebird/js/release/util.js:16:23)
Gladys | at MappingPromiseArray._promiseFulfilled (/src/server/node_modules/bluebird/js/release/map.js:68:38)
Gladys | at MappingPromiseArray.PromiseArray._iterate (/src/server/node_modules/bluebird/js/release/promise_array.js:115:31)
Gladys | at MappingPromiseArray.init (/src/server/node_modules/bluebird/js/release/promise_array.js:79:10)
Gladys | at MappingPromiseArray._asyncInit (/src/server/node_modules/bluebird/js/release/map.js:37:10)
Gladys | at _drainQueueStep (/src/server/node_modules/bluebird/js/release/async.js:97:12)
Gladys | at _drainQueue (/src/server/node_modules/bluebird/js/release/async.js:86:9)
Gladys | at Async._drainQueues (/src/server/node_modules/bluebird/js/release/async.js:102:5)
Gladys | at Immediate.Async.drainQueues (/src/server/node_modules/bluebird/js/release/async.js:15:14)
Gladys | at processImmediate (node:internal/timers:534:21)

Additionally, during my HTTP call, I must have missed one of your instructions, as the format does not seem to be correct: it must be numeric.

Thanks for your feedback on this,

Have a nice evening,

Jean

pierre-gilles · August 20, 2026, 6:18pm

Hi @jean_bruder

Good news: your calculation has nothing to do with the error

1. The error in the log comes from the body of your HTTP request, not the calculation.

Look closely at the end of the line: {{1.0.else.0.0.value}}} — there are three } in a row. The two curly braces close your variable, and the last one closes your JSON. Handlebars interprets these three curly braces as the closing of a « triple curly brace » {{{ }}}, and complains (got 'CLOSE_UNESCAPED').

Just don’t put them together. Instead of:

{"puissance": {{1.0.else.0.0.value}}}

write:

{
  "puissance": {{1.0.else.0.0.value}}
}

(a simple space before the final curly brace is also enough: {"puissance": {{1.0.else.0.0.value}} }). Be careful, putting the space inside the variable doesn’t change anything: {{ 1.0.else.0.0.value }}} still crashes, it’s only right after the }} that you need space.

2. For the numeric format: definitely no quotes around the variable.

Gladys parses the body as JSON before sending it, so:

"puissance": "{{ma_variable}}" → sends "22.5", a string
"puissance": {{ma_variable}} → sends 22.5, a real number

3. And yes, the calculation does return a number, but not necessarily an integer: if your original value is 20.5, {{ma_variable}} + 2 gives you 22.5. If your API expects an integer, you can round directly in the « Calculated » tab:

round({{ma_variable}} + 2) → 23
round({{ma_variable}} + 2, 2) → two decimal places

jean_bruder · August 23, 2026, 7:21pm

Good evening @pierre-gilles,

Topic now closed, and multimedia button now fully functional for radio and music, thank you for your patience and your listening

Topic		Replies	Views
Récupérer consigne thermostat dans le déclencheur d'une scène Configuration	17	1229	April 19, 2023
Faire une opération mathématique sur une “variable de scène” Demandes livrées feature-core , scene , scene-action	81	3370	May 13, 2023
Être capable d'injecter une variable dans requête HTTP + contrôler un appareil Demandes livrées feature-integration , scene , scene-action	37	3088	May 18, 2023
Gestion du chauffage MQTT dans Gladys Assistant v4.11.2! Actualités	66	2769	October 27, 2022
Alternatives pour les scènes interrompues par les mises à jour Configuration scene-action	15	147	August 20, 2026

HTTP request: calculation of value sent

Related topics