Page tree
Skip to end of metadata
Go to start of metadata

This section consists of the following:

Architecture of a Custom Driver

The architecture of a custom driver is a shown below.

Module Code Modifications

You will need to interface your custom protocol with the framework by adding code for the device actions in this section.

Create Action and Device Type Parsing

To use your own set of validations for createAction, such as validation of a UNID, detecting a duplicate create request and so on, modify create_action.js: createActionValidator() (line 46).

To create interface blocks by parsing CSV files, modify create_action.js: createActionCompletor()  (line 118).

Provision Action and Publish Interface Blocks

Currently, the driver framework picks up interface blocks from literals.js and publishes it to the feedback channel when the device is created. To modify this behavior, you will have to change the interface blocks created by device type parsing and then publish those provision_action.js: provisionActionExecutor() (line 135).

Deprovision Action

To check if the device is provisioned before deprovisioning, modify deprovision_action.js: deprovisionActionValidator() (line 42).

To stop polling or deprovision the physical device modify deprovision_action.js: deprovisionActionExecutor() (line 73).

Update Action

update_action.js: updateActionCompletor() (line 38) merges an update request with the existing config object and publishes the feedback object, after which you can choose to check the monitoring object and value control requests.

Update Action by Deep Topic Assignments

Deep topic assignments are those made from a device's interface, such as changes to a datapoint's monitor rate.

handle_interface_objects.js: handleDeepTopicAssignments() (line 312) handles assignments on interface objects like monitoring requests, or value setting request. 

Replace Action

To validate if the device exists for replacement, or if the UNID provided for replacement is not already in use, check replace_action.js: replaceActionValidator() (line 40).

To store the replaced UNID, use replace_action.js: replaceActionExecutor() (line 93).

To publish the replaced UNID in cfg and sts objects, use replace_action.js: replaceActionCompletor() (line 115).

Delete Action

delete_action.js: deleteActionValidator() (line 35) validates if a device exists before deleting the device. You can add any more custom checks required before deleting a device.

Load Action

To handle load requests modify load.js: handleLoadResponse() (line 77).

Test Action

To test a device, modify test_action.js: testActionExecutor() (line 70).

Datapoint Connections

To check if the device exists to create a datapoint connection, modify connection.js: handleProvisionConnectionRequest() (line 317).

To handle updates from sources in the connections, modify connection.js: handleMessagesFromSource() (line 269).

Monitor Datapoints

If you want to get data from the physical device and publish it to the monitoring service, modify monitor.js: setMonitoringRateForDatapoint() (line 33) in setInterval() (line 51).

Set Datapoint Value

To set a value in the physical device modify value_control.js: handleValueRequest() (line 86).

Datapoint Get

To get a value of a datapoint from a physical device modify get.js: handleDatapointGetRequests() (line 40).

  • No labels