SUPPORTED_PLUGIN_NAMES

The base class of the adapter. Project adapters should extend this class.

The base bridge module creates a bridge by automatically binding the K4Model to your adapter class. The adapter directory is passed into the adapter opts as a relative path.

The directory structure should be as follows:

      - index.js
      |- commands
         - switchMultilevelOn.js
         - switchMultilevelOff.js
      |- responses
         - switchMultilevelReport.js
      - mapping.json

The Adapter Mapping file in mapping.json should look like the following (possibly more complex than this)

{
      "com.k4connect.zwave.dimmer": {
          "commands": {
              "on": "SwitchMultilevelOn",
              "off": "SwitchMultilevelOff"
          },
          "variables": {
              "level": "switchMultilevelReport"
          }
      }
}

Command Flow

When a command is executed on the K4Model, it is processed through the module using this flow:

• Call the Base Bridge K4Model execute() handler
• Use the K4Model path to identify the matching Device instance on the bridge
• If a Device instance exists, use its Mapping definition to create the appropriate Command instance
• Once a Command instance is created, the Core Bridge Class sets the Command instance args object, Device, and Adapter references
• The Adapter getAddress() method is called to get the destination device address (if applicable) for the transport
• The Command is passed to the Adapter send() method. The command.buildBody() should be called to generate the data buffer
• (if applicable): The Command is registered with the Sequencer plugin or is added to the Queue. See next() or add(), respectively.
• The Core Bridge send() method is called by the main Adapter logic or via the Queue plugin, depending on what the Bridge is configured for.
• The Core Bridge send() method hands over the Command to the Transport.
• The Transport sends the Command data buffer to the destination

Response Flow

When data is received from the transport, it is processed through the module using this flow:

• The Queue is given first attempt to handle the data (if applicable)
  • Queue checks the data for a termination (success or error) string. If waiting on more data, stores the current data without calling any handler. If neither of those is true, the queue will not handle the data.
  • If the data has the termination string, and a handler exists for it, the handler callback function is called.
• The Sequencer is given second attempt to handle the data (if applicable)
  • Sequencer calls adapter getSequence() to retrieve a sequence id from the data. If null is returned, the sequencer will not handle the data.
  • If a sequence id is returned, and a handler is registered for that sequence id, that specific handler callback function is called (and cleared).
• If neither the queue nor the sequencer can handle the data, each Response class is called with fromData()
  • The Response fromData() method should return null if it cannot handle the data, or return an instance of itself if it can.
  • The Adapter getId() method is called to retrieve the device id of the data
  • The Response instance address and device references are set.
  • The Response instance init() method is called, which parses the data and marshals it into a friendlier format (but of flexible type).
• Response is passed to the appropriate Device instance
  • The Response value() method is called to obtain the marshaled, parsed Response data.
  • The Device instance emits an event to listeners (if any exist) that a Response has been received. The emitted event name is received--${response.name}, where the `response.name` refers to the Response instance name getter
  • The Device instance looks up within its mapping to update any relevant K4Model variables or to fire any matching K4Model events