AI-assisted Configuration Generation

Tell the AI the device model, wiring, and desired features; the AI organizes them into configuration files, which you then import via Device Configuration → Advanced Config → Config Import/Export. This reduces the work of adding peripherals and execution rules one by one.

Any ordinary AI chat tool works — no skill installation and no firmware code changes are needed for configuration generation. The AI generates candidate configs; the device's existing import flow checks and prepares them for application, and you verify the actual effect after restart.

Applicability

Confirm the device version first

This page follows the firmware/web whole-set migration implementation verified on 2026-10-05 and applies to versions that have the "Stage and precheck", "Migration status", and "Apply on next restart" flow. It describes the current source capability and does not mean all released firmware or online devices already have this flow.

If an older device shows different UI, import results, or endpoint fields, first verify the firmware and web versions, then follow the Device Configuration description for the corresponding version. Do not assume an old version can apply a config just because the JSON parses.

Which Files Can Be Generated

Generate only the files needed this time; you do not need to pack all types into one bundle.

Config content	File	Usage boundaries
Peripheral definitions	peripherals.json	Defines GPIO, buses, sensors, displays, etc.; verify the board, wiring, and driver capability
Triggers and actions	periph_exec.json	Configures local timed, event, polling, or platform-triggered rules; references must resolve
Feature switches	features.json	Based on the target's existing feature config, enable compiled features with satisfied dependencies as needed
Basic device info	device.json	Merges only allowed name, location, description, time, logging, and similar fields; identity and account bindings are not migrated
Data-transform scripts	rule_scripts.json	Generate only when transformation is needed and the target supports it; ordinary GPIO linkage needs none
Screen layout	screen_panel.json	Must match the target screen capabilities and data sources; not a generic substitute for OLED peripheral parameters
Point-history configuration	point_history.json	Configures recording sources and policies; does not include historical sample data
IR keys	ir_keys.json	Only for target versions with the corresponding IR capability

The fields device.json may currently merge are deviceName, location, description, enableNTP, ntpServer1, ntpServer2, timezone, syncInterval, logLevel, cacheDuration. Device identity, product/account bindings, developer mode, and other target fields keep their original values and are re-verified by the server.

How Network and Protocol Settings Are Handled

Network config such as Wi-Fi in network.json, MQTT/Modbus connection config in protocol.json, and users.json and auth.json are outside the writable scope of the current unified import entry and must not be added to an AI-generated package.

For example, when a requirement states "GPIO5 controls an LED, GPIO8 controls a relay, plus Wi-Fi and MQTT connection info", the AI should deliver the peripheral and execution config package and separately list the filling checklists for the Network Configuration and MQTT Configuration pages. Network passwords and MQTT keys are filled in by the user on the device pages and do not need to be handed to the AI.

Local buttons, timers, or sensor linkage can work independently of MQTT; only platform control or platform reporting requirements need the corresponding protocol configuration. That connection info cannot be imported through this entry does not mean the firmware must be modified to use existing local automation.

Preparation

Information to provide	Example or notes
Target hardware	Full board/module model, chip, Flash/PSRAM, and the current active board type; do not write just "ESP32"
Firmware and web	Firmware version or build environment, web version, and target feature support
Peripherals and wiring	Model, power supply, GPIO, bus, and address; a reviewed wiring diagram or manual excerpt can be provided
Output behavior	Active-high/low, on or off after initialization, whether state is held when offline
Trigger entries	Button, timer, sensor condition, platform command, or other entries; describe both on and off
Data and feedback	Collection period, report identifiers, display fields, how invalid/expired data is handled
Config baseline	New config or modifying an existing device; for an existing device, provide the relevant target export files
Protocol prerequisites	Whether MQTT is connected and the fields actually delivered by the platform; whether Modbus already has serial, slaves, and tasks

If you only say "GPIO5 controls an LED, GPIO8 controls a relay, and the LED turns on when the relay opens", the board type, active levels, initial states, off behavior, and control entries still need to be determined. The AI should fill in this information first and must not assume a particular chip or relay module on its own.

Preserving Existing Configuration

