简介：基于STM32与ESP8266的物联网智能家居安防系统完整毕设工程，适合嵌入式、物联网方向学习者参考。项目覆盖温湿度、气体、人体红外等多传感器数据采集，以及OLED、LCD、触摸屏显示和语音识别，同时支持微信小程序远程控制、OneNET平台接入和短信告警联动。资源包共180个文件，以C语言源码（.c/.h）和Keil工程文件为主，另含烧录hex、界面bmp图片及docx/md说明文档，压缩包仅1.81MB，模块划分清晰，便于按功能拆解。已有725人学习下载，可从中提取串口通信、定时器、ADC采样、RTC时钟、EEPROM掉电保存、Wi-Fi通信等毕设级代码框架，也可对照触摸屏二级页面（闹钟、音乐、阈值设置等）理解人机交互与安防逻辑的设计思路。
1. 一套能“报警到人”的物联网家居安防，硬件其实就三层
做智能家居安防的系统设计，最怕的不是传感器选型，而是需求堆叠之后通信链路乱成一团。这个标题看起来很庞大，拆开看核心链路其实非常清晰：STM32 做主控把传感器数据汇总，ESP8266 负责把数据送到 OneNET 云平台，微信小程序负责远程看状态和手动控制，安防警报、语音播报、触摸屏、短信通知这些，全是挂着主控上的“执行末梢”。真正要先把住的是数据从传感器到手机屏幕之间怎么走、丢了怎么补、异常怎么触发。
这套方案很适合毕业设计、物联网竞赛作品，还有真正想在家里低成本搭一套可用安防系统的工程师。它有一个反直觉的地方：最花时间的往往不是 STM32 的驱动代码，而是 ESP8266 的 AT 指令对接 OneNET 的鉴权细节，以及微信小程序侧的 API Key 管理和数据推送处理。这两处打通之后，剩下的模块接上去只是时间问题。本文不涉及任何网络代理相关话题，所有联网能力均通过常规物联网云平台实现。
2. 整体架构与通信协议选型：为什么是 OneNET 而不是自建 MQTT Broker
2.1 STM32、ESP8266 与 OneNET 三层结构中的职责划分
一套完整的物联网智能家居安防系统，在数据链路天然是三层结构：感知执行层、接入传输层、应用服务层。STM32 作为感知执行层的核心，要处理的是传感器轮询、ADC 采集、GPIO 检测、报警输出，以及对 ESP8266 的串口控制。ESP8266 做的事情就是接入层的“管道工”，它通过 UART 接收 STM32 的指令和数据，以 TCP 方式连接到 OneNET 的 MQTT 服务器，完成数据发布和订阅。
这里有一个关键点要和刚开始做的人说清楚：ESP8266 本身也是一颗可以独立跑逻辑的芯片，手上的 NodeMCU 开发板内建了 Lua 或 Arduino 运行时。但在这个系统里，建议把 ESP8266 当成纯粹的透传模块用，也就是给 STM32 让出全部业务逻辑。原因很直接，STM32 的实时性、定时器资源、中断响应比 ESP8266 可靠得多，安防场景下某个传感器触发必须在毫秒级响应，ESP8266 跑复杂逻辑时 Wi-Fi 协议栈中断会把任务调度打乱。
分层的表格可以这样列：
| 层级 | 设备 | 职责 |
|---|---|---|
| 感知执行层 | STM32F103C8T6 | GPIO 采集、ADC、定时器扫描、警报输出、触摸屏驱动 |
| 接入传输层 | ESP8266-01S / NodeMCU | 透传 STM32 的 MQTT 数据，维持 TCP 长连接 |
| 应用服务层 | OneNET + 微信小程序 | 设备影子、历史数据、API 请求、远程控制下发 |
| 用户交互层 | 触摸屏 + 微信小程序 | 本地参数设置、远程状态监控、警报消息触达 |
STM32 工程建议用标准库或者 HAL 库都可以，但要注意的是串口中断接收 ESP8266 返回的 AT 响应时，一定要用环形缓冲区，因为 ESP8266 可能回复一长串+MQTTSUBRECV开头的推送数据，一次性收不完就会丢帧。这也是很多人在网上搜“esp8266开发板与stm32通信”时遇到乱码和丢数据的根源。
2.2 MQTT 与 HTTP 的选择：设备影子机制是刚需
OneNET 平台同时支持 MQTT、HTTP、TCP 直连等接入方式。这里核心矛盾在于：HTTP 请求是请求-响应模式，小程序问一次设备状态就得发一次 HTTP 请求，但设备现场如果发生了闯入警报，不可能等着小程序来“问”才知道上报，安防数据必须由设备主动推送。所以选 MQTT 几乎是必然的。
MQTT 在 OneNET 上的优势还有一点容易被忽略：设备影子（数据流）机制。STM32 定时上报温湿度、烟雾浓度、人体红外状态到不同数据流，OneNET 会自动存储最近一条数据，微信小程序查询设备状态时不需要唤醒设备，直接读数据流的最新值就可以。这个设计极大降低了 STM32 的功耗，也避免了主控随时要被请求打断的尴尬。
协议头也可以看到 MQTT 在应用层的简洁性。OneNET 使用 MQTT 3.1.1 协议，默认端口 1883（注意不加密），保活时间建议设 60 秒到 120 秒之间。STM32 端的 MCU 只需要按固定周期通过 ESP8266 透传发布消息，结构清晰，逻辑简单。相比自建 EMQX 或 Mosquitto Broker，OneNET 免去了自己维护服务器的问题，而且自带数据流展示、触发器、API 鉴权，对毕业设计和中小项目来说性价比很高。
注意：OneNET 的 MQTT 接入地址根据平台区域不同会有差异，新版的 OneNET 开放平台提供的是 mqtts.heclouds.com 或类似域名，端口 1883 或 8883。创建产品时平台会直接给出接入地址，不要从旧教程里抄地址。
2.3 STM32 与 ESP8266 的串口通信帧设计
STM32 通过串口向 ESP8266 发送 AT 指令，这里面临一个工程问题：AT 指令本身没有协议头尾，如果 STM32 往 ESP8266 发的传感器数据里恰好包含\r\n，就可能被解析成指令的一部分。虽然 MQTT 发布的数据通过 AT 透传模式AT+CIPSEND发送不受影响，但要管理 ESP8266 的入网状态、订阅主题、心跳保活，就需要定制一套主机与透传模块之间的通信帧。
我一般会在 STM32 侧定义这样一个帧结构：
#define FRAME_HEAD1 0xAA #define FRAME_HEAD2 0x55 #define FRAME_CMD_SET_WIFI 0x01 #define FRAME_CMD_CONNECT_ONENET 0x02 #define FRAME_CMD_PUBLISH_DATA 0x03 #define FRAME_CMD_SUBSCRIBE 0x04 typedef struct { uint8_t head[2]; uint8_t length; uint8_t cmd; uint8_t payload[64]; uint8_t checksum; } Frame_t; uint8_t CalcChecksum(Frame_t *frame) { uint8_t sum = 0; for (int i = 0; i < frame->length + 3; i++) { sum += ((uint8_t *)frame)[i]; } return sum; }这段代码解决的是 STM32 与 ESP8266 之间的控制通道问题，帧头用连续两个固定字节0xAA 0x55，后面挂长度、命令码、负载数据和校验和。每次 STM32 要配置 ESP8266 时先按这个帧组装，校验和是前面所有字节的累加。相比直接用sprintf拼 AT 指令字符串，这样做的最大好处是 ESP8266 接收端（不管是 AT 固件还是刷了自定义固件）可以明确判断一条指令是否完整，不会有半包错位的问题。
如果你用的是 NodeMCU 或者 D1 Mini 板子，也可以跳过 STM32，直接用板载的 USB-TTL 调试串口与 STM32 对接，注意 RX、TX 交叉，电平都是 3.3V 所以不用转换芯片。GPIO 对应关系各板卡略有不同，以 NodeMCU 为例，D1 对应 GPIO5，D2 对应 GPIO4，别搞混了，搞混会造成“ESP8266 扩展 IO 口”的困惑——串口引脚和 GPIO 复用关系要查数据手册确认。
3. OneNET 接入实操：APIKey 生成、AT 指令序列与 STM32 数据上报
3.1 OneNET 产品创建、设备添加与 APIKey 生成步骤
OneNET 接入的第一步不是写代码，而是把云端资源建对。登录 OneNET 开放平台后进入控制台，创建产品时有三项选错会导致后面全部跑不通：“产品行业”选智能家居、“联网方式”选 Wi-Fi、“接入协议”选 MQTT。创建完成之后平台会分配一个产品 ID，这个 ID 在 MQTT 连接中作为 username 的一部分使用。
产品创建完成后，需要在产品下添加设备。设备名称建议用设备型号加编号，比如stm32_home_01。设备创建成功后会有两个关键字符串：设备 ID 和设备 APIKey。设备 APIKey 就是网上经常搜到的“onenet生成apikey”的产物，它出现在两个地方：一个是 MQTT 连接鉴权时的密码，另一个是 HTTP API 请求 URL 中的头信息。
这里把生成和权限的对应关系整理成表格，方便排查问题时对照：
| 对象 | 在哪生成 | 用途 | 注意事项 |
|---|---|---|---|
| 产品 ID | 产品创建后自动生成 | MQTT username 组成 | 一个产品下的设备共享这个 ID |
| 产品 APIKey | 产品详情页 | 管理产品下所有设备 | 一般用于 HTTP API 云端调用 |
| 设备 ID | 添加设备时生成 | MQTT clientId 组成 | 唯一标识设备 |
| 设备 APIKey | 设备详情页 | 设备上报数据鉴权、HTTP 读数据流 | 不要暴露在小程序前端，必须走后端中转 |
APIKey 相当于设备的“访问令牌”，如果把设备 APIKey 直接写死在微信小程序前端代码里，任何抓包的人都能用 Burp Suite 这类工具查看小程序请求内容，拿到凭据后就可以读取或篡改你的设备数据。稳妥的做法是微信小程序请求自己的后端服务（云函数或服务器），后端保存 APIKey 并调用 OneNET 的 HTTP API。如果是纯毕设演示，安全要求不高，也要至少加一层请求签名，不要裸奔。
3.2 ESP8266 的 MQTT 接入 AT 指令与连接参数
ESP8266 的 AT 固件版本建议用 1.7.4 以上，1.5.4 和 1.6.2 的 MQTT AT 指令集不完整，需要自己用AT+CIPSTART建立 TCP 然后再用AT+CIPSEND发送原始 MQTT 报文，工作量成倍上升。新固件（AT 2.x）里 MQTT 指令整体向AT+MQTTUSERCFG、AT+MQTTCONN收敛，下面给出现在常用的完整连接序列：
AT+RST # 等待约 3 秒，模块重启完成 AT+CWMODE=1 # 设置为 Station 模式，仅连接路由器，不创建热点 AT+CWJAP="MyWiFi","WiFiPassword" # 连接 Wi-Fi 热点，返回 WIFI GOT IP 表示成功 # 注意：SSID 和密码中的逗号和引号需要转义，否则会被当作指令分隔符 AT+MQTTUSERCFG=0,1,"NULL","productId","deviceApiKey",0,0,"" # 第2参数1表示使能 MQTT；用户名填产品ID，密码填设备APIKey # 通常把本地用户名设为NULL，直接在后面的参数里指定 AT+MQTTCONN=0,"mqtts.heclouds.com",1883,1 # 建立 MQTT 连接，1883 是非加密端口 # 最后一个参数为 ClientID，OneNET 要求 ClientID 和设备ID一致这里要特别注意AT+MQTTUSERCFG的参数顺序。不同版本的 AT 固件对 clientID 的传入方式有差异，有的版本要求把 clientID 放在AT+MQTTCONN的最后一个参数里，有的版本要求放在中断名里。如果连接返回ERROR，优先检查是不是 ClientID 与设备 ID 不一致，其次是密码是不是设备 APIKey 而非产品 APIKey。这两个坑在“nb模组连接onenet”的帖子中也经常出现，本质是同一个鉴权问题。
连接成功后，订阅和发布指令如下：
AT+MQTTSUB=0,"topic/cmd",0 # 订阅下行命令主题，OneNET 设备默认收命令的主题因产品协议而异 # MQTT 协议下建议用自定义主题，OneNET 平台会映射到数据流 AT+MQTTPUB=0,"topic/datapoint","{\"temp\":26.5,\"hum\":60.1,\"smoke\":0,\"pir\":1}",0,0 # 第一个0是 MQTT 连接号；第二个参数是主题名 # 后面依次是消息内容、QoS等级（0/1/2）、是否保留消息注意发布的消息内容要求是合法的 JSON 字符串，OneNET 会自动解析其中的键值对并映射到同名数据流。JSON 里的字符串不能包含转义不当的双引号，STM32 的sprintf在格式化时要用\"把内部双引号转义掉。如果你在串口调试助手里看到发布成功但 OneNET 数据流里没有数据，九成原因是 JSON 格式不合法，先把数据拷贝到 JSON 校验工具里看一眼比反复发指令有效得多。
3.3 STM32 侧的定时上报与命令接收代码骨架
STM32 作为主控，与 ESP8266 的关系是“管理加使用”。当系统上电时，STM32 通过串口发送配置帧让 ESP8266 连网和接入 OneNET，然后进入主循环。主循环里的上报采用定时标志位策略，用定时器中断每 10 秒置位一次g_upload_flag，主循环检测到标志后采集传感器数据并组装 JSON，再下发发布指令。
下面给出一段核心代码，展示数据上报逻辑：
void Sensor_Upload_Task(void) { if (g_upload_flag == 0) { return; } g_upload_flag = 0; uint8_t temp = Read_Temperature(); uint8_t hum = Read_Humidity(); uint16_t smoke = Read_SmokeSensor(); uint8_t pir = Read_PirSensor(); char json_buf[128]; snprintf(json_buf, sizeof(json_buf), "{\"temp\":%d,\"hum\":%d,\"smoke\":%d,\"pir\":%d}", temp, hum, smoke, pir); // 发送发布指令 Esp8266_SendCmd("AT+MQTTPUB=0,\"topic/datapoint\",\""); Esp8266_SendData(json_buf, strlen(json_buf)); Esp8266_SendCmd("\",0,0\r\n"); }这段代码的关键是分三段往 ESP8266 的串口写数据，先写指令头，再写 JSON 内容，最后写结尾。不能一次用sprintf拼完的原因在于 JSON 里可能含有变量值的长度变化，分次发送可以靠 ESP8266 的“>”提示符来确认每段是否写入成功。如果最终发布失败，抓串口日志时更容易定位是头、内容还是尾的问题。
接收命令侧用串口中断配合环形缓冲区处理 ESP8266 推上来的数据。当 ESP8266 收到云平台下发的主题消息时，会主动打印+MQTTSUBRECV: 0,主题长度,主题,数据长度,数据。STM32 中断服务函数里只需要把原始字节存入缓冲区，主循环里再解析：
void ESP8266_UART_IRQHandler(void) { uint8_t byte = 0; if (LL_USART_IsActiveFlag_RXNE(USART2)) { byte = LL_USART_ReceiveData8(USART2); RingBuffer_Push(&rx_ring, byte); } } void Command_Parse(void) { if (RingBuffer_Find(&rx_ring, "+MQTTSUBRECV", 12)) { // 这里做字符串查找，定位负载数据位置 char *p = RingBuffer_FindPayload(&rx_ring); if (p != NULL) { if (strstr(p, "\"led\":1")) { GPIO_SetBits(GPIOC, GPIO_PIN_13); } } RingBuffer_Clear(&rx_ring); } }环形缓冲区解决了 ESP8266 推送数据不按帧到达的问题，但要注意主循环里不能阻塞太久，否则缓冲区溢出会丢掉后续数据。安防系统里用户按下微信小程序上的“布防”按钮，数据从 OneNET 下发到 ESP8266，STM32 收到后要立刻将布防标志位置位，这个操作必须放在中断优先级较高的上下文里完成。
提示：STM32 开发环境的搭建建议直接用 STM32CubeMX 生成初始化代码，然后嵌入手写的任务逻辑。网上说的“error: no stm32 target found”通常是 ST-Link 驱动问题，检查设备管理器里 Virtual COM Port 是否有感叹号，有感叹号就重装驱动后重插。
4. 本地安防交互：触摸屏 UI、语音播报与传感器报警分级
4.1 触摸屏界面设计与 STM32 的串口屏驱动方式
触摸屏在安防系统里的角色是本地控制台，不需要联网，也不依赖小程序端就能独立查看报警状态。选串口屏还是并口屏，主要看主控资源余量。并口屏（如 ILI9341 直驱）接在 STM32 上要占用一组 GPIO 做数据线和控制线，画 UI 要自己写绘图库，对以安防逻辑为主的项目会觉得太耗时间。
串口屏的选择逻辑是“用协议换时间”。常见选型是 2.4 寸或 3.5 寸的 TTL 串口屏，屏幕通过串口接收指令直接绘制控件。开发时分两步走，第一步用屏幕厂家的上位机软件把页面、按钮、文本控件画好，每个控件会分配一个 ID 号；第二步在 STM32 代码里通过串口发送指令改变控件属性，比如改变文字的颜色来提示报警状态。
STM32 驱动串口屏发送的指令格式在各家协议上略有差异，但思路相同。用迪文屏举例，写文本控件：
void Screen_SetText(uint16_t page_id, uint16_t ctrl_id, uint8_t *text) { uint8_t tx_buf[128]; uint8_t len = strlen((char *)text); tx_buf[0] = 0x5A; // 帧头 tx_buf[1] = 0xA5; // 帧头2 tx_buf[2] = len + 6; // 长度：命令字+控件ID+数据长度 tx_buf[3] = 0x82; // 写变量指令 tx_buf[4] = 0x00; // 变量地址高位 tx_buf[5] = 0x10; // 变量地址低位，这个要和组态配置一致 memcpy(&tx_buf[6], text, len); UART_Send(tx_buf, len + 6); }这段代码本质上是组织一帧屏幕协议数据。最容易出错的地方是帧长度计算，很多初学者忘了在长度字段里包含命令字和地址字节，导致屏幕始终无响应。调试时可以先用串口助手手动发帧，确认屏幕动作后再移植到 STM32 中，减少查错范围。
触摸屏的点击事件处理建议做成回调模式，当串口屏检测到按键按下时，屏幕会主动上报一条数据帧给 STM32。STM32 侧解析帧中的按键 ID 号，执行对应操作。比如切换到“布防”页面、调整报警阈值、禁用某个传感器，这些操作全部在本地完成，不经过云平台，反应的实时性更有保障。
4.2 安防警报的分级逻辑：从事件检测到声光报警动作
安防警报的触发如果只做“传感器一变就响铃”，这个系统在实际使用中会让人崩溃，因为没有任何传感器能保证零误报。设计合理的警报系统一定要有分级和确认机制。这个系统把警报分为三级：
- 一级警报：有人体红外触发且门窗磁传感器打开，连续触发超 300ms，判定为闯入警报。此时蜂鸣器长鸣、红色灯光闪烁、触摸屏弹出警报页、微信小程序远程推送通知。
- 二级警报：烟雾或可燃气体浓度超过阈值，触发 5 秒延迟确认，若浓度持续超标则拉响蜂鸣器并在触摸屏上显示“燃气泄漏”提示。
- 三级警报：温湿度异常（比如温度超过 55℃ 或低于 0℃），只发送通知不做声光动作，主要用于防止水管冻裂、设备过热等非入侵场景。
分级判定写在 STM32 的定时器中断回调里，采用状态机扫描。每 200ms 扫描一次传感器状态，维护历史状态向量和持续时间计数。
void Alarm_StateMachine(void) { static uint8_t last_state = 0; static uint16_t confirm_cnt = 0; uint8_t cur_state = 0; if (Read_Pir() == HIGH) cur_state |= 0x01; if (Read_WindowSensor() == OPEN) cur_state |= 0x02; if (Read_Smoke() > SMOKE_THRESHOLD) cur_state |= 0x04; if (cur_state == last_state) { if (confirm_cnt++ > 10) Alarm_Trigger(cur_state); } else { last_state = cur_state; confirm_cnt = 0; } }这个代码的思路是“连续 10 次扫描（2 秒）都维持同一异常状态才触发警报”。连续确认机制能滤掉大部分因环境扰动产生的误报，人在传感器前正常走过不会产生 2 秒持续遮挡。
警报触发后的动作可以拉一个硬件控制函数库，SPI 或 GPIO 驱动蜂鸣器、LED 灯带和语音模块。上电后警报响铃前先发一条串口指令到语音模块播放“请注意，有人闯入”，这个提示音比蜂鸣器的叫声在家庭场景下更容易分辨。语音模块选 SYN6288 或 WT588D 都行，SYN6288 的串口控制开放度更高，可以动态组织播报话术。
4.3 语音交互与离线识别：本地关键词播报，云端语音留给小程序
标题里“语音”这个词在实现时有两条路线：语音播报和语音识别。语音播报是 STM32 最擅长做的，接一个中文 TTS 模块，发生警报时把具体的事件用中文说出来；语音识别就要复杂得多，如果放在 STM32 上做离线识别，通常只能识别几个预先训练好的命令词，识别率还不稳定。
安防系统的实际使用习惯决定了“识别”需求很简单，用户最常说的是“我回家了，撤防”，最紧张的情况是“出事了，报警”。考虑这些场景之后，一个更务实的方案是：语音识别放在微信小程序端完成。手机端调用微信的录音能力，把录音文件传到一个在线语音识别服务，识别结果转成文本后经 OneNET 下发控制指令。ESP8266 收到后通过串口告诉 STM32 撤防或布防。这种方案的效果远好于在 STM32 上跑 KWS 模型，而且实现成本低。
离线语音播报仍保留在本地。STM32 与 TTS 模块之间使用异步串口通信，波特率建议 9600。系统在警报触发的同时把警报文本发送给 TTS 模块，TTS 模块在收到0xFD帧头后开始解析，完成字节长度、命令字、语速音调的组装后开始朗读。TTS 模块比较适合的播报词是动态拼接的，比如“厨房一氧化碳浓度异常”比单纯的“浓度 80ppm”更有用，因为普通家庭成员并不理解 ppm 是什么单位。
注意：语音播报和触摸屏会同时占用 STM32 的串口资源，所以在硬件设计时给主控预留至少三个 UART 是被低估的需求。USART1 用于调试打印，USART2 接 ESP8266，USART3 接屏幕或 TTS，另一个用软件模拟串口接剩余的外设，就可以避免资源不足导致互斥阻塞。
5. 短信通知、知心天气联动与系统调试避坑
5.1 短信通知的两条实现路径：云端触发器与本地 4G/GSM 模块
短信能力在这个系统里作为“最后一道触点”存在，它解决的场景是：用户不在手机旁边，或者打开了微信小程序但忽略了消息通知，这时一条 SMS 足以引起注意。实现短信有两条路径，选择哪条取决于你对云平台可控性的要求。
路径一是用 OneNET 平台的触发器功能。在 OneNET 控制台的“触发器”服务里创建一个新触发器，数据流选择烟雾浓度，判定条件设为大于 400ppm，触发动作填写一个可访问的 HTTP URL。这个 URL 指向你的后端服务器，服务器收到 OneNET 的 POST 回调后，再调用短信服务商（如阿里云短信、腾讯云 SMS）的 API 完成发送。
# 后端服务收到的 OneNET 触发器回调示例 POST /sms/alarm HTTP/1.1 Host: yourserver.com Content-Type: application/json { "device_id": "stm32_home_01", "data_stream_id": "smoke", "value": 600, "trigger_time": "2025-06-12 08:30:22" }后端收到这个回调后做两件事：一是记录日志用于追溯，二是判断当前时间段是否为夜间（夜间短信优先级提高），然后调短信 API 发送。这条路的好处是 STM32 端不用管短信协议，而且可以做到短信内容的动态渲染；坏处是依赖 OneNET 的触发器网络通知到达率，如果公网环境不佳会有延迟。
路径二是在硬件板上直接集成 SIM800C 或合宙 Air724 等蜂窝通信模块。STM32 通过 AT 指令操作 GSM 模块，直接在本地发送短信。不必通过云平台转发，延迟更低，也完全避开了云平台回调不可达的问题。但要注意，使用蜂窝模块时申请运营商 SIM 卡流程要合规，且模块的供电要求比较高，SIM800C 在发射瞬间实测电流可达 2A 峰值，必须使用外部稳压芯片，不能直接从 STM32 的 3.3V LDO 取电。
| 方案 | 延迟 | 离线可用 | 资费 | 实现难度 | 适用场景 |
|---|---|---|---|---|---|
| OneNET 触发器 + 短信 API | 2~5 秒 | 依赖云和宽带 | 按条收费 | 中间态 | 室内有联网条件 |
| SIM800C 本地直发 | <1 秒 | 不依赖家宽 | 按条收费 | 硬件设计复杂 | 野外、断网告警场景 |
5.2 知心天气的接口对接与温控设备联动
这个系统引入知心天气（第三方免费天气接口）的目的是让安防系统行动更“聪明”，比如当室外温度达到 40℃ 时自动给用户发提醒，或结合室内温度判断要不要给鱼缸或植物设备留出控制接口。知心天气 API 的调用可以放在微信小程序端完成，因为小程序天然支持 HTTPS，只需要在小程序后台配置合法域名即可。
如果想让 STM32 侧的安防逻辑联动天气信息，就要让 ESP8266 通过透明传输模式向天气 API 发出 GET 请求。OneNET 平台本身不直接关联知心天气，但可以让 ESP8266 在空闲时以 TCP 连接的方式访问第三方 API 域名。
AT+CIPSTART="TCP","api.seniverse.com",80 AT+CIPSEND GET /v3/weather/now.json?key=YOUR_API_KEY&location=shenzhen&language=zh-HansHTTP/1.1 Host: api.seniverse.com User-Agent: STM32-Device/1.0 Connection: closeESP8266 收到响应后，STM32 解析 JSON 中的temperature字段，如果温度超过阈值就可以不依赖云端，而是直接在本地逻辑里改变空调或通风设备的开关状态。这个设计的好处是，即便 OneNET 云平台短时不可用，本地天气联动仍然可以独立运行，安防系统的主干不受影响。
天气数据的 JSON 解析放在 STM32 上需要额外引入微型 JSON 解析库。F103C8T6 的 64KB Flash 空间相对紧张，建议用 cJSON 的裁剪版或者改为正则匹配方式，只提取temperature和code两个字段。
注意：调用天气 API 时需要处理时区问题，知心天气默认返回的是城市本地时间，对做“白天高温提醒”有影响。项目中建议将小时字段和 Alarm 状态机里“夜间”时间配合使用，两者之间用统一的标准时间格式对比判断，不要混用本地时间和 UTC 时间。
5.3 三类高频问题的定位技巧与验证方法
第一类是设备在 OneNET 上显示“在线”但不上报数据。先检查上报时间间隔，OneNET 的在线状态判定是 120 秒内收到一次消息。如果 STM32 里写的是 10 秒上报一次，实际发布失败一次就会导致掉线判定，所以要加一个重发机制。最简单的是在Sensor_Upload_Task的发布流程中，如果 ESP8266 返回ERROR就等待 5 秒再重发，最多重发三次。
第二类是触摸屏数据不刷新。触摸屏的控件 ID 与 STM32 发送的地址不一致是常见原因。调试时用一个最简单的静态页面，写死一个控件 ID 发送，如果屏幕还是不刷新，用示波器辅助查看串口 TX 引脚是否有波形，排除引脚复用配置错误。指纹识别这一类问题其实就是“换一个固定值先跑通再上真变量”的排查思路。
第三类是 STM32 与 ESP8266 调试时经常遇到的Virtual COM Port驱动问题。插上 USB 转串口（CH340 或 CP2102）后如果设备管理器显示感叹号，说明驱动未自动安装。CH340 驱动在芯片厂商官网上下载后手动安装，安装完不要马上插拔，等驱动稳定 5 秒后再打开串口助手，避免首次枚举失败。串口调试助手波特率选 115200，数据位 8 位，停止位 1 位，无校验——这是 ESP8266 AT 固件的默认参数，如果刻意改成 9600 反而会导致乱码。
最后一个验证技巧：在整套系统联调之前，先把 OneNET 的 MQTT 连接用 PC 上的 MQTT 客户端工具（如 MQTTX）手动验证一遍。用产品 ID 作为用户名、设备 APIKey 作为密码、设备 ID 作为 ClientID 连接成功后，能订阅和发布数据，再回到 STM32 排查问题。这能一次性把云端配置和硬件代码的故障域隔离开，减少排查面。调试期间不要修改设备 APIKey，修改后 STM32 侧需要同步更新，这个动作很容易被遗漏，结果就是设备在平台上看得到却连不上。
本文还有配套的精品资源，点击获取
