Smart Gateway

How Modbus RTU-to-MQTT Conversion Happens at the Gateway

For a piece of field data to enter the platform, two things must be settled first: by what protocol it travels upward, and what the gateway converts the downstream device protocol into. The approach given by the product knowledge base is to write the answer into the model number: the model rule of the FG lightning-protection smart gateway encodes, segment by segment, the gateway type, the mounting method, the power supply, the downlink and the uplink, so that reading the model reveals its uplink/downlink combination. The gateway type falls into two classes, transparent transmission and protocol conversion, and protocol conversion takes place at the edge layer of the general monitoring-system architecture, carried by devices such as the lightning-protection smart gateway and the intelligent edge-computing gateway. Devices commonly use Modbus RTU, Zigbee and LoRa on the downlink, and Modbus TCP or MQTT on the uplink over Ethernet or 4G, with IEC 61850 optional at the gateway level. This article explains how to read the model, where the protocol is converted, and the uplink/downlink relationship to align during selection, and it marks the boundary of the material.

2026-09-26 Smart Gateway FEXLINK 8 min
FG gateway: reading the model and protocol conversion
FG gateway: reading the model and protocol conversion

Direct answer

For a piece of field data to enter the platform, two things must be settled first: by what protocol it travels upward, and what the gateway converts the downstream device protocol into. The approach given by the product knowledge base is to write the answer into the model number: the model rule of the FG lightning-protection smart gateway encodes, segment by segment, the gateway type, the mounting method, the power supply, the downlink and the uplink, so that reading the model reveals its uplink/downlink combination. The gateway type falls into two classes, transparent transmission and protocol conversion, and protocol conversion takes place at the edge layer of the general monitoring-system architecture, carried by devices such as the lightning-protection smart gateway and the intelligent edge-computing gateway. Devices commonly use Modbus RTU, Zigbee and LoRa on the downlink, and Modbus TCP or MQTT on the uplink over Ethernet or 4G, with IEC 61850 optional at the gateway level. This article explains how to read the model, where the protocol is converted, and the uplink/downlink relationship to align during selection, and it marks the boundary of the material.

1. Model rule: encoding the uplink/downlink relationship

The product knowledge base records that the model rule of the FG lightning-protection smart gateway is "FG – gateway type, mounting method, power supply – downlink, uplink". That is, the first half of the model describes the device itself and the second half describes how it connects to the two sides above and below.

The advantage of this writing is readability. During procurement and wiring one need not first open the manual, because the model already distinguishes what the downlink side connects to and what the uplink side uses. For system integration, this layer of information saves one confirmation. In the model rule the gateway type takes only two values, 01 and 02, corresponding respectively to transparent transmission and protocol conversion, which is the starting point for understanding the division between the two gateway classes.

2. Transparent transmission and protocol conversion: two gateway types

Gateway type 01 is transparent transmission and 02 is protocol conversion. Transparent transmission means the data passes through the gateway in its original form and the gateway does not change its protocol form; protocol conversion means the gateway performs one protocol translation between the downlink and the uplink.

The two classes face different scenarios. When the field device and the platform use the same protocol, transparent transmission suffices; when the field device uses a downlink such as RS485 or Zigbee while the platform side needs another protocol over Ethernet, protocol conversion is needed to bridge them. The product knowledge base places the two together in the model rule, showing that the first step of selection is not to look at the number of interfaces but to determine whether conversion is needed at all.

3. Comparison of two specific models

The model table of the product knowledge base gives two examples that confirm the reading above. The FG lightning-protection smart gateway (FG-0221-ER) is powered at DC12V, has a data-transmission mode of protocol conversion, with RS485 downlink and Ethernet uplink. The FG lightning-protection smart gateway (FG-0221-EZ) is likewise DC12V and protocol conversion, the difference being a Zigbee downlink with Ethernet still on the uplink.

