Typical gateway connection patterns

How to choose a topology

Pattern 1. One local RS-485 segment

The simplest pattern: the gateway polls RTU 1 devices, the operator uses Control and dashboards, and logs are stored locally. External integration may be disabled.

flowchart LR
    O[Operator laptop] -->|HTTP| G[UMEC Gateway]
    G -->|RTU 1 / RS-485| D1[Meter]
    G -->|RTU 1 / RS-485| D2[Sensor]
    G -->|RTU 1 / RS-485| D3[Controller]
    G --> S[(Storage / Logs)]

Pattern 2. Two independent RS-485 lines

Use two lines when devices are physically separated, use different serial parameters, or one group must remain available if the other segment has a problem.

flowchart LR
    G[UMEC Gateway]
    G -->|RTU 1: 9600 8N1| A1[Ventilation]
    G -->|RTU 1: 9600 8N1| A2[CO2 sensors]
    G -->|RTU 2: 19200 8E1| B1[Meters]
    G -->|RTU 2: 19200 8E1| B2[Relay modules]
    UI[Web UI] --> G

Pattern 3. Local RTU devices plus TCP device

The TCP channel is used for network Modbus devices and integration endpoints. Do not treat it as transparent RS-485: it has its own polling, not-polling, and disabled modes.

flowchart LR
    G[UMEC Gateway]
    G -->|RTU 1| R1[RS-485 devices]
    G -->|TCP bus3| T1[Modbus TCP device]
    G -->|TCP tunnel| T2[Remote Modbus endpoint]
    G --> C[Control / Dashboards / Automation]

Pattern 4. Local site plus MQTT

MQTT is enabled after local operation is verified. The gateway keeps polling locally and sends prepared telemetry outward. Losing the broker should not stop local Control and scenarios.

flowchart LR
    D[RTU/TCP devices] --> G[UMEC Gateway]
    G --> UI[Local web UI]
    G -->|MQTT / Wi-Fi or Ethernet| B[(Broker)]
    B --> P[SCADA / Cloud / Analytics]

Pattern 5. SCADA reaches RTU through Modbus TCP server

Here the gateway accepts Modbus TCP requests and routes them to RTU lines. This is useful when the upper system speaks Modbus TCP while field devices remain on RS-485.

flowchart LR
    S[SCADA / PLC] -->|Modbus TCP| L[Gateway listener]
    L --> G[UMEC Gateway route map]
    G -->|RTU 1| A[Slave ID 1..20]
    G -->|RTU 2| B[Slave ID 21..40]
    G --> N[NAT / strict map]

Pattern 6. NAT for repeated addresses

NAT is useful when different segments contain the same slave IDs, but the external system must see them as distinct addresses. Do not use NAT as a substitute for clean addressing: every rule must be explicit and verifiable.

flowchart LR
    S[Modbus TCP client] --> G[Gateway NAT]
    G -->|source unit 101 -> RTU1 unit 1| A[Device A / unit 1]
    G -->|source unit 102 -> RTU2 unit 1| B[Device B / unit 1]
    G -->|priority order| R[NAT rules]

Pattern 7. Multiple gateways for dispatching

Large sites often work better with several gateways placed close to equipment: one in the metering cabinet, one near ventilation, and one in a remote pump room. SCADA or a dispatching server receives data from every gateway, while local diagnostics remain available in each zone.

flowchart LR
    subgraph Site[Site]
      G1[Gateway A / Metering cabinet] --> M1[Meters]
      G2[Gateway B / Ventilation] --> V1[AHU / CO2 / dampers]
      G3[Gateway C / Pump room] --> P1[Pumps / sensors]
    end
    G1 -->|MQTT or Modbus TCP| D[Dispatching]
    G2 -->|MQTT or Modbus TCP| D
    G3 -->|MQTT or Modbus TCP| D
    D --> O[Operator / engineer]

Pattern 8. Distributed sites in UMEC Space

UMEC Space fits deployments with many sites: stores, warehouses, pump stations, ventilation rooms, and metering cabinets. Each gateway collects data locally, while the platform shows the site list, communication status, alarms, trends, and aggregated dashboards. Customers operate sites in UMEC Space Dashboard, with mobile access through UMEC Home or UMEC Business.

flowchart LR
    subgraph Stores[Distributed sites]
      A[Store 1 / Gateway]
      B[Store 2 / Gateway]
      C[Warehouse / Gateway]
      D[Pump station / Gateway]
    end
    A -->|MQTT over TLS / site credentials| U[(UMEC Space)]
    B -->|MQTT over TLS / site credentials| U
    C -->|MQTT over TLS / site credentials| U
    D -->|MQTT over TLS / site credentials| U
    U --> M[Dispatcher]
    U --> E[Service engineer]

Worked examples

Screen set for topology verification

Common RS-485 mistakes

From box to first dashboard

Security checklist