1. 从老人夜灯需求到 ESP32-S3 项目骨架老人上厕所夜灯这个场景表面看是个小夜灯实际要解决两件事一是记录老人整晚起夜频率用来观察身体状态变化二是判断老人进厕所后停留时间是否异常比如超过 15 分钟没出来就要触发提醒。这类需求适合用 ESP32-S3-DEVKITC-1 做原型因为它自带 Wi-Fi、GPIO 够用、还能跑 MicroPython开发节奏比纯 C 快很多。我这次用 TraeCN 的 SOLO 模式来搭这个项目。SOLO 模式的特点是你说清楚目标它自己拆任务、建目录、写骨架、跑测试你主要负责审阅和补配置。整个流程会覆盖 MicroPython 固件烧录、项目骨架生成、Proteus 仿真联调以及一个绕不开的坑Proteus 9.0 SP2 模拟不了 Wi-Fi所以依赖 Wi-Fi 的 MQTT 模块没法直接仿真。解决办法是把业务逻辑和通信层解耦仿真时用桩函数替代 MQTT真机再切回真实连接。这篇文章会交付可复制的config.toml和settings.json骨架、TaoToken 统一 Key/API 通道的接入步骤以及串口日志和仿真波形的验证动作。适合正在用 TraeCN 做嵌入式原型、或者想跑通 ESP32-S3 MicroPython Proteus 这条链路的开发者。下面按实际操作顺序展开。2. TaoToken 前置统一 Key 与 API 通道在 SOLO 模式里TraeCN 需要调用模型能力来生成代码、拆解任务、写测试。如果你同时用多个模型或工具Key 管理会很乱。TaoToken 的作用是提供一个统一的 API 通道把模型对话、编码计划、Key 管理集中到一处省去到处配环境变量的麻烦。接入前先确认两件事一是你已经有可用的 API Key二是知道自己的调用场景。这个项目里主要用到两类能力一类是模型对话用来让 SOLO 理解需求并生成骨架另一类是长期编码/Agent 场景适合把整个项目交给 SOLO 持续迭代。具体操作上先到控制台创建 Key然后按文档把 Key 配到 TraeCN 的模型设置里。如果你用的是 Coding Plan可以直接在计划里绑定 KeySOLO 会自动读取。接入文档里有不同客户端的配置示例照着填就行。注意Key 不要硬编码进config.toml或提交到 Git。建议用环境变量或本地.env文件并在.gitignore里排除。这一步做完SOLO 才有稳定的模型通道可用。接下来才是真正的项目搭建。3. 可复制配置config.toml 与 settings.jsonSOLO 生成骨架后最关键的补充是配置文件。下面这份config.toml覆盖了设备、Wi-Fi、MQTT、夜灯阈值和仿真开关。注意simulation段它是解决 Proteus 无法仿真 Wi-Fi 的核心。# config.toml [device] name esp32s3-nightlight board ESP32-S3-DEVKITC-1 firmware MicroPython [wifi] ssid Xiaomi 12 Pro password xxxxxxxx timeout_ms 10000 [mqtt] broker 115.190.228.104 port 1883 topic_prefix nightlight/elder client_id esp32s3-nightlight-01 keepalive 60 [nightlight] led_pin 48 pir_pin 4 dark_threshold 300 light_duration_ms 30000 stay_warn_minutes 15 [simulation] enabled true mock_wifi true mock_mqtt truesettings.json用来放运行时参数和测试开关和config.toml分工前者偏部署环境后者偏业务逻辑。{ runtime: { log_level: INFO, serial_baud: 115200, loop_interval_ms: 500 }, test: { unit: true, integration: true, mock_broker: 127.0.0.1, mock_port: 1883 }, alerts: { stay_too_long: true, frequent_night: true, frequent_threshold: 4 } }这两个文件放在项目根目录SOLO 生成的main.py会读取它们。如果你在 Proteus 里跑把simulation.enabled设为true代码会走桩函数真机烧录时改成false走真实 Wi-Fi 和 MQTT。项目骨架大致是这样esp32s3-nightlight/ ├── config.toml ├── settings.json ├── main.py ├── lib/ │ ├── nightlight.py │ ├── mqtt_client.py │ └── mock_mqtt.py ├── tests/ │ ├── test_nightlight.py │ └── test_integration.py └── README.mdlib/mqtt_client.py负责真实连接lib/mock_mqtt.py负责仿真时的桩实现。main.py根据config.toml的simulation.enabled决定导入哪个。4. 验证请求串口日志与仿真波形配置写完后先做单元测试再做集成测试。单元测试针对nightlight.py的逻辑比如判断是否该亮灯、是否该触发停留告警。# tests/test_nightlight.py from lib.nightlight import should_light, is_stay_too_long def test_should_light_when_dark_and_motion(): assert should_light(light_value200, motionTrue, threshold300) is True def test_should_not_light_when_bright(): assert should_light(light_value800, motionTrue, threshold300) is False def test_stay_too_long(): assert is_stay_too_long(entry_ts0, now_ts16*60, limit_minutes15) is True集成测试在 Proteus 里跑重点看串口日志和波形。Proteus 9.0 SP2 的 MicroPython 仿真器支持串口输出你可以把print的内容重定向到虚拟终端。预期日志类似[INFO] boot: esp32s3-nightlight [INFO] simulation mode: mock_wifiTrue mock_mqttTrue [INFO] nightlight: dark detected, LED on [INFO] mqtt: mock publish topicnightlight/elder/event payload{event:light_on} [INFO] stay monitor: entry recorded [WARN] stay monitor: stay too long, alert triggered波形方面把 PIR 引脚和 LED 引脚接到虚拟示波器能看到 PIR 触发后 LED 拉高的时序。如果 LED 没亮先查dark_threshold是否设得太低或者 PIR 引脚号是否和 Proteus 里的接线一致。真机验证时把simulation.enabled改成false烧录后看串口是否连上 Wi-Fi再确认 MQTT 是否成功 publish 到nightlight/elder/event。后端 FastAPI 订阅这个主题就能拿到事件做业务处理。5. 本篇常见错排查第一个坑是 Proteus 里 Wi-Fi 模块报错。原因很直接Proteus 9.0 SP2 模拟不了 Wi-Fi任何依赖network模块的代码都会失败。解决办法就是前面说的桩函数把 MQTT 调用替换成mock_mqtt.py里的本地打印或本地 socket。不要试图在 Proteus 里连真实 broker浪费时间。第二个坑是config.toml解析失败。MicroPython 没有内置 TOML 解析器需要自己写轻量解析或用ujson转。SOLO 生成的骨架里通常会带一个lib/toml_lite.py如果没有就手动加一个只支持当前配置结构的解析函数。注意字符串引号和布尔值true/false的写法MicroPython 对大小写敏感。第三个坑是串口日志乱码。检查settings.json里的serial_baud是否和 Proteus 虚拟终端一致常见是 115200。如果还是乱码确认固件烧录时选的波特率和运行时一致。第四个坑是 MQTT 连不上。先确认 broker 地址和端口没写错再确认 ESP32-S3 和 broker 在同一网络可达。如果 broker 在公网注意防火墙和端口开放。真机调试时先用mqtt_client.py单独跑一个连接测试再集成到主流程。第五个坑是 SOLO 生成的测试跑不过。多半是导入路径问题MicroPython 的sys.path和桌面 Python 不同。在main.py开头加sys.path.append(/lib)或者把测试文件放到和lib同级目录。6. 继续接入与下一步项目跑通后下一步是把 SOLO 的持续编码能力用起来。如果你要长期迭代这个夜灯项目或者扩展成多设备 Agent 管理可以用 Coding Plan 把 Key 和计划绑定让 SOLO 在每次提交后自动跑测试、生成变更说明。模型对话入口适合临时问配置问题或让 SOLO 解释某段逻辑。API Key 管理和接入文档在控制台和文档页配好后整个链路就顺了。实际用下来这套流程最省时间的地方是配置和桩函数分离Proteus 里跑逻辑真机跑通信两边不互相拖累。你可以先把config.toml和settings.json复制过去再让 SOLO 补mock_mqtt.py基本半小时能跑通第一个仿真波形。