Export and preserve the relevant original configs from the target device first. Before handing materials to an external AI, check whether names, texts, templates, or scripts contain identity information, passwords, or other private content; keep the raw backup locally.

Files such as peripherals.json and periph_exec.json are treated as the complete candidate content of the selected files — a file containing "only new entries" is not automatically appended to the device's original file. The AI should merge changes at generation time, preserving original IDs, untouched peripherals, rules, feature selections, and their references. Do not use empty arrays or empty files as placeholders for "types not currently needed".

If other configs reference the IDs being modified, provide those dependencies for the AI to verify as well; only the complete files that actually need changes go into the generated package. When the target export is missing, first supplement the baseline, or explicitly confirm this is a new config with nothing to preserve.

From Requirement to Import

1. Prepare materials: confirm the target hardware, versions, existing configs, and requirements. When a platform is involved, complete the network and protocol settings on the dedicated pages first.
2. Generate the candidate: copy the prompt in the next section, attach the requirements and necessary materials. The AI lists missing items first; once the information is complete, it outputs one fastbee-config.json package plus a change description.
3. Verify and save: check pins, active levels, initial states, on/off actions, trigger entries, and preservation of the original config. Save the complete JSON as a UTF-8 .json file without Markdown fences, comments, or explanatory text inside.
4. Select and preview: log in to the target device and confirm the developer-mode feature is enabled. Go to Device Configuration → Advanced Config → Config Import/Export and select the config package; select interdependent files such as peripherals, execution, and features together.
5. Stage and precheck on target: review the file preview, confirm on the page, then run the whole-set staging and precheck. The target device verifies the complete candidate, existing dependencies, features, and resources; fix errors, regenerate, and preview again — do not skip conflicts.
6. Confirm the preparation result: review the target precheck and the items requiring confirmation, then complete preparation. prepared, applied=false, restartRequired=true means "prepared, applies on next restart". The page does not restart automatically, and the runtime state has not switched at this point.
7. Restart and verify: after confirming the prepared state and field conditions, schedule a restart separately. Reconnect to the same target device, check applied, restored, or conflicted results via "Migration status" and config readback, then verify triggers, data, and outputs.

Check status first when the result is unclear

A lost, timed-out, or incomplete response during import does not mean nothing was written. Click "Migration status" to confirm the stage first and keep the error message; do not resend the whole package or restart repeatedly. Handling is documented in Device Configuration.

An ordinary config package may contain enabled rules that could auto-execute by condition after the restart load. Cross-board migration requires wiring remapping with peripherals and rules kept disabled, re-verified before enabling.

The current whole-set candidate file contents total at most 128 KiB, individual files may have smaller limits, and target runtime resources apply. Do not bypass limits by splitting required dependencies; that the page can read a file does not mean the device can apply it.

Prompt You Can Copy Directly

Copy the whole block below and fill in the inputs at the end. The prompt carries the formats of the base package, digital outputs, and platform-switch rules; dedicated sensors, collection actions, display, and Modbus still need description excerpts or export templates of the target version. When the AI cannot read a link, it should ask you to supply the content and must not claim to have read it or fabricate fields from memory.

You are a FastBee-Arduino configuration assistant. Based on the target device, wiring,
requirements, and exported configs I provide, generate candidate files that can pass
the device's existing "Config Import/Export" entry precheck.
Use an ordinary conversation only: no skills, no firmware modifications, no device
connections, and no actions.

1. Confirm requirements first
1. List the board/module, chip, Flash/PSRAM, firmware and web versions, active board
   type, and supported features. Do not default to ESP32, and do not treat another
   same-chip board's wiring table as this board's available pin table.
2. List each peripheral's model, wiring, active level, initial state, and on/off
   trigger entries. The initial state is not the electrical state before driver
   initialization at reset — the latter needs hardware guarantees.
3. Distinguish "one command executes both the relay and LED actions" from "the LED
   follows whenever any entry changes the relay". The latter must verify each control
   entry, state source, and propagation mechanism; do not claim satisfaction by
   generating just one set of dual-action rules.