Set side by side, the difference is concentrated in the "downlink" segment: ER corresponds to RS485 and EZ to Zigbee. Both use Ethernet on the uplink, showing that they are consistent on the platform side and differ only in what is connected on the line side. This is exactly the value of the model encoding: under the same power supply and the same gateway type, changing one field corresponds to another fieldbus.

4. Protocol conversion happens at the edge layer

Protocol conversion is not a matter for the platform side but a responsibility of the edge layer. The product knowledge base divides the general monitoring-system architecture into perception layer, edge layer, platform layer and application layer, where the edge layer is made up of the lightning-protection smart gateway, the intelligent edge-computing gateway, the industrial wearable and the cloud PLC, with the duties of protocol conversion, edge computing and local caching.

Keeping this layer's responsibility clear prevents looking in the wrong direction during troubleshooting. If the downlink protocol will not connect, the problem is between the edge layer and the perception layer; if the uplink protocol will not connect, the problem is between the edge layer and the platform layer. Since protocol conversion is completed at the edge layer, the gateway is the hub of this segment. The product knowledge base also shows that protocol conversion is one of the three duties of the edge layer, alongside edge computing and local caching.

5. Communication protocol matrix and common suffixes

The specific protocol names are given by the communication protocol matrix of the product knowledge base. Device downlink protocols include Modbus RTU (RS485), Zigbee (Modbus) and LoRa; device uplink protocols include Modbus TCP and MQTT (over Ethernet or 4G), with IEC 61850 optional at the gateway level.

The common suffixes are a shorter way of marking within the model. The product knowledge base records: -R is RS485 (Modbus), -E is Ethernet (MQTT) and -Z is Zigbee (Modbus), with some products offering 4G (MQTT) as an option. This shows that MQTT is not something outside the physical link but is carried over an uplink such as Ethernet or 4G. Reading the suffixes against the protocol matrix, the model fields and the protocol names line up one to one.

6. Access capability of the edge-computing gateway

Beyond protocol conversion, the edge layer also has devices that carry edge computing. The model table of the product knowledge base records that the ESX intelligent edge-computing gateway (ESX-0223-GR) is powered at DC5V, with an access capability of 30 devices and 2000 data points, RS485 downward and wired 4G upward; the CW industrial gateway (CW-C1) is powered at DC24V, with RS485 downward and Ethernet upward.

These parameters show that the edge-computing gateway and the lightning-protection smart gateway sit at similar positions on the link but with different emphases: the former stresses access scale and local processing, the latter stresses protocol conversion in a protection scenario. During selection one first checks whether the device count and data points are sufficient, then aligns the power supply and the uplink/downlink modes.

7. Align uplink and downlink before selection

Taken together, selection can proceed in one order: first determine the protocol of the field devices, then see what protocol the platform side needs, and on that basis decide between transparent transmission and protocol conversion; next check whether the power supply and mounting method match the field conditions; and finally confirm whether the rated access capability covers the field device count and data points.

The basis for this order comes from the model rule itself: it writes the gateway type, power supply, downlink and uplink into the number, showing that these are exactly the items that must be determined first during selection. The product knowledge base gives no single answer corresponding to specific field conditions, so this article explains only the alignment relationship and does not decide for the reader which model a given site should choose.

Scope and limitations

First, this article only restates the content listed in the product knowledge base; the factual boundary is limited to the model rule and model table of the FG lightning-protection smart gateway, the general four-layer monitoring-system architecture, the communication protocol matrix, the common suffixes, and the model-table records of the ESX intelligent edge-computing gateway and the CW industrial gateway.

Second, in the model rule of the FG lightning-protection smart gateway, gateway type 01 as transparent transmission and 02 as protocol conversion, and the power supply, protocol-conversion mode, downlink and uplink of FG-0221-ER and FG-0221-EZ, are quoted as recorded in the product knowledge base; this article does not infer unlisted model combinations.

Third, that the edge layer is made up of the lightning-protection smart gateway, the intelligent edge-computing gateway, the industrial wearable and the cloud PLC, with the duties of protocol conversion, edge computing and local caching, is quoted as recorded in the product knowledge base.

Fourth, the downlink Modbus RTU (RS485), Zigbee (Modbus) and LoRa and the uplink Modbus TCP, MQTT (Ethernet, 4G) and IEC 61850 (gateway level, optional) of the communication protocol matrix, together with the common suffixes -R, -E and -Z and the optional 4G (MQTT) of some products, are quoted as recorded in the product knowledge base.

Fifth, the 30 devices and 2000 data points of the ESX intelligent edge-computing gateway and the power supply and uplink/downlink of the CW industrial gateway are quoted as recorded in the product knowledge base; this article does not infer other access scales or field performance.

Sixth, this article explains only how to read the model, where protocol conversion takes place and the alignment relationship for selection; it provides no specific engineering networking, address planning or setting scheme.

Related Knowledge

Why Gateway Local Caching Matters
Smart Gateway

Why Gateway Local Caching Matters

Local caching occupies an independent place among gateway capabilities because it determines whether data survives an uplink interruption. According to the existing product material, the general four-layer architecture of the monitoring system lists protocol conversion, edge computing and local caching side by side as the duties of the edge layer; in the intelligent-gateway reference parameters of the grounding-resistance monitoring system, the data-cache item gives a convention of not less than fifteen days, with no fewer than one hundred and twenty-eight mount points that can be cascaded, together with multiple serial ports and multiple Ethernet ports. That is, the cache is not attached storage but a definite capability written into the edge-layer duties and the system reference parameters. For outage or cascade scenarios, its meaning is to keep field data from being lost while it cannot be uploaded, and to back-fill it once the link recovers. This article restates these existing conventions only and does not infer the cache-capacity configuration or back-fill strategy of any specific project.

2026-10-03
First Put the Edge Layer Back into the Four-Layer Architecture
Smart Gateway

First Put the Edge Layer Back into the Four-Layer Architecture

Under the conventions of the product knowledge base, edge computing in the edge layer is not a vague term but one responsibility standing alongside protocol conversion and local caching. The product knowledge base divides the general architecture of the monitoring system into four layers, in which the responsibilities of the edge layer are summarised as protocol conversion, edge computing and local caching, and its composition includes access gateways, the industrial wearable and the cloud PLC. As for edge computing itself, the carriers explicitly named in the product knowledge base are the edge-computing instructions in the programmable logic control software, and the local acquisition and processing actions performed by the gateways, the wearable and the cloud PLC. It should be noted that, within the text of the product knowledge base, the specific algorithm list of edge computing is not expanded, so this article states only the positioning of edge computing, its carrying devices and the access order, and does not write an algorithm list on behalf of the product knowledge base or count unlisted algorithm capabilities as present.

2026-10-03
First Look at the Recommended Combination Given by the Scenario
Smart Gateway

First Look at the Recommended Combination Given by the Scenario

For online monitoring of substation and traction-substation grounding grids, the recommended combination given in the typical application scenarios and selection comparison of the product knowledge base is: the grounding resistance monitor (FR-01311, one set per point), the lightning-protection smart gateway (FG) and the FEXCloud platform. That is, monitoring units are laid out by grounding point, one set per point, then aggregated by the lightning-protection smart gateway and finally connected to the platform. As for the gateway configuration, the system-level smart-gateway reference parameters of the product knowledge base give mounting of no fewer than 128 points with cascading, at least 4 RS485 channels, at least 2 Ethernet channels, optional 4G, 5G or LoRa, a data cache of at least 15 days, a wide supply of DC9 to 36 volts and IP65 protection. The product knowledge base gives no point table, wiring scheme or acceptance convention of a specific project, so this article states only the recommended combination, gateway parameters and range classification without expanding them into an engineering scheme.

2026-10-03

Want a deeper look at FEXLINK solutions?

Contact the FEXLINK solutions team for customised solutions and technical support.