简介这份资源面向嵌入式开发初学者与智能家居DIY爱好者提供基于STM32单片机实现WiFi控制家电插座开关及定时功能的完整工程方案帮助读者理解从硬件选型到固件开发的整体流程。压缩包共224个文件约101.37MB包含32个c与33个h源码文件、20个o编译产物、19个crf与20个d中间文件以及uvproj、uvopt等Keil工程配置另有11个doc与9个pdf文档、34张jpg图片和6段mp4视频覆盖原理讲解、电路设计与调试记录。资源围绕STM32F4系列与ESP8266/ESP32 WiFi模块展开涉及UART/SPI通信、TCP/IP协议栈、FreeRTOS多任务定时管理、继电器驱动及PCB布局等关键知识点并附有schdoc原理图与hex固件。已有1555人学习下载适合作为课程设计、毕业设计或智能插座原型开发的参考模板便于快速搭建可运行的定时开关控制系统。1. 从零拆解STM32 加 WiFi 做家电插座定时开关到底难在哪很多人第一次听到“基于 STM32 单片机 WiFi 控制家电插座开关定时功能”脑子里浮现的画面是手机点一下继电器“咔哒”一声灯亮了完事。真动手才发现难的不是点灯而是“定时”这件事在嵌入式里怎么落地——本地定时和云端定时谁说了算、断网之后定时还准不准、继电器吸合瞬间单片机为什么会复位。我见过太多人卡在“能连上 WiFi但定时到点不动作”这一步最后怀疑人生。这个方向本质上是一个“弱电控强电”的物联网执行终端STM32 负责逻辑和定时WiFi 模组负责和手机/云端的通信继电器负责真正通断 220V 回路。它适合有 C 语言基础、想从裸机过渡到联网控制的开发者也适合做智能家居小批量定制的硬件爱好者。核心诉求就四个远程开关、本地定时、状态回传、断电记忆。把这四件事做扎实这个插座才算能用而不是个玩具。2. 硬件选型与电路别让继电器把单片机拖复位2.1 主控、WiFi 模组和继电器的三角关系主控选 STM32F103C8T6 是最稳的起点72MHz 主频、64KB Flash、20KB RAM跑一个定时任务加串口协议绰绰有余价格也压得住。WiFi 模组常见做法是选支持 AT 指令的串口透传模组STM32 通过 UART 发 AT 指令控制它连热点、连服务器、收发数据。为什么不直接把 WiFi 协议栈跑在 STM32 上因为那需要更大的 RAM 和更复杂的协议栈移植对第一次做这个方案的人来说串口透传模组把复杂度隔离掉了出问题也容易定位是模组还是主控。继电器模块要选带光耦隔离的这一点是血泪经验。市面上很多廉价继电器板是“单片机 IO 直驱三极管”的结构线圈断电瞬间的反向电动势会通过三极管耦合回 IO 口轻则 IO 抖动重则整片复位。带光耦的模块把控制侧和负载侧电气隔开STM32 的 IO 只驱动光耦内部的发光二极管电流小、干扰小。部件常见型号关键参数选型理由主控STM32F103C8T672MHz / 64KB Flash / 20KB RAM资源够、资料多、成本低WiFi 模组串口 AT 透传模组3.3V TTL 串口 / 支持 STA 模式协议栈内置主控只管发指令继电器5V 光耦隔离单路模块触点 10A/250VAC隔离干扰扛得住家电电流电源220V 转 5V 隔离电源模块输出 5V/1A给继电器和降压电路供电2.2 供电和 IO 分配3.3V 与 5V 不能混着来供电是第二个翻车高发区。继电器模块要 5VSTM32 要 3.3VWiFi 模组多数也是 3.3V。常见做法是用一个 220V 转 5V 的隔离电源模块做前级再用 AMS1117-3.3 把 5V 降到 3.3V 给主控和模组。注意 AMS1117 的压差和散热5V 降到 3.3V、负载 200mA 时它自身要消耗约 0.34W贴片封装会烫最好留一块铜皮散热。IO 分配上继电器控制脚不要选复用功能多的引脚比如 PA13/PA14 是 SWD 调试口占用了就没法下载程序。我一般把继电器控制放在 PB0WiFi 模组的 UART 用 USART2PA2/PA3留 USART1 给调试打印。下面是一个最小系统的引脚定义片段/* 引脚定义集中管理改板子只改这里 */ #define RELAY_PIN GPIO_Pin_0 #define RELAY_PORT GPIOB #define WIFI_UART USART2 #define WIFI_TX_PIN GPIO_Pin_2 /* PA2 - 模组 RX */ #define WIFI_RX_PIN GPIO_Pin_3 /* PA3 - 模组 TX */ /* 继电器初始化推挽输出默认拉低断开 */ void Relay_Init(void) { GPIO_InitTypeDef gpio; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); gpio.GPIO_Pin RELAY_PIN; gpio.GPIO_Mode GPIO_Mode_Out_PP; gpio.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(RELAY_PORT, gpio); GPIO_ResetBits(RELAY_PORT, RELAY_PIN); /* 上电默认断开安全第一 */ }这段代码的逻辑很直白把继电器控制脚配成推挽输出上电先拉低保证插座默认是断电状态。参数上GPIO_Speed_50MHz对继电器这种慢速负载其实过剩但设高了没坏处关键是上电默认电平如果默认拉高上电瞬间插座就通电接了大功率电器会有安全隐患。这一点新手特别容易忽略板子一上电继电器就“啪”一声吸合吓一跳。3. 定时功能的实现本地 RTC 和云端指令怎么配合3.1 用 RTC 做本地定时断网也不丢定时功能的核心矛盾是网络会断但定时不能停。如果所有定时都依赖云端下发指令那断网期间插座就变成砖头。所以本地必须有一份定时表用 STM32 内置的 RTC实时时钟来跑。RTC 由独立的低速时钟驱动主电源断了还能靠纽扣电池维持走时这是它比 SysTick 更适合做定时的原因。常见做法是维护一个定时任务数组每个任务包含“时、分、使能、动作开/关、星期掩码”。RTC 秒中断里每秒检查一次当前时间是否命中某个任务。下面是一个简化的任务结构和检查逻辑/* 单条定时任务最多支持 8 条 */ typedef struct { uint8_t hour; /* 0-23 */ uint8_t minute; /* 0-59 */ uint8_t enable; /* 1启用 0停用 */ uint8_t action; /* 1开 0关 */ uint8_t weekmask; /* bit0周日 ... bit6周六 */ } TimerTask; TimerTask g_tasks[8]; /* RTC 秒中断中调用命中则执行动作 */ void Timer_Check(uint8_t hour, uint8_t minute, uint8_t week) { for (uint8_t i 0; i 8; i) { if (!g_tasks[i].enable) continue; if (g_tasks[i].hour ! hour || g_tasks[i].minute ! minute) continue; if (!(g_tasks[i].weekmask (1 week))) continue; Relay_Set(g_tasks[i].action); /* 执行开或关 */ } }逻辑说明每秒进一次Timer_Check逐条比对小时、分钟和星期掩码全部命中才动作。参数上weekmask用位掩码表示星期几比如0x3F表示周一到周六0x7F表示每天。这里有个细节如果两条任务设在同一分钟一条开一条关执行顺序就取决于数组顺序所以我在写入任务时会做一次冲突检查同一时刻只允许一条任务生效避免继电器来回跳。3.2 云端定时和本地定时的同步策略云端定时不是没用它的价值在于“远程修改”和“跨设备联动”。但云端下发的时间是服务器时间本地 RTC 走的是自己的晶振两者会漂。常见做法是设备每次连上服务器时用服务器时间校准一次 RTC之后本地自己跑云端修改定时表时把整张表下发覆盖本地。这样断网期间本地照常执行联网后自动对齐。同步协议我一般用最简单的 JSON 行协议一行一条指令以换行符结尾。比如云端下发一条定时{cmd:set_timer,idx:0,hour:7,min:30,action:1,week:127,enable:1}STM32 侧解析时不要用完整的 JSON 库RAM 吃不消。用字符串查找定位关键字段就够了比如找hour:然后atoi后面的数字。参数上week用 0-127 表示七天的位掩码idx是任务槽位 0-7。这种“够用就好”的解析方式在资源受限的单片机上比引入 cJSON 更实际代价是格式必须严格多一个空格都可能解析失败所以云端拼字符串时要固定格式。3.3 掉电保存定时表写进 Flash 的正确姿势定时表不能只放 RAM断电就没了。STM32F103 有内置 Flash可以划一页出来存定时表。但 Flash 写之前必须先擦除整页而且擦写次数有限约 1 万次不能每次改一条任务就擦一次。我的做法是定时表在 RAM 里改改完后打一个“脏标记”在主循环里检测到脏标记且距离上次写入超过 5 秒才真正写 Flash。这样既保证掉电前能存下来又不会频繁擦写。#define TIMER_FLASH_ADDR 0x0801FC00 /* 最后一页1KB */ #define TIMER_MAGIC 0x5A5A0001 typedef struct { uint32_t magic; /* 校验用防止空片读出乱码 */ TimerTask tasks[8]; uint32_t crc; /* 简单累加和 */ } TimerStore; void Timer_Save(void) { TimerStore store; store.magic TIMER_MAGIC; memcpy(store.tasks, g_tasks, sizeof(g_tasks)); store.crc 0; for (uint8_t i 0; i sizeof(store.tasks); i) store.crc ((uint8_t *)store.tasks)[i]; FLASH_Unlock(); FLASH_ErasePage(TIMER_FLASH_ADDR); uint32_t *p (uint32_t *)store; for (uint8_t i 0; i sizeof(store) / 4; i) FLASH_ProgramWord(TIMER_FLASH_ADDR i * 4, p[i]); FLASH_Lock(); }逻辑说明先把 RAM 里的任务表打包成一个带 magic 和 crc 的结构体擦除目标页后按字写入。参数上TIMER_FLASH_ADDR选最后一页是为了不侵占程序空间具体地址要对照芯片手册的 Flash 分区不同型号最后一页起始地址不一样。magic的作用是上电读取时判断这页到底有没有被写过如果读出来不是0x5A5A0001说明是空片直接用默认任务表避免把随机数据当成定时任务执行。4. 避坑与排查那些让插座“抽风”的细节4.1 继电器吸合导致单片机复位现象定时到点继电器一吸合单片机立刻重启串口打印从头开始。原因继电器线圈是感性负载断电瞬间产生反向高压通过电源线或地线耦合进单片机供电触发欠压复位。解决第一继电器模块必须带光耦隔离控制侧和负载侧不共地第二继电器线圈两端并联续流二极管很多模块已集成第三单片机供电入口加 100uF 电解加 0.1uF 陶瓷电容做去耦。这三条做完复位基本消失。4.2 WiFi 模组连不上热点AT 指令没回显现象发AT没反应或者返回ERROR。原因串口波特率不匹配、TX/RX 接反、模组供电电流不够。排查顺序先用 USB 转串口直接接模组确认模组本身能工作再检查 STM32 和模组的 TX/RX 是否交叉连接STM32 的 TX 接模组 RX最后量模组供电电压WiFi 模组发射瞬间电流能到 300mA如果电源模块带不动电压会跌到 3V 以下模组直接罢工。解决给模组单独一路 LDO或者加大电源模块的电流余量。4.3 定时到点不动作但手动开关正常现象手机点开关继电器有反应但设了定时到点没动静。原因RTC 没走、秒中断没开、或者时间比对逻辑写错。排查先读 RTC 当前时间看是不是在走再确认秒中断是否使能最后检查Timer_Check里的星期掩码很多人把week的取值搞错RTC 返回 1-7 表示周一到周日而掩码用的是 bit0-bit6差一位就永远不命中。解决统一约定RTC 的星期值减 1 再当位偏移用。4.4 断电后定时表丢失或变成乱码现象重新上电定时任务全没了或者出现一堆莫名其妙的任务。原因Flash 写入时没擦除干净、写入过程中断电、或者读取时没校验 magic。解决写入前必须FLASH_ErasePage写入时先写 magic 最后写 crc读取时先校验 magic 再校验 crc任一不过就用默认表。另外Flash 操作期间最好关中断避免中断里读 Flash 导致总线冲突。4.5 手机 App 显示的状态和实际不符现象App 显示“已开”但插座实际是关的。原因状态回传丢失或者 App 本地缓存没更新。解决每次继电器动作后STM32 主动上报一次当前状态而不是等 App 来查App 侧收到上报再刷新 UI。另外继电器的实际触点状态和 IO 电平不一定一致比如继电器坏了如果要做高可靠可以加一路光耦检测触点是否真的闭合把真实状态回传。5. 进阶技巧把定时精度和可靠性再往上提一档5.1 用 RTC 闹钟替代秒中断轮询前面用秒中断每秒轮询任务表简单但费电而且中断里做字符串比对不优雅。更进阶的做法是用 RTC 的 Alarm 功能把最近一条要执行的任务时间写进 Alarm 寄存器到点触发闹钟中断中断里执行动作并重新计算下一条任务的时间写进去。这样 CPU 大部分时间可以休眠功耗从十几毫安降到几百微安适合电池备份场景。代价是任务表变动时要重新计算 Alarm逻辑复杂一点。/* 找出下一条将要执行的任务写入 RTC Alarm */ void Timer_ScheduleNext(uint8_t cur_hour, uint8_t cur_min, uint8_t cur_week) { uint16_t min_delta 0xFFFF; TimerTask *next NULL; for (uint8_t i 0; i 8; i) { if (!g_tasks[i].enable) continue; uint16_t now cur_hour * 60 cur_min; uint16_t tgt g_tasks[i].hour * 60 g_tasks[i].minute; uint16_t delta (tgt now) ? (tgt - now) : (tgt 1440 - now); if (delta min_delta) { min_delta delta; next g_tasks[i]; } } if (next) RTC_SetAlarm(min_delta); /* 简化示意实际要算绝对时间 */ }逻辑说明遍历所有启用任务算出距离当前时间的分钟差取最小的那条作为下一条。参数上1440是一天的分钟数用于处理跨零点的情况。注意这里只按分钟算没考虑星期实际实现要把星期掩码也纳入计算否则设了“仅周一”的任务可能在周二被触发。这个函数在每次任务执行后和任务表修改后都要调用一次。5.2 加一层看门狗和状态自检插座是长期无人值守的设备死机了没人给你重启。独立看门狗IWDG必须开主循环里定时喂狗任何一处卡死超过设定时间就自动复位。喂狗时间我一般设 2 秒太短容易误复位太长死机后恢复慢。另外上电自检要做三件事读 Flash 校验定时表、检测 WiFi 模组是否响应 AT、检测继电器驱动脚电平是否正常。自检不过就进入安全模式只保留手动开关不执行定时避免带病运行。5.3 一个容易被忽略的细节继电器动作的“最小间隔”如果两条定时任务设得很近比如 7:00 开、7:01 关继电器一分钟内动作两次机械寿命会受影响。更极端的情况是任务表被错误配置成同一分钟反复开关。我的习惯是在Relay_Set里加一个最小间隔保护记录上次动作的时间戳如果距离上次动作小于 10 秒直接忽略本次请求并记录一条日志。这个保护看起来简单但能挡住大部分因为配置错误或网络重发导致的继电器“抽搐”。static uint32_t g_last_relay_tick 0; void Relay_Set(uint8_t on) { uint32_t now GetTick(); if (now - g_last_relay_tick 10000) return; /* 10 秒内不重复动作 */ g_last_relay_tick now; if (on) GPIO_SetBits(RELAY_PORT, RELAY_PIN); else GPIO_ResetBits(RELAY_PORT, RELAY_PIN); Report_State(on); /* 动作后主动上报 */ }逻辑说明用系统 tick 做时间戳10 秒内的重复请求直接丢弃。参数10000是毫秒按需调整继电器的机械寿命通常在十万次量级10 秒间隔意味着最坏情况一天动作 8640 次十天就接近寿命上限所以实际产品里这个间隔应该更大比如 30 秒。这个保护逻辑我是在一次调试中加的当时云端因为网络重发同一秒内下了三次开指令继电器连响三声虽然没坏但听着就心疼。做这个方案最大的体会是联网控制本身不难难的是让它在断网、断电、干扰、误操作这些“不理想”的情况下还能按预期工作。我现在的习惯是每加一个功能先问自己“如果这时候断网会怎样”“如果这时候断电会怎样”把这两个问题答清楚了再写代码。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 12:38:57 · 阅读 1.2k STM32+WiFi智能插座定时功能实战：本地RTC与云端同步避坑指南
简介这份资源面向嵌入式开发初学者与智能家居DIY爱好者提供基于STM32单片机实现WiFi控制家电插座开关及定时功能的完整工程方案帮助读者理解从硬件选型到固件开发的整体流程。压缩包共224个文件约101.37MB包含32个c与33个h源码文件、20个o编译产物、19个crf与20个d中间文件以及uvproj、uvopt等Keil工程配置另有11个doc与9个pdf文档、34张jpg图片和6段mp4视频覆盖原理讲解、电路设计与调试记录。资源围绕STM32F4系列与ESP8266/ESP32 WiFi模块展开涉及UART/SPI通信、TCP/IP协议栈、FreeRTOS多任务定时管理、继电器驱动及PCB布局等关键知识点并附有schdoc原理图与hex固件。已有1555人学习下载适合作为课程设计、毕业设计或智能插座原型开发的参考模板便于快速搭建可运行的定时开关控制系统。1. 从零拆解STM32 加 WiFi 做家电插座定时开关到底难在哪很多人第一次听到“基于 STM32 单片机 WiFi 控制家电插座开关定时功能”脑子里浮现的画面是手机点一下继电器“咔哒”一声灯亮了完事。真动手才发现难的不是点灯而是“定时”这件事在嵌入式里怎么落地——本地定时和云端定时谁说了算、断网之后定时还准不准、继电器吸合瞬间单片机为什么会复位。我见过太多人卡在“能连上 WiFi但定时到点不动作”这一步最后怀疑人生。这个方向本质上是一个“弱电控强电”的物联网执行终端STM32 负责逻辑和定时WiFi 模组负责和手机/云端的通信继电器负责真正通断 220V 回路。它适合有 C 语言基础、想从裸机过渡到联网控制的开发者也适合做智能家居小批量定制的硬件爱好者。核心诉求就四个远程开关、本地定时、状态回传、断电记忆。把这四件事做扎实这个插座才算能用而不是个玩具。2. 硬件选型与电路别让继电器把单片机拖复位2.1 主控、WiFi 模组和继电器的三角关系主控选 STM32F103C8T6 是最稳的起点72MHz 主频、64KB Flash、20KB RAM跑一个定时任务加串口协议绰绰有余价格也压得住。WiFi 模组常见做法是选支持 AT 指令的串口透传模组STM32 通过 UART 发 AT 指令控制它连热点、连服务器、收发数据。为什么不直接把 WiFi 协议栈跑在 STM32 上因为那需要更大的 RAM 和更复杂的协议栈移植对第一次做这个方案的人来说串口透传模组把复杂度隔离掉了出问题也容易定位是模组还是主控。继电器模块要选带光耦隔离的这一点是血泪经验。市面上很多廉价继电器板是“单片机 IO 直驱三极管”的结构线圈断电瞬间的反向电动势会通过三极管耦合回 IO 口轻则 IO 抖动重则整片复位。带光耦的模块把控制侧和负载侧电气隔开STM32 的 IO 只驱动光耦内部的发光二极管电流小、干扰小。部件常见型号关键参数选型理由主控STM32F103C8T672MHz / 64KB Flash / 20KB RAM资源够、资料多、成本低WiFi 模组串口 AT 透传模组3.3V TTL 串口 / 支持 STA 模式协议栈内置主控只管发指令继电器5V 光耦隔离单路模块触点 10A/250VAC隔离干扰扛得住家电电流电源220V 转 5V 隔离电源模块输出 5V/1A给继电器和降压电路供电2.2 供电和 IO 分配3.3V 与 5V 不能混着来供电是第二个翻车高发区。继电器模块要 5VSTM32 要 3.3VWiFi 模组多数也是 3.3V。常见做法是用一个 220V 转 5V 的隔离电源模块做前级再用 AMS1117-3.3 把 5V 降到 3.3V 给主控和模组。注意 AMS1117 的压差和散热5V 降到 3.3V、负载 200mA 时它自身要消耗约 0.34W贴片封装会烫最好留一块铜皮散热。IO 分配上继电器控制脚不要选复用功能多的引脚比如 PA13/PA14 是 SWD 调试口占用了就没法下载程序。我一般把继电器控制放在 PB0WiFi 模组的 UART 用 USART2PA2/PA3留 USART1 给调试打印。下面是一个最小系统的引脚定义片段/* 引脚定义集中管理改板子只改这里 */ #define RELAY_PIN GPIO_Pin_0 #define RELAY_PORT GPIOB #define WIFI_UART USART2 #define WIFI_TX_PIN GPIO_Pin_2 /* PA2 - 模组 RX */ #define WIFI_RX_PIN GPIO_Pin_3 /* PA3 - 模组 TX */ /* 继电器初始化推挽输出默认拉低断开 */ void Relay_Init(void) { GPIO_InitTypeDef gpio; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); gpio.GPIO_Pin RELAY_PIN; gpio.GPIO_Mode GPIO_Mode_Out_PP; gpio.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(RELAY_PORT, gpio); GPIO_ResetBits(RELAY_PORT, RELAY_PIN); /* 上电默认断开安全第一 */ }这段代码的逻辑很直白把继电器控制脚配成推挽输出上电先拉低保证插座默认是断电状态。参数上GPIO_Speed_50MHz对继电器这种慢速负载其实过剩但设高了没坏处关键是上电默认电平如果默认拉高上电瞬间插座就通电接了大功率电器会有安全隐患。这一点新手特别容易忽略板子一上电继电器就“啪”一声吸合吓一跳。3. 定时功能的实现本地 RTC 和云端指令怎么配合3.1 用 RTC 做本地定时断网也不丢定时功能的核心矛盾是网络会断但定时不能停。如果所有定时都依赖云端下发指令那断网期间插座就变成砖头。所以本地必须有一份定时表用 STM32 内置的 RTC实时时钟来跑。RTC 由独立的低速时钟驱动主电源断了还能靠纽扣电池维持走时这是它比 SysTick 更适合做定时的原因。常见做法是维护一个定时任务数组每个任务包含“时、分、使能、动作开/关、星期掩码”。RTC 秒中断里每秒检查一次当前时间是否命中某个任务。下面是一个简化的任务结构和检查逻辑/* 单条定时任务最多支持 8 条 */ typedef struct { uint8_t hour; /* 0-23 */ uint8_t minute; /* 0-59 */ uint8_t enable; /* 1启用 0停用 */ uint8_t action; /* 1开 0关 */ uint8_t weekmask; /* bit0周日 ... bit6周六 */ } TimerTask; TimerTask g_tasks[8]; /* RTC 秒中断中调用命中则执行动作 */ void Timer_Check(uint8_t hour, uint8_t minute, uint8_t week) { for (uint8_t i 0; i 8; i) { if (!g_tasks[i].enable) continue; if (g_tasks[i].hour ! hour || g_tasks[i].minute ! minute) continue; if (!(g_tasks[i].weekmask (1 week))) continue; Relay_Set(g_tasks[i].action); /* 执行开或关 */ } }逻辑说明每秒进一次Timer_Check逐条比对小时、分钟和星期掩码全部命中才动作。参数上weekmask用位掩码表示星期几比如0x3F表示周一到周六0x7F表示每天。这里有个细节如果两条任务设在同一分钟一条开一条关执行顺序就取决于数组顺序所以我在写入任务时会做一次冲突检查同一时刻只允许一条任务生效避免继电器来回跳。3.2 云端定时和本地定时的同步策略云端定时不是没用它的价值在于“远程修改”和“跨设备联动”。但云端下发的时间是服务器时间本地 RTC 走的是自己的晶振两者会漂。常见做法是设备每次连上服务器时用服务器时间校准一次 RTC之后本地自己跑云端修改定时表时把整张表下发覆盖本地。这样断网期间本地照常执行联网后自动对齐。同步协议我一般用最简单的 JSON 行协议一行一条指令以换行符结尾。比如云端下发一条定时{cmd:set_timer,idx:0,hour:7,min:30,action:1,week:127,enable:1}STM32 侧解析时不要用完整的 JSON 库RAM 吃不消。用字符串查找定位关键字段就够了比如找hour:然后atoi后面的数字。参数上week用 0-127 表示七天的位掩码idx是任务槽位 0-7。这种“够用就好”的解析方式在资源受限的单片机上比引入 cJSON 更实际代价是格式必须严格多一个空格都可能解析失败所以云端拼字符串时要固定格式。3.3 掉电保存定时表写进 Flash 的正确姿势定时表不能只放 RAM断电就没了。STM32F103 有内置 Flash可以划一页出来存定时表。但 Flash 写之前必须先擦除整页而且擦写次数有限约 1 万次不能每次改一条任务就擦一次。我的做法是定时表在 RAM 里改改完后打一个“脏标记”在主循环里检测到脏标记且距离上次写入超过 5 秒才真正写 Flash。这样既保证掉电前能存下来又不会频繁擦写。#define TIMER_FLASH_ADDR 0x0801FC00 /* 最后一页1KB */ #define TIMER_MAGIC 0x5A5A0001 typedef struct { uint32_t magic; /* 校验用防止空片读出乱码 */ TimerTask tasks[8]; uint32_t crc; /* 简单累加和 */ } TimerStore; void Timer_Save(void) { TimerStore store; store.magic TIMER_MAGIC; memcpy(store.tasks, g_tasks, sizeof(g_tasks)); store.crc 0; for (uint8_t i 0; i sizeof(store.tasks); i) store.crc ((uint8_t *)store.tasks)[i]; FLASH_Unlock(); FLASH_ErasePage(TIMER_FLASH_ADDR); uint32_t *p (uint32_t *)store; for (uint8_t i 0; i sizeof(store) / 4; i) FLASH_ProgramWord(TIMER_FLASH_ADDR i * 4, p[i]); FLASH_Lock(); }逻辑说明先把 RAM 里的任务表打包成一个带 magic 和 crc 的结构体擦除目标页后按字写入。参数上TIMER_FLASH_ADDR选最后一页是为了不侵占程序空间具体地址要对照芯片手册的 Flash 分区不同型号最后一页起始地址不一样。magic的作用是上电读取时判断这页到底有没有被写过如果读出来不是0x5A5A0001说明是空片直接用默认任务表避免把随机数据当成定时任务执行。4. 避坑与排查那些让插座“抽风”的细节4.1 继电器吸合导致单片机复位现象定时到点继电器一吸合单片机立刻重启串口打印从头开始。原因继电器线圈是感性负载断电瞬间产生反向高压通过电源线或地线耦合进单片机供电触发欠压复位。解决第一继电器模块必须带光耦隔离控制侧和负载侧不共地第二继电器线圈两端并联续流二极管很多模块已集成第三单片机供电入口加 100uF 电解加 0.1uF 陶瓷电容做去耦。这三条做完复位基本消失。4.2 WiFi 模组连不上热点AT 指令没回显现象发AT没反应或者返回ERROR。原因串口波特率不匹配、TX/RX 接反、模组供电电流不够。排查顺序先用 USB 转串口直接接模组确认模组本身能工作再检查 STM32 和模组的 TX/RX 是否交叉连接STM32 的 TX 接模组 RX最后量模组供电电压WiFi 模组发射瞬间电流能到 300mA如果电源模块带不动电压会跌到 3V 以下模组直接罢工。解决给模组单独一路 LDO或者加大电源模块的电流余量。4.3 定时到点不动作但手动开关正常现象手机点开关继电器有反应但设了定时到点没动静。原因RTC 没走、秒中断没开、或者时间比对逻辑写错。排查先读 RTC 当前时间看是不是在走再确认秒中断是否使能最后检查Timer_Check里的星期掩码很多人把week的取值搞错RTC 返回 1-7 表示周一到周日而掩码用的是 bit0-bit6差一位就永远不命中。解决统一约定RTC 的星期值减 1 再当位偏移用。4.4 断电后定时表丢失或变成乱码现象重新上电定时任务全没了或者出现一堆莫名其妙的任务。原因Flash 写入时没擦除干净、写入过程中断电、或者读取时没校验 magic。解决写入前必须FLASH_ErasePage写入时先写 magic 最后写 crc读取时先校验 magic 再校验 crc任一不过就用默认表。另外Flash 操作期间最好关中断避免中断里读 Flash 导致总线冲突。4.5 手机 App 显示的状态和实际不符现象App 显示“已开”但插座实际是关的。原因状态回传丢失或者 App 本地缓存没更新。解决每次继电器动作后STM32 主动上报一次当前状态而不是等 App 来查App 侧收到上报再刷新 UI。另外继电器的实际触点状态和 IO 电平不一定一致比如继电器坏了如果要做高可靠可以加一路光耦检测触点是否真的闭合把真实状态回传。5. 进阶技巧把定时精度和可靠性再往上提一档5.1 用 RTC 闹钟替代秒中断轮询前面用秒中断每秒轮询任务表简单但费电而且中断里做字符串比对不优雅。更进阶的做法是用 RTC 的 Alarm 功能把最近一条要执行的任务时间写进 Alarm 寄存器到点触发闹钟中断中断里执行动作并重新计算下一条任务的时间写进去。这样 CPU 大部分时间可以休眠功耗从十几毫安降到几百微安适合电池备份场景。代价是任务表变动时要重新计算 Alarm逻辑复杂一点。/* 找出下一条将要执行的任务写入 RTC Alarm */ void Timer_ScheduleNext(uint8_t cur_hour, uint8_t cur_min, uint8_t cur_week) { uint16_t min_delta 0xFFFF; TimerTask *next NULL; for (uint8_t i 0; i 8; i) { if (!g_tasks[i].enable) continue; uint16_t now cur_hour * 60 cur_min; uint16_t tgt g_tasks[i].hour * 60 g_tasks[i].minute; uint16_t delta (tgt now) ? (tgt - now) : (tgt 1440 - now); if (delta min_delta) { min_delta delta; next g_tasks[i]; } } if (next) RTC_SetAlarm(min_delta); /* 简化示意实际要算绝对时间 */ }逻辑说明遍历所有启用任务算出距离当前时间的分钟差取最小的那条作为下一条。参数上1440是一天的分钟数用于处理跨零点的情况。注意这里只按分钟算没考虑星期实际实现要把星期掩码也纳入计算否则设了“仅周一”的任务可能在周二被触发。这个函数在每次任务执行后和任务表修改后都要调用一次。5.2 加一层看门狗和状态自检插座是长期无人值守的设备死机了没人给你重启。独立看门狗IWDG必须开主循环里定时喂狗任何一处卡死超过设定时间就自动复位。喂狗时间我一般设 2 秒太短容易误复位太长死机后恢复慢。另外上电自检要做三件事读 Flash 校验定时表、检测 WiFi 模组是否响应 AT、检测继电器驱动脚电平是否正常。自检不过就进入安全模式只保留手动开关不执行定时避免带病运行。5.3 一个容易被忽略的细节继电器动作的“最小间隔”如果两条定时任务设得很近比如 7:00 开、7:01 关继电器一分钟内动作两次机械寿命会受影响。更极端的情况是任务表被错误配置成同一分钟反复开关。我的习惯是在Relay_Set里加一个最小间隔保护记录上次动作的时间戳如果距离上次动作小于 10 秒直接忽略本次请求并记录一条日志。这个保护看起来简单但能挡住大部分因为配置错误或网络重发导致的继电器“抽搐”。static uint32_t g_last_relay_tick 0; void Relay_Set(uint8_t on) { uint32_t now GetTick(); if (now - g_last_relay_tick 10000) return; /* 10 秒内不重复动作 */ g_last_relay_tick now; if (on) GPIO_SetBits(RELAY_PORT, RELAY_PIN); else GPIO_ResetBits(RELAY_PORT, RELAY_PIN); Report_State(on); /* 动作后主动上报 */ }逻辑说明用系统 tick 做时间戳10 秒内的重复请求直接丢弃。参数10000是毫秒按需调整继电器的机械寿命通常在十万次量级10 秒间隔意味着最坏情况一天动作 8640 次十天就接近寿命上限所以实际产品里这个间隔应该更大比如 30 秒。这个保护逻辑我是在一次调试中加的当时云端因为网络重发同一秒内下了三次开指令继电器连响三声虽然没坏但听着就心疼。做这个方案最大的体会是联网控制本身不难难的是让它在断网、断电、干扰、误操作这些“不理想”的情况下还能按预期工作。我现在的习惯是每加一个功能先问自己“如果这时候断网会怎样”“如果这时候断电会怎样”把这两个问题答清楚了再写代码。希望帮到你。本文还有配套的精品资源点击获取