This section consists of the following:
The architecture of a custom driver is a shown below.
You will need to interface your custom protocol with the framework by adding code for the device actions in this section.
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).
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.
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).
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).