UMEC Space Wiki | UMEC Space Platform

The main idea

Many sites already have useful equipment: meters, sensors, variable-frequency drives, ventilation controllers, pump stations, power equipment, climate systems, and other Modbus devices. Without a platform, those values often stay local: visible to an engineer next to the cabinet, a site SCADA system, or someone opening the gateway web interface.

With UMEC Space, the gateway changes the level of the solution. It does not only read registers; it turns local Modbus points into visible, controllable, and serviceable digital objects on the platform. Values can be shown on dashboards, exposed in mobile applications, used for notifications and alerts, passed into scenarios, or integrated with outside systems.

UMEC Space Dashboard

Customers sign up, sign in, and operate their site through dashboard.umec.deviot.cloud.

What appears after provisioning

After successful provisioning, the gateway should appear in the customer account. If it does not, first check UMEC_SPACE mode, Cloud runtime, MQTT connected, and active uplink on the local Settings page.

Where to upload models

The model JSON exported from the gateway Modbus device card is uploaded in Dashboard under Models. After upload, it appears as a Custom Model.

Existing equipment does not have to be replaced

If a device already speaks Modbus RTU or Modbus TCP, the gateway can become its platform path: reading values, sending commands, and forwarding state.

The platform makes the site visible

Data stops being only a local register table. It becomes readable cards, charts, states, notifications, and actions in UMEC Space.

Local reliability remains

The gateway should prove local operation first: the line responds, values are fresh, and commands are verified. Platform connection then adds remote visibility and control.

Why this is more than a local gateway

Capability	Local gateway only	Gateway + UMEC Space
Monitoring	An operator opens local Control or a dashboard inside the site network.	State can be shown on platform dashboards and viewed remotely.
Mobile access	Usually requires local network access, VPN, or presence on site.	Mobile applications can expose state and actions for business users and end users.
Alerts and notifications	Problems are noticed when someone opens the interface or watches a local system.	Events can become notifications, alerts, and service reactions according to the project rules.
Control	Commands are sent from local Control or local scenarios.	Allowed commands can become platform actions with permissions and audit context.
Scaling	Each site has to be understood separately.	Similar sites can use a shared model for dashboards, notifications, and support.
Integrations	The integrator builds MQTT, storage, API, roles, UI, and mobile experience separately.	UMEC Space provides the platform path with cloud, API, dashboard, and applications.

Data path from Modbus to the platform

flowchart LR
    A[Modbus equipment
meters, sensors, drives, controllers] --> B[UMEC Modbus Gateway]
    B --> C[Local proof
line, device, fresh values, commands]
    C --> D[UMEC_SPACE mode]
    D --> E[UMEC Space IoT Cloud Platform]
    E --> F[Dashboards]
    E --> G[Mobile apps]
    E --> H[Alerts and notifications]
    E --> I[Remote control]
    E --> J[API and integrations]

What the business gains

Fast site digitization

The project does not have to start by replacing all equipment. The gateway connects existing Modbus points and makes them available for platform workflows.

Unified dashboards

Values from different devices can be collected into readable panels: engineering values, states, warnings, trends, rooms, zones, or equipment groups.

Mobile applications

For the business, this means remote monitoring and service work. For end users, it means a simpler interface to the capabilities the project chooses to expose: state, notifications, actions, and history.

Alerts and notifications

Thresholds, offline states, faults, abnormal values, and service events can become notifications. This reduces dependence on manual checks of the local interface.

Remote control

Commands that are safe and allowed for the project can become platform actions: changing a setpoint, switching a mode, acknowledging a fault, or running a service operation.

Less integration routine

A typical project does not need to assemble cloud, dashboard, mobile UI, API, roles, and notifications separately. The gateway uses the UMEC Space platform path.

What operators and service teams gain

The operator sees readable device names, channels, units, and states rather than raw register addresses.
The dispatcher gets a site or fleet overview instead of a separate local screen for each cabinet.
The service team can identify the fault domain faster: network, Modbus line, device, command, platform, or permissions.
The business can expose different interface levels: technical views for operations and simpler views for end users.
History, states, and notifications help move from reactive support to regular monitoring.

How to connect the gateway to UMEC Space

The correct sequence remains local-first. The platform amplifies a proven system, but it should not hide line errors or an incorrectly defined device.

Prove local operation In Setup, configure the line and device. In Control, confirm fresh values and commands. Do not move to the platform if the device is only saved but not responding.

Select UMEC_SPACE mode In Settings, choose the platform mode. This is the primary path when the gateway should operate as part of UMEC Space.

