As a user,
I want to be able to know which device/condition triggered a scene,
So I can use it in other actions
Ex:
I have a door opening scene (with the tag alarm ) and when a door opens, I retrieve the state of all the doors and send a message to tell me « look at the state of the doors. »
What I would have liked to do is simply know which door triggered the scene directly (itâs less tedious than fetching everything, etc.)
What do you think?
I agree with you on the need, but with a somewhat more global perspective.
My homeâs intrusion detection scene waits for a door, window, or motion sensor to trigger and then sends me a message.
Except the message is a list of all devices with their value (0 or 1). Thatâs not very user-friendly.
It would be better to display « open / closed » for example in the message. And add a default variable with the data of the device that triggered the scene?
I think this is a separate request
The doors were an example for me ^^
Basically, if a scene triggers I want to identify who triggered the scene.
Imagine,
I have
[quote=« lmilcent, post:2, topic:8534 »]
And
Good evening,
I voted to include this feature
Iâll give an example
I create a scene with all my temperature sensors as triggers if a certain threshold is exceeded.
If this threshold is exceeded then we send a message with the information about the scene trigger as well as the temperature associated with that trigger.
I can retrieve the temperature information with « Retrieve the last state » but I canât get the info about who triggered the scene
Hopefully this feature will arrive soon in Gladys
Iâm bringing this point up
@prohand are you going to go for it?
Youâve been waiting for it for two years ahah
Sorry, I havenât synced the status here, but itâs already developed:
master â claude/gladys-feature-request-clny6j
ouvert 07:14PM - 23 Jul 26 UTC
### Pull Request check-list
To ensure your Pull Request can be accepted as fast⊠as possible, make sure to review and check all of these items:
- [x] If your changes affect the code, did you write the tests?
- [x] Are server tests passing with coverage? (`cd server && npm run coverage`) â Codecov requires **100% coverage on lines changed in this PR** (full scene test suite passing locally: 229 tests, all branches of the new code are exercised)
- [ ] Did Cypress E2E tests pass? (`npm run cypress:run` from repo root, if UI changed)
- [x] Is the linter passing? (`npm run eslint` on both front/server)
- [x] Did you run prettier? (`npm run prettier` on both front/server)
- [x] If you are adding a new feature/service, did you run the integration comparator? (`npm run compare-translations` on front)
- [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community ([forum](https://community.gladysassistant.com/)) for testing before merging. An AMD64 preview image is built automatically for non-draft PRs; for ARM64, comment `/build-arm64` on the PR.
- [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code)
- [ ] If you are adding a new features/services which needs explanation, did you modify the user documentation? See [the GitHub repo](https://github.com/GladysAssistant/v4-website) and the [website](https://gladysassistant.com).
- [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`) so that the demo website is working without a backend? (if needed) See [https://demo.gladysassistant.com](https://demo.gladysassistant.com).
NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.
### Description of change
Implements the community feature request [Avoir la possibilité de récupérer qui a déclenché la scÚne](https://community.gladysassistant.com/t/avoir-la-possibilite-de-recuperer-qui-a-declencher-la-scene/8534).
When a scene is triggered by a device state change (`device.new-state`), scene actions can now use variables identifying the trigger in their texts (send message, SMS, HTTP request, MQTT, ask AIâŠ):
- `{{triggerEvent.device.name}}` â name of the device that triggered the scene
- `{{triggerEvent.deviceFeature.name}}` â name of the device feature
- `{{triggerEvent.last_value}}` â the new value
- `{{triggerEvent.previous_value}}` â the previous value
Example: a single scene with several door sensors as triggers can now send "{{triggerEvent.device.name}} was just opened" instead of requiring one scene per door.
**Server** (`server/lib/scene/scene.checkTrigger.js`): when a `device.new-state` trigger fires, the trigger event injected into the scene scope is enriched with the related device & device feature (name + selector), looked up in RAM through the `stateManager` (no DB query, computed once per event). If the feature is not found in RAM, the event is passed through unchanged.
**Front** (`DeviceFeatureState.jsx`, `TriggerCard.jsx`): the device state trigger now exposes these variables in the scene editor variable picker, following the exact same pattern as the calendar trigger (`setVariablesTrigger`). They automatically appear in every action input using `TextWithVariablesInjected`.
**Translations**: added in English, French and German (`compare-translations` passing).
**Tests**: new end-to-end server test verifying that a scene triggered by a device state change renders the enriched variables in a sent message (`Garage door (Door state) = 1`).
---
đ€ Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01QB1TD1R94bgsRT8qjnM2mv
---
_Generated by [Claude Code](https://claude.ai/code/session_01QB1TD1R94bgsRT8qjnM2mv)_
## Summary by CodeRabbit
* **New Features**
* Added scene variables for the triggering device, feature, current value, and previous value in device state-change actions.
* Added translated labels for these variables in English, French, and German.
* Device state-change variables are displayed consistently without duplicate trigger numbering.
* **Bug Fixes**
* Device state-change events now include relevant device and feature details when scenes run.
* Improved handling when device or feature information is unavailable while preserving event values.
prohand
August 17, 2026, 11:22am
11
Perfect
Thanks @pierre-gilles