relayr Cloud Adapter
The relayr Cloud Adapter translates the unified Gateway Agent messaging into the Cloud-specific protocol, enabling a communication between the the relayr Cloud and all the Gateway Agent components.
The relayr Cloud Adapter assures an efficient and reliable data exchange with the Cloud by providing advanced buffering and compression capabilities.
For a step-by-step guide on how to install the relayr Cloud Adapter, see the Installation Guide.
Configuring relayr Cloud Access Credentials
MQTT credentials are required to authorize access to a device or a group of devices created in the relayr Cloud.
MQTT Credentials in the Configuration Manager
If you have the Configuration Manager installed, you can configure your MQTT credentials in its UI. For details, see the Configuring Access Credentials to the relayr Cloud section.
MQTT Credentials in the Installation Script
Apart from using the Configuration Manager, you can also configure your MQTT credentials from the main menu of the Gateway Agent installation script. The script automatically updates the relayr Cloud Adapter configuration with credentials for the selected device or device group.
For a list of requirements to run the script, see the Installation Guide.
To configure the credentials using the installation script, follow these steps:
- Run the installer:
python ./gwa-install.py
- In the main script menu, select Configure relayr Cloud access credentials.
Provide your User and Password to the relayr Cloud.
Select a device or device group for which you want to configure the connection and press the Enter key to continue.
- Press the
y
key when the following question is displayed:
Do you want to update relayr Cloud adapter configuration file with login credentials?
The obtained credentials are automatically entered in the username
, password
and credentials_type
fields in the application configuration file.
The Gateway Agent is now able to exchange information about a given device or device group with the relayr Cloud.
Alternatively, you can get your MQTT credentials manually and enter them in the configuration file. For more information, see the relayr Cloud API documentation.
Configuring the relayr Cloud Adapter
There are two configuration files of the relayr Cloud Adapter:
Deployment configuration file - Configuration of the Cloud connection, Gateway Agent MQTT and HTTP connections, database and health monitoring.
Application configuration file - Configuration of the MQTT access credentials to the relayr Cloud.
After changing the configuration settings, restart the relayr Cloud Adapter to apply the changes by means of the following command:
systemctl restart gwa-relayr-cloud-v2-adapter-c
For an example of the relayr Cloud Adapter configuration files, see here.
Deployment Configuration File
The deployment configuration file of the relayr Cloud Adapter is located at:
/etc/relayr/gwa-relayr-cloud-v2-adapter-c/gwa-relayr-cloud-v2-adapter-config.json
To modify the file, edit it in a text editor.
The file consists of several sections with the following configuration options available:
cloud_connection
- configuration of the MQTT connection to the relayr Cloud:
Configuration Setting | Description | Default Value |
---|---|---|
host | Host name or IP address of the relayr Cloud MQTT broker. Here, leave the default value unchanged. | cloud-mqtt.prd.az.relayr.io |
port | TCP port number of the relayr Cloud MQTT broker. Here, leave the default value unchanged. | 8883 |
ca_file | Path to a SSL Certificate Authorities file. Here, leave the default value unchanged. | /etc/ssl/certs/ca-certificates.crt |
reconnect_interval | Reconnect interval to the relayr Cloud MQTT broker, specified in seconds. If the value is missing, the default value is assumed. | 5 |
keepalive | Time interval given in seconds for sending keepalive messages for the relayr Cloud MQTT connection. If the value is missing, the default value of 10 seconds is assumed. | 10 |
max_cache_size | Maximum number of cached messages in PAHO client queues (messages waiting for publication). By default, 10000 . See here for more information. | 10000 |
max_inflight_messages | Maximum number of QoS 1 or 2 messages that can be in the process of being transmitted simultaneously. | 1 |
enable_server_cert_auth | If set to true , certificates are verified. If verification does not succeed, the adapter exits. | true |
cloud_http_connection
- configuration of the relayr Cloud HTTP connection for sending complex measurements to the Cloud:
Configuration Setting | Description | Default Value |
---|---|---|
host | Host name or IP address of the relayr Cloud's HTTP interface. | cloud.prd.az.relayr.io |
port | Port number of the relayr Cloud's HTTP interface. | 443 |
http_timeout | Timeout of HTTP requests . | 5 |
mqtt_connection
- configuration of the Gateway Agent MQTT connection:
Configuration Setting | Description | Default Value |
---|---|---|
host | Host name or IP address of the MQTT broker of the Gateway Agent's Northbound Interface. | 127.0.0.1 |
port | TCP port number of the MQTT broker of the Gateway Agent's Northbound Interface. | 1883 |
reconnect_interval | Reconnect interval of the Gateway Agent Northbound interface MQTT broker, given in seconds. If the value is missing, the default value of 1 second is assumed. | 1 |
keepalive | Keepalive value for the Gateway Agent Northbound Interface MQTT connection. If the value is missing, the default value of 30 seconds is assumed. | 30 |
max_inflight_messages | Maximum number of QoS 1 or 2 messages that can be in the process of being transmitted simultaneously. This includes messages currently going through handshakes and messages that are being retried. If set to 1 , this guarantees an in-order delivery of messages. | 100 |
http_connection
- configuration of the Gateway Agent HTTP connection, e.g. for communication with the Task Executor:
Configuration Setting | Description | Default Value |
---|---|---|
host | Host name or IP address of the Gateway Agent's HTTP interface. | localhost |
port | TCP port number of the Gateway Agent's HTTP interface. Allowed values: integers between 1 and 65535 . | 22080 |
use_ssl | It determines if the connection to the Gateway Agent's HTTP interface requires the SSL connection. Possible values are: true or false . | false |
ca_file | Path to the SSL Certificate Authorities file. Here, leave the default value unchanged. | /etc/ssl/certs/ca-certificates.crt |
auth_enable | It determines if the Gateway Agent's HTTP interface requires authorization (possible values are: true or false ). | false |
username | Username to the Gateway Agent's HTTP interface. It is required only if the auth_enable field is set to true . | "" |
password | Password to the Gateway Agent's HTTP interface. It is required only if the auth_enable field is set to true . | "" |
http_timeout | Timeout of HTTP requests. | 10 |
nb_configs_connection
- configuration of the HTTP connection to receive configuration updates of business parameters from the relayr Cloud. There are separate sections for the Rule Engine and GWA Analytics connection. To make business parameters available to one component only, configure only thegwa_rule_engine
or thegwa_analytics
section:
Configuration Setting | Description | Default Value |
---|---|---|
gwa_rule_engine.host | Host name or IP address of the Rule Engine's business-params REST endpoint to receive the configuration of business parameters. | 127.0.0.1 |
gwa_rule_engine.port | Port number of the Rule Engine's business-params REST endpoint to receive the configuration of business parameters. | 25080 |
gwa_analytics.host | Host name or IP address of the GWA Analytics business-params REST endpoint to receive the configuration of business parameters. | 127.0.0.1 |
gwa_analytics.port | Port number of the GWA Analytics business-params REST endpoint to receive the configuration of business parameters. | 27080 |
database
- settings related to the data buffering and compression. See the Data Buffering and Compression Mechanism section for more information.
Configuration Setting | Description | Default Value |
---|---|---|
path | Path to local database for data buffering and task mapping. It is used when in_memory_database is set to false . | /var/cache/relayr/gwa-relayr-cloud-v2-adapter-c/cloud.sqlite3 |
data_buffering | If set to true , the data buffering is enabled. | false |
in_memory_database | If set to true , the database exists only in RAM and is deleted when the application exits. | false |
cache_only_critical_data | If set to true , only messages other than measurements (alerts and task updates) are cached in the database. | false |
offline_buffer_only | If set to true , data is buffered in the local database only when the adapter is disconnected from the relayr Cloud. | false |
message_limit | Number of messages to be buffered before sending. If it is not defined or set to 0, the default buffered message limit of 1000 messages is applied. | 1000 |
buffering_time | Timeout between consecutive publishes of cached data. When it expires, up to the message_limit of messages are published. | 60 |
use_compression | If set to true , then gzip compression is used while publishing the buffered data. | false |
max_db_size | Maximum memory size for buffered data, given in megabytes. The minimum value is 1 . For more information, see the Maximum Database Size Setting section. | 100 |
health_monitor
- settings related to the health monitoring functionality:
Configuration Setting | Description | Default Value |
---|---|---|
heartbeat_interval | Time interval at which heartbeat messages are sent, given in seconds. | 60 |
Recommended Configuration for Unstable Internet Connection
If the Internet connection is not stable (e.g. if you are using LTE connection), it is not recommended to increase the default values of the
keepalive
andmax_inflight_messages
settings of thecloud_connection
configuration section.
keepalive
value
The keepalive
value is a time interval for sending keepalive messages to the message broker of the relayr Cloud.
If the connection with the Cloud is interrupted, the relayr Cloud Adapter is notified about that when it does not get a response to the sent keepalive message. Until then, the PAHO client of the relayr Cloud Adapter keeps sending messages to the Cloud.
If you increase the
keepalive
value, the time needed to notify the relayr Cloud Adapter about the interrupted connection is longer. That is why it is recommended to leave the default value of 10 seconds unchanged in case of unstable Internet connections.
max_inflight_messages
value
The max_inflight_messages
value determines the maximum number of messages which can be transmitted simultaneously to the relayr Cloud.
When the Cloud message broker receives messages, it sends a confirmation to the relayr Cloud Adapter. If the connection to the Cloud is interrupted in the meantime, the confirmation may not arrive. Because of that, the relayr Cloud Adapter resends such messages when the connection is resumed.
If you increase the
max_inflight_messages
value, there may be more duplicated messages sent to the Cloud. That is why it is recommended to leave the default value of 10 messages unchanged in case of unstable Internet connections.
Application Configuration File
The application configuration file of the relayr Cloud Adapter is located at:
/etc/relayr/gwa-relayr-cloud-v2-adapter-c/gwa-relayr-cloud-v2-adapter-application-config.json
The file has the following configuration options available:
Configuration Setting | Description | Example of Value |
---|---|---|
username | Username for MQTT credentials that authorize access to a device or a device group defined in the relayr Cloud. This field is filled in automatically when you configure MQTT access credentials. | f3cc6bab-b39e-4f5a-934a-23h935d8b27a |
password | Password for MQTT credentials that authorize access to a device or a device group defined in the relayr Cloud. This field is filled in automatically when you configure MQTT access credentials. | dw3Bf5gdxgaqBmQhkrg9wk8vZ |
credentials_type | This field informs if you have access to a device (device ) or a device group (group ). This field is filled in automatically when you configure MQTT access credentials. | device |
subscribe_devices | Optional field. An array of device UUIDs for additional subscriptions. See here for more information. | ["a6a1f131-a565-4dge-bdbb-b4595a157d53", "86fbab71-0796-4ffe-b2a9-2d9f0233c39c"] |
Example:
{
"cloud_connection": {
"username": "f3cc6bab-b39e-4f5a-934a-23h935d8b27a",
"password": "dw3Bf5gdxgaqBmQhkrg9wk8vZ",
"credentials_type": "group",
"subscribe_devices": ["a6a1f131-a565-4dge-bdbb-b4595a157d53", "86fbab71-0796-4ffe-b2a9-2d9f0233c39c"]
}
}
You can configure your MQTT credentials automatically in the following ways:
using the Configuration Manager's UI. See here for more information.
using the installation script. See here for more information.
Alternatively, you can get your MQTT credentials manually and enter them in the configuration file. For more information, see the relayr Cloud API documentation.
Configuring Additional Device Subscriptions
In the subscribe_devices
field of the application configuration file, you can optionally provide an array of device UUIDs that the Cloud Adapter subscribes for.
Use this configuration setting if you configure MQTT access credentials for a group of devices and you want to handle business parameters or any other messages coming from the relayr Cloud, such as commands and installations.
In the subscribe_devices
field, provide an array of device UUIDs that belong to the group for which you have configured the MQTT credentials. This allows the Cloud Adapter to receive configuration of business parameters, commands, and installations from the Cloud even if these devices haven't reported any data yet.
The
subscribe_devices
field can only contain UUIDs of devices that belong to the group you are authorized to access. If you provide any other UUIDs, the Cloud Adapter disconnects due to an invalid configuration error.
The Cloud Adapter saves its device subscriptions in its database. If you want to reconfigure the MQTT access credentials for a different device group, it is recommended to remove the old database to avoid the invalid configuration error.
Data Buffering and Compression Mechanism
In order to optimize the bandwidth usage, the Gateway Agent provides a data buffering and compression mechanism to minimize the amount of data that needs to be sent over the air.
The chart below illustrates the impact of the data compression on saving the bandwidth costs. Depending on the length of the raw text data, bandwidth savings can be up to 14 times.
In this mechanism, the relayr Cloud Adapter accumulates the measurement data and sends 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. You can configure the maximum database size for the buffered data.
Settings related to data buffering and compression are configured in the database
section of the deployment configuration file. See here for a list of available settings.
See section below for examples of data buffering and compression scenarios.
Data Buffering Scenarios
This section presents available scenarios of data buffering and compression mechanism of the relayr Cloud Adapter.
1. Simple buffering
Configuration Setting | Value |
---|---|
data_buffering | true |
in_memory_database | false |
offline_buffer_only | false |
cache_only_critical_data | false |
message_limit | 0 |
buffering_time | 0 |
use_compression | false |
In this scenario:
The default values are used:
message_limit
: 1000buffering_time
: 60 seconds
Every measurement (and other types of payload) is buffered.
If more than 1000 messages are in buffer, 1000 messages (
message_limit
) are published.Additionally, all the measurements that are in the buffer are published every 60 seconds (
buffering_time
).
2. Advanced buffering
Configuration Setting | Value |
---|---|
data_buffering | true |
in_memory_database | false |
offline_buffer_only | false |
cache_only_critical_data | false |
message_limit | 100 |
buffering_time | 90 |
use_compression | false |
In this scenario:
Every measurement (and other types of payload) is buffered.
If 100 messages (or more) are in the buffer, then 100 messages (
message_limit
) are published.Additionally, every 90 seconds (
buffering_time
), up to 100 (message_limit
) of messages are published.No compression is used.
3. Advanced buffering with compression
Configuration Setting | Value |
---|---|
data_buffering | true |
in_memory_database | false |
offline_buffer_only | false |
cache_only_critical_data | false |
message_limit | 100 |
buffering_time | 3600 |
use_compression | true |
In this scenario:
Every measurement (and other types of payload) is buffered.
If 100 messages (or more) are in the buffer, then 100 messages (
message_limit
) are published.Additionally, every 3600 seconds (
buffering_time
), up to 100 (message_limit
) measurements are published.All buffered messages are compressed with
gzip
.
4. Advanced buffering in offline mode with in-memory database
Configuration Setting | Value |
---|---|
data_buffering | true |
in_memory_database | true |
offline_buffer_only | true |
cache_only_critical_data | false |
message_limit | 100 |
buffering_time | 3600 |
use_compression | true |
In this scenario:
Every measurement (and other types of payloads) is buffered only if there is no connection to the Cloud. In the online mode, messages are sent without any buffering.
When the adapter is disconnected and then reconnects successfully to the Cloud, up to 100 (
message_limit
) messages are sent immediately.Then, up to 100 messages (
message_limit
) are sent every 3600 seconds (buffering_time
).Database is stored in RAM (
in_memory_database
) and is lost when the adapter exits.All buffered messages are compressed with
gzip
.
5. Critical data caching
Configuration Setting | Value |
---|---|
data_buffering | true |
in_memory_database | false |
offline_buffer_only | false |
cache_only_critical_data | true |
message_limit | 100 |
buffering_time | 3600 |
use_compression | true |
In this scenario:
Critical data (alerts and task updates) is buffered and sent immediately to the Cloud. In the online mode,
message_limit
is not observed.When the adapter is disconnected and then reconnects successfully to the Cloud, up to 100 messages (
message_limit
) are sent immediately.Then, up to 100 messages (
message_limit
) are sent every 3600 seconds (buffering_time
).All measurements are sent immediately without any buffering.
If the connection is off, then measurements are cached inside the PAHO client (up to the
max_cache_size
of messages are kept in RAM memory). See here for more information.If the message count exceeds the
max_cache_size
, consecutive measurements are lost.All alerts and task updates are stored in the database.
All buffered messages are compressed with
gzip
.
6. Critical data caching in offline mode only
Configuration Setting | Value |
---|---|
data_buffering | true |
in_memory_database | false |
offline_buffer_only | true |
cache_only_critical_data | true |
message_limit | 100 |
buffering_time | 3600 |
use_compression | true |
In this scenario:
Critical data (alerts and task updates) is buffered only if there is no connection to the Cloud. In the online mode,
message_limit
is not observed and caching is not used.When the adapter is disconnected and then reconnects successfully to the Cloud, then up to 100 messages (
message_limit
) are sent immediately.Then, up to 100 messages (
message_limit
) are sent every 3600 seconds (buffering_time
).All measurements are sent immediately without any buffering.
If the connection is off, then measurements are cached inside the PAHO client (up to the
max_cache_size
of messages are kept in RAM memory). See here for more information.If the message count exceeds
max_cache_size
, consecutive measurements are lost.All alerts and task updates are stored in the database.
All buffered messages are compressed with
gzip
.
Maximum Database Size Setting
The max_db_size
, available in the database
section of the deployment configuration file, defines the maximum number of megabytes that are used for the buffered data. The configured size is observed both for a local database and for a database stored in RAM (when in_memory_database
is set to true
).
The Cloud Adapter checks the used memory size at the application startup and every 1000 data samples it receives. If the maximum size is exceeded, consecutive messages are not stored in the database, but sent directly to the Cloud, until the amount of data in the database is smaller than the configured limit.
The size of the used memory calculated by the Cloud Adapter does not immediately get smaller when some data from the database is sent to the Cloud. The size decreases only after vacuuming the database. The Cloud Adapter clears the database when 10 consecutive checks have shown that the maximum database size is exceeded.
It is not possible to calculate precisely the exact amount of the used memory, because the Cloud Adapter allocates some memory for performing current operations, e.g. for caching messages in internal PAHO queues, as explained here.
Maximum Cache Size Setting
The max_cache_size
setting, available in the cloud_connection
section of the deployment configuration file, defines a maximum number of cached messages in PAHO client queues (messages waiting for publication). This setting has an impact on memory usage.
The default value of 10 000 messages takes approximately 10 000 * (average message size +30)
bytes of memory. If the average payload length is specified as around 60 bytes, at least 900KB of memory is needed to store 10.000 messages
in internal PAHO queues.
These queues are required to make sure that every message is delivered to the Cloud. The Cloud's broker acknowledges the message delivery. In case of unstable network connection, acknowledgments may or may not arrive, so internal queues are responsible for republishing the data and monitoring its arrival to the broker.
Reporting Device Location
The Cloud Adapter supports reporting a device location to the relayr Cloud.
To report a location, publish a message to the v1/nb/{DID}/locations/location
topic with the location details in the message payload.
Example:
mosquitto_pub -t "v1/nb/0ad304ac-4b69-46b2-9062-1ed1a3c14d3d/locations/location" -m '{ "address": "uniwersytecka 20", "city": "KATOWICE", "country": "PL", "latitude": 8.0, "longitude": 180.0, "zipCode": "43-200", "timestamp": 1}'
Latitude
andlongitude
are required. The remaining fields are optional. See the relayr MQTT Broker documentation for more information.
Protocol Adapters do not support reporting device location. You can report it e.g. from the Rule Engine.
Publishing Logs
The Cloud Adapter supports reporting logs to the relayr Cloud.
To report a log, publish a log message to the v1/nb/{DID}/logs/{LOG_ID}
topic, e.g.:
mosquitto_pub -t "v1/nb/0ad304ac-4b69-46b2-9062-1ed1a3c14d3d/logs/restart" -m '{ "message": "Device has been restarted", "level": 2, "ts": 1492515087123}'
For details on the
devices/{deviceId}/logs
endpoint in the relayr Cloud, see the relayr MQTT Broker documentation.
Publishing Complex Measurements
The Cloud Adapter supports reporting complex measurements to the relayr Cloud. A complex measurement is a batch of measurement data, in which several samples of collected data values are sent as a compressed blob message to the Cloud's blob storage.
The Cloud Adapter can receive complex measurement messages from Protocol Adapters. To report them, you must first configure complex measurements in the Protocol Adapters' configuration. Complex measurements can also be processed by the Rule Engine, the GWA Analytics and can be stored by the Storage Service.
The Cloud Adapter sends complex measurements to the Cloud over the HTTP connection, which you can configure in the cloud_http_connection
section of the deployment configuration file. To access the Cloud's HTTP interface, you need to be authorized by means of the MQTT access credentials.
The Cloud Adapter sends complex measurements to the Cloud using the following POST
request format:
POST /devices/{deviceId}/measurements/binary/{measurementName}
HTTP headers:
x-mqtt-credentials: <user:password>
x-authorize-as-device-id: <uuid>
HTTP body: (multipart/form-data)
binary-measurement-metadata: {
"version": "1",
"startTs": 123455,
"endTs": 7463452
}
value : <binary body payload with streaming support>
In the request body,
version
andstartTS
are requiredbinary-measurement-metadata
, but the Cloud Adapter can optionally send other fields, too. Each payload with a complex measurement message is sent as a compressed.gzip
file.
Complex Measurement Message
The Cloud Adapter publishes a complex measurement to the Cloud when it receives a complex measurement message on the northbound interface.
Depending on the measured value, a complex measurement message can contain data in various domains, e.g. measurements in the time domain, reported by Protocol Adapters, or measurements in the frequency domain, reported by the Pico Adapter or calculated by the Rule Engine or the GWA Analytics.
In a complex measurement message:
startTs
is a moment when data acquisition begins.endTs
is a moment when data acquisition finishes.xStart
is the first value on the X axis. ThexStart
unit depends on the measured value. For measurements in the time domain, it is a timestamp indicating the moment when the first data sample is collected. For measurements in the frequency domain, it is the first frequency on the X axis.xStep
represents a resolution of data on the X axis. For measurements in the time domain,xStep
is a time interval between consecutive data samples, given in milliseconds (you configure this interval in thesampling_interval
setting of the Protocol Adapters' configuration). ThexStep
value allows you to know the precise moment when each data sample was collected. For measurements in the frequency domain,xStep
represents the frequency resolution of data representation on the X axis.yValues
is an array of ordered measurement values.
Example 1: time-based measurement:
v1/nb/{UUID}/complex_measurements/temperature {
“id”:“temperature”,
“startTs”: 1492515087123,
“endTs”: 1492515092123,
“xStart”: 1492515087123,
“xStep”: 1000,
“yValues”: [42, 43, 39, 37, 40, 48, 45, 40, 38, 33, 30, 31...]
}
In this example,
temperature
is a time-based measurement. ThexStart
value is1492515087123
, which shows the moment when the first data sample (42
) was collected. ThexStep
value is1000
, which means that consecutive data samples were collected at the interval of 1000 milliseconds.
Example 2: frequency-based measurement:
v1/nb/{UUID}/complex_measurements/acceleration_xaxis_fft {
“id”:“acceleration_xaxis_fft”,
“startTs”: 1492515087123,
“endTs”: 1492515092123,
“xStart”: 90,
“xStep”: 10,
“yValues”: [3, 12, 48, 579, 644, 689, 711, 647, 78, 644, 669, 112, 638, 652, 617, 48...]
}
In this example,
acceleration_xaxis_fft
is a frequency-based measurement. ThexStart
value is90
, which shows that the first frequency on the X axis is 90 Hz. ThexStep
value is10
, which means that the frequency step on the X axis, between consecutive data samples, is 10 Hz.
Receiving Configuration of Business Parameters from the Cloud
The Cloud Adapter supports receiving configuration updates from the relayr Cloud. This allows you to define a set of parameters with configurable values that can be used by the Rule Engine or GWA Analytics. For example, you can create rules that trigger alerts based on configurable thresholds.
The Cloud Adapter receives updates of business parameters over the HTTP connection, which you can configure in the nb_configs_connection
section of the Cloud Adapter's deployment configuration file. There are separate configuration sections for the Rule Engine and GWA Analytics REST interfaces:
"nb_configs_connection": {
"gwa_rule_engine":{
"host": "127.0.0.1",
"port": 25080
},
"gwa_analytics":{
"host": "127.0.0.1",
"port": 27080
}
},
Configure both sections if you want to make business parameters available to both components. To make them available to one component only, configure only the gwa_rule_engine
or the gwa_analytics
section.
In older Cloud Adapter's versions, the
nb_configs_connection
had only one set of settings (host
andport
with the default values of127.0.0.1
and25080
, respectively). This configuration still works and makes business parameters available to the Rule Engine only.
For more information on creating rules and scripts with configurable parameters, see the Rule Engine and the GWA Analytics documentation.
For details on the
devices/{deviceId}/configs
endpoint in the relayr Cloud, see the relayr MQTT Broker documentation.
Examples of Configuration Files
Deployment Configuration File
{
"cloud_connection": {
"host": "cloud-mqtt.prd.az.relayr.io",
"port": 8883,
"ca_file": "/etc/ssl/certs/ca-certificates.crt",
"reconnect_interval": 5,
"keepalive": 10,
"max_cache_size": 10000,
"max_inflight_messages": 1,
"enable_server_cert_auth": true
},
"cloud_http_connection": {
"host": "cloud.prd.az.relayr.io",
"port": 443,
"http_timeout": 5
},
"mqtt_connection": {
"host": "127.0.0.1",
"port": 1883,
"reconnect_interval": 1,
"keepalive": 30,
"max_inflight_messages": 100
},
"http_connection": {
"host": "127.0.0.1",
"port": 22080,
"use_ssl": false,
"ca_file": "/etc/ssl/certs/ca-certificates.crt",
"auth_enable": false,
"username": "",
"password": "",
"http_timeout": 10
},
"nb_configs_connection": {
"gwa_rule_engine":{
"host": "127.0.0.1",
"port": 25080
},
"gwa_analytics":{
"host": "127.0.0.1",
"port": 27080
}
},
"database": {
"path": "/var/cache/relayr/gwa-relayr-cloud-v2-adapter-c/cloud.sqlite3",
"data_buffering": false,
"in_memory_database": false,
"offline_buffer_only": false,
"cache_only_critical_data": false,
"message_limit": 1000,
"buffering_time": 60,
"use_compression": true,
"max_db_size": 100
},
"health_monitor": {
"heartbeat_interval": 60
}
}
Application Configuration File
{
"cloud_connection": {
"username": "f3cc6bab-b39e-4f5a-934a-23h935d8b27a",
"password": "dw3Bf5gdxgaqBmQhkrg9wk8vZ",
"credentials_type": "group",
"subscribe_devices": ["a6a1f131-a565-4dge-bdbb-b4595a157d53", "86fbab71-0796-4ffe-b2a9-2d9f0233c39c"]
}
}