树莓派上的 .NET IoT：外设接入与采集上报

AI 陪伴硬件的端侧，我选树莓派做载体、.NET IoT 做外设抽象：统一 GPIO / I2C / UART 访问，业务代码不必散落在一堆 shell 脚本里。C# 的类型系统和 DI 容器，也让「驱动—设备影子—MQTT 通道」的分层更容易测试和替换。

端侧分层

1. 驱动层：读传感器、控执行器，封装重试与硬件异常
2. 设备影子层：本地缓存最近状态，弱网可续传
3. 通道层：MQTT 上报与指令订阅，和云端 topic 规范对齐
4. 能力层：唤醒、录音、播放、对话会话编排

各层之间用接口隔离：换麦克风模块时，只动驱动层，不动对话编排。

驱动层实践

• 初始化失败抛带错误码的异常，写本地 log，不要静默空转
• I2C 设备先探测地址再读数，避免总线 hang 住整个进程
• GPIO 中断与轮询混用时，注意 debounce，防止误触发风暴

采集与上报策略

采集频率按场景分级：状态心跳低频（如 30s），交互事件即时上报。批量遥测可本地聚合再发，减轻 broker 压力。时间戳以 UTC 存储，展示层再转本地时区。

MQTT 客户端单独进程或 BackgroundService 维护，和业务 API 解耦。断线重连后先同步设备影子，再拉云端待执行指令，避免「旧状态覆盖新指令」。

本地测试与模拟

开发阶段我会用接口 mock 驱动层，在 xUnit 里跑状态迁移与上报逻辑，不必每次接真板。联调时再打开 .NET IoT 的具体实现。录音、播放等与实时性相关的模块，单独做延迟与缓冲区压测，防止在弱 CPU 的树莓派上出现 underrun。

树莓派上 CPU 与 IO 争抢明显：不要在 GPIO 中断回调里做 JSON 序列化或写磁盘。采集线程只入队，BackgroundService 消费队列再上报，这是我在多个端侧项目里验证过最稳的模式。

交付与运维

进程守护与开机自启必须进交付清单：systemd 单元文件、重启策略、依赖启动顺序（网络就绪后再连 MQTT）。日志落本地轮转，远程只拉关键错误段，避免把用户对话音频路径等敏感信息全量上传。

常见坑

• 树莓派 SD 卡寿命：日志和控制频繁写 flash，建议 log 目录挂 tmpfs 或外接存储
• 单进程阻塞：音频采集和 MQTT 回调同线程，会造成指令延迟——IO 密集任务放独立线程
• 缺少看门狗：进程僵死但 systemd 认为 active，需健康检查或硬件 watchdog
• 权限不足：GPIO 组未加入运行用户，表现为「偶发能读、重启后不能读」

与云端联调

联调时我会先打通「心跳 + 一条指令 + 一条回执」最小闭环，再叠对话能力。设备注册、证书下发、topic 分配应在出厂或首次激活阶段完成，现场实施人员不应手改 broker 地址。端侧配置变更（如采样间隔）优先走云端下发 manifest，减少逐台 SSH 改文件。

检查清单

• [ ] 拔网 5 分钟后恢复，影子状态与云端一致
• [ ] 外设热插拔或初始化失败有明确 UI/LED 指示
• [ ] OTA 与日常 MQTT 通道资源隔离
• [ ] 本地配置文件有 schema 校验，坏配置不启动

端侧稳定，是后面接 LLM 对话的前提；模型再聪明，麦克风驱动挂了也只是一块板子。

交付给硬件团队时，我会附带一份「端侧健康指标」说明：心跳间隔、最后一次成功上报时间、驱动初始化错误码含义。现场实施按表排查，比远程猜日志省太多时间。

小结

树莓派端侧交付清单里，驱动稳定性、进程守护、日志轮转和弱网续传往往比业务功能更决定口碑。用 .NET IoT 把外设访问收敛到清晰分层后，后续接对话能力或 OTA 才不会把脚本堆成泥球。现场安装要附带自检命令，减少远程口头排障。