SiteWise Calibration Attributes: Explain Why a Coefficient Change Does Not Refresh a Transform

A calibration coefficient can change successfully in AWS IoT SiteWise while the latest transformed measurement remains unchanged. That does not necessarily mean the formula cached the wrong coefficient. First ask whether an input event occurred that should trigger a new transform result.

A transform using one raw measurement and one coefficient attribute has two distinct change paths. The coefficient supplies a parameter; a new non-attribute input supplies the computation trigger. Treating both changes as equivalent leads to misleading refresh expectations.

State the formula and identify each input type

For an invented laboratory signal, define scaled = raw * gain. The raw property is a measurement and gain is an attribute. Use simple units for this exercise and assume the coefficient is already approved for this fictitious signal. No physical calibration or metrology accuracy is implied.

The SiteWise transform documentation requires at least one non-attribute input and explicitly states that changing an attribute does not launch a transform update. A new data point on a non-attribute input does. The attribute guide describes attributes as generally static asset information, with model defaults that assets can override.

Record the actual property identities and types, not only their displayed names. A coefficient called Gain can be modeled differently in another application, and a model default is not proof of an asset’s effective overridden value.

Walk through the quiet interval

Use a strictly chronological synthetic sequence, with the attribute change established before the next measurement arrives:

t =  0: gain is 0.10; a new raw measurement is 100
         expected transformed value: 10

t = 10: gain changes to 0.12; no new raw measurement arrives
         no transform computation is triggered by this change alone

t = 20: a newly acquired raw measurement is again 100
         expected transformed value: 12

The two raw readings have the same numeric value but are separate observations. Their timestamps describe two actual acquisition events in the proposed fixture. The second is not an old reading given a newer time merely to force a refresh.

Between t = 10 and t = 20, a consumer can see the new gain alongside the previous transformed result. That combination is explainable: the displayed result belongs to the earlier measurement computation. The consumer should retain the result’s observation context instead of assuming every displayed field was recomputed together.

The numbers 10 and 12 are arithmetic expectations, not service outputs observed during a test. Any practical qualification must inspect the actual stored result and its timestamp after the corresponding input has been processed.

Separate a current display requirement from calibration history

Ask what the product actually wants after the coefficient changes. One requirement is “use the new gain on subsequent measurements.” Another is “immediately display the old raw reading evaluated under the new gain.” A third is “recompute historical measurements under a corrected calibration.” These are different outputs.

The attribute change alone does not satisfy the latter two requirements through this transform trigger. A user interface could deliberately calculate a preview, but it must label that preview as a reinterpretation of an earlier reading, not a newly measured value. Historical correction needs its own approved data-processing and provenance design.

If calibration must be effective according to acquisition time, write down that rule explicitly. This single-attribute walkthrough does not establish correct treatment of delayed or replayed readings crossing the coefficient-change boundary. Retain the raw data and a calibration-change record so that such a requirement can be implemented and verified deliberately.

Do not change physical measurement timestamps to make a result appear fresh. That conceals the distinction the integration needs to preserve.

Qualify the trigger without changing several variables

Start with one measurement input, one coefficient attribute, known good data and an isolated asset. Verify the initial result, then change only the attribute and observe that this alone does not create the expected new computation. Finally, provide a genuinely new synthetic measurement event and compare the arithmetic result.

Capture the asset and property identifiers, effective gain, raw value and timestamp, and derived value and timestamp at each stage. Check that the intended asset received the coefficient change before investigating transform behavior. A change to the wrong asset can resemble a trigger problem but has a different cause.

Adding another measurement input changes the event model: SiteWise documents independent triggering by non-attribute inputs using available values. That is outside this deliberately single-measurement fixture and should not be introduced merely as a refresh workaround.

No asset update or SiteWise computation was executed here. Acceptance is a clearly explained sequence connecting coefficient ownership, triggering measurement and derived result, with any immediate-preview or historical-correction requirement stated separately.