{CnlNum} cannot be used directly in an event trigger because an event trigger can fire for multiple channels, while a data trigger is bound to one fixed channel. Commission the action by first deciding whether it needs the triggering event's channel identity or a predetermined channel number. That distinction determines whether to retain the event trigger or move channel-specific processing to a data trigger.
Trigger requirement classification
Before anything else, confirm what the downstream action must receive. A request for a “channel number” can mean a fixed configured channel, the channel associated with the current event, or merely a value that identifies the event source. These cases require different trigger designs.
| Required result | Applicable trigger path | Acceptance check |
|---|---|---|
| A known channel fixed during configuration | Data trigger with {CnlNum}
|
Every execution produces the configured channel number |
| The channel associated with whichever event fired | Event trigger using its event-context variables | The generated output distinguishes events from different channels |
| Object, device, channel context, or event description | Event trigger using {EvObj}, {EvDev}, {EvCnl}, or {EvText}
|
The selected value contains the identifier required by the receiver |
- Write down the exact field expected by the receiving script, message, or integration.
- Classify that field as fixed configuration data or dynamic event context.
- Select the trigger type only after making that classification.
Do not move on until an event from two different channels demonstrates whether the required output must change with the event source.
Available variable confirmation
Open the event-trigger configuration and work from the variables actually exposed there. The event trigger provides {EvNum}, {EvTime}, {EvObj}, {EvDev}, {EvCnl}, and {EvText}. The reported event-trigger context does not provide {CnlNum}.
| Variable | Context indicated by its name | Commissioning use |
|---|---|---|
{EvNum} |
Event number | Correlate the generated action with an event |
{EvTime} |
Event time | Check that the action represents the current event |
{EvObj} |
Event object | Test whether object context identifies the required source |
{EvDev} |
Event device | Test whether device context provides sufficient routing |
{EvCnl} |
Event channel context | Evaluate as the first event-trigger candidate for channel-related output |
{EvText} |
Event text | Use when the receiver needs the event description |
{CnlNum} |
Fixed data-trigger channel number | Use only on the data-trigger path described here |
Do not infer the exact representation of {EvCnl} from its name. Put it into a temporary diagnostic output, fire a controlled event, and inspect the rendered value. Continue only if that value matches the receiver's required channel identifier and format.
Event-trigger routing setup
Retain the event trigger when one action must respond to events originating from multiple channels. Its execution context is dynamic: the triggering channel can change from one event to the next. A fixed-channel placeholder such as {CnlNum} therefore cannot be treated as ordinary trigger configuration data on this path.
- Add
{EvNum},{EvTime}, and{EvCnl}to a temporary diagnostic payload. Include{EvObj}and{EvDev}if routing may depend on object or device context. - Generate one controlled event from the first test channel and record the expanded values.
- Generate the same class of event from a second channel and record the expanded values.
- Compare the two payloads. Identify which event variable changes in the form needed by the downstream action.
- Replace the temporary payload with the required production format, using only variables whose rendered values have been confirmed.
This test also separates substitution failure from routing failure. An unchanged literal such as {CnlNum} indicates that the event-trigger context did not expand that token; a populated but unsuitable {EvCnl} value indicates a format or interface mismatch. Do not move on until two source channels produce correctly distinguishable outputs.
Data-trigger alternative
Move the action to a data trigger when the process requires {CnlNum} specifically and the monitored channel can be fixed in the trigger configuration. This works because the data trigger has one configured channel, so the system can resolve that channel number without deriving it from a variable event source.
- Create or select the data trigger associated with the required fixed channel.
- Place
{CnlNum}in the action field that must receive the channel number. - Cause a controlled data change on that channel.
- Confirm that the output contains the expected channel number rather than the literal placeholder.
- If several channels need identical processing, configure the required channel-bound trigger instances and test each channel independently.
The tradeoff is architectural: an event trigger consolidates handling across varying event sources, while a data trigger supplies fixed-channel context. Do not substitute one for the other until the test confirms that its firing condition matches the required operational event.
Failed substitution diagnosis
When the generated action contains the wrong channel information, diagnose the trigger context before changing the receiver.
| Observed result | Likely cause | Corrective action |
|---|---|---|
{CnlNum} remains literal in an event-trigger output |
The token is not available in that trigger context | Use a confirmed event variable or change to a fixed-channel data trigger |
{EvCnl} expands but does not match the required identifier |
The event channel representation differs from the receiver's required channel number | Use confirmed object/device context for routing, transform the confirmed value downstream, or use a data trigger |
| Output identifies the correct source but the action fires at the wrong time | The selected trigger type does not match the required firing condition | Return to the requirement classification and select the trigger by event-versus-data behavior |
| One channel passes and another fails | The design assumes fixed context while processing multiple event sources | Test each source and remove any fixed-channel assumption from the event-trigger path |
Do not treat a manually typed channel number as a dynamic replacement. It may pass a single-channel test while silently mislabeling later events. Proceed only after the output changes correctly when the triggering channel changes.
End-to-end verification
- Trigger a known condition on the first channel and record the event identity, event time, source context, and delivered action.
- Repeat the test from a second channel covered by the same event trigger.
- Confirm that each action is associated with the correct event and that its channel-related field changes as expected.
- For every data-trigger alternative, change only its configured channel and confirm that
{CnlNum}expands to that fixed channel. - Repeat one negative test that must not fire the action. Confirm that trigger selection has not widened the firing condition.
Accept the configuration only when the receiver gets the required identifier, no placeholder remains unexpanded, two event sources remain distinguishable, and each trigger fires only on its intended condition.
Frequently asked questions
Why does {CnlNum} not work in an event trigger?
An event trigger can fire for different channels, whereas {CnlNum} belongs to a data trigger tied to one fixed channel. Use a verified event-context variable or change to a fixed-channel data trigger.
Why does an event trigger need a different channel variable?
The channel is selected by the event at runtime rather than fixed in the trigger configuration. Test {EvCnl} with events from two channels and verify its rendered form before using it for routing.
Why does {EvCnl} need to be tested before use?
Its exact rendered representation must match the identifier expected by the receiving action. Send it in a diagnostic payload and inspect the value produced by a controlled event.
How do I verify the final trigger configuration?
Fire controlled conditions from two channels, confirm the delivered identifiers differ correctly, and check that no token remains literal. Then run a condition that must not trigger and confirm that no action is sent.