Hallo @jean_bruder 
Tatsächlich ist es nicht möglich, das zu tun, was du tust; du musst die Berechnung und das Senden des JSON aufteilen.
Hallo @pierre-gilles
Ich weiß nicht, wie ich deine Antwort auf meine Szene anwenden soll: Der berechnete Wert, der per HTTP/POST zurückgegeben werden soll, stammt aus einer Operation an einem per HTTP/GET empfangenen Wert, zu dem ein Wert addiert/subtrahiert wird, und muss im numerischen Format vorliegen. Wie verwende ich den berechneten Wert eines Geräts?
Danke dir,
Jean
Du kannst ein virtuelles Gerät (MQTT-Integration) verwenden, das als „Puffer“ für den Endwert dient, den du anschließend per HTTP sendest.
Guten Abend @pierre-gilles
Ich nutze die aktuelle gute Stimmung im Forum und aller Entwickler, die nicht aufhören zu innovieren, um alte Anfragen auszugraben, die ich nicht zu Ende geführt habe … 
Glaubst du, dass es immer noch unmöglich ist, eine Berechnung auf einen gesendeten Wert anzuwenden, denn das könnte wirklich viele Anwendungsfälle vereinfachen: Man könnte eine GET-Anfrage durchführen und dann eine POST als interaktive Reaktion
Bis bald,
Schönen Abend,
Jean
Hallo @jean_bruder
Also, ich werde dir anders antworten, als du es erwartest: Ich denke nicht, dass man die Berechnung in den Block „HTTP-Anfrage“ einfügen sollte, denn alles, was du beschreibst, ist heute schon möglich
Zuerst zum „Warum nicht“: Der Body einer HTTP-Anfrage ist freier Text. Es kann JSON, XML, form-urlencoded oder irgendetwas anderes sein. Wenn wir damit beginnen würden, Berechnungen darin auszuwerten, müsste Gladys erraten, welcher Teil des Textes eine Formel ist und welcher Teil der Inhalt ist, der unverändert gesendet werden soll, mit dem Risiko, dabei perfekt gültige Bodies zu beschädigen. Das würde bedeuten, eine spezielle Syntax zu erfinden, sie zu dokumentieren, sie zu warten… während das Trennen von „ich berechne“ und „ich sende“ klarer bleibt und dir zusätzlich ermöglicht, den berechneten Wert anderswo in der Szene wiederzuverwenden.
Und vor allem: Das GET, dann Berechnung, dann POST kannst du schon machen, ohne neue Funktionalität.
Was in deiner Szene letztes Jahr fehlte, ist einfach, dass die Antwort einer HTTP-Anfrage als Szenenvariable exponiert wird. Du machst dein GET, klickst einmal auf „Ausprobieren“, damit Gladys die Schlüssel der Antwort entdeckt, und kannst sie dann mit {{ in alle folgenden Blöcke injizieren, einschließlich in einen zweiten HTTP-Aufruf. Konkret:
data.temperature{{ data.temperature }} + 2{{Es funktioniert und hat sogar einen angenehmen Nebeneffekt: Dein berechneter Wert wird zu einem echten Sensor mit Historie und Diagrammen.
Aber ich verstehe dich, das Puffergerät ist etwas umständlich, wenn der Wert nicht historisiert werden soll.
Deshalb gute Nachricht: Eine neue Aktion „Variable definieren“ kommt
https://github.com/GladysAssistant/Gladys/pull/2863
Sie ermöglicht es dir, einen Wert einmal zu setzen, entweder Text oder eine Berechnung (Registerkarte „Berechnet“, z. B. {{ data.temperature }} + 2), ihm einen Namen zu geben und ihn in allen folgenden Aktionen der Szene wiederzuverwenden. Keine Notwendigkeit mehr, ein permanentes MQTT-Gerät zu erstellen, keine Notwendigkeit des Blocks „Letzten Zustand abrufen“. Deine Szene wird:
{{ data.temperature }} + 2{{ zum Injizieren deiner Variable in den BodyDrei Blöcke, jeder mit einer klaren Rolle, und die Berechnung bleibt im dafür vorgesehenen Block. Das ist genau dein Anwendungsfall
@pierre-gilles Danke, danke, danke, danke 
Guten Abend @pierre-gilles,
Keine Eile mit der Antwort
Ich habe eine Frage zum Berechnungsvorgang und dem Ergebnis: Gibt der Berechnungsvorgang tatsächlich einen numerischen Ganzzahlwert zurück?
Denn im Log habe ich diesen Fehler:
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)
Zusätzlich scheint bei meinem HTTP-Aufruf etwas nicht zu stimmen, denn das Format scheint nicht korrekt zu sein: Es muss numerisch sein.
Vielen Dank für dein Feedback dazu,
Schönen Abend noch,
Jean
Hallo @jean_bruder 
Gute Nachricht: Deine Berechnung hat nichts mit dem Fehler zu tun 
1. Der Fehler im Log kommt vom Body deiner HTTP-Anfrage, nicht von der Berechnung.
Schau dir das Ende der Zeile an: {{1.0.else.0.0.value}}} — es gibt drei } hintereinander. Die beiden geschweiften Klammern schließen deine Variable, und die dritte schließt dein JSON. Handlebars liest diese drei geschweiften Klammern als das Schließen einer « dreifachen geschweiften Klammer » {{{ }}} und beschwert sich (got 'CLOSE_UNESCAPED').
Es reicht, sie nicht zusammenzusetzen. Statt:
{"puissance": {{1.0.else.0.0.value}}}
schreibe:
{
"puissance": {{1.0.else.0.0.value}}
}
(Ein einfacher Leerraum vor der abschließenden geschweiften Klammer reicht auch: {"puissance": {{1.0.else.0.0.value}} }). Achte darauf, dass der Leerraum außerhalb der Variable nichts ändert: {{ 1.0.else.0.0.value }}} stürzt genauso ab, es muss direkt nach den }} ein Leerraum sein.
2. Für das numerische Format: Auf keinen Fall Anführungszeichen um die Variable.
Gladys parst den Body in JSON, bevor er gesendet wird, also:
"puissance": "{{ma_variable}}" → sendet "22.5", eine Zeichenkette 
"puissance": {{ma_variable}} → sendet 22.5, eine echte Zahl 
3. Ja, die Berechnung gibt eine Zahl zurück, aber nicht unbedingt eine ganze Zahl: Wenn dein Ursprungswert 20.5 ist, gibt {{ma_variable}} + 2 22.5 zurück. Wenn deine API eine ganze Zahl erwartet, kannst du direkt im Tab « Berechnet » runden:
round({{ma_variable}} + 2) → 23round({{ma_variable}} + 2, 2) → zwei DezimalstellenGuten Abend @pierre-gilles,
Thema jetzt geschlossen und Multimedia-Button jetzt vollständig funktionsfähig für Radio und Musik. Danke für deine Geduld und dein Zuhören 