Updated Event
- Nina Cardillo
The updated event object is published on this topic: glp/0/{SID}/ev/updated/dev/{Protocol}/type/{Application_Type}
Where:
| SID | is the segment identifier. |
| Protocol | is the protocol identifier, such as lon, cm, modbus, etc. |
| Application_Type | is the application type as reported with the device’s status object. |
The updated event object has the following syntax:
| { handle: Handle block: BPATH, datapoint: DPATH, value: V } |
Parameter | Description |
|---|---|
| Handle | The device handle used with the IAP/MQ topic. |
| BPATH | The path to the interface object within the device, such as “if/Light/2”. |
| DPATH | The path to the datapoint object within the block, such as “nvoLuxLevel”. |
| V | The value of the datapoint object’s value property. |
The updated event occurs whenever a value update is processed, regardless of its source. A datapoint that is being monitored with periodic polling triggers periodic updated events, as will an assignment of a new datapoint value through IAP/MQ.
The event is unfiltered and fires even when the value does not change compared to the previous one. Monitoring options such as throttle or threshold have no effect on this event.
Example
For example, the following datapoint value assignment yields an updated event shown.
Datapoint Update: 58 → glp/0/SID/rq/dev/lon/nc.0/if/LightSensor/0/nciLowLightAlarm/value
{ |
The updated event may be limited to applicable device instances. An applicable device instance is one where the app might supply an application algorithm. Such an app depends on the updated event to receive and respond to updated input datapoint values without using any datapoint monitoring methods.
Remote edge devices supply built-in processing with built-in application code. Protocol engines cannot raise the updated event for such a device instance.
Apps that require datapoint value change notifications for datapoints hosted by remote edge devices, use datapoint monitoring methods. discussed in Datapoint Objects and Interface Blocks.