蜂信物联

简体中文

English

简体中文

English

主题

AI辅助生成配置 ​

把设备型号、接线和希望实现的功能告诉 AI，由 AI 整理为配置文件，再进入 设备配置 → 高级配置 → 配置导入/导出 导入，可以减少逐条添加外设和执行规则的操作。

使用普通 AI 聊天工具即可，无需安装技能，也无需为配置生成修改固件代码。AI 负责生成候选配置；设备现有导入功能负责检查并准备应用，重启后再核对实际效果。

适用范围 ​

先确认设备版本

本页依据 2026-10-05 核对的固件/Web 工作区整组迁移实现，适用于具备“暂存并预检”“迁移状态”和“待下次重启应用”流程的版本。这是当前源码能力说明，不表示所有已发布固件或在线设备都已具备该流程。

旧设备若界面、导入结果或接口字段不同，先核对固件与 Web 版本，再参照对应版本的设备配置说明。不要仅凭 JSON 能解析，就认为旧版本也能应用。

可以生成哪些文件 ​

只生成本次需要的文件，不必把全部类型装进一个包。

配置内容文件使用边界
外设定义peripherals.json定义 GPIO、总线、传感器和显示器等；核对板卡、接线及驱动能力
触发与动作periph_exec.json配置本地定时、事件、轮询或平台触发的规则；引用必须能解析
功能开关features.json根据目标原有功能配置，按需启用已编译且依赖满足的功能
设备基本信息device.json仅合并允许的名称、位置、描述、时间、日志等字段；不迁移身份及账号绑定
数据转换脚本rule_scripts.json仅在需要转换且目标支持时生成，普通 GPIO 联动不必添加
屏幕布局screen_panel.json需匹配目标屏幕能力及数据来源，不是 OLED 外设参数的通用替代
点位历史配置point_history.json配置记录来源和策略，不包含历史采样数据
红外按键ir_keys.json仅用于支持相应红外能力的目标版本

device.json 当前允许合并的字段为 deviceName、location、description、enableNTP、ntpServer1、ntpServer2、timezone、syncInterval、logLevel、cacheDuration。设备身份、产品/账号绑定、开发模式及其他目标字段保持原值，并由服务端再次核对。

网络和协议怎样处理 ​

Wi-Fi 等网络配置 network.json、MQTT/Modbus 连接配置 protocol.json，以及 users.json、auth.json，不在当前统一导入入口的可写范围内，不能加入 AI 生成包。

例如，需求中同时给出“GPIO5 控制 LED、GPIO8 控制继电器、Wi-Fi 和 MQTT 连接信息”时，AI 应交付外设与执行配置包，并另列网络配置、MQTT 配置页面的填写清单。网络密码、MQTT 密钥由用户在设备页面填写，不必交给 AI。

本地按键、定时或传感器联动可以独立于 MQTT 工作；只有平台控制、平台上报等需求才需要完成相应协议配置。不能通过本入口导入连接信息，并不代表需要修改固件才能使用已有本地自动化能力。

开始前准备 ​

需要提供的信息示例或说明
目标硬件板卡/模组完整型号、芯片、Flash/PSRAM，以及当前活动板型；不只写“ESP32”
固件与 Web固件版本或构建环境、Web 版本，以及目标功能支持情况
外设与接线型号、供电、GPIO、总线和地址；可提供经审阅的接线图或说明书片段
输出行为高/低电平有效、初始化后开还是关、掉线时是否保持状态
触发入口按键、定时、传感器条件、平台命令或其他入口；开、关都要说明
数据与反馈采集周期、上报标识、显示字段、失效/过期数据如何处理
配置基线全新配置还是修改现有设备；已有设备提供本次相关的目标导出文件
协议前提MQTT 是否已连通、平台实际下发的字段；Modbus 是否已有串口、子设备及任务

若只说“GPIO5 控制 LED，GPIO8 控制继电器，继电器打开时 LED 也打开”，还需确定板型、有效电平、初始状态、关闭行为和控制入口。AI 应先补齐这些信息，不应自行假设为某个芯片或某种继电器模块。

保留已有配置 ​

先在目标设备导出并保全相关原始配置。交给外部 AI 前，检查名称、文本、模板或脚本中是否包含身份信息、口令等私有内容；原始备份留在本地。

peripherals.json、periph_exec.json 等按所选文件的完整候选内容处理，不会把一个“只含新增条目”的文件自动追加到设备原文件。AI 应在生成阶段合并修改，保留原有 ID、未涉及的外设、规则、功能选择及其引用。不要用空数组或空文件为“暂时用不到的类型”占位。