4. Confirm whether this is a new config or a modification. For an existing device,
   use my exported target files as the baseline: preserve untouched entries, original
   IDs, other feature selections, and dependencies; merge at generation time before
   outputting complete files.
5. When key hardware, behavior, protocol semantics, or the config baseline are
   missing, ask first and list the items to confirm. A requirement summary is fine,
   but do not call guessed configs ready to use.

2. Generation scope
- Common files: peripherals.json, periph_exec.json; add features.json only when
  feature changes are needed.
- On demand: device.json, rule_scripts.json, screen_panel.json, point_history.json,
  ir_keys.json; target capability and the corresponding format basis are required.
- Do not include network.json, protocol.json, users.json, or auth.json. List the
  filling steps on the device's dedicated pages for Wi-Fi, MQTT, and Modbus
  connection settings; do not copy secrets.
- device.json provides only the allowed merge fields: deviceName, location,
  description, enableNTP, ntpServer1, ntpServer2, timezone, syncInterval, logLevel,
  cacheDuration. Do not generate identity, product/account binding, or developer
  mode changes.
- features.json format: version=1, features is an object, and each feature entry
  uses {"enabled":true/false}. For example features.lcd.enabled is a boolean; the
  actual output must preserve the target's other feature selections. A sparse
  features file is not an incremental patch. Enable only features that the target
  has compiled, whose dependencies are satisfied, and that this requirement needs.
  Do not fabricate feature keys such as mqtt, and do not enable scripts or all
  optional features by default for ordinary GPIO rules.
- Do not generate empty placeholder files or use empty arrays to unintentionally
  wipe existing config. Selected files are treated as complete candidates; the total
  content must not exceed 128 KiB and remains subject to per-file and resource limits.

3. Base format basis
1. Ordinary target-device config package: type="fastbee-config-bundle", version=1,
   scope="selected"; files is an array where each item contains name and content.
   name is a supported config file name; content is the complete JSON serialization
   of that file as a string — not a nested object, not a file path. Inner quotes
   must be correctly escaped, and both the inner and outer levels must JSON.parse.
   Do not invent a package format, and do not use scope="reusable-plan", which
   requires extra source declarations and a board-swap flow.
2. The peripherals.json root object contains only the peripherals array. Each
   peripheral has a string id, name, a numeric type, a boolean enabled, a pins
   array, and a params object. IDs are unique and stable. Native GPIO digital
   output: type=12, pins=[actual GPIO], params.ioSource=0, and params.initialState
   is the physical level 0 or 1. An active-high LED initialized off takes 0; an
   active-low relay initialized off takes 1. These are conditional examples only —
   the actual values follow my confirmed wiring and active levels.
3. The periph_exec.json root object contains a rules array. Each rule includes:
   id, name (strings), enabled (boolean), execMode=0, triggers (array), actions
   (array), protocolType=0, scriptContent="", reportAfterExec=false. Each rule has
   at least 1 trigger and 1 action; the current maximum is 3 triggers and 4 actions.
   Do not generate "pure-manual rules" with empty triggers; the upper-limit count
   is not proof the target has enough memory.
4. Platform switch trigger with MQTT configured: triggerType=0, triggerPeriphId=
   the platform item.id, operatorType=0 (equals), compareValue="1" or "0".
   triggerPeriphId is the platform message identifier and need not equal the
   peripheral id. Local timer triggerType=1, event=4, polling=5; their specific
   sources, periods, and event fields must follow the target export or the
   corresponding documentation — do not reuse the platform-trigger format.
5. Digital-output action fields: targetPeriphId=target peripheral id, actionType
   is a number, actionValue="", useReceivedValue=false, syncDelayMs=0, execMode=0.
   actionType=0 outputs physical high, 1 outputs physical low; 13 is inverted high
   (logical on, physical low), 14 is inverted low (logical off, physical high). Each
   action's target, type, and active level must match.
6. Verify peripheral ids, collection/report ids, platform trigger ids, and protocol
   mappings separately. Not all peripherals are required to use sensorId, and a
   platform field matching does not promise no execution rule is needed.
