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.
In this article, we are going to have a look at two blocks that are rarely used but are really helpful to describe conditional logic: the Selector and Switch blocks from the Flow Manipulation section.
Overview
Both the Selector and the Switch block let you define some kind of if-then logic and bring more dynamic behaviour to your models. They do this very differently, though.
The Selector works like a lookup. The output of the block is always one of the values that you set as parameter. Which parameter is used as output is decided by the input ports. The first input port to receive a boolean true value will cause the correlated parameter to be sent (e.g. Input port 1 = true → Input1 is used).
If no input port is set to “true”, the value specified by No Input is used.
Switch somewhat works the other way: it will send the value given on the input port when the name given in Selected Input matches that of the related parameter. Note that selecting here essentially only works during deployment of an instance - because that is when parameters are determined and set - and won’t change during runtime. We’ll have a look at how this is still useful.
Common Use Cases
Generic lookup with Selector
The logic here is essentially “if this applies, send that as output”.
For example, this model takes the status.maintenance information and a temperature value to send an Event with the current working state of a device:
We assume that “Stopped” is the default state:
If a measurement with a value > 50 °C is received during a maintenance window, the status would still be “Maintenance”. Both input ports would be “true”, but since the maintenance check is on a lower port, it takes precedence.
Switch behaviour per model instance depending on device or context
Switch takes one of its inputs and uses that as output.
In this model we take either a value read from a device (Managed Object) or from a constant value to calculate a derived measurement:
We define a template parameter called “offsetSource” to represent this choice:
It’s best to set this as a fixed list of values, since they need to match the names of the input parameters later:
With this, the configuration would use the template parameter like this:
Although we are not using input3-5, they still need to have a name.
You can now create an instance like so to activate a model for a device and decide where the offset value is coming from on a case-by-case basis:
What to watch out for
Don’t overuse
There are often multiple ways to wire the logic in your model, but some are more efficient and descriptive than others.
If you are working with numeric values and want to map certain ranges to certain values, chances are that you can use the Range Lookup block instead.
Similarly, if you want to use the Selector to output a boolean value, a combination of blocks from the Logic section might also do the job.
The Switch block is best used to control the flow of logic. In cases where you are just looking to use different values per instance, you might use Template Parameters directly. And if you are looking for dynamic behaviour during runtime, the Gate block may let you express your logic more naturally.
Use the correct type
The Switch block just passes its input through to its output. So all input ports must have the same type, and this is also used as the output type.
For the Selector, you can control which type the parameters actually are by choosing the correct Type parameter.
Model Complexity
Switch can be useful for handling multiple cases in a single model. However, if these cases are generally independent of each other, it might be just better to create separate models. This also potentially reduces the performance overhead of blocks that are never used in the individual instances.
On the other hand, using Switches might allow you to collapse multiple models into a single one - which makes it simpler to see generic patterns and reduces the cost of making changes.
Summary
The Switch and Selector blocks are really helpful tools that let you express your logic more naturally and can replace complex if-then-else Gate logic in certain situations.
Want to read more? Check out other articles of this series Blocks Explained!