Multi-Input Processing

Combine readings from multiple DataStreams before running your analysis. When a JavaScript Analyzer uses several inputs, readings can arrive at different times. Data Assembly settings control how those readings wait and form an input set for the script.

Configure these settings through the Analyzer's dataAssemblyPolicy. This guide follows Stage B of the JavaScript Analyzer example: combine a converted temperature with another existing temperature, then calculate whether both are above 80 °C. It focuses on collecting the inputs; the script and mappings remain in that guide.

How Input Data Is Combined

A multi-input Analyzer needs a reading from every declared input before it can evaluate a complete set:

1. Each input DataStream has its own waiting queue.
2. Readings enter that queue in arrival order.
3. When every input has a queued reading, one reading is selected from the front of each queue.
4. Additional readings remain available for a later set after the selected set is released.

For two temperature streams, the first queued A reading pairs with the first queued B reading. A newer A reading does not replace the older queued one merely because it is closer in time to B.

Arrival order and sample time serve different purposes. Collection uses arrival order; each reading retains its own source timestamp. The resulting set does not guarantee simultaneous sampling or nearest-timestamp matching. In the previous example, the script explicitly chooses the later input timestamp for its output.

The policy applies to Analyzers with two to ten inputs. A single-input Analyzer does not use this multi-input collection step, and its returned dataAssemblyPolicy is null.

Configure the Assembly Policy

Choose the waiting capacity and timeout behavior for your reporting rates:

Field	Meaning	Range / values	Default
queueLimit	Maximum waiting readings per input DataStream, not the combined total.	1 to 100	100
timeoutSeconds	How long the oldest unmatched arrival can wait for a complete set.	1 to 200 seconds	5
onTimeout	How to handle the queued readings when the wait expires.	DropPartial or PublishPartial	DropPartial

If dataAssemblyPolicy is omitted for a multi-input Analyzer, these defaults apply. Get Analyzer returns the effective settings with all defaults resolved.

queueLimit bounds each waiting queue. A full queue does not accept another reading at that time. Select its capacity with the input rates in mind; a faster source can accumulate readings while it waits for a slower source.

To change an existing Analyzer's policy:

1. Read its current input bindings and policy. If the defaults already fit your use case, keep them.

2. Disable the Analyzer before updating it, then use Partially Update Analyzer. The following example sets all three policy fields explicitly:

   PATCH /api/v1/orgs/{orgId}/devices/{deviceId}/analyzers/{analyzerId}
   Content-Type: application/json
   Authorization: Bearer YOUR_ACCESS_TOKEN
   
   {
     "dataAssemblyPolicy": {
       "queueLimit": 100,
       "timeoutSeconds": 5,
       "onTimeout": "DropPartial"
     }
   }

   Use your deployment's API base URL and authorized token, replacing the Org, Device and Analyzer IDs with those for the target Analyzer.

3. GET the saved definition and confirm the three effective values. Re-enable it and check new output readings.

For a new Analyzer, include the same dataAssemblyPolicy object in the Create Analyzer body. The JavaScript example supplies these default values explicitly.

Check the result: The saved definition contains the intended input bindings and effective policy. Successful configuration or enabling alone does not demonstrate that a complete input set has arrived or that the script has produced output.

Handle Timeouts and Incomplete Inputs

The wait is measured from the oldest queued arrival that is still waiting, using its arrival time in WEDA. It is not measured from the device's sample timestamp. More readings from an already available input do not restart that deadline.

• All inputs become available: A complete set can be released for evaluation without waiting for the timeout.
• At least one input is still missing when the wait expires: The configured timeout behavior applies.
• No readings are queued: There is no incomplete set waiting for that deadline.

onTimeout	What happens to the waiting readings	Analyzer result for this incomplete set
DropPartial	Discard all currently queued readings for the incomplete wait.	No evaluation and no output.
PublishPartial	Release one queued reading from each input that currently has one, forming an incomplete set.	The Analyzer skips evaluation because some declared inputs are missing.

Note: PublishPartial does not run a partial calculation

In the current release, a JavaScript Analyzer requires all declared inputs to be present before its script runs. PublishPartial does not make the script run with missing input variables. An incomplete set is skipped, so that set produces no Analyzer output.

A guard inside the script cannot change this missing-input rule, because the script is not evaluated for that set. Use the default DropPartial behavior for this guide's complete two-temperature calculation.

When output is missing, check both sources for new readings and compare their reporting intervals with timeoutSeconds. Changing the timeout does not correct a script error or an output-mapping problem; follow the JavaScript troubleshooting checks for those cases.

Example: Combine Readings That Arrive at Different Times

Assume the Analyzer is enabled, input collection is ready, and timeoutSeconds is 5. A1 and A2 are successive readings from temperature_a; B1 and B2 are successive readings from temperature_b.

The times below illustrate arrival order, not the readings' source timestamps:

Check the result: The first calculation uses A1 and B1, even though A2 arrived more recently. The second uses A2 and B2. Read the Boolean both_abnormal output described in the JavaScript guide, matching its source sample timestamp to the input set. A1/B1 are both above 80 °C; A2/B2 are not. The second result is a published false, not a missing result.

Now consider a separate run with onTimeout: DropPartial, where B does not arrive in time:

Arrival time	Event	Waiting / result
t=0s	A1 arrives.	Wait for B; the deadline is t=5s.
t=1s	A2 arrives.	Both A readings wait; the deadline remains t=5s.
t=5s	B is still missing when the timeout is handled.	Discard A1 and A2. No script evaluation or output for that incomplete wait.
t=6s	B1 arrives.	Wait for a new A reading; the discarded readings are no longer available to pair with it.

These are illustrative sequences. For your device, compare actual arrival behavior, source timestamps, policy settings and output values. Retain the same input IDs, script and output mappings while checking the policy so that a configuration change does not obscure what you are verifying.