What this device is and why it exists

If explained in the simplest possible way

Imagine a control cabinet with several devices inside: controllers, sensors, meters, and actuators. They all exchange data over Modbus. The gateway becomes the central point where you can see them, configure them, monitor them, and connect the site to the outside world.

For the user this means one very practical advantage: instead of scattered settings, manual register work, and unclear service files, there is one understandable control point.

What the gateway actually does

• stores line and device settings without reflashing;
• polls devices continuously and updates live values;
• provides a readable web interface for day-to-day work;
• runs local automation scenarios;
• keeps logs and diagnostic evidence;
• sends data outward and accepts outside requests when the site really needs that.

How the work usually unfolds

Most projects do not begin with cloud integration or polished dashboards. First the device must be reachable, the communication lines must work, and the field devices must respond. Only after that does it make sense to move into daily operation, automation, and outside integration.

flowchart LR
    A[Power on] --> B[First login
to the web interface]
    B --> C[Set network
and time]
    C --> D[Set Modbus
lines]
    D --> E[Add
devices]
    E --> F[Verify
live values]
    F --> G[Daily operation
and scenarios]
    G --> H[Integrations
if needed]

Why local operation comes first

On real sites the internet may be unstable, the upper-level system may not be ready yet, and the cabinet still needs to work. That is why the core idea is simple: first local stability, then outside links.

In short, the gateway must remain useful on its own. Even without the cloud, it should keep polling devices, showing them in the interface, and running local logic.

Three logical channels you should know about

In the documentation you will see three names: RTU 1, RTU 2, and TCP. These are not random modes. They are the three logical channels through which the gateway works with devices.

• RTU 1 The first RS-485 line, with its own settings and devices.
• RTU 2 The second RS-485 line, configured independently from the first.
• TCP The network Modbus channel, used for TCP devices and part of the integration logic.

Operating mode in normal human terms

Operating mode is separate from the communication lines. It defines how the gateway should behave toward the outside world. For example, it may work with UMEC Space IoT Cloud, use Generic MQTT, or stay fully local.

It is important not to confuse the two ideas: operating mode is about the external side of the system, while the Modbus lines are about communication with field devices.

stateDiagram-v2
    [*] --> UMEC_SPACE
    UMEC_SPACE --> MQTT_GENERIC: external MQTT selected
    MQTT_GENERIC --> MQTT_DISABLED: external path disabled
    MQTT_DISABLED --> UMEC_SPACE: back to UMEC Space
    state UMEC_SPACE {
      [*] --> Cloud_Work
    }
    state MQTT_GENERIC {
      [*] --> MQTT_Work
    }
    state MQTT_DISABLED {
      [*] --> Local_Only
    }

How this documentation is organized

This wiki is organized around real user tasks, not around internal firmware modules. You do not need to understand the code before you understand what to do on site.