Logic Block Scripting
Documentation of logic block scripting concepts
For general scripting concepts refer to this page: Scripting
Rule logic script
The Rule logic script defines the custom logic that is evaluated during rule runs.
Once a Custom Logic Block is saved, it can be selected as a logic block when creating a rule. Inputs need to be linked to an input device or tag and parameters need to be set.
Further, one or more actions need to be defined. The templating syntax can be used to access the results of a Custom Logic Block {{result.*}}. For example, {{result.message}} for the script shown above.
Custom logic timer
There is also the possibility to emit a timer inside the custom logic block.
When emitting the timer event, two params can be specified
runAt
required, a date which needs to be at least 15 seconds in the futuremeta
optional, object which can contain any values
The meta object will be available when the rule is triggered by that timer and can be accessed at timer.meta
during script run. This can provide useful information for the next timed run or help uniquely identify timers when running them.
Refer to Stateful Operations for more information on how to share data between runs of a rule.
Event Object
The Custom Logic Block script is invoked with the event object as param. It contains the following properties & strucutre:
inputs
object, contains the values of the specified variablesstate
object, contains the user defined rule statetype
string, indicates how the rule was invoked (eithertimer
oruplink
)dataSources
object, see data source propertiesdevice
object, see device propertiesproperties
object, contains the user defined properties of the custom logic block
Note: if type
has the value of timer
certain properties will behave differently:
the variable values of the
inputs
object will be nulldataSources
will be an empty objectdevice
will be undefined
Device Properties
The following properties of a device can be accessed when using template syntax.
Note: The prefix device.
is always required in order to access sub properties.
name
the device namedescription
the device descriptionintegrationId
the integrationId of the device (only for LoRaWAN devices)workspaceId
the workspaceId of the devicedataFlowId
the data flow id of the deviceconnectivity
the connectivity of the deviceid
the akenza device iddeviceId
the unique device id
Data Source Properties
The following properties of a data source can be accessed when using template syntax.
To access a specific data source, use dataSources.X
where X
is the number of the data source as specified in the rule (starting at 1).
Some properties can be null in certain circumstances (e.g. the correlationId
or the device
) if e.g. the rule was triggered by a timer event or the data source is set to access the last sample.
Note: The prefix dataSources.X.
is always required in order to access sub properties.
correlationId
the correlation id of the data source (only available if the data source was triggering the flow)device
the complete device object. See Device Properties for sub propertiesdeviceId
the unique device idakenzaDeviceId
the akenza device idtopic
the topic of the sampletimestamp
the timestamp of the sampledata.*
access any values of the sample.meta.*
access any values of the meta objectuplinkMeta
the complete uplink meta objecttrigger
boolean, indicates whether the data source has triggered the uplinkdeviceInput
boolean, indicates if the data source is a devicetagInput
boolean, indicates if the data source is a tag
The values related to the sample (namely correlationId
, topic
, timestamp
, data
, meta
and uplinkMeta
) are resolved based on which data source triggered the rule evalution. If the data source is triggering (trigger = true
) the rule, the values will be the one from the triggering uplink. Otherwise the values will correlate the most recent stored sample.
Uplink Meta Properties
The following properties of uplink meta data can be accessed when using template syntax
Note: The prefix uplinkMeta.
is always required in order to access sub properties.
dataReceived
the ISO-8601 timestamp when the data was recievedbytesReceived
the number of bytes received in the uplink requestprocessingStart
the ISO-8601 timestamp when the processing was startedscriptRunUplinkStart
the ISO-8601 timestamp when script run was startedscriptRunUplinkEnd
the ISO-8601 timestamp when script run endedprocessingEnd
the ISO-8601 timestamp when the processing endedoutputProduced
the ISO-8601 timestamp when all output were produceduplinkDuration
the ISO-8601 duration of the whole uplink flowprocessingDuration
the IOS-8601 duration of the processingscriptRunningDuration
the ISO-8601 duration of the script run
Emitting actions
If a condition is met, an action has to be emitted that will invoke the consecutive rule actions.
Re-invoking the rule engine
It is possible to re-invoke the rule engine by enabling the setting in the rule action. This is useful, to apply another rule to the output of a custom logic block.
Note that the emit action is expected to have a specific format (same structure as the sample output in device type scripts), see Emit Function for details. This means that properties like topic
, timestamp (optional)
and data
should be provided and will be processed in subsequent rules.
If the topic
is specified in the emit action, it will override the one specified in the custom akenza db rule action.
Rule Action - Custom Payload
When using a custom payload template in the rule action, make sure to use {{result.*}}
to access data that has been emitted as part of the rule action. For example, to store the result of a rule action that has been used to re-invoke the rule engine, use {{result.data}}
. Otherwise the whole result object will be stored as a sample meaning topic
, timestamp
, data
and meta
(if specified) will be contained in the data object.
Emitting a timer
By emitting a timer, you can schedule a rule to run be invoked again in the future.
meta
can then be accessed using event.timer.meta
.
Event examples
Logic Block uplink event
A decoded uplink that triggers a custom logic block, looks as follows. Note that the state is controlled by the script author (see Stateful Operations):
Logic Block timer event
A time-based event that triggers a custom logic block, looks as follows. Note that the state is controlled by the script author (see Stateful Operations):
Logic Block last sample timer event
A time-based event that triggers a custom logic block, looks as follows.
Note that the state is controlled by the script author (see Stateful Operations):
Last updated