Bonsoir,
Je ne sais pas comment « caster » le résultat qui semble être envoyé sous forme de chaine, alors qu’est attendue une valeur numérique dans le cas suivant :
Votre aide serait appréciée, merci par avance,
Belle soirée,
Jean
Salut @jean_bruder 
Effectivement, il n’est pas possible de faire ce que tu fais; il faut que tu décomposes le calcul et l’envoi du JSON.
- Tu peux modifier l’état d’un capteur avec une valeur « calculée » dans « Contrôler un appareil ».
- Ensuite, tu peux injecter cette valeur calculée dans un JSON comme tu fais ici.
Bonjour @pierre-gilles
Je ne sais pas comment appliquer ta réponse à ma scène : la valeur calculée à renvoyer via HTTP/POST est issue d’une opération sur une valeur réceptionnée par HTTP/GET à quoi on ajoute/retire une valeur, et doit être au format numérique. Comment utiliser la valeur calculée d’un appareil ?
Merci à toi,
Jean
Tu peux utiliser un appareil virtuel (intégration MQTT) qui fait office de « tampon » pour la valeur finale que tu envoies ensuite en HTTP.
Bonsoir @pierre-gilles 
Je profite de la bonne humeur actuelle du forum et de l’ensemble des développeurs qui n’arrêtent pas d’innover pour déterrer d’anciennes demandes que je n’avais pas menée à son but … 
Penses-tu qu’il est toujours impossible d’appliquer un calcul à une valeur envoyée, car ça pourrait franchement simplifier plein d’usages : on pourrait effectuer une requête GET, puis une POST en réaction interactive
A te relire,
Belle soirée,
Jean
Salut @jean_bruder
Alors, je vais te répondre différemment de ce que tu attends : je ne pense pas qu’il faille ajouter le calcul dans le bloc « Requête HTTP », parce que tout ce que tu décris est déjà possible aujourd’hui
Sur le « pourquoi pas » d’abord : le body d’une requête HTTP, c’est du texte libre. Ça peut être du JSON, du XML, du form-urlencoded, n’importe quoi. Si on se mettait à évaluer des calculs dedans, il faudrait que Gladys devine quelle partie du texte est une formule et quelle partie est du contenu à envoyer tel quel, avec le risque de casser des body parfaitement valides au passage. Ça voudrait dire inventer une syntaxe spéciale, la documenter, la maintenir… alors que séparer « je calcule » et « j’envoie » reste plus clair, et te permet en prime de réutiliser la valeur calculée ailleurs dans la scène.
Et surtout : le GET puis calcul puis POST, tu peux déjà le faire, sans nouvelle fonctionnalité.
Ce qui manquait dans ta scène l’an dernier, c’est simplement que la réponse d’une requête HTTP est exposée comme variable de scène. Tu fais ton GET, tu cliques une fois sur « Essayer » pour que Gladys découvre les clés de la réponse, et tu peux ensuite les réinjecter avec {{ dans tous les blocs suivants, y compris dans un second appel HTTP. Concrètement :
- Requête HTTP (GET) : tu récupères ta valeur, ex.
data.temperature - Contrôler un appareil : ton appareil virtuel (intégration MQTT), onglet « Calculée » :
{{ data.temperature }} + 2 - Récupérer le dernier état de ce même appareil : tu obtiens une variable numérique propre
- Requête HTTP (POST) : tu injectes cette variable dans ton JSON avec
{{
Ça marche, et ça a même un effet de bord agréable : ta valeur calculée devient un vrai capteur, avec historique et graphiques.
Mais je te comprends, l’appareil tampon est un peu lourd quand la valeur n’a pas vocation à être historisée.
Du coup, bonne nouvelle : une nouvelle action « Définir une variable » arrive
Elle te permettra de poser une valeur une fois, soit du texte, soit un calcul (onglet « Calculée », ex. {{ data.temperature }} + 2), de lui donner un nom, et de la réutiliser dans toutes les actions suivantes de la scène. Plus besoin de créer un appareil MQTT permanent, plus besoin du bloc « Récupérer le dernier état ». Ta scène deviendra :
- Requête HTTP (GET)
- Définir une variable « Valeur à envoyer », onglet « Calculée » :
{{ data.temperature }} + 2 - Requête HTTP (POST) avec
{{pour injecter ta variable dans le body
Trois blocs, chacun avec un rôle clair, et le calcul reste dans le bloc prévu pour ça. C’est exactement ton cas d’usage
@pierre-gilles Merci, merci, merci, merci 
Bonsoir @pierre-gilles,
Aucune urgence de réponse
Je me permets une question concernant le calcul et ce qu’il renvoi : est-ce bien une valeur entière numérique qui est le résultat de ce calcul :
Car, dans le log, j’ai cette erreur :
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)
De plus, lors de mon appel HTTP, j’ai dû louper une de tes indications, car le format ne semble pas convenir : il doit être numérique.
Merci pour ton retour sur le sujet,
Belle soirée,
Jean
Salut @jean_bruder 
Bonne nouvelle : ton calcul n’a rien à voir avec l’erreur 
1. L’erreur du log vient du body de ta requête HTTP, pas du calcul.
Regarde bien la fin de la ligne : {{1.0.else.0.0.value}}} — il y a trois } à la suite. Ce sont les deux accolades qui ferment ta variable, collées à l’accolade qui ferme ton JSON. Handlebars, lui, lit ces trois accolades comme la fermeture d’une « triple accolade » {{{ }}}, et se plaint (got 'CLOSE_UNESCAPED').
Il suffit de ne pas les coller. Plutôt que :
{"puissance": {{1.0.else.0.0.value}}}
écris :
{
"puissance": {{1.0.else.0.0.value}}
}
(une simple espace avant l’accolade finale suffit aussi : {"puissance": {{1.0.else.0.0.value}} }). Attention, mettre l’espace à l’intérieur de la variable ne change rien : {{ 1.0.else.0.0.value }}} plante pareil, c’est bien juste après les }} qu’il faut de l’air.
2. Pour le format numérique : surtout pas de guillemets autour de la variable.
Gladys parse le body en JSON avant de l’envoyer, donc :
"puissance": "{{ma_variable}}"→ envoie"22.5", une chaîne
"puissance": {{ma_variable}}→ envoie22.5, un vrai nombre
3. Et oui, le calcul renvoie bien un nombre, mais pas forcément un entier : si ta valeur d’origine est 20.5, {{ma_variable}} + 2 te donne 22.5. Si ton API attend un entier, tu peux arrondir directement dans l’onglet « Calculée » :
round({{ma_variable}} + 2)→23round({{ma_variable}} + 2, 2)→ deux décimales
Bonsoir @pierre-gilles,
Sujet à présent clos, et bouton multimédia à présent pleinement fonctionnel pour la radio et la musique, merci pour ta patience et ton écoute 