Custom UI

This example explains how to customize plugin UI interactions when using the dobot-plus skill in an AI Agent via function descriptions in Requirements.md. The Skill generates function.json and ui/Main.tsx from your requirements; this page covers layout conventions, available component types, and how to specify UI explicitly or rely on default inference.

Workflow

The UI page is one step in the Skill workflow, generated alongside Lua, HTTP, and block/script configs:

For the full development flow, see Adapting Modbus RTU Devices or Adapting I/O Devices.

Page Layout

When generating pages, the dobot-plus skill uses a fixed left-right split layout:

Area	Position	Content
Device status	Left Card	Read-only status display (read functions)
Control panel	Right Card	Parameter inputs and action buttons (write / control functions)

Do not change this layout rule in Requirements.md. Changing the split to stacked layouts, multiple tabs, or other structures makes Agent behavior unstable and produces unpredictable pages.

Pages use antd as the base component library (react@18 + antd@5). The root node is DobotPlusApp, and MQTT pushes real-time updates to the left status area.

Specifying UI in Requirements.md

Add a UI interaction description line under each function. The Agent maps it to the ui field in function.json.

Recommended Format

Under a function section (e.g. ### 4.1 SetSpeed — set speed), add:

### 4.1 SetSpeed — set speed

- Action: write speed register, range 0~100
- Parameter: speed (number, default 50)
- UI: Slider

Short forms also work:

- UI: button
- UI: read-only status
- UI: select (options: Mode A / Mode B / Mode C)

Function Type vs UI Mapping

Function type	Typical naming	Suggested UI	Placement
No-parameter control	StartDevice, OpenGripper	Button	Right control area
Parameterized write	SetSpeed, SetForce	Slider / Input / Select	Right control area
Enum selection	SetMode, SetChannel	Select / Radio / Dropdown	Right control area
Boolean toggle	EnableVacuum	Switch / Checkbox	Right control area
Status read	GetStartStatus, GetPosition	Tag / Text / Table	Left status area
File operation	ImportConfig	Upload	Right control area

Read functions also need a keyWord (English camelCase noun, e.g. startStatus) assigned during Agent decomposition for MQTT status push and page binding. Write functions use an empty keyWord.

Component Types

The component types below map one-to-one to ui enum values in function.json.

Display Components

Used in the left Device status area for read-only, no-input functions.

Component	ui value	Use case	Requirements.md example
Read-only text	No fixed enum; Agent may use tag or Statistic	Single numeric or string status	UI: read-only text / UI: read-only status
Tag	tag	Boolean or enum status with color distinction	UI: Tag (1=running, 0=stopped)
Table	table	Multi-row, multi-field status list	UI: table showing channel status

Control Components

Used in the right Control panel area. Parameterized functions render controls in the form; functions with ui: button are grouped in the bottom button area.

Component	ui value	Use case	Requirements.md example
Input	input	Numeric or text parameter input	UI: input (range 0~255)
Slider	slider	Continuous value adjustment (speed, force, etc.)	UI: slider (0~100)
Select	select	Single choice from many options	UI: select (options: A / B / C)
Dropdown	dropdown	Dropdown menu selection	UI: Dropdown menu
Radio	radio	Few mutually exclusive options	UI: radio (on / off / auto)
Switch	switch	Boolean toggle	UI: switch
Checkbox	checkbox	Boolean checkbox	UI: checkbox
Button	button	No-parameter immediate action (start, stop, reset)	UI: button
Upload	upload	File import	UI: file upload

Default Inference Rules

If a function description does not specify a UI type, the Agent infers from semantics and parameter types:

Function characteristic	Default UI
No-parameter control / trigger	Button
number parameter with a clear range	Slider
number / string parameter without range or needing precise input	Input
Enum or limited options	Select or Radio
boolean parameter	Switch
Read-only status returning boolean or discrete enum	Tag
Read-only status returning number / string	Read-only text (Statistic)
Multi-row structured data	Table

Explicitly writing UI types in Requirements.md is recommended, especially for edge cases (e.g. "force as slider, mode as radio, status as Tag") to reduce mismatches.

Full Example Snippets

The following is from the I/O control example, showing buttons paired with read-only status:

### 4.1 StartDevice — start external device

- Action: `DO(1, ON)` — high level on DO-1
- UI: button

### 4.2 GetStartStatus — read start status

- Action: read `DI(1)`
- Return: `1` = started; `0` = not ready
- UI: read-only status

Common parameter + control combination for Modbus devices:

### 4.1 SetVacuumLevel — set vacuum level

- Action: write register 0x0001, range 0~100 (%)
- Parameter: level (number, default 50)
- UI: slider

### 4.2 ActivateVacuum — turn on vacuum

- Action: write control word bit0 = 1
- UI: button

### 4.3 GetVacuumStatus — read vacuum status

- Action: read status register bit0
- Return: `1` = on, `0` = off
- UI: Tag

Generated Output

After the Skill finishes, UI-related files are:

File	Description
function.json	Per-function ui, keyWord, params, etc.
ui/Main.tsx	Plugin control UI (Agent fills TODOs from function.json)
.dobot/http/http.ts	Frontend HTTP client
lua/httpAPI.lua	Controller-side HTTP handlers

The Agent first generates a Main.tsx scaffold via page.js, then completes interaction logic per function.json and Skill conventions. To tweak copy or styling afterward, edit ui/Main.tsx directly; i18n strings live in Resources/i18n/.

Note: The Skill allows only antd components for UI generation—do not use @dobot-plus/components.

UI Example Screenshots

• OnRobot VG10 (Modbus RTU — slider + button + status)

• DH AG-95

• I/O control (button + read-only status)

FAQ

Generated UI component type does not match expectations

Add an explicit UI: line under the function in Requirements.md, remove ambiguous wording, and re-run /dobot-plus. For a single control tweak, edit the ui field in function.json and update ui/Main.tsx manually.

Left status area shows no data

• Confirm read functions have a keyWord (check function.json)
• Confirm DobotPlusApp MQTT push works (Skill defaults to useMqtt={true})
• Use dpt dev with a real device and verify Lua return values

Buttons and parameter controls are misplaced

By convention, ui: button controls render at the bottom of the right form; other control components render in the form field area. Do not request custom layout in Requirements.md.

Need custom components or complex pages

The current Skill targets standard Dobot+ plugin scenarios with the antd components and fixed left-right layout above. For complex interactions, manually rewrite ui/Main.tsx after /dobot-plus, or refer to the Basic IO example.

Related Links

• Adapting Modbus RTU Devices
• Adapting I/O Devices
• Agent Skill Overview
• Development Guide — Build & Use