1. Introduction
   1. Generic Driver Workflow
   2. Generic Driver Data Flow
2. What To Expect
3. Key Features

Introduction

This document is a comprehensive guide for setting up the Generic Driver—an integration solution designed to collect telemetry from devices adhering to HTTP or MQTT protocols, while also supporting a standard JSON structure. The Generic Driver is equipped with functionalities to address specific challenges, all while maintaining idempotency. This unique feature ensures that the driver’s capabilities can be effectively used by multiple entities, offering a consistent solution tailored to a variety of integration needs. Effortlessly constructed by end-users, the Generic Driver offers a quick and user-friendly setup process. Users can simply select and configure data sources, along with implementing data processing filters, making the integration process swift and intuitive.

Generic Driver Workflow

The workflow diagram in Figure 1 outlines both the startup sequence of the Generic Driver and the logical flow it follows upon receiving a data packet. It is important to note that a Generic Driver comprises a singular data source and may include one or more filters in its configuration. This diagram serves as a guide to understanding the dynamic processes involved in the operation of the Generic Driver, from initialization to the handling of incoming data packets.

Figure 1 - Generic Driver Startup Sequence and Data Packet Reception Flow

The following steps provide a detailed outline of the activities occurring at each phase within the workflow diagram in Figure 1.

1. Telemetry Arrival: Upon arrival, telemetry is received in the form of raw bytes. The Generic Driver’s coordinator processes these raw bytes as a bytes array.
2. Coordination by the Generic Driver: The Generic Driver manages the flow of data.
3. Raw Data Retrieval: The data source retrieves and returns a set of raw bytes. This step establishes the initial interaction between the Generic Driver and the physical device, collecting the raw data for future processing.

4. Filter Execution Loop: The Generic Driver will iteratively pass the set of raw bytes through each filter within a loop. Each filter is executed sequentially for every data packet. The filter operates by taking the raw data and the values processed up to that point as input, enabling it to perform one or more of the following actions:

   • Process and/or change the raw data packet.
   • Read the payload values.
   • Add or remove one or more payload values.
   • Change one or more payload values.

   Payload Values are Key-Value Pairs, encompassing information such as gatewayID, deviceID, propertyID, or timestamp. They are eventually converted into Meta/Telemetry properties for transmission to the Collector. Each data packet generates independent payload values through the filter.

   Payload Values are Key-Value Pairs, encompassing information such as gatewayID, deviceID, propertyID, or timestamp.

   Payload values are eventually converted into Meta/Telemetry properties for transmission to the Collector. Each data packet generates independent payload values through the filter, and it is processed independently from other data packets.

5. Payload Value Processing: Once the filters have processed all the telemetry, and the Generic Driver has received all the Payload Values, the Generic Driver organizes the Payload Values into ‘Device Properties’. Each device property encapsulates the properties of a device for a specific timestamp. The Generic Driver groups Key-Value Pairs by device and timestamp, into the various properties, and sends the Device Properties to the ‘Device Communicator’.
6. Transform Set Application: Upon reaching the Device Communicator, the user can apply ‘Transform Sets’ to the Device Properties. Transform Sets provide a mechanism for users to customise and refine the processed data according to specific requirements or standards.
7. Telemetry Forwarding: If the transform sets are normal, the Generic Driver forwards the telemetry to the collector. The collector further processes and transmits the telemetry to Commander for additional actions.

Generic Driver Data Flow

The data flow diagram presented in Figure 2 illustrates the transformation of data through the Generic Driver. The use case can be summarized as follows:

The Generic Driver processes incoming data originating from the weather station, effecting a transformation into a format compatible with Commander display. This enables users to visualize the recorded temperature and humidity on their screen through illustrative graphs.

Figure 2 - Generic Driver Data Flow

Here is a detailed outline of the activities occurring at each step within the data flow diagram in Figure 2.

1. Temperature and humidity data originate from the Weather Gauge (a physical device). Note that the data will come in as a JSON document. The data is transmitted to the Generic Driver for processing.
2. The Generic Driver processes the incoming data, and the data undergoes transformation into a format suitable for further analysis or storage.
3. The processed data is transmitted as telemetry to Commander. Once received by Commander, the information is displayed on the screen, ready for analysis and catering to various user requirements.

What To Expect

This document has been created with a focus on making the content accessible to non-technical individuals. It aims to provide a clear understanding of the functionality of the Generic Driver and offers instructions for its easy and effective setup. The main topics covered include:

1. Creating a device
   • Import file (JSON).
   • Create a device from scratch using the user Interface.
2. Device driver set-up.
3. Device information configuration.
4. Data sourced and their configuration.

Key Features

The Generic Driver is versatile in its capabilities, it:

• Supports both JSON and custom payloads.
• Facilitates the transmission and reception of HTTPS requests, with support for TLS 1.2 and higher.
• Subscribes to three distinct types of queues: MQTT, NATS, and RabbitMQ.