7. For peripheral types, actions, scripts, screens, and protocol sources not listed
   in this prompt, do not fill fields out of thin air. Use the target-version
   documentation or export templates I provide; when materials are unreadable or
   insufficient, ask first. Modbus identity is managed by protocol configuration —
   do not fabricate it in peripherals.json. Collection and display must verify
   completion state, validity, and data freshness; a fixed delay is not proof that
   collection completed.

4. Output requirements
1. Give a short requirement summary first: wiring, active levels, initial states,
   trigger entries, on/off behavior, and preserved content.
2. If key items are missing, give the to-confirm list first; once complete, output
   one complete fastbee-config.json package. Unless I ask for proofreading or
   per-file imports, do not re-output all inner files and their stringified copies.
3. List added, modified, and preserved content, plus the settings that must be
   completed on the network/protocol pages first.
4. Verify the package and inner JSON, duplicate file names, IDs, action types,
   references, and feature dependencies. Say "JSON parse passed" only if you ran a
   parsing tool; otherwise write "tool parsing not run". Always distinguish static
   checks, target-device precheck, restart application, and physical verification.
5. Files contain no comments, placeholders, trailing commas, ellipses, or
   explanatory text. If the output is truncated, regenerate the complete affected
   files and re-assemble and re-parse the package — do not recover by stitching
   chat fragments.
6. Remind me to complete selection, preview, staging, target precheck, confirmation,
   a separate restart, and result verification per the page. When a response is
   unclear, check migration status first; do not auto-retry the import or restart.

My inputs:
- Board/module, chip, Flash/PSRAM:
- Firmware version/build environment, web version, active board type:
- Supported/enabled features:
- New or modified; existing related exported configs:
- Peripheral models, power supply, wiring, and active levels:
- Initial states; on/off trigger entries and behavior:
- Collection period, display, reporting, or physical feedback requirements:
- Whether network/protocol is configured; platform fields or existing Modbus sources:
- Content to preserve and other constraints:
- Attached documentation excerpts or exported templates:

Common Scenarios

LED and Relay Linkage

You can provide a requirement like the following, fill in the bracketed information, and hand it to the AI:

Target board and version: [actual info]. GPIO5 is connected to an LED lit by high
level, and GPIO8 to a relay module energized by low level. Both are off after
initialization.
When the relay is opened via [local button/platform command/other explicit entry],
the LED lights up; when closed, the LED turns off.
This time only this control entry needs to execute the two output actions.
[If it must follow under any entry's control, rewrite this sentence and list all
entries actually used.]
Existing related configs: [provide the target export; or confirm this is a new
config with nothing to preserve].

The local-button scenario also needs the input peripheral, button wiring, and event basis; it does not require MQTT connected first. GPIO5/GPIO8 are just this requirement's wiring, not recommended pins applicable to all ESP32-family boards.

The following is a field-complete platform-control example package to illustrate the final deliverable form. Conditions of use:

• The example hardware is ESP32-S3-WROOM-1-N16R8 with build environment esp32s3-F16R8; verify on the target's active board type that GPIO5/GPIO8 are not occupied by other functions and confirm the active levels above.
• The target uses the whole-set migration version described on this page; MQTT is configured and connected on the protocol page, and the platform sends the relay_switch field to the target's configured control topic.
• The target's peripheral and execution files have no other entries to preserve. Devices with existing configs must be merged by the AI on their export baseline — do not replace them directly with this example.
• The example explicitly enables two peripherals and two rules; after restart they run by the platform trigger conditions, and no new optional script features are needed. It contains no feature, device, or protocol files.

State or command	GPIO8 relay	GPIO5 LED
After peripheral initialization	High level, off	Low level, off
relay_switch="1"	Action 13, low level, on	Action 0, high level, lit
relay_switch="0"	Action 14, high level, off	Action 1, low level, off

The two actions execute in rule order; hardware switching at the same time is not guaranteed, and there is no whole-output rollback guarantee. They respond only to the control entry agreed here and do not prove the LED follows when other buttons, rules, or direct-control interfaces change the relay; the LED expresses control intent and does not prove the relay contacts or load have acted.

