Blocks Explained Series
Analytics Builder comes with dozens of built-in blocks for every kind of task. There are input and output blocks, but more importantly, there is a whole zoo of blocks that are meant to build business logic:
- calculations and aggregations,
- logic combinations,
- and blocks that help you define and manipulate the general data flow.
This series tries to guide you through the jungle of blocks by providing helpful descriptions and examples on some of the most commonly used blocks and their typical use cases.
This time, we have a look at the Gate block from the Flow Manipulation section that comes in handy when you need to model some form of condition in your model.
Overview
The Gate block controls whether incoming values are passed to the output based on the gate state (open/closed) and whether or not the block is enabled at all.
While seemingly similar, the Enable and Open ports behave differently. Enable takes a boolean, and as long as that boolean is true, the Input Values are passed through.
If Open is connected, only a pulse on that port will open the Gate. It stays open until it is closed (with a pulse on Close or automatically).
Hence, it acts like a logical valve for streaming data and becomes active only when both conditions are true:
Active = Enabled AND Open
-
When the gate is open and enabled → input values pass through
-
When the gate is closed or disabled → a Null Value is emitted if it is set; otherwise, no output is generated
The possible states of the block depend on the input port connections.
| Port | Condition | Initial State | Behaviour |
|---|---|---|---|
| Enable | Connected | Gate starts disabled | Gate will not pass data until enabled |
| Enable | Not connected | Gate always enabled | Data passes through freely if Gate is open |
| Open | Connected | Gate starts closed | Gate will not pass data until opened |
| Open | Not connected | Gate starts open | Data passes through freely as long as Gate is enabled |
For a lot of scenarios where you are working with a single boolean as input, the Enable port is often the only input port you need.
On the other hand, it can make sense to leave the Enable port totally disconnected and trigger the opening (and closing) via pulses — e.g., when these are two different signals to begin with.
The case where both, the Enable and Open/Close ports are connected, makes the most sense for combining different conditions.
Typically, this is a combination of one general on/off switch (like the device being in Maintenance mode) and a dynamic filter for sending values — like a Measurement reaching certain thresholds.
Null Values
The Gate can work like the name implies: as long as it’s closed (or just not enabled at all), it will block the input value from being sent further down. However, in some scenarios, instead of just sending nothing, you want to send another value to work with in your model logic or to have at least some indication that the gate is closed.
This is what the Null Value and the related Null Value Type parameters are for.
Because it is sent on the Output port, the Null Value must be the same type as the Input Value.
Close Duration Behavior
This parameter allows you to define a duration in seconds after which the Gate will be opened automatically. This only works when the Gate is enabled.
I.e., if Close Duration is NOT set:
Close signal → gate remains closed until Open signal
If Close Duration IS set:
Close signal → gate closes temporarily
After duration → gate opens automatically
Note: If the gate opens automatically and is enabled, the latest input value is emitted.
This automatic opening is useful for implementing some timeouts.
Example Use Cases
1. Gas Safety — AND Gate for Compound Alarm
Scenario
A gas monitor measures concentration in ppm. High gas alone may not require a critical alarm if the ventilation fan is running — the fan handles the hazard automatically. A CRITICAL alarm should only fire when both conditions are true: gas is dangerously high AND the fan is not running (has less than 0.5 RPM). Thus, measurements of PPM need only to be checked if the fan is off.
Model
| Gas ppm | Fan status | Behaviour |
|---|---|---|
| 650 | OFF | Gate OPEN → Alarm raised  |
| 650 | ON | Gate CLOSED → Measurements are not forwarded, no Alarm  |
| 200 | OFF | Gate OPEN but Threshold not crossed → no Alarm |
| 200 | ON | Gate CLOSED, PPM ok → All normal |
You can change the model to just use an actual AND block in this simple example. The benefit of the Gate block here is that it avoids potentially complex checks and calculations that are not needed in the end.
2. Pump Hours Gate — Alert Suppression Window
Scenario
Pump vibration is measured in mm/s. High vibration during business hours (08:00–18:00 Mon–Fri) is actionable — maintenance staff are present. High vibration at 2 AM is not useful to alert on — no one can respond, and it generates Alarm fatigue. The Gate uses a time schedule to OPEN during operational hours and CLOSE outside them.
Model
| Vibration mm/s | Time | Behaviour |
|---|---|---|
| 9.5 | 10:30 Tuesday | Gate OPEN → MAJOR alarm |
| 9.5 | 02:00 Tuesday | Gate CLOSED → logged only  |
| 3.2 | 13:00 Monday | Gate OPEN but Threshold not crossed → All normal |
3. Pump Reboot Window — Ignore Measurements
A pump that is started freshly takes some time to achieve a normal operating state. During that startup, some measurements like pressure or vibration may look off but are actually ok. To avoid any false Alarms or misleading derived Measurements, we suppress the execution of our model for a minute or so.
In this example, we use a Python block to run some code to clean the input signal and generate a new Measurement Output with it. Also, we receive an Event every time the model starts to generate outputs. The “reboot” signal is assumed to come in as another Event input but could also be derived from anything else.
The Close Duration is used to automatically open the Gate after the Reboot signal. We also send a “-1” as Null Value to the Python block to indicate that the Pump currently doesn’t deliver any valid values.
| Vibration mm/s | Pump Reboot Signal | Behaviour |
|---|---|---|
| 9.5 | No Signal Received | Python block generates Measurements and sends an initial c8y_PumpRestarted Event |
| 10.5 | Signal Received | Gate CLOSED → Python block received “-1” and no new Measurement is being generated |
| 10.5 | 60 Seconds after Reboot Signal | Gate OPENS → Measurements are being sent again, c8y_PumpRestart Event is being generated |
What to Watch Out For
Gate Block Submits the Latest Value When It Opens
Once the Gate opens during a model activation, it will also submit the latest Input value it saw. This makes sense if you are thinking in terms of continuous Measurements, but it can lead to a situation where you see a Value that should have been “blocked” — especially when working with ManagedObject, Alarm, Event, or Operation Input Blocks.
Null Value Type Must Match the Input Type
This can be a small issue when you connect the Value port directly to something that produces a pulse Value type output — like, e.g., most of the Input blocks. The Null Value must be either string, float, or boolean. So you might have to re-arrange your blocks a bit to give the Gate one of those primitive types.
Summary
The Gate block is an easy way to add “if-this-then-do-that” logic to your model.
There are often multiple ways to achieve your desired logic — just make sure to understand when your Gate is open and forwards values to avoid wrong or unnecessary output.
For more complex logic, have a look at using things like the Python or the Smart Function block.
Want to read more? Check out other articles of this series Blocks Explained!