Additional relay JSON сonfigurations
Some relay protocols support advanced configuration through the JSON Config field.
JSON configuration allows you to:
— modify the transmitted data set
— use processed sensor values
— rename transmitted fields
— filter packets before transmission
— configure special transmission scenarios
Supported parameters depend on the selected relay protocol.
JSON configuration is specified in the JSON Config field when creating or editing a relay configuration.
Wialon Retranslator
Transmitting processed sensor values
Allows relay transmission of sensor values after they have been processed by the PILOT system.
For example, a fuel level sensor can be transmitted after calibration has been applied.
Example
{
"sensors_use": {
"fuel_1": 135785,
"NameSensor": 228
}
}
|
-
sensors_use — list of object sensors whose processed values should be used
-
fuel_1 — parameter name transmitted to the destination system
-
135785 — sensor ID in the system
The sensor ID can be found in the object sensor settings.
-
Fuel level sensors must have calibration configured correctly
-
Values outside the calibration range are transmitted as raw values
-
For example, instead of liters, a raw value such as 65530 may be transmitted
Sensor filtering and processing
Example
{
"sensors_use": {
"temp_1": 1370805,
"temp_2": 1370806
},
"tags_rewrite": {
"temp_2": "temp2",
"temp_01": "temp1"
},
"sensors_filter": {
"temp_1": {
"max": 130,
"min": 1,
"type": "int"
},
"temp_2": {
"max": 100,
"min": 1,
"type": "int"
}
},
"sensors_notuse": {
"temp_1": 1,
"temp_2": 1
}
}
|
-
sensors_use — allows the use of specified object sensor values
-
tags_rewrite — renames parameters before transmission
Example:
{
"tags_rewrite": {
"temp_2": "temp2"
}
}
|
In this case, temp_2 will be transmitted as temp2.
-
sensors_filter — filters sensor values before transmission
Supported parameters:
|
Parameter
|
Description
|
|
type
|
Data type. Currently only int is supported
|
|
min
|
Minimum allowed value
|
|
max
|
Maximum allowed value
|
Example:
{
"sensors_filter": {
"temp_1": {
"min": 1,
"max": 130,
"type": "int"
}
}
}
|
Filtering works only for sensors transmitting integer values.
-
sensors_notuse — excludes sensors from transmission
Example:
{
"sensors_notuse": {
"temp_1": 1,
"temp_2": 1
}
}
|
This configuration prevents the specified sensors from being transmitted.
Sensor settings configured in PILOT do not affect relay processing through this mechanism. All transmission parameters must be configured explicitly in JSON config.
|
Packet filtering
Allows packets matching specified conditions to be excluded from transmission.
Example
{
"packet_filter": {
"Valid": "0"
},
"keys_to_skip": [
"HardVersion"
]
}
|
-
packet_filter — skips a packet if a specified parameter contains the configured value.
Example:
{
"packet_filter": {
"Valid": "0"
}
}
|
If the Valid parameter equals 0, the packet will not be transmitted.
Multiple conditions can be configured.
-
keys_to_skip — skips a packet if it contains any specified field
Example:
{
"keys_to_skip": [
"HardVersion"
]
}
|
If the packet contains the HardVersion field, it will not be transmitted.
Multiple fields can be specified.
Wialon IPS and Wialon IPS v2
Parameter renaming
Allows parameter names to be replaced before transmission.
Example
{
"params": {
"Vsourse": {
"name": "pwr_ext",
"type": "int"
}
}
}
|
In this example, the Vsourse parameter is transmitted as pwr_ext.
Sending IButton in the packet body
Example
{
"params": {
"IButton": {
"type": "tcp_box"
}
}
}
|
How it works
When the IButton parameter is configured with the tcp_box type, the identifier value is transmitted in the packet body.
If the parameter is missing, the IButton value is not added to the packet and an empty value is transmitted.
This option is commonly used to transmit a driver identifier outside the standard parameter block.
inputs block
Allows additional digital inputs to be generated based on sensor values.
Example
{
"inputs": {
"DIN1": {
"max": 1,
"min": 1,
"value": false,
"myval": false
}
},
"params": {
"DIN1": {
"name": "DIN1",
"type": "int"
}
}
}
|
inputs parameters
|
Parameter
|
Description
|
|
min
|
Minimum allowed value
|
|
max
|
Maximum allowed value
|
|
value
|
If set to true, the actual sensor value is transmitted. If omitted or set to false, standard packet generation logic is used
|
|
myval
|
Allows a custom value to be transmitted instead of the sensor value when the condition is met
|
Simplified example
{
"inputs": {
"DIN1": {
"max": 1,
"min": 1
}
},
"params": {
"DIN1": {
"name": "DIN1",
"type": "int"
}
}
}
|
If the sensor value falls within the range from 1 to 1, the value 1 is transmitted.
This mechanism is typically used to duplicate sensor states as binary values.
For example, it can be used to transmit door status through the inputs block.
Wialon Retranslator, Galileo, and EGTS
Field renaming
Example
{
"tags_rewrite": {
"temperature": "galileo_temp_0",
"digital": "galileo_in_2"
}
}
|
Allows field names to be replaced before transmission.
Examples:
-
temperature→ galileo_temp_0
-
digital→ galileo_in_2
Saving relay logs
Example
{
"save_data_for_report": "1"
}
|
Enables storage of relay data for reporting, diagnostics, and troubleshooting purposes.
Temperature data generation
Example
{
"temperature_data_generator": {
"DOS": "galileo_in_2",
"closed_value": 0,
"temperature_sensors": [
"galileo_temp_0"
]
}
}
|
This configuration is intended for special integration scenarios.
When specified conditions are met, the system can automatically generate temperature sensor values.
Parameters
|
Parameter
|
Description
|
|
DOS
|
Monitored sensor
|
|
closed_value
|
Value that triggers the condition
|
|
temperature_sensors
|
List of temperature sensors
|
This functionality is designed for specific integration requirements and should only be used when requested by the receiving system.