Save the following complete content as fastbee-config.json:

{
  "type": "fastbee-config-bundle",
  "version": 1,
  "scope": "selected",
  "files": [
    {
      "name": "peripherals.json",
      "content": "{\"peripherals\":[{\"id\":\"led1\",\"name\":\"Status LED\",\"type\":12,\"enabled\":true,\"pins\":[5],\"params\":{\"ioSource\":0,\"initialState\":0}},{\"id\":\"relay1\",\"name\":\"Relay\",\"type\":12,\"enabled\":true,\"pins\":[8],\"params\":{\"ioSource\":0,\"initialState\":1}}]}"
    },
    {
      "name": "periph_exec.json",
      "content": "{\"rules\":[{\"id\":\"relay_on\",\"name\":\"Relay and light on\",\"enabled\":true,\"execMode\":0,\"triggers\":[{\"triggerType\":0,\"triggerPeriphId\":\"relay_switch\",\"operatorType\":0,\"compareValue\":\"1\"}],\"actions\":[{\"targetPeriphId\":\"relay1\",\"actionType\":13,\"actionValue\":\"\",\"useReceivedValue\":false,\"syncDelayMs\":0,\"execMode\":0},{\"targetPeriphId\":\"led1\",\"actionType\":0,\"actionValue\":\"\",\"useReceivedValue\":false,\"syncDelayMs\":0,\"execMode\":0}],\"protocolType\":0,\"scriptContent\":\"\",\"reportAfterExec\":false},{\"id\":\"relay_off\",\"name\":\"Relay and light off\",\"enabled\":true,\"execMode\":0,\"triggers\":[{\"triggerType\":0,\"triggerPeriphId\":\"relay_switch\",\"operatorType\":0,\"compareValue\":\"0\"}],\"actions\":[{\"targetPeriphId\":\"relay1\",\"actionType\":14,\"actionValue\":\"\",\"useReceivedValue\":false,\"syncDelayMs\":0,\"execMode\":0},{\"targetPeriphId\":\"led1\",\"actionType\":1,\"actionValue\":\"\",\"useReceivedValue\":false,\"syncDelayMs\":0,\"execMode\":0}],\"protocolType\":0,\"scriptContent\":\"\",\"reportAfterExec\":false}]}"
    }
  ]
}

The platform on and off message bodies are respectively [{"id":"relay_switch","value":"1"}] and [{"id":"relay_switch","value":"0"}], and must be sent to the target's configured control topic. The example does not enable auto-reporting; a successful MQTT connection or send is not equal to successful rule execution or load action.

This example illustrates format and behavior; the target-device precheck and physical verification are still required. An initial config cannot guarantee the chip's pin states before driver initialization at reset — the actual circuit should ensure the output state in that phase meets the requirement.

Temperature/Humidity Collection with OLED Display

Target board, version, and existing configs are attached. I need to collect temperature
and humidity with [actual model]; the sensor is wired to [actual GPIO/bus address], the
SSD1306 OLED resolution is [actual resolution], and the I2C SDA/SCL and address are
[actual values].
Collect every 10 seconds and display temperature and humidity on the OLED; MQTT is not
needed.
Follow the attached export template of this version, preserve existing content, and
generate the peripheral and collection/display rules; when feature switches are needed,
adjust based on the complete features.json.
Show an invalid state when collection fails or data expires — do not treat old data or
zero values as this round's success.

The AI should verify the sensor driver, bus references, collection-action fields, display template, and required features such as the display feature for the target. Timed collection differs from periodic-judgment conditions; a fixed 200 ms wait cannot prove collection completed. Incomplete materials should be supplemented before generating files.

Platform Control with Existing MQTT

Network and MQTT are already configured; do not modify connection parameters.
The platform sending [{"id":"relay_switch","value":"1"}] to the target's control topic
means open, and value "0" means close. Wiring, active levels, and existing configs are
attached.
Please add the corresponding platform rules and explain the relationship between action
targets and trigger identifiers.
If status reporting is needed, confirm the reporting fields and their mapping to the
platform Thing Model per the target version first.

