You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scenes already have an active flag, but until now it could only be toggled by hand in the scene UI. This PR adds two new scene actions that let a scene turn another scene's active flag on or off:
Enable a scene (scene.enable)
Disable a scene (scene.disable)
This removes the need for the virtual MQTT device workaround people currently use to arm/disarm a scene from another scene.
The use case described on the forum: a scene checks a water tank level every 5 minutes and notifies when it reaches 40%. It should only be armed while the tank is being filled. With these actions, the checking scene can disable itself once it has notified, and a second scene (bound to a dashboard button) re-enables it when a new filling starts.
Details:
New ACTIONS.SCENE.ENABLE / ACTIONS.SCENE.DISABLE constants.
Server handlers persist the flag through scene.update, which already cancels or re-schedules the target scene's triggers, so a disabled scene really stops listening immediately.
A scene is allowed to target itself: that is what makes the "run once, then disarm until re-armed" pattern possible. Contrary to the "Start scene" action, the current scene is therefore kept in the scene selector.
Edge cases: AbortScene('SCENE_NOT_FOUND') when no scene is selected or when the target scene no longer exists (deleted in the meantime); unexpected errors are propagated.
The two actions are also exposed in the MCP scene creation schemas, so the AI assistant can build such scenes.
Front: shared action card component, entry in the action selector, and translations in en, fr and de.
This pull request was produced by an automated run.
Add two new scene actions, scene.enable and scene.disable, that turn the
active flag of another scene on or off. This lets a scene arm or disarm
another one without going through a virtual MQTT device.
A scene is allowed to target itself, so a scene can disarm itself once its job
is done and be re-armed later by another scene.
- new ACTIONS.SCENE.ENABLE / ACTIONS.SCENE.DISABLE constants
- server action handlers persisting the flag through scene.update, which also
cancels or re-schedules the target scene triggers
- AbortScene when no scene is selected or the target scene no longer exists
- MCP scene creation schemas for both actions
- front action card, action selector and en/fr/de translations
@Pierre-Gilles, you've reached your PR review limit, so we couldn't start this review.
Next review available in:33 minutes
Limit details: You’ve used all 8 included reviews currently available under your plan.
You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.51%. Comparing base (a40d19f) to head (c2a2ae0). ⚠️ Report is 20 commits behind head on master.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Looks good to merge. This is a well-scoped additive feature: two new scene actions (scene.enable / scene.disable) that persist the existing active flag through scene.update, so scheduled jobs and MQTT subscriptions are cancelled or re-armed the same way as the scene-list toggle.
What I checked:
Constants feed ACTION_LIST, so Joi already accepts the new types; MCP scene.create union and en/fr/de keys are wired.
Self-targeting is correctly kept (unlike scene.start), which is what makes the “run once, then disarm” pattern work.
Missing / deleted target → AbortScene('SCENE_NOT_FOUND'); other errors still propagate from the action.
Disable does not abort an in-flight execution, which matches the current UI toggle (it only stops listening). Remaining actions in the current run still execute — that is the right behavior for “notify, then disarm myself”.
execute() still ignores active, so a disabled scene can still be started by hand / scene.start / dashboard. The notices correctly talk about triggers only.
No new DEVICE_FEATURE_CATEGORIES / TYPES.
Not risk:high (no auth, migration, or host/runtime change). Not needs:human-review: this exposes the existing active flag with the same semantics as the UI switch, from a community request.
Non-blocking notes on the inline comments: a no-op enable/disable still goes through addScene (resets interval / for_duration timers), and the selector does not show which scenes are currently disabled.
…scenes
Address review feedback on the enable/disable a scene actions.
setSceneActive now returns early when the target scene already has the
requested active value. scene.update re-adds the scene to the live store,
which cancels its triggers and schedules them again, so an action keeping a
scene in the state it is already in restarted interval jobs and dropped
pending "for duration" timers on every run. A scene re-armed on a schedule
could therefore never reach its next tick.
The scene selector of the action card also appends a "disabled" suffix to
the scenes which are not active: they are the usual targets of an "Enable a
scene" action and were indistinguishable from the enabled ones.
Autofix-Pass: 1
The reason will be displayed to describe this comment to others. Learn more.
Re-reviewed after c2a2ae0. Both notes from the previous pass are fixed:
setSceneActive now returns early when the in-memory scene already has the requested active value, so a scheduled re-arm no longer resets interval jobs or for_duration timers. Covered by skip + still-update-when-different tests.
The scene selector suffixes currently disabled scenes (Name (disabled)), with en/fr/de via withText.
Looks good to merge. Additive scene.enable / scene.disable actions persist the existing active flag through scene.update (same cancel/re-schedule path as the scene-list toggle). Self-targeting is correctly kept (unlike scene.start) for the “run once, then disarm” pattern. Missing or deleted target still AbortScene('SCENE_NOT_FOUND'). Constants feed ACTION_LIST, so Joi accepts the new types; MCP scene.create union and the front action card are wired. No new DEVICE_FEATURE_CATEGORIES / TYPES.
Not risk:high (no auth, migration, or host/runtime change). Not needs:human-review: this exposes the existing active flag with the same semantics as the UI switch, from a community request.
Sent by Cursor Automation: Automatic PR review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
area:server
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Implements feature request: https://community.gladysassistant.com/t/pouvoir-activer-desactiver-une-scene-depuis-une-autre-scene/10580
Description
Scenes already have an
activeflag, but until now it could only be toggled by hand in the scene UI. This PR adds two new scene actions that let a scene turn another scene'sactiveflag on or off:scene.enable)scene.disable)This removes the need for the virtual MQTT device workaround people currently use to arm/disarm a scene from another scene.
The use case described on the forum: a scene checks a water tank level every 5 minutes and notifies when it reaches 40%. It should only be armed while the tank is being filled. With these actions, the checking scene can disable itself once it has notified, and a second scene (bound to a dashboard button) re-enables it when a new filling starts.
Details:
ACTIONS.SCENE.ENABLE/ACTIONS.SCENE.DISABLEconstants.scene.update, which already cancels or re-schedules the target scene's triggers, so a disabled scene really stops listening immediately.AbortScene('SCENE_NOT_FOUND')when no scene is selected or when the target scene no longer exists (deleted in the meantime); unexpected errors are propagated.en,frandde.This pull request was produced by an automated run.
Forum
Forum: https://community.gladysassistant.com/t/pouvoir-activer-desactiver-une-scene-depuis-une-autre-scene/10580
Checklist
cd server && npm run coverage(Codecov requires 100% coverage on changed lines) and Cypress (npm run cypress:run) if the UI changednpm run eslint,npm run prettier)Generated by Claude Code