Dans l’action de scène « parler à une enceinte », le volume est défini de façon fixe. Ce serait utile de pouvoir le définir avec une variable récupérée au préalable.
Le cas d’usage : faire une annonce dans une scène à un volume dépendant de l’heure de la journée, pour être plus discret en soirée et la nuit.
Il faudrait donc que le champ volume de cette action puisse être défini avec une variable sous la forme {{ }}.
Peut-être que le fonctionnement de l’action ‹ contrôler un appareil › qui permet de définir une valeur simple ou calculée pourrait être repris…
Salut tout le monde !
Ce sujet est désormais en cours de développement .
Une PR a été ouverte pour permettre un volume calculé (via variable) dans l’action « Parler à une enceinte » :
master ← claude/play-notification-volume-variable
ouvert 02:24AM - 25 Aug 26 UTC
Implements feature request: https://community.gladysassistant.com/t/utiliser-une… -variable-comme-volume-pour-parler-a-une-enceinte/10692
### Description
The volume of the "Talk on a speaker" (`music.play-notification`) scene action could only be a fixed number. It can now also be a calculated value based on scene variables, so an announcement can be played quieter in the evening or at night, as requested on the forum.
The volume field gets the same **Simple / Computed** toggle already used by the "Control a device" and "Wait" actions:
- Simple: the existing slider, stored in `volume` (unchanged default behaviour).
- Computed: a text field where scene variables can be injected with `{{ }}`, stored in a new optional `evaluate_volume` field.
Server side, `evaluate_volume` is rendered with Handlebars against the scene scope and evaluated with the scene formula engine (the same restricted mathjs instance used by the other actions). The result is rounded and clamped between 0 and 100, since the speaker services expect a percentage, and the scene is aborted with `ACTION_VALUE_NOT_A_NUMBER` if the formula throws or does not return a finite number, instead of sending `NaN` to a speaker.
Backward compatibility: an action storing a plain numeric `volume` keeps behaving exactly as before, and an action without any volume still lets each speaker service apply its own default.
Changes:
- `server/lib/scene/scene.actions.js`: resolve the volume of the play notification action.
- `server/models/scene.js`: accept the new `evaluate_volume` string field.
- `server/services/mcp/lib/sceneSchemas.js`: same field in the MCP scene schema.
- `front/.../actions/PlayNotification.jsx`: Simple/Computed toggle for the volume.
- `front/.../edit-scene/index.js`: `evaluate_volume` added to the attributes whose variable paths are rewritten when action groups move.
- i18n: new strings in `en`, `fr` and `de`.
- `server/test/lib/scene/actions/scene.action.playNotification.test.js`: tests for the no-volume, fixed-volume, calculated, clamped (both bounds) and invalid formula paths.
This PR was produced by an automated run.
## Forum
Forum: https://community.gladysassistant.com/t/utiliser-une-variable-comme-volume-pour-parler-a-une-enceinte/10692
### Checklist
- [ ] 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
What was actually verified in the sandbox: the scene and MCP test suites pass (490 tests), and `c8` reports every changed line of `scene.actions.js` as covered. The full server suite has pre-existing failures unrelated to this change (missing `sqlite3` CLI, network-dependent gateway/AI tests), so the first box is left unticked. Cypress was not run (no browser available), and the new UI was checked with a production front build only, not manually in a browser. `npm run compare-translations` passes.
N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin.