Device Drivers
A Device Driver is a special type of plugin that defines how Iotellect Server interacts with certain types of hardware devices. The driver is specified during the creation of a Device account.
Iotellect directly supports many communication and control protocols. Device drivers bundled with Iotellect Server allow you to connect various devices produced by thousands of manufacturers.
However, in some cases, it may be necessary to connect a new device that uses a custom protocol for which Iotellect does not have an out-of-the-box solution. In such cases, it is possible to implement a new device driver in programmatic or low code mode. Another option is to use a "device-side" protocol converter called Iotellect Agent.
Iotellect Device Drivers are written in the Java programming language and are thus platform-independent. Since device drivers are implemented in the form of server plugins, installing a new driver is as easy as copying a single file and restarting the server.
 | Iotellect regularly creates new Iotellect Server device drivers for different types of hardware devices and protocols. Please, check the Iotellect website for the most recent list of available device drivers. |
Standard Device Drivers
The below table lists standard device drivers provided by Iotellect and derived products:
Protocol | Driver | Description |
Communicating with implemented Iotellect Agents using any language/platform (Iotellect BASIC, C/C++, .NET, Java). | ||
Asterisk | Monitoring and management of Asterisk computer-integrated telephony by sending CLI commands and response processing. | |
BACnet | Support for BACnet IP and BACnet MS/TP. Reading/writing device properties. Accessing device services and receiving notifications. | |
CoAP | Web transfer protocol for use with constrained nodes and constrained networks in the Internet of Things. | |
CORBA | Performing CORBA calls via IP network by specifying input parameters and processing any output. | |
CWMP | Managing and monitoring customer-premises equipment (CPE) according to TR-069 specifications. | |
DHCP | DHCP server operability monitoring. | |
DLMS/COSEM | Acquiring spot meter reading values and their history. | |
DNP3 | Full support for DNP3 application layer: read/write, select and operate, direct operating, event handling, etc. | |
DNS | DNS zone contents validation. DNS server operability monitoring. | |
Ethernet/IP | Support for open industrial Ethernet, CIP protocol. | |
FTP | Remote file attributes monitoring. FTP server operability monitoring. | |
GPS/GLONASS Data | Receiving arbitrary reports from any satellite trackers and other M2M devices via TCP or UDP. Business-rule-based command parsing. Out-of-the-box support for different tracker models. | |
HTTP/HTTPS | Exposing web page contents for the system core. Web server operability monitoring. | |
ICMP | Availability monitoring (ping) and route tracing (traceroute). | |
IEC 60870-5-104 | Support for IEC 60870-5-104 protocol, both slave and master modes. | |
IEC 60870-5-104 | Support for IEC 60870-5-104 protocol in server mode. | |
IMAP | IMAP server operability monitoring. | |
IPMI | Monitoring and control of IPMI-enabled servers and network devices. | |
JMS | IBM WebSphere MQ monitoring. | |
JMX | Reading/writing MBean attributes. Executing MBean operations. Receiving MBean notifications. | |
LDAP | Exposing search request results to system core for further processing. Operability monitoring for Active Directory or any LDAP server. | |
LON/LonTalk | LON device network and LNS servers can be interfaced through an OPC server and OPC device driver. Available LON-to-OPC bridges include IPLONGATE, Matrikon OPC Server for Echelon LNS, Matrikon OPC Server for Echelon LonManager, ConneXSoft CXS iLink DA Server for Echelon Smart Server, Gesytec Easylon OPC Server, Newron System NLOPC MIP, and more. | |
LON/LonTalk | Echelon SmartServer and the hardware behind it can be interfaced through the SOAP (Web Service) API and SOAP device driver. | |
Meter-Bus | Acquiring spot meter reading values and their history. | |
Modbus | Support for Modbus/RTU, Modbus/ASCII, Modbus/TCP, and Modbus/UDP. Registering read/write operations. | |
GSM/GPRS Modem Control | Sending/receiving SMS messages, modem control, and data retrieval via AT command execution. | |
MQTT | ISO standard publish-subscribe-based messaging protocol for use on top of TCP/IP protocol. | |
NMEA 0183 | Exposing any NMEA sentence fields for system core. Device location tracking. | |
ODBC | Via standard JDBC-ODBC bridge, see SQL device driver. | |
OPC DA | Support for OPC DA 2.0 via DCOM. Works under Windows and Linux. | |
OPC DA/HDA/AE | Iotellect Agent Driver + Iotellect OPC Agent | Support for OPC DA, AE, and HDA. Iotellect OPC Agent is standalone software installed on Windows and working with Iotellect servers running on Windows or Linux. |
OPC UA | Full support of OPC UA stack. | |
POP3 | POP3 server operability monitoring. | |
Radius | Radius server operability monitoring. | |
S7 Protocol | Managing PLCs of the Siemens S7 family. | |
SIP | Placing test VoIP calls and retrieving call metrics. | |
SMB/CIFS | Accessing and monitoring files and folders shared via Microsoft Windows Network (SBM/CIFS) technology. | |
SMI-S | Control of disk storage supporting SMI-S protocol. Monitoring object properties, executing queries and object methods, processing events. | |
SMPP | Sending SMS messages through an SMPP gateway. | |
SMTP | SMTP server operability monitoring. | |
SNMP | Support for SNMP v1, v2c, and v3. Read/write operations, receiving and sending traps. MIB directory and editor. | |
SOAP | Performing arbitrary Web Service calls via SOAP protocol by specifying input data and processing any output. | |
SQL | Support for any JDBC/ODBC-compliant database server. Dynamic SELECT / UPDATE / INSERT / DELETE query execution. Exposing query results for system core. Database status monitoring. | |
SSH | Executing shell scripts and applications on remote machines. SSH server operability monitoring. | |
Telnet | Executing shell scripts and applications on remote machines. Telnet server operability monitoring. | |
VMware SOAP API | Retrieving hypervisor/VM status and performance counters. | |
WMI | Monitoring WMI object properties, executing WQL queries and object methods, processing WMI events. | |
XMPP | Implementation of Sensor Data and Control extensions of the protocol. | |
Executing custom applications/scripts on demand or upon schedule. Retrieving and processing their output. | ||
Localizing any remote device driver by creating local "Avatars" to simplify solution development and improve network performance. | ||
Local file monitoring, checksum verification, exposing file contents for system core. | ||
| Acting as a self-service driver construction kit for solution engineers to support proprietary protocols without any Java coding. | |
| Local folder monitoring, exposing folder contents for system core. | |
| Storage of topologies in various graph databases supported by Apache TinkerPop, including Neo4j. Access to graph computing operations provided by Gremlin language. | |
| Monitoring incoming data via Serial/TCP/UDP connections. | |
The device simulator, provides variables of different types, wave generators, test operations and events. | ||
Advanced web application monitoring. Allows analyzing availability, health, and performance by modeling end-user activity scenarios of any complexity. |
Driver Reference
The subsections of the current section are devoted to different device drivers that are bundled with Iotellect core and diverse vertical market solutions.
Description of every driver includes the following:
Section | Notes |
Driver Information | Driver details, such as driver plugin ID, etc. |
Global Settings | Global configuration of driver plugin. |
User-level Settings | User-level configuration of driver plugin. |
Device Account Properties | Device-level configuration of driver plugin. This includes connection settings, manually configured definitions of device resources, etc. |
Device Assets | Description of the method used by the driver to define device assets. |
Device Settings | Description of the method used by the driver to create variables corresponding to the hardware device's settings. |
Device Operations | Description of the method used by the driver to create functions/actions corresponding to the hardware device's operations. |
Device Events | Description of the method used by the driver to create event definitions corresponding to the types of notifications provided by the hardware device. This section also illustrates how and when the event instances are received from the hardware and converted into Iotellect events. |
Connection Handling | Details on how and when the driver switches the device between Online and Offline status. |
Synchronization Details | Any information on the driver-specific peculiarities of the Device synchronization process. |
Setting Levels
Since a device driver is a plugin, it has the configuration options that most plugins have. For every driver up to three levels of settings are available:
Global Settings These affect the default behavior of drivers. Global settings may be edited only by users with sufficient permissions.
User-level Settings. These affect the behavior of a driver only if it is assigned to a Device that belongs to a certain user account. When the driver is communicating with a certain device, it uses the user-level settings stored in the Device owner's account.
Device-level Settings (Device Properties). These settings define how the device driver connects to the device, communicates with it, and processes device data.
Many drivers do not use all three setting levels.
Administering Device Drivers
Two context types are used to administer Device Drivers: first is the general Drivers/Plugins Configuration context, which serves as a container. The other is the Driver/Plugin Configuration context, which holds the configuration for a single driver.
These appear in two places:
Under the Root context, where they contain global settings
Under the User context, where they contain user-level settings
If a given driver doesn't contain settings on one of these levels, the corresponding Device Driver Configuration context will not be created (i.e, won't exist in the System Tree).
Device-level settings for a driver may be accessed using the Edit Device Properties action of a Device context.
Was this page helpful?