若其他配置引用本次修改的 ID，也要提供这些依赖供 AI 核对；只有实际需要改变的完整文件才放入生成包。目标导出缺失时，先补充基线，或明确确认这是没有待保留条目的新配置。

从需求到导入 ​

  1. 准备材料：确认目标硬件、版本、现有配置和需求。涉及平台时，先在专用页面完成网络与协议设置。
  2. 生成候选：复制下一节提示词，附上需求和必要资料。AI 先列出缺项；信息完整后，输出一个 fastbee-config.json 配置包及变更说明。
  3. 核对并保存：检查引脚、有效电平、初始化状态、开关动作、触发入口和原配置保留情况。将完整 JSON 保存为 UTF-8 的 .json 文件，文件内不包含 Markdown 围栏、注释或解释文字。
  4. 选择与预览：登录目标设备，确认“开发环境功能”已开启。进入 设备配置 → 高级配置 → 配置导入/导出，选择配置包；有依赖的外设、执行、功能等文件一起选择。
  5. 暂存与目标预检：审查文件预览并按页面确认，再进行整组暂存与预检。目标设备会核对完整候选、已有依赖、功能和资源；修正错误后重新生成并预览，不跳过冲突。
  6. 确认准备结果：审阅目标预检和需确认的事项，完成准备。prepared、applied=false、restartRequired=true 表示“已准备，待下次重启应用”。页面不会自动重启，此时运行态尚未切换。
  7. 重启与核验：确认准备状态和现场条件后，单独安排重启。重新连接同一目标设备，通过“迁移状态”和配置回读检查已应用、已恢复或冲突结果，再验证触发、数据和输出。

结果不明时先查状态

导入过程中响应丢失、超时或结果不完整，不等于没有写入。先点击“迁移状态”确认阶段，保留错误信息，不直接重发整包或反复重启。处理方法见设备配置说明。

普通配置包可包含已启用规则，重启加载后可能按条件自动执行。跨板迁移则需要接线重映射并保持外设和规则停用，复核后再启用。

当前整组候选文件内容合计最多 128 KiB，单个文件还可能有更小的限制，并受目标运行资源约束。不要通过拆开必需依赖来绕过限制；页面能读入文件也不表示设备一定能应用。

可直接复制的提示词 ​

复制下方整段，并填写末尾的输入。提示词携带基础包、数字输出和平台开关规则的格式；专用传感器、采集动作、显示、Modbus 等还需要目标版本的说明片段或导出模板。AI 无法读取链接时，应请你补充内容，不能声称已阅读或凭记忆编造字段。

text
你是 FastBee-Arduino 配置助手。请根据我提供的目标设备、接线、需求和导出配置，
生成可供设备现有“配置导入/导出”入口预检的候选文件。
使用普通对话完成，不创建技能，不修改固件，不连接设备或执行动作。

一、先确认需求
1. 列出板卡/模组、芯片、Flash/PSRAM、固件和 Web 版本、活动板型及已支持功能。
   不默认 ESP32，不把同芯片的其他板卡接线表当作本板可用引脚表。
2. 列出每个外设的型号、接线、有效电平、初始化状态，以及开、关触发入口。
   初始化状态不等于复位到驱动初始化前的电气状态，后者需要硬件保证。
3. 区分“一次命令执行继电器和 LED 两个动作”与“任意入口改变继电器时 LED 都跟随”。
   后者必须核对各控制入口、状态来源和传播机制；不能只生成一组双动作规则就宣称满足。
4. 确认新建还是修改已有配置。已有设备以我提供的目标导出文件为基线：
   保留未涉及条目、原 ID、其他功能选择和依赖；先在生成阶段合并，再输出完整文件。
5. 关键硬件、行为、协议含义或配置基线缺失时，先提问并列出待确认项。
   可给需求摘要，不能把猜测配置称为可直接使用。

二、生成范围
- 常用文件：peripherals.json、periph_exec.json；需要变更功能时才加入 features.json。
- 按需支持：device.json、rule_scripts.json、screen_panel.json、point_history.json、
  ir_keys.json；须有目标能力及对应格式依据。
- 不包含 network.json、protocol.json、users.json、auth.json。
  Wi-Fi、MQTT、Modbus 连接设置另列设备专用页面的填写步骤，不复制秘密。
- device.json 只提供允许合并的字段：
  deviceName、location、description、enableNTP、ntpServer1、ntpServer2、timezone、
  syncInterval、logLevel、cacheDuration。不要生成身份、产品/账号绑定或开发模式变更。