Complete provisioning Check cloud context, credentials, and connectivity. BLE/provisioning belongs to the platform mode. After successful provisioning, the customer can sign in to UMEC Space Dashboard and see the bound gateway in the account.

Verify runtime Read actual state, not only saved configuration: Cloud runtime, MQTT connected, uplink ready, errors, and counters.

Upload device models For each configured Modbus device, export the model JSON from the gateway through the device model export action, then upload that file to UMEC Space Dashboard under Models. Uploaded files appear as Custom Models.

Configure the platform view Decide which devices, channels, and commands belong on dashboards, in mobile apps, alerts, and notifications. Sensor data and control commands map correctly on the platform after the device models are registered in Models.

Set permissions and control boundaries Not every command should be available remotely. Allow only actions that are safe for the specific site and user role.

How to put the gateway into pairing mode

Mobile pairing is part of the UMEC Space path. It is available only when the gateway runs in UMEC_SPACE mode and the device has a working local configuration. Pairing does not replace Modbus commissioning.

Open Settings and select UMEC_SPACE as the operating mode.
Check Network/Uplink and confirm that the gateway has a working outward path.
Install UMEC Home for iPhone or UMEC Home for Android on the phone, enable Bluetooth, and allow location access if the phone requests it for BLE device discovery.
Connect the phone to the 2.4 GHz Wi-Fi network where the gateway should operate. Do not use a 5 GHz network for first pairing.
Open the UMEC/provisioning block in Settings and start BLE/provisioning. If the web password was lost, use soft recovery first.
In the app, tap + or Add device on the main screen. Keep the phone close to the gateway and follow the app prompts.
When the app asks for a network, select the 2.4 GHz Wi-Fi network and enter its password. Then tap Connect device.
Wait for connection to finish. On success, the app shows a device identifier, such as a MAC address or device number, and asks for a readable device name.
After pairing is confirmed, sign in to UMEC Space Dashboard and confirm that the gateway appears in the customer account.
Return to Settings and verify Cloud runtime, MQTT connected, active uplink, errors, and counters. If pairing fails, restart BLE/provisioning and add the device again.

How to use the mobile app

The mobile app is the operator-facing UMEC Space view for already provisioned equipment. The common flow is the same across UMEC Space devices: sign in, choose the site or object, add the device if it is not yet bound, then use dashboards, notifications, history, and allowed commands according to the project permissions.

UMEC Home on the App Store - for private users and home sites.
UMEC Home on Google Play - the Android version for private users and home sites.
UMEC Business on Google Play - the Android app for companies, installers, service teams, and UMEC Space operational roles.

Use dashboards for current values and business-level status, not for low-level line debugging.
Use notifications and alerts after channel thresholds and freshness rules are configured.
Use remote commands only when the command is intentionally exposed and safe for the user role.
Use UMEC Space Dashboard for platform setup: customer registration, the provisioned gateway view, and uploading device models under Models.
Before expecting telemetry on the platform, export model JSON from the gateway and upload it as a Custom Model. Without the model, the platform may see the gateway but not know which sensors and commands to expose.
If the app does not show the expected device, check UMEC_SPACE mode, pairing state, cloud runtime, and local Modbus proof.

What “seamless integration” means

In this documentation, “seamless” does not mean that the site needs no commissioning. Modbus lines, addresses, registers, channels, and commands still have to be configured correctly. Seamless means that the gateway has a native UMEC_SPACE mode, platform provisioning, a unified runtime context, and a predictable telemetry and command path.

For the operator, this is one product route: first the gateway proves local communication with equipment, then that equipment appears in UMEC Space platform logic where it can be visualized, controlled, notified on, and integrated with the rest of the solution.

Boundaries and security

Local proof first, cloud second: the platform should not mask incorrect Modbus settings.
Remote control should be enabled only for commands that are safe and understood by the site owner.
Passwords, tokens, and MQTT/platform secrets must not be shown in plain text and must not be written to logs.
If outside connectivity is lost, the gateway should remain useful locally: Control, local scenarios, logs, and diagnostics still matter.
Dashboards, mobile screens, alerts, and notifications depend on the exact project configuration and user permissions.

Where to go next

Quick Start for the short path from first login to local proof and mode selection.
Commissioning for detailed line, device, channel, and command setup.
Settings for UMEC_SPACE mode, runtime truth, uplink, and apply semantics.
Integrations for outside paths, Generic MQTT, Modbus TCP, and integration boundaries.
UMEC Space Dashboard for customer registration, the bound gateway, Models, and Custom Models.
umec.space for the public description of the UMEC platform, applications, and IoT infrastructure.

The gateway's main value is connecting Modbus equipment to the platform