Here relay_switch is the platform trigger identifier; relay1 can be the actual peripheral ID, and the two need not share a name. Collection and reporting may also have independent identifiers — do not unify them into some sensorId.

Adding a Feature to an Existing Config

These are peripherals.json, periph_exec.json, and features.json exported from the
target device, with notes on the related screen/history references.
After confirming [new peripheral model and wiring], add only [explicit feature].
Preserve existing IDs, peripherals, rules, feature selections, and display references;
do not delete or rename old entries.
Output a package of complete files that actually changed, and list the added and
preserved counts; if exports or dependencies are missing, point out the gaps first —
do not substitute empty arrays.

Before importing, check against the AI's change summary that the original entries are still there. If only rules change, the peripherals file may be left out of the package, but the AI still needs to know the target's existing peripherals, and the device precheck also verifies target dependencies.

Extending Rules with Existing Modbus

Complete the UART, slave, and task configuration in Modbus RTU Configuration first, then provide the relevant source descriptions, addresses, register meanings, units, and control requirements. The AI can generate collection or control rules based on the target's existing protocol sources; it must not stuff protocol.json into this package, nor create protocol-managed Modbus identities in the peripheral files on its own.

Common Issues and Result Verification

Symptom	How to handle
Package contains network, protocol, or auth files	Remove the unsupported files and use the dedicated pages instead; do not bypass the check by renaming files
JSON reported invalid	Check the outer package and each content string; remove comments and Markdown fences, and regenerate complete files when truncated
Target or data source reported missing	Verify IDs, sources, and types against the existing baseline and the same bundle; do not casually change IDs or delete dependencies to pass
Feature reported unavailable	Distinguish not-compiled, not-enabled, dependency-not-ready, and insufficient resources; a switch alone cannot add an uncompiled driver
Pin, parameter, or resource conflict reported	Fix per the target board type and precheck result; do not borrow another chip's pin table or substitute PSRAM headroom for internal RAM
Busy, low memory, or 503 returned	Check migration status and known results first; when re-operation is confirmed safe, wait per the prompt — do not split dependencies or retry at high frequency
Shows prepared or pending restart	Not yet applied; verify field conditions, restart separately, then check state and config readback
Response lost or timed out	Check "Migration status" first and keep records; do not assume nothing was written and repeat the import
Rule does not execute after application	Check enabled state, trigger entries, platform fields, data validity, execution results, and target feature state
LED and relay states inconsistent	Check active levels, off actions, action failures, and other control entries; a dual-action rule is not all-entry state following

Post-import checks should cover three layers:

1. Config applied: verify the same target device, the migration result, peripheral and rule counts, IDs, enabled states, and preservation of the original config. Restored or conflicted results must not be treated as the new config applied.
2. Business chain works: a local trigger actually happens, or MQTT receives the agreed message; collection, display, rule results, and required reporting meet the requirement. A button confirmation or command enqueue is not action completion.
3. Physical results match expectations: under confirmed wiring and test conditions, check the LED, relay contacts, or load feedback, and test open, close, and post-restart initial states separately. Short-term success is not a long-term-stability pass.

The AI's JSON parsing and reference checks are static verification; device precheck, restart application, physical actions, and long-term runs each need their own evidence and cannot replace one another.

Advanced Topics and References

• Device Configuration and Import/Export: complete operation flow, status queries, and board migration.
• Feature Configuration: feature dependencies, enable states, and effect boundaries.
• Peripheral Configuration Guide: models, wiring, and parameters.
• PeriphExec Configuration Guide: triggers, actions, and references.
• Platform Trigger: matching platform messages to rules.
• Screen Configuration: dedicated structure for screens and data sources.
• Network Configuration, MQTT Configuration, Modbus RTU Configuration: settings that must be completed on the dedicated pages.

For board reuse, prefer the device's "Export reusable plan" and "Board-swap wiring migration". scope: "reusable-plan" requires the source board type and capability declarations, target GPIO remapping, and disabled peripherals and rules; it differs from this page's scope: "selected" package for a confirmed target device — you cannot convert between them by changing only the scope field.