Document triggeringGroup and triggeringGroupName in RulesDSL (#2311)

* Document triggeringGroup and triggeringGroupName in RulesDSL

Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>

* variable -> variables

Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>

---------

Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
pull/2324/head
jimtng 2024-06-30 21:26:59 +10:00 committed by GitHub
parent 16f8b62de5
commit 512d2364dc
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 5 additions and 2 deletions

View File

@ -152,7 +152,8 @@ Therefore, if the Rule needs to know what the command was, use the [implicit var
As with Item based event-based triggers discussed above, you can listen for commands, status updates, or status changes on the members of a given Group.
You can also decide whether you want to catch only a specific command/status or any.
All of the [implicit variables]({{base}}/configuration/rules-dsl.html#implicit-variables-inside-the-execution-block) get populated using the Item that caused the event.
The implicit variable `triggeringItem` is populated with the Item that caused the Rule to trigger.
The implicit variables `triggeringItem` and `triggeringItemName` are populated with the Item and the item name that caused the Rule to trigger.
The implicit variables `triggeringGroup` and `triggeringGroupName` are populated with the Group and the group name specified in the trigger, whose member caused the Rule to trigger.
```java
Member of <group> received command [<command>]
@ -195,7 +196,7 @@ When using an item and you want to ignore the date-portion of that item the `tim
System-based triggers are provided as described in the table below:
| Trigger | Description |
|--------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| System started | `System started` is triggered upon openHAB startup. In openHAB version 2, `System started` is also triggered after the rule file containing the System started trigger is modified, or after item(s) are modified in a .items file. |
| System reached start level `<level>` | `System reached start level <level>` is triggered when openHAB reaches a specific start level. A list of possible start levels is available below. Please note that only levels 40 and higher are useful as the rule engine needs to be ready first. |
@ -766,6 +767,8 @@ Besides the implicitly available variables for items and commands/states, rules
- `newState` - implicitly available in every rule that has at least one status update or status change event trigger.
- `triggeringItemName` - implicitly available in every rule that has at least one status update, status change or command event trigger.
- `triggeringItem` - implicitly available in every rule that has a "Member of" trigger.
- `triggeringGroupName` - implicitly available in every rule that has a "Member of" trigger.
- `triggeringGroup` - implicitly available in every rule that has a "Member of" trigger.
- `receivedEvent` - implicitly available in every rule that has a channel-based trigger.
- `triggeringChannel` - implicitly available in every rule that has a channel-based trigger.
- `triggeringThing` - implicitly available in every rule that has a thing-based trigger.