---
alias: user-guide-automation-protocol-protocols-index
tags:
- connect iot
description: "Documentation details available communication drivers and their associated settings for integration"
---

# Communication Drivers

Each of the available communication drivers is documented within its own entry.

* [BLE (Bluetooth Low Energy)](driver_ble.md)
* [CSV](driver_csv.md)
* [Database](driver_database.md)
* [Factory Automation](driver_factoryautomation.md)
* [File Raw](driver_fileraw.md)
* [Fuji Nexim](driver_fujinexim.md)
* [IPC-CFX](driver_ipccfx.md)
* [Kafka](driver_kafka.md)
* [Keyboard Wedge](driver_keyboardwedge.md)
* [MQTT](driver_mqtt.md)
* [OIB](driver_oib.md)
* [OPC DA](driver_opcda.md)
* [OPC UA](driver_opcua.md)
* [PanaCIM](driver_panacim.md)
* [Rest Client](driver_restclient.md)
* [Rest Server](driver_restserver.md)
* [Secs/Gem](driver_secsgem.md)
* [Serial](driver_serial.md)
* [TCP/IP](driver_tcpip.md)

Custom communication drivers can also be developed and used. Please refer the Developers Guide for further information.

## Choosing a Driver

Choose the driver from how the equipment offers its data. The driver definition, the communication parameters, and the equipment tasks of every workflow are written for one protocol, so a change of driver later means building them again. Ask the following questions in order. The first question that applies decides the driver:

| Question | Driver |
|---|---|
| Does the equipment exchange files in a folder? | [File Raw](driver_fileraw.md), whatever the format of the files: read each file with `ReadFile`, and parse the content in the workflow. Use [CSV](driver_csv.md) only when each row must be handled and confirmed before the next one, with `MoreDataRequest`. |
| Is the equipment a GEM tool, with an HSMS port or a serial line? | [Secs/Gem](driver_secsgem.md), also when the tool listens on TCP. HSMS is a protocol of its own, and the TCP/IP driver only cuts text into frames. |
| Does the equipment run an OPC UA server? | [OPC UA](driver_opcua.md). The driver is a client. For an OPC DA server, use [OPC DA](driver_opcda.md). |
| Does the equipment publish to, or read from, an MQTT broker? | [MQTT](driver_mqtt.md). The driver is one client of the broker and does not host a broker. |
| Does the controller call an HTTP API? | [Rest Client](driver_restclient.md). Each command is one request, and connecting sends no request, so an unreachable server shows only as a failed command. |
| Does another system call the controller over HTTP? | [Rest Server](driver_restserver.md). Each event is an endpoint path, and the driver answers each request automatically or waits for the workflow to reply with *Request Reply Command*. When both directions happen, use one connection of each driver. |
| Does a simple device, such as a reader, a scale, or a printer, send text or frames over a TCP socket? | [TCP/IP](driver_tcpip.md). For a serial port, use [Serial](driver_serial.md). |

Table: Questions that choose a driver

When the equipment fits none of the questions, or more than one, such as a GEM tool that also runs an OPC UA server, ask which interface the integration must use rather than guess. GEM collection events carry their data, and OPC UA gives live values.

### What Each Choice Commits You To

The File Raw, CSV, and Rest Server drivers work on entries that the integration chooses: folders, files, and endpoint paths. For the other drivers, collect the identifiers of the equipment before you build anything:

| Driver | What to collect | From |
|---|---|---|
| Secs/Gem | SVIDs, DVIDs, ECIDs, CEIDs and their reports, and remote commands with their parameters and formats | The GEM manual of the tool |
| OPC UA | The NodeIds of the variables and methods, and the object of each method | The server |
| MQTT | The topics, and how each payload is encoded | The publishers |
| TCP/IP | The frame format: delimiter, tokens, and command texts | The manual of the device |
| Rest Client | The endpoints, methods, parameters, and success statuses | The documentation of the API |

Table: Identifiers to collect per driver

A wrong identifier is not refused when you save the driver definition. It shows later as an event that never arrives, a report that the equipment refuses, or a value that is always empty.

Each choice also commits the integration to the following:

