Add documentation on triggers yaml#2884
Conversation
📝 WalkthroughWalkthroughUpdates ChangesAutomation trigger documentation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
docs/automations.md (1)
99-100: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winBroaden the usage note.
triggers.yamldescriptions are also consumed by the coreget_triggers_for_targetwebsocket API, so this sentence is too narrow. Update it to mention both frontend and backend consumers. As per path instructions, keep Markdown guidance direct and authoritative.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/automations.md` around lines 99 - 100, The current description of triggers.yaml only mentions frontend usage as an example, but the core get_triggers_for_target websocket API also consumes these descriptions from the backend. Expand the usage note to mention both frontend and backend consumers of the triggers.yaml file, specifically including reference to the get_triggers_for_target websocket API. Keep the language direct and authoritative as per Markdown documentation standards.Source: Path instructions
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@docs/automations.md`:
- Around line 99-100: The current description of triggers.yaml only mentions
frontend usage as an example, but the core get_triggers_for_target websocket API
also consumes these descriptions from the backend. Expand the usage note to
mention both frontend and backend consumers of the triggers.yaml file,
specifically including reference to the get_triggers_for_target websocket API.
Keep the language direct and authoritative as per Markdown documentation
standards.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2573572d-fca1-4ae2-a170-77a822cf1bfb
📒 Files selected for processing (1)
docs/automations.md
abmantis
left a comment
There was a problem hiding this comment.
As you pointed out in #2884 (comment) we should make the python code and the yaml description match, otherwise it becomes confusing for a new contributor to follow.
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
abmantis
left a comment
There was a problem hiding this comment.
Since we should add docs in the future for the new trigger helpers (that handle target + behavior), maybe keep behavior out of this one? Currently it has behavior but not using the standard selector.
You can check the todo integration for an example of a trigger that extends the base Trigger class directly and does not have behavior (but has target).
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/automations.md`:
- Line 96: The `triggers.yaml` usage description under the automations docs is
too narrow and only mentions the frontend; update the wording to reflect that
trigger descriptions are also consumed by core APIs. Edit the sentence in the
automations documentation so it explicitly references both the frontend and core
API usage, and include `get_triggers_for_target` as the example symbol to make
the scope clear.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 26220623-5c41-4f1c-bafb-19b30f4ba558
📒 Files selected for processing (1)
docs/automations.md
|
|
||
| ### Trigger description | ||
|
|
||
| Triggers should have their description in a `triggers.yaml` file. The description specifies the structure of the triggers and is used by the frontend, for example. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Update triggers.yaml usage description to include core API, not just frontend.
Past review feedback noted that triggers.yaml descriptions are also used in core via the get_triggers_for_target websocket API, not only the frontend. The current text "and is used by the frontend, for example" understates the usage. Consider: "The description specifies the structure of the triggers and is used by the frontend and core APIs, such as get_triggers_for_target."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/automations.md` at line 96, The `triggers.yaml` usage description under
the automations docs is too narrow and only mentions the frontend; update the
wording to reflect that trigger descriptions are also consumed by core APIs.
Edit the sentence in the automations documentation so it explicitly references
both the frontend and core API usage, and include `get_triggers_for_target` as
the example symbol to make the scope clear.
Proposed change
Add documentation on triggers yaml
Type of change
Checklist
Additional information
Summary by CodeRabbit
EventTriggerwith a concreteOccupancyClearedTrigger.entity_idand an occupancy-cleared description).occupancy_clearedtrigger targeting a presence binary sensor, including the relevant selector configuration.