- features.json 格式为 version=1，features 是对象，功能项使用 {"enabled":true/false}。
  例如 features.lcd.enabled 是布尔值；实际输出须保留目标其他功能选择。
  稀疏 features 文件不是增量补丁。仅启用目标已编译、依赖满足且本需求必要的功能。
  不编造 mqtt 等功能键，不为普通 GPIO 规则默认打开脚本或全部可选功能。
- 不生成空文件占位，不用空数组无意清空已有配置。
  所选文件作为完整候选处理；总内容不超过 128 KiB，仍须服从单文件和资源限制。

三、基础格式依据
1. 普通目标设备配置包：
   type="fastbee-config-bundle"，version=1，scope="selected"，
   files 为数组，每项包含 name 和 content。
   name 是支持的配置文件名；content 是该文件完整 JSON 序列化后的字符串，
   不是嵌套对象，不是文件路径。内层引号必须正确转义，内层和外层均须能 JSON.parse。
   不自创包格式，不使用需要额外来源声明和换板流程的 scope="reusable-plan"。
2. peripherals.json 根对象仅包含 peripherals 数组。
   每个外设有字符串 id、name，数字 type，布尔 enabled，pins 数组和 params 对象。
   id 唯一且稳定。原生 GPIO 数字输出 type=12，pins=[实际GPIO]，
   params.ioSource=0，params.initialState 为物理电平 0 或 1。
   高电平有效 LED 初始化关闭时取 0；低电平有效继电器初始化关闭时取 1。
   这只是条件示例，实际以我确认的接线和有效电平为准。
3. periph_exec.json 根对象包含 rules 数组。每个规则包括：
   id、name（字符串），enabled（布尔），execMode=0，
   triggers（数组），actions（数组），protocolType=0，
   scriptContent=""，reportAfterExec=false。
   每条规则至少有 1 个触发器和 1 个动作，当前最多 3 个触发器、4 个动作。
   不生成空 triggers 的“纯手动规则”；上限计数不是目标内存足够的证明。
4. 已配置 MQTT 的平台开关触发：
   triggerType=0，triggerPeriphId=平台 item.id，
   operatorType=0（等于），compareValue="1" 或 "0"。
   triggerPeriphId 是平台消息标识，未必等于外设 id。
   本地定时 triggerType=1，事件=4，轮询=5；
   其具体来源、周期、事件字段需依据目标导出或对应说明，不能套用平台触发格式。
5. 数字输出动作字段：
   targetPeriphId=目标外设 id，actionType 为数字，actionValue=""，
   useReceivedValue=false，syncDelayMs=0，execMode=0。
   actionType=0 输出物理高电平，1 输出物理低电平；
   13 是反向高（逻辑开、物理低），14 是反向低（逻辑关、物理高）。
   每条动作的目标、类型和有效电平必须匹配。
6. 外设 id、采集/上报 id、平台触发 id 和协议映射分别核对。
   不要求所有外设都使用 sensorId，也不承诺平台字段匹配后必然无需执行规则。
7. 本提示词未列出的外设类型、动作、脚本、屏幕和协议来源，不凭空补字段。
   使用我提供的目标版本说明或导出模板；资料不可读或不足时先补问。
   Modbus 身份由协议配置管理，不在 peripherals.json 中伪造。
   采集与显示需核对完成状态、有效性和数据时效，不把固定延时当作采集完成证明。

四、输出要求
1. 先给简短需求摘要：接线、有效电平、初始化状态、触发入口、开关行为及保留内容。
2. 缺关键项则先给待确认清单；信息完整后给一个完整 fastbee-config.json 配置包。
   除非我要求校对或分文件导入，不重复输出所有内层文件及其字符串化副本。
3. 列出新增、修改、保留内容，以及必须先在网络/协议页面完成的设置。
4. 核对包和内层 JSON、重复文件名、ID、动作类型、引用和功能依赖。
   能运行解析工具才说“JSON 解析通过”；否则写“未运行工具解析”。
   始终区分静态检查、目标设备预检、重启应用和实物验证。
5. 文件不含注释、占位符、尾逗号、省略号或解释文字。
   输出若截断，重新生成完整受影响文件并重新组包、解析，不靠拼接聊天片段恢复。
6. 提醒我按页面完成选择、预览、暂存、目标预检、确认、单独重启和结果核验。
   响应不明时先查迁移状态，不自动重试导入或重启。