* Declare what the equipment exchanges as properties, events, and commands of the driver definition, and reach them with the equipment tasks, such as **On Equipment Event** and **Execute Equipment Command**. **Send Notification to Driver** and **Subscribe In Driver** carry messages between the controller and the driver process, not the addresses of the equipment.
* A direction parameter states the role of the driver, not of the equipment. Secs/Gem `connectionMode` and TCP/IP `mode` are `Active` when the equipment listens and the driver connects, so a tool documented as *HSMS passive* needs an `Active` driver.
* One machine can use several drivers in one controller, such as Secs/Gem for the tool and File Raw for its result files, each with its own driver definition. See [[user-guide-automation-controller-workflow-setup]].

## Available Data Types

The available data types in the system are listed below:

* Boolean
* String
* Decimal
* Integer
* Long
* Object
* Password
* DateTime
* Culture

## Parameters

All communication drivers share settings with the same format/meaning:

Name | Type | Possible Values | Default Value |  Description
--- | --- | --- | --- | ---
setupTimeout | Integer | | 10000 | Max time for the setup flow (milliseconds)
heartbeatInterval | Integer | | 60000 | Interval to trigger an optional heartbeat to validate communication or any other task (milliseconds)
intervalBeforeReconnect | Integer | | 5000 | Time to wait between connection attempt (milliseconds)
connectingTimeout | Integer | | 30000 | Max time for the connection to be established (milliseconds)

Table: Communication driver settings

## Tokens

Some communication driver parameters accept **tokens**: placeholders in the form `${TokenName}`
that the driver substitutes with a runtime value instead of a literal, hardcoded value.

Token support is protocol- and parameter-specific — not every parameter accepts them, and the
set of available tokens depends on the driver and on which parameter is being configured. Where
a parameter supports tokens, its description states so explicitly and lists the tokens it accepts.

Examples:

* The [Factory Automation](driver_factoryautomation.md#protocol-parameters) driver's `queueName`
  parameter accepts `${SystemName}`, replaced with the name of the Critical Manufacturing system.
* The [File Raw](driver_fileraw.md#commands) and [CSV](driver_csv.md#commands) drivers'
  file-manipulation commands accept `${Path}`, `${Archive}`, `${Temp}`, and `${Id}` in their path
  parameters (token names are case-insensitive).
* The [OIB](driver_oib.md#extensions-subscription-name-suffix) driver's `Subscription Name Suffix`
  settings accept `${id}` and `${guid}`.

Separately, the [MQTT](driver_mqtt.md#extended-parameters), [TCP/IP](driver_tcpip.md#extended-parameters),
[Serial](driver_serial.md#extended-parameters), and [Keyboard Wedge](driver_keyboardwedge.md#extended-parameters)
drivers support a `Token` identifier type on properties. This matches incoming message content by
prefix rather than by exact value or regular expression — it is a property-matching mode, not a
value-substitution token. See the "Identifier Type" description on the relevant driver page for details.

## Communication States

All communication drivers follow this state model:

![communicationState][communicationState]

A driver process starts in the `Unknown` state, and its first transition is to `Connecting`, when the controller asks it to connect. `Ready` follows `Disconnected` only when no connection is requested.

## Driver/Controller communication

The communication the Connect IoT components is done using WebSockets. The intention is to allow customization to override one or more components using the programming language of the choice of the customer. The establish communication is described in the following diagram:

```mermaid
sequenceDiagram
    activate Monitor
    Monitor->>Manager: Request Create Driver
    activate Manager
    Monitor->>Manager: Request Create Controller
    Manager->>Driver: Create Process
    activate Driver
    Manager->>Controller: Create Process
    activate Controller
    Driver->>Driver: Create Communication Channel
    Driver->>Monitor: Connect with Monitor
    Controller->>Monitor: Connect with Monitor
    Driver->>Monitor: Notify Communication Channel Details
    Monitor->>Controller: Notify Driver Communication Details
    Controller->>Controller: Prepare Workflows
    Controller->>Driver: Connect with Driver
    Controller-->>Driver: Exchange communication Data
    Driver-->>Controller: Exchange communication Data
    deactivate Driver
    deactivate Controller
    deactivate Manager
    deactivate Monitor
```

[communicationState]: ../images/automation_protocol_communication_states.svg