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 PropertyChanged, DeviceOnline, or UploadRequestEvent events.
The following code snippets provide examples of the above mentioned event types within a device event trigger:
PropertyChanged event:
{"deviceId"="com.bosch.iot.dm:devices:Thermometer","featureId"="TemperatureSensor","category"="status","propertyId"="temperature","value"=10}DeviceOnline event:
{"deviceId"="com.bosch.iot.dm:devices:Thermometer"}UploadRequestEvent event:
{"correlationId"="363645645264","options": {"validity.sec":"1800","storage.providers":"aws","metadata.description":"15_oct_2021_data","tag.groups":"daily_data"}}
When adding a device event trigger you can view the expected event structure from the Manager UI by using the Event Fields Metadata button as shown below:
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") == nullThrough Groovy we may also check the time of day and based on that decide whether to intervene or not.