Frequently Asked Questions
This section provides answers to the most frequently asked questions about the Gateway Agent.
Which Gateway Agent components are mandatory and which are optional?
You can deploy the Gateway Agent can be deployed in several architecture variants. In each of them, at least one Protocol Adapter is required to retrieve data from devices. At least one Cloud Adapter is also required to enable bidirectional communication between the relayr Gateway Agent and the relayr Cloud. Depending on a specific use case, you may also need other components, e.g. the Task Executor to support tasks, such as remote software and configuration updates.
The remaining components, such as the Rule Engine or the Configuration Manager are optional in all deployment variants. For an overview of the Agent components, see the Available Components section.
Which ready-to-use Protocol Adapters are delivered by relayr?
You can find a list of out-of-the-box Protocol Adapters offered by relayr here. For detailed information, refer to the adapter-specific documentation. Apart from the ready-to-use solutions, it is also possible to develop custom protocol adapters to extend the Gateway Agent capabilities.
What are the hardware and software requirements to run the Gateway Agent?
A list of minimum platform requirements and supported Linux distributions can be found in the Requirements section.
For more resource-constrained devices, you can deploy the Nano Agent, which is a lightweight version of the Gateway Agent. For more information on its requirements and capabilities, see the Deployment on Nano Devices section.
How can I install the Gateway Agent components?
The Gateway Agent components can be easily installed by means of the installation script provided by relayr. For details, see the Installation Guide.
For the Nano Agent, it is recommended to use a more lightweight installer, described here.
Do I need to be a developer to use the Gateway Agent?
No, you do not need to have developer skills to use the Gateway Agent. All you need to do to get going is to configure components using your favorite text editor or the graphical user interface of the Configuration Manager.
Which configuration files can I modify using the Configuration Manager?
The Configuration Manager enables editing application configuration files of Gateway Agent components. The application configuration files contain settings related to measurements, alerts, configuration parameters and metadata reported by devices. To modify deployment configuration files, e.g. settings related to the Cloud connection, you need to edit them manually in a text editor.
What is the role of the Rule Engine?
The Rule Engine enables customizing the entire logic of data processing without a need for software recompilation. Data processing is defined as a set of rules written in Lua and executed according to a defined schedule or when new data is published. All data is processed at the Edge, before being sent to the Cloud.
The Rule Engine capabilities include calculating the average value from a set of measurements, correlating several data types into a single alert, converting measurement units or generating periodic reports about the state of the system.
How can I optimize the bandwidth usage?
The relayr Cloud Adapter provides a data buffering and compression mechanism to minimize the amount of data that needs to be sent over the air. It can accumulate the measurement data and send it in batches at the specified reporting interval (e.g. 120 seconds) or when a given number of measurements is reached (e.g. 700 samples). The measurement data can be compressed before it is published to the Cloud. The buffered measurements are stored in a local database and they persist over the adapter or platform restarts, or they can be stored in the database existing in RAM only. For more information on available data buffering scenarios, see here.
What is the standard format of messages exchanged by the Gateway Agent components?
The Gateway Agent components communicate via JSON encoded messages over the internal message bus. Here is the example of a measurement published via MQTT. It has an ID (id
), a timestamp (ts
) and a value
:
v1/sb/Example1/measurements/TIMES {"id": "TIMES", "ts": 1581671960628, "value": 5447345}