Analytics Builder 10.9.0 | Using Analytics Builder for Cumulocity IoT | Details of Values and Blocks | Pulse signals
 
Pulse signals
A pulse is used to signal a point in time or a change of state. Examples of use cases for pulses are:
*A person goes through a gate (for example, at a train station).
*A button is pressed (for example, an emergency stop button).
*A machine goes into a new state (for example, a gateway is reset or powered on).
*A device has made a connection to the network.
In Cumulocity IoT, events, alarms and operations are used as the sources of pulses. See also the following topics in the Cumulocity IoT documentation: Events and Operations in the Concepts guide and Alarms in the Reference guide.
A pulse may be merely a point in time, but it can also convey extra information, for example, the version number of the software or which network node it has connected to. These can be obtained using the Extract Property block. If you are writing your own custom blocks, these are accessible if the input is declared as a Value type, which has a properties field. This can be used with numeric value types as well. See the documentation for the Analytics Builder Block SDK for more information on the Value type.
In contrast to measurement values, the timing and number of pulses is very significant, and even though the only difference between subsequent pulses may be the time they were received, each is still significant (whereas multiple measurements with the same value are of little interest).
In contrast to measurement values, a pulse is only active for a single evaluation of a model, where a model evaluation processes all blocks that have a timer that fires (including input blocks) and any blocks connected to outputs that have changed. While both pulses and boolean measurement values are represented by the boolean type in the EPL of the blocks, their behavior is different:
*If a boolean measurement value is received by a block, it will stick to its value until replaced. For example, if looking at whether temperature sensors 1 and 2 are both over a threshold using an AND block, that value is still true after receiving high measurements.
*If a pulse is received by a block, it is reset after it is evaluated. For example, if an Average (Mean) block is reset by an event, then the reset happens when the event is received. After that, if no further event is received, the block is not reset on future value inputs.
It is still valid and sensible to combine multiple pulses, for example, with an AND block. If two pulses occur at the same point in time, that will be a single evaluation. For example, the Threshold block has a Crossed Threshold output port which is a pulse that is sent only when a continuous value input goes from one side of the threshold value to another. Two sensors on the same device (thus with the same timestamp) may cross thresholds at the same time, so the AND of the output of two such thresholds will only trigger if both inputs cross the threshold with new values of the same timestamp. Note that if one sensor crosses the threshold and then later the other sensor, the blocks below would never give an output from the AND block. They would only do this if the two occurred at the same time.