In the « speak to a speaker » scene action, the volume is set in a fixed way. It would be useful to be able to set it with a variable retrieved beforehand.
Use case: making an announcement in a scene at a volume depending on the time of day, to be quieter in the evening and at night.
Therefore, the volume field of this action should be able to be set with a variable in the form of {{ }}.
Perhaps the operation of the ‹ control a device › action, which allows setting a simple or calculated value, could be reused…
Hi everyone!
This topic is now in development .
A PR has been opened to allow a calculated volume (via variable) in the « Talk to a speaker » action:
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.
Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.