我的输入：
- 板卡/模组、芯片、Flash/PSRAM：
- 固件版本/构建环境、Web 版本、活动板型：
- 已支持/启用的功能：
- 新建或修改；现有相关导出配置：
- 外设型号、供电、接线和有效电平：
- 初始化状态；开、关触发入口与行为：
- 采集周期、显示、上报或实物反馈要求：
- 网络/协议是否已配置；平台字段或已有 Modbus 来源：
- 需要保留的内容和其他限制：
- 随附说明片段或已导出模板：

常见场景 ​

LED 与继电器联动 ​

可先提供这样的需求，补齐方括号中的信息后交给 AI：

text
目标板卡和版本：[填写实际信息]。GPIO5 接高电平点亮的 LED，
GPIO8 接低电平吸合的继电器模块。初始化后两者都关闭。
通过[本地按键/平台命令/其他明确入口]打开继电器时，LED 点亮；关闭时 LED 熄灭。
本次只要求该控制入口执行两个输出动作。
[如需任意入口控制都跟随，改写这一句，并列出实际使用的所有入口。]
现有相关配置：[提供目标导出；或确认这是没有待保留条目的新配置]。

本地按键场景还需输入外设、按键接线和事件依据；它不要求先连接 MQTT。GPIO5/GPIO8 只是本需求中的接线，不是所有 ESP32 系列板卡都适用的推荐引脚。

以下给出一个字段完整的平台控制示例包，便于理解最终交付形式。使用条件：

  • 示例硬件为 ESP32-S3-WROOM-1-N16R8，构建环境 esp32s3-F16R8；须在目标活动板型核对 GPIO5/GPIO8 未被其他功能占用，并确认上述有效电平。
  • 目标使用本页所述整组迁移版本，MQTT 已在协议页配置并连通，平台向目标订阅的控制主题发送 relay_switch 字段。
  • 目标外设和执行文件中没有其他待保留条目。已有配置的设备须由 AI 在其导出基线上合并，不能直接用这个示例替换。
  • 示例明确启用两个外设和两条规则；重启后按平台触发条件运行，无需新增可选脚本功能。未包含功能、设备或协议文件。
状态或命令GPIO8 继电器GPIO5 LED
外设初始化后高电平，关闭低电平，熄灭
relay_switch="1"动作 13，低电平，打开动作 0，高电平，点亮
relay_switch="0"动作 14，高电平，关闭动作 1，低电平，熄灭

两个动作按规则顺序执行，不保证硬件同时切换，也没有两个输出的整体回滚保证。它们仅响应这里约定的控制入口，不能证明其他按钮、规则或直接控制接口改变继电器时 LED 也会跟随；LED 表示控制意图，不证明继电器触点或负载已动作。

保存以下完整内容为 fastbee-config.json：

json
{
  "type": "fastbee-config-bundle",
  "version": 1,
  "scope": "selected",
  "files": [
    {
      "name": "peripherals.json",
      "content": "{\"peripherals\":[{\"id\":\"led1\",\"name\":\"状态灯\",\"type\":12,\"enabled\":true,\"pins\":[5],\"params\":{\"ioSource\":0,\"initialState\":0}},{\"id\":\"relay1\",\"name\":\"继电器\",\"type\":12,\"enabled\":true,\"pins\":[8],\"params\":{\"ioSource\":0,\"initialState\":1}}]}"
    },
    {
      "name": "periph_exec.json",
      "content": "{\"rules\":[{\"id\":\"relay_on\",\"name\":\"继电器与灯打开\",\"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\":\"继电器与灯关闭\",\"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}]}"
    }
  ]
}

平台打开和关闭的消息体分别为 [{"id":"relay_switch","value":"1"}]、[{"id":"relay_switch","value":"0"}]，须发送到目标已配置的控制主题。示例没有开启自动上报，MQTT 连接成功或发送成功不等于规则执行和负载动作成功。

本示例用于说明格式和行为，仍需目标设备预检与实物验证。初始化配置不能保证芯片复位到驱动初始化前的引脚状态，实际电路应保证该阶段的输出状态符合需求。

温湿度采集与 OLED 显示 ​

text
目标板卡、版本、现有配置见附件。我需要用[实际型号]采集温湿度，
传感器接[实际GPIO/总线地址]，SSD1306 OLED 分辨率为[实际分辨率]，
I2C SDA/SCL 和地址分别为[实际值]。
每 10 秒采集一次，在 OLED 上显示温度和湿度，不需要 MQTT。
请依据所附该版本导出模板，保留已有内容，生成外设和采集/显示规则；
需要功能开关时基于完整 features.json 调整。
采集失败或数据过期时显示无效状态，不把旧数据或零值当作本轮成功。

AI 应核对传感器驱动、总线引用、采集动作字段、显示模板和所需功能，例如目标对应的显示功能。定时采集与周期判断条件不同；固定等待 200 ms 不能证明采集已经完成。不完整的资料应补齐后再生成文件。

已有 MQTT 的平台控制 ​

text
网络和 MQTT 已配置，不修改连接参数。
平台向目标的控制主题发送 [{"id":"relay_switch","value":"1"}] 表示打开，
value 为 "0" 表示关闭。接线、有效电平和现有配置见附件。
请新增对应平台规则，并说明动作目标与触发标识之间的关系。
如需状态上报，请先依据目标版本确认上报字段和平台物模型对应关系。

这里的 relay_switch 是平台触发标识；relay1 可以是实际外设 ID，两者无需同名。采集和上报还可能有独立的标识，不能统一改成某个 sensorId。

在已有配置中增加功能 ​

text
这是从目标设备导出的 peripherals.json、periph_exec.json 和 features.json，
并附上相关屏幕/历史引用说明。
请在确认[新外设型号与接线]后，只增加[明确功能]。
保留已有 ID、外设、规则、功能选择和显示引用，不删除或重命名旧条目。
输出实际发生修改的完整文件组成的配置包，并列出新增与保留数量；
如果导出内容或依赖缺失，先指出缺项，不用空数组代替。

导入前对照 AI 的变更摘要检查原有条目仍在。若只改变规则，外设文件可以不放入包，但 AI 仍需知道目标既有外设，设备预检也会核对目标依赖。

已有 Modbus 的规则扩展 ​

先在 Modbus RTU 配置中完成 UART、子设备和任务配置，再提供相关来源说明、地址、寄存器含义、单位及控制需求。AI 可以基于目标已有协议来源生成采集或控制规则；不能把 protocol.json 塞入本包，也不能在外设文件中自行创建协议管理的 Modbus 身份。

常见问题与结果核验 ​

现象应如何处理
包里包含网络、协议或认证文件移除不支持的文件，改用专用页面设置；不要改文件名绕过检查
提示 JSON 无效检查外层包和每个 content 字符串；去掉注释和 Markdown 围栏，截断时重新生成完整文件
提示目标或数据源缺失对照现有基线及同组文件核对 ID、来源和类型；不能随意改 ID 或删除依赖来通过
提示功能不可用区分未编译、未启用、依赖未就绪和资源不足；仅添加开关无法补上未编译驱动
提示引脚、参数或资源冲突按目标板型和预检结果修正；不要套用其他芯片引脚表或以 PSRAM 余量替代内部 RAM
返回忙碌、低内存或 503先核对迁移状态和已知结果；确认可重新操作后按提示等待，不拆散依赖、不高频重试
显示已准备或待重启还未应用；核对现场条件后单独重启，再检查状态和配置回读
响应丢失或超时先查“迁移状态”，保留记录；不要假设未写入后直接重复导入
应用后规则不执行检查启用状态、触发入口、平台字段、数据有效性、执行结果及目标功能状态
LED 与继电器状态不一致检查有效电平、关闭动作、动作失败和其他控制入口；双动作规则不是全入口状态跟随

导入完成后的检查应覆盖三个层次：

  1. 配置已应用：核对同一目标设备、迁移结果、外设和规则数量、ID、启用状态及原配置保留情况。已恢复或冲突不能当作新配置已应用。
  2. 业务链路有效：本地触发实际发生，或 MQTT 收到约定消息；采集、显示、规则结果和必要上报符合需求。按钮确认或指令入队不等于动作完成。
  3. 实物结果符合预期：在已确认的接线和测试条件下检查 LED、继电器触点或负载反馈，并分别测试打开、关闭和重启后的初始状态。短时成功不等于长期稳定通过。

AI 的 JSON 解析和引用检查属于静态核验；设备预检、重启应用、实物动作及长期运行需各自的证据，不能互相替代。

进阶与参考 ​

换板复用时，优先使用设备提供的“导出可复用方案”和“换板接线迁移”。scope: "reusable-plan" 需要来源板型与能力声明、目标 GPIO 重映射，并停用外设和规则；它与本页面向已确定目标设备的 scope: "selected" 配置包不同，不能只修改 scope 字段互相转换。

蜂信物联 | fastbee.cn

Copyright © 2026-present 曲靖蜂信科技有限公司