The IAP Driver Library (IDL) is a piece of software that implements the interface to IAP/MQ that is common amongst all drivers. It comes in the form of a dynamic library (.SO) that is linked into a driver process. The driver process is called IDI, which stands for IDL Driver Instance.
This section describes how to interface custom protocols with IAP/MQ and how to use IDL API.
IDL Based Drivers
The simplest of the IDI must define at least six routines that it has to register with the IDL in order for the IDL to use them as callback functions when performing IAP/MQ related operations. These six include four routines for device actions (create, provision, deprovision and delete) and two routines for datapoint operations (read and write). These callbacks are registered with the IDL using register-APIs such as IdlDevCreateCallbackSet().
Most of the callbacks, when called by the IDL, must call the corresponding IDL result API to denote to the IDL whether the operation was successful or not, and what was the final result. For example, when the IDL calls the callback DpRead() to read a datapoint, the IDI must call IdlDpReadResult() upon completion of the read operation.
When a device create request is received, the IDL will find the corresponding XIF (interface file), parse it and store the device details and datapoint details in its memory. Polling of its datapoints can only start after the device has been provisioned. Periodic polling can be achieved by configuring the monitoring properties of each datapoint in the device, whereas on-demand polling can be achieved by viewing the datapoints in the CMS Datapoint Browser Widget (DBW). On-demand Datapoint writes can also be done through the DBW, for both the normal priority as well as overrides.
When the user imports a new device type in the Device Type Widget, the loader service loads the XIF file in the
/var/apollo/data/<protocol>/res directory and then restarts the Protocol Engine. The IDL based engine on start-up checks the res directory and publishes AMD (Application Metadata) objects of each XIF present. The CMS then shows the type loaded popup.
The IDL obtains details about the IDI through a JSON object in a conf file. This file must reside on the SSIoT and it’s absolute path must be specified in the IDL init call. The parameters in the conf file describe the IDI instance and how it works.
For more information and a description of the conf file parameters, see Conf File.