Most calculation blocks have one main input which is called Value. This is the value on which the block performs its main calculation.

Blocks may have a number of similar inputs, which may be labeled Value 1, Value 2, and so on. You can find such inputs with the Difference block (see also the example in Value types) or with the AND and OR logic blocks. Typically, there is nothing significant as to which input is used.

Blocks that maintain some internal state may also have a Reset input, which is typically a pulse type. This does not have to be connected, but can be used to explicitly control on which range of readings a block should perform a calculation. For example, a model that monitors vehicle journeys may reset on the engine starting, which signifies the beginning of a journey. See also Value types for an example that illustrates the Reset input.

Blocks typically re-calculate their output when a new input is received. Some blocks may also generate output at some point after receiving an input, either because of time delay parameters set (for example, with the Missing Data or Time Delay blocks), or because their output may change over time even if the input value is constant. For example, the Integral block with a positive input generates an ever-increasing output until its window is full (or indefinitely if no duration has been set, when the block is calculating the integral over an unbounded window).

As with real-world sensors, it is not practical to create a continuously changing output. As well as generating an output if their input value changes, such blocks may also have a Sample input which triggers the block to re-evaluate and generate a new output, even if the input has not received any new value and the output has not changed by a significant amount. This is useful if there is a specific point in time when the output of the block should be calculated, as its output is going to be used at a later point in the model.

Alternatively, such blocks may have an Output Threshold parameter, which is used to control how frequently the output is re-calculated. When set, the block determines when its output will change by the output threshold, and when that occurs, even if it is not as a result of any new input value, the block generates an output value.

The Output Threshold should be set taking into account what error margins will exist on the input value (real-world physical sensors have some limited precision and accuracy in the property they are measuring), and what precision is required in the output.

Take care to avoid Output Threshold values that are too large or too small. If the values are too large, the block does not generate a new output when needed (unless the Sample input is used). If the values are too small, the block limits how frequently it generates output. If you want to change the values, send a POST request to Cumulocity IoT that changes the value for the minimum_wait_time_secs key. See Configuration for detailed information.

The scale of appropriate values varies depending on what the magnitude of the input value is. If Output Threshold is not set, then the block only generates new outputs if it receives an input (this may be appropriate if it is receiving frequent inputs on the value, or if the Sample input is being used).

For some inputs, the block by default uses the source timestamp available on the input (for example, for a Cumulocity IoT measurement, event or alarm). The block reorders the input based on the timestamp (see also Input blocks and event timing), but drops events that are delayed by too much. If this behavior is not desirable (for example, if a device's clock is not well synchronized, or if data from a device may be delayed), then you can disable this behavior by selecting the Ignore Timestamp parameter. If this is selected, the timestamp of the data is ignored, and the model processes the input data as soon as it is received, regardless of what timestamp it has. This may give different results compared to the default behavior of using timestamps. The behavior which is most desirable will depend on the nature of the device and its connectivity to Cumulocity IoT.

Note that when a model is running in simulation mode, the setting of the Ignore Timestamp parameter is ignored. The block will always use the source timestamp, so that when replaying simulation events, the data is guaranteed to be processed in order and this will yield more realistic results (and there is no record of when the data was received, only the source timestamp). See also About simulation mode.