UI Reference

Screen-by-screen guide to the embedded web interface

This section explains what each screen is for, how to read it, and which controls matter in day-to-day work. Use it together with the workflow chapters when you need to understand the interface itself.

How to use this section

Workflow chapters focus on procedures. This reference focuses on what the operator sees on screen: pages, panels, buttons, selectors, warnings, and changing runtime states.

What every screen description covers

  • Purpose Why the page exists and when to open it.
  • Main regions Which parts of the layout carry the most meaning.
  • Key controls Which buttons, selectors, and actions are important.
  • State changes What changes between normal, warning, and degraded cases.
  • Dependencies What changes because of selected line, device, or operating mode.

Screen family map

Login

The login page is the first screen an operator sees. It should stay simple in the documentation: one clean example is enough to show the credential form and the language chosen automatically from the browser.

Setup

Setup defines the communication lines, devices, channels, and commands that later appear in the live interface. It is the main configuration surface and needs the most detailed field-by-field explanation.

Control

Control is the main runtime page for observing a selected device and sending commands. It must explain how to distinguish a healthy live state from stale or offline data.

Dashboards

Dashboards summarize the state of a larger area or system. They are intended for quick interpretation rather than detailed editing.

Scenarios and Scenario Log

These pages explain how automation rules are created, enabled, and later reviewed through execution history.

Storage and Modbus Log

These pages help operators and support engineers inspect stored files, exported data, and communication evidence.

Settings and Help

Settings explain system-level behavior, while Help provides built-in reference material inside the product itself.

Quick overview

Login

First access to the system and the start of every operator session.

Setup

Communication lines, devices, channels, and commands.

Control

Live values, device state, and command execution.

Diagnostics

History, evidence, and system support surfaces.

Examples and what to notice

Login

  • Purpose: authenticate the operator and enter the web interface.
  • Key regions: username, password, submit action, and visible page language.
  • What to notice: the page stays minimal and immediately understandable.

Login page

Login page on the English interface.
A single login example is enough for this section.

Setup

  • Purpose: describe the real system model used later by Control, dashboards, automation, and logs.
  • Key regions: line settings, device list, device editor, channel editor, and command editor.
  • What to notice: each saved field affects runtime behavior later.

Line editor

Setup line editor on the English interface.
Use this example to explain baud rate, parity, timing, and line-level behavior.

Device editor

Setup device editor on the English interface.
This view explains identity, address, naming, and the device structure.

Channel editor

Setup channel editor on the English interface.
Use this example to connect a register definition to a later Control value.

Command editor

Setup command editor on the English interface.
This example explains how a saved command becomes an operator action.

Control

  • Purpose: inspect live state and send commands to the selected device.
  • Key regions: device selector, value area, online or offline status, and command area.
  • What to notice: healthy values, degraded trust, and visible result after a command.

Healthy live state

Control page showing a healthy online device state in English.
Fresh values and a stable online device.

Stale or offline state

Control page showing a stale or offline device state in English.
A degraded state that should be recognized immediately.

Command result

Control page after an operator command in English.
The visible state after a command has been executed successfully.

Dashboards

  • Purpose: show the state of a zone, room, or system at a glance.
  • Key regions: widgets, alarm emphasis, summaries, and navigation between views.
  • What to notice: the difference between normal overview and warning state.

Scenarios and Scenario Log

  • Purpose: configure rules and verify later how they executed.
  • Key regions: scenario list, editor blocks, enable state, and execution entries.
  • What to notice: how rule logic becomes evidence in the log.

Storage and Modbus Log

  • Purpose: inspect files, exported data, and communication history.
  • Key regions: tree navigation, file list, selected-file actions, and line-specific history.
  • What to notice: where stored evidence differs from live runtime data.

Settings and Help

  • Purpose: understand system-wide options and built-in product guidance.
  • Key regions: operating mode fields, integration-dependent sections, maintenance actions, and help navigation.
  • What to notice: which settings change the system behavior and where Help explains data formats.

How to read the examples

  • Start with the purpose of the page, then inspect the main regions.
  • Compare normal and degraded states to see what changes first during a problem.
  • Use command examples to verify what successful control looks like in practice.
  • Remember that selected line, selected device, and operating mode can change the page content.