Definition
Edge Gateway (Edge Gateway) aggregates Modbus, OPC-UA, BACnet and other industrial protocol devices within the local area network, and converts them uniformly to MQTT for reporting to the platform. Suitable for factories, buildings, and other dense equipment sites, achieving smooth cloud access for existing industrial devices.
Core Capabilities
The Edge Gateway has Protocol Adaptation capability, supporting multi-protocol collection and conversion; supports Device Access layer communication with the platform via MQTT; can deploy edge computing logic (such as local caching, data aggregation, rule pre-execution); supports offline resumption and caching, automatically synchronizing after network recovery.
Deployment Scenarios
Suitable for scenarios with dense on-site equipment and diverse protocols, such as factory workshops, intelligent buildings, energy stations, and substations. The gateway is deployed on-site and connects to industrial devices via Ethernet or serial port, and to the cloud via 4G/5G/wired connection. It supports Device Onboarding, sub-device management, and remote upgrades, achieving unified operation and maintenance of the gateway and sub-devices.
Comparison with Direct Connection Mode
Direct Connection Mode: Devices have IP capability and connect directly to the cloud. Gateway Mode: Devices connect through the gateway proxy, suitable for existing non-IP devices and heterogeneous protocol scenarios. The gateway acts as a proxy for the devices, handling sub-device registration, data reporting, and command forwarding, while the platform manages sub-devices indirectly through the gateway.
Where the gateway session ends and the cloud session begins
An edge gateway is the boundary between two sessions, not another directly connected endpoint. Southbound, it keeps Modbus slave polling, an OPC-UA secure channel, or BACnet object subscriptions. Timeouts, byte order, register addresses, and object identifiers stay on the local network. Northbound, it reports only engineering values and alarms that already follow the platform contract. The gateway therefore keeps both identities: a slave id, node path, or point name mapped to one sub-device under a product. A service call from the platform reaches the gateway first, then becomes a register write or a method call. Properties in the thing model should be engineering values from the point list, not unexplained fragments of a message. If the gateway is treated as a serial pass-through, the platform cannot assign a point to a specific sub-device, and the device shadow, alarms, and remote maintenance all lose their object. Catch-up reports cached during an outage must carry the time they were collected. Otherwise, once the link returns, the history curve is written as if it had just happened.
Site conditions that justify a gateway
Bringing existing devices in through a gateway usually requires several conditions at once. The device has no protocol stack suited to the public network, or its protocol session must not be exposed there. Devices are concentrated in the same cabinet, shop, or floor, so a cellular link for each one does not pay. The site can power a gateway continuously and connect it by serial, Ethernet, or a field bus. A local cache is useful only when the gateway has enough storage and the platform accepts catch-up by timestamp. If a sub-device can already hold an encrypted long-lived connection, and certificates or keys can be written per unit on the line, forcing a gateway in front of it only adds a fault that takes the whole group offline. Gateway firmware updates and point-list changes should be scheduled apart, so one reboot does not stop collection and reporting together. Before one point list is reused across shops, slave addressing and byte order have to match. Collecting a number is not the same as collecting the right number.
When the point list and sub-device identities diverge
The usual field error is a point list that does not match the wiring: a register offset by one, byte order reversed, or the two registers of a float swapped. The platform then draws a curve that cannot be real, and alarm thresholds stop meaning anything. Another error is using a repeatable slave address as the unique id on the platform. After a cabinet is moved or a gateway configuration is copied, two devices collapse onto one shadow. If the gateway process is still alive, the southbound bus is down, and sub-devices still show as online, the gateway heartbeat is being taken for the sub-device heartbeat. Reporting only a one-minute average smooths out the excursion at the moment of failure, so later diagnosis cannot find the raw point. A write that waits in the gateway queue with no deadline can, when the network returns, operate a breaker that was requested hours earlier. Point lists should be versioned. Quality stamps and collection time should be kept. An unreachable sub-device and an unreachable gateway should be shown separately. Keep the previous point list after publication so it can be compared. If a field rewire changes only the gateway memory and not the mapping on the platform, a reboot returns to the old, wrong address.