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).
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.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.
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.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.
To handle load requests modify load.js: handleLoadResponse() (line 77).
To test a device, modify test_action.js: testActionExecutor() (line 70).
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).
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).
To get a value of a datapoint from a physical device modify get.js: handleDatapointGetRequests() (line 40).