SiteWise Rule Actions: Why a SELECT Alias Is Missing from a Substitution Template

An AWS IoT rule can produce a calculated field in its SELECT output while the SiteWise action cannot find that field in a substitution template. The two expressions are evaluated in different contexts. An alias created with AS is not automatically a variable available to the action parameter.

Diagnose this boundary before changing the SiteWise destination or converting the value into another datatype. The examples below use AWS IoT SQL version 2016-03-23, as in the official SiteWise rule configurations. They are partial, synthetic review fixtures, not deployed rules.

Separate the original payload from the SELECT result

Suppose the incoming laboratory telemetry contains:

{"raw_tenths": 120}

A rule expression can calculate an engineering value:

SELECT raw_tenths / 10 AS scaled
FROM 'lab/gateway17/temperature'

The intended arithmetic is 120 divided by 10, producing 12 under the output field name scaled. Seeing that field in a SELECT preview does not prove it exists in the original message.

The SiteWise rule-action guide explicitly warns that substitution templates are evaluated separately from SELECT and cannot reference an alias created by AS. The AWS IoT substitution-template reference gives the same boundary.

Consequently, this action-value fragment refers to the wrong context for the example:

{"doubleValue": "${scaled}"}

The original payload has no scaled field. Do not assign an invented zero or claim that the action successfully stored 12 merely because SELECT produced it. Inspect the actual rule/action outcome in an isolated test.

Evaluate the needed expression in the action field

For this small deterministic conversion, the proposed corrected fragment is:

{"doubleValue": "${raw_tenths / 10}"}

It reads the original numeric input and performs the supported arithmetic directly in the template. This is a fragment of the value object, not the complete iotSiteWise action. An actual action also needs an approved destination, timestamp, quality treatment and role configuration.

Keep the arithmetic definition under one review even if it appears in both a SELECT projection and an action field. Two independently edited copies can drift. If SELECT’s calculated field serves no other required purpose, simplify that projection rather than leaving a misleading alias that appears to drive SiteWise when it does not.

This article concerns AS aliases in a simple SELECT rule. It does not treat every SQL naming mechanism as identical or claim to describe additional language features such as separately declared variables.

Use a conflicting input field to expose the boundary

A stronger fixture deliberately adds a same-named field to the original message:

{"raw_tenths": 120, "scaled": 99}

The SELECT expression still calculates 12. A template referencing ${scaled}, however, addresses the original payload’s 99 in this example, not the newly calculated SELECT alias. A preview-only check could therefore miss a wrong but valid numeric action value.

Use this collision only as synthetic test data. Its purpose is to prove which context supplies the action parameter. The corrected ${raw_tenths / 10} should remain tied to the raw input in both payload variants. These are expected evaluations from the documented rules, not observed service outputs.

Keep three different names in the review record

The SQL alias scaled names a projected output field. The MQTT topic identifies the incoming publication route. A SiteWise property alias identifies a destination data stream. Their use of the word alias or a familiar sensor label does not make them interchangeable.

Record the original payload, SQL version and expression, action substitution text, and destination identity in separate fields. Check numeric representation and missing-input handling against the selected expression contract. A valid destination cannot repair an action expression evaluated against the wrong input context.

Avoid turning this investigation into a timestamp conversion exercise. Preserve valid equipment time in the eventual fixture, but first establish the value-selection boundary with a deliberately minimal payload and partial action snippet.

Qualify the action, not only the SQL preview

Prepare the base payload, the conflicting-field payload, and a missing-raw-input case in an isolated rule. Review the SELECT result and action evaluation separately, then inspect the resulting SiteWise value only when the action has succeeded. Keep failed or missing evaluations distinguishable from a numeric zero.

No rule was created or invoked here. The acceptance evidence should show that the action obtains its value from the intended original field and expression. That closes the specific gap between a convincing SELECT result and a SiteWise parameter that never had access to its alias.