Device event trigger

Device event triggers automatically fire a rule when a certain event coming from the device is reported to the system, for example a change in the device state or a device becoming online.

Like the other built-in triggers of the system, each device event trigger consists of an event and a condition.

Event

The event itself consists of a topic (event type) and input data (event data). The mass management engine provides metadata of the possible event types and their structure. Thus, there is a well-defined and extensible set of event types to choose from, for instance DeviceOnline, BundleFactoryAdded or PropertyChanged events.
The following code snippet provides an example of the event structure of a PropertyChanged event type within a device event trigger:

{
"deviceId"="com.bosch.iot.dm:devices:Thermometer",
"featureId"="TemperatureSensor",
"category"="status",
"propertyId"="temperature",
"value"=10
}

The event data affects the execution scope of tasks launched by rules with device scope. Generally, the scope of a rule is inherited by all tasks launched by the rule, however:

  • when the event which fires the rule concerns only a specific device, the scope of the task launched by the rule as a result of it is limited to the particular device only (provided that the trigger condition is satisfied)

  • when the event which fires the rule does not concern a specific device, the scope of the task launched by the rule involves all devices in the scope

Condition

There are two types of trigger conditions in Bosch IoT Manager - conditions defined through Groovy scripts and through RQL filters.

Even though the condition syntax in the following examples is different, they would both lead to the same outcome.

RQL condition

RQL conditions are evaluated only by the data included in the event.

An example trigger condition, provided as an RQL filter, that will target only devices, on which the temperature has exceeded 10 degrees Celsius would be:

and(eq(featureId,"TemperatureSensor"),eq(propertyId,"temperature"),gt(value,10)

If we have to compare the two types of conditions, the processing of RQL filters is lighter and more efficient.

Groovy condition

All Groovy conditions contain the following bindings:

  • Target variable, which points to the concrete device

  • Event variable, which contains the event data

In parallel, the same condition, where the temperature has exceeded 10 degrees Celsius, through Groovy would be:

return event.featureId == 'TemepratureSensor' && event.propertyId == 'temeperature' && event.value > 10

Groovy allows you to check information beyond the event data which has arrived, such as information related to the device. As an example, which illustrates the much broader opportunities offered by Groovy conditions we could check whether the device on which the temperature has changed has only a temperature sensor, or incorporates an automatic thermostat ("AutoAdjuster") as well.

If there isn’t such thermostat, we trigger the rule, otherwise we do nothing and rely on the thermostat to do its job.

return target.feature("AutoAdjuster") == null

Through Groovy we may also check the time of day and based on that decide whether to intervene or not.