智能温湿度联动控制系统
让一条指令，有来有回
双人协作的四端物联网项目。我主要负责 STM32、串口协议和 Python 网关，和队友一起对齐设备、云端与 Android 的状态。
- 我负责
- 成员 A：STM32 固件、UART 协议、Python 网关与联调
- 协作方式
- 双人协作 · 云平台与 Android 主要由队友负责
- 技术与工具
- STM32 / C / Python / UART / MQTT / ThingsBoard / Kotlin
- 源码
- 私有仓库，仅公开摘要
超时单独标记为“未知”，不把没收到结果当成成功。
2026-10-28 实机串口的原始输出，摘自项目仓库 evidence/w2-serial-raw-2026-10-28.log。传感器原始值、CRC 校验和换算值逐行对应；网关只解析换算行。
验证与边界
有依据的进展
- 我的 STM32 基线、真实串口温湿度上传与网关工作已合并
- 固件控制安全修复、设备身份与终态回执修复已合并
- 仓库保留自有板台架、上行采集及队友 Android 只读云端接入证据
还没验证，或需要留意
- 远程控制与阈值编辑等相关 PR 仍有未合并部分
- 台架 GPIO 读回不等于风机或雾化负载已实际动作
- 真实负载、急停、冷启动与四端同窗对账仍需要补齐验收
开发记录问题、取舍与过程
四个端，共用一套状态语义
系统的目标链路是：STM32 采集和控制，Python 网关连接串口与 MQTT，ThingsBoard 管理遥测和 RPC，Android 提供查看与操作。上行数据走到手机，下行指令也需要带着执行结果回来。
这是双人综合实训。我主要负责嵌入式与网关方向，队友主要负责云平台与 Android。 接口约定、部分网关工作、测试和联调有交叉，不能按仓库所有者来分配整套成果。
先让数据真实走起来
我推进 STM32 启动基线、传感器采样、UART 协议与网关上传。最新合并记录包含真实串口持续采集，并明确区分采样条数、MQTT 提交与数据库入库：传输确认不能自动等同于云端数据已正确保存。
队友的 Android 只读云端接入已合并。控制、阈值编辑和历史曲线的后续分支，则要分别查看合并与验收状态。
“收到指令”不等于“执行成功”
固件与网关需要区分 APPLIED、REJECTED 和 FAILED。安全联锁主动拒绝属于 REJECTED；超时意味着结果未知，不能直接写成失败，更不能伪造成功。
我参与的安全修复包括命令 ID、设备和启动身份关联，最小运行时间、输出互斥、旧采样屏障以及配置回读。台架验证能读回 GPIO 逻辑，但它不能证明继电器触点、风扇转速或实际出雾。
目前到了哪里
截至本次资料核对，固件安全与网关修复已有合并记录，完整远程控制整合仍有开放 PR。项目保持开发中；实际负载、物理急停、断电恢复和四端同一时窗的联调，是接下来需要补齐的证据。
这份记录从哪里来
资料核对于 2026-11-12。以下是整理时阅读的文件与记录，不代表本次重新执行了源项目的硬件、部署或完整回归。
- 团队目录与分工
README.md - STM32 安全修复及台架范围
PR #29（已合并） - 真实串口上行采集证据
PR #32（已合并） - 远程控制与配置整合
PR #25 / #26 / #28（未合并） - 回执绑定设备与终态
PR #35（已合并） - 实机串口原始输出
evidence/w2-serial-raw-2026-10-28.log
源仓库为私有，仅保留适合公开的摘要。内部地址、凭证、财务原文及个人计划未公开。