
简介这是一份基于STM32ESP8266OneNET云平台的智能家居系统毕业设计项目面向电子、嵌入式相关专业学生和毕设开发者解决传统家居环境远程监测与设备控制难题完整覆盖从硬件搭建、数据采集到云端联调的软硬件设计链路。系统以STM32F1为主控芯片借助WiFi模块ESP8266-01S接入OneNET云平台整合甲烷MQ4、一氧化碳MQ7、温湿度DHT22、光照BH1750与人体感应LH1778等传感器对各类环境数据进行定期采集处理并同步送显到1.44寸TFT彩色液晶屏与云平台实现远程查看和智能化控制。压缩包共12.65MB包含可直接运行的STM32源码、MQTT通信源码、详细论文文档及答辩PPT模板论文中附有原理图、程序说明与硬件设计目录结构清晰方便按模块查阅和对照复刻。已有705人学习下载适合需要快速搭建毕设原型、理清物联网云平台交互流程或参考完整项目文档的读者。拿到资料后结合对应硬件模块即可复现同一套系统显著节省从零开发与调试的时间。1. 为什么这套方案是毕设级项目的“标准答案”凌晨两点被热醒摸黑去找空调遥控器这时候你大概会想如果有个手机能控制一切就好了。而基于STM32ESP8266OneNET云平台的智能家居系统做的就是这件事——把温湿度、光照、人体红外这些传感器接在STM32上通过ESP8266把数据推到OneNET云平台手机端实时查看还能反向控制继电器开关家电。这套架构是目前STM32毕业设计里最常见、也最容易出成果的选题之一它把嵌入式、通信协议、物联网平台三块硬技术凑齐了难度又刚好卡在“跳一跳够得着”的位置。适合谁大四做毕设的本科生、想给简历加一个完整物联网项目的在职新人甚至是想给家里做个低成本智能控制方案的动手党。这套方案不用买昂贵的开发板一块STM32F103C8T6最小系统板加一个ESP8266模块就能开工整体硬件成本可以控制在几十块钱以内。最关键的是OneNET是国内平台接入文档全中文不用面对一堆英文SDK发愁。下面我从硬件选型讲到代码实现再讲这项目里最容易翻车的几个坑尽量让你少走弯路。2. 系统架构与硬件选型先想清楚数据怎么流2.1 三层架构感知层、网络层、应用层智能家居系统听起来高大上拆开看就是个典型的三层物联网架构。感知层就是STM32连接的各个传感器——DHT11测温湿度、BH1750测光照强度、HC-SR501检测人体活动外加继电器模块控制家电。网络层由ESP8266承担它干两件事一是通过WiFi连上路由器二是用MQTT协议跟OneNET云平台保持长连接。应用层就更直接了OneNET自带的可视化页面和手机App能实时展示设备上报的数据也能下发控制指令。这三层之间的数据流才是设计的核心。传感器数据进入STM32的ADC或GPIO经过滤波、换算成实际物理值后按照约定好的JSON格式拼成字符串通过串口USART1发给ESP8266。ESP8266收到后不做任何解析直接当作MQTT消息发布到OneNET的指定Topic。控制指令方向刚好相反OneNET平台下发消息ESP8266在订阅的Topic里收到JSON字符串原样通过串口丢给STM32STM32解析后控制继电器动作。这里有一个很多刚做毕设的人容易犯的错想把所有逻辑都堆在ESP8266上让STM32只当个数据采集器。但ESP8266的AT固件模式下处理能力很有限而且做数据解析会拖累WiFi通信稳定性。正确的做法是让ESP8266当“哑管道”所有业务判断都留在STM32端。这样出了问题也好排查——串口助手一抓包就知道是设备层的问题还是网络层的问题。2.2 STM32选型为什么是F103C8T6而不是其他型号STM32家族很庞大但做这套智能家居毕设F103C8T6是最合适的选择。这块芯片拥有72MHz主频、64KB Flash、20KB RAM三个USART、两个SPI、两个I2C资源对智能家居场景来说绰绰有余。更重要的是它的生态——标准外设库文档最全网上教程和代码参考多得看不完真遇到问题搜索一下基本都有答案。如果你选H743这种高端型号性能倒是强了但参考代码少、配置复杂毕设周期会被拖得很长。内存占用也要算一笔账。DHT11读取要写延时函数BH1750走I2C协议需要缓冲区MQTT的JSON报文最长不过一两百字节再加上RTOS任务栈如果你上操作系统20KB RAM其实有点紧张。所以我的建议是系统不上FreeRTOS用裸机加定时器调度的方式跑。逻辑简单、不易死锁、调试方便而且代码量足够写满毕设论文。别觉得裸机掉档次稳定性和可解释性才是毕设答辩最看重的。2.3 ESP8266模块选型AT固件还是SDK开发ESP8266有两种玩法刷AT固件当透明传输模块或者用SDK直接做二次开发。智能家居毕设我强烈推荐AT固件方案。理由很实际——如果你用SDK开发等于同时维护两套代码STM32端一套逻辑ESP8266端一套逻辑调试复杂度翻倍。而AT固件下ESP8266就是个“串口转WiFi”的黑匣子STM32只要按AT指令格式发命令它就能完成连接路由器、建立MQTT连接、发布订阅消息等一系列操作。某宝上常见的ESP8266模块有两种引脚版本ESP-01S和ESP-12F。ESP-01S引脚少、尺寸小但只有两个GPIO可用而且天线信号一般ESP-12F引脚引出完整板载PCB天线信号稳定得多。预算允许就选ESP-12F后续不管是做本地调试还是实际部署都省心。注意模块的工作电平是3.3V不能直接接5V串口否则大概率当场烧毁——这是新手最容易翻车的第一道坎。3. STM32端的数据采集与控制逻辑裸机也能跑得很稳3.1 传感器驱动DHT11和BH1750的读法差异DHT11是单总线协议一根数据线既要发指令又要收数据时序要求精确到微秒级。读它的标准流程是主机拉低总线至少18ms发起起始信号然后释放总线等待DHT11响应之后依次读取40位数据——8位湿度整数、8位湿度小数、8位温度整数、8位温度小数、8位校验和。STM32端最关键的是那几个延时函数的精度F103主频72MHz用普通的for循环延时配合示波器校准过基本能满足时序要求。下面是最小可用的DHT11读取代码用标准外设库写的// DHT11_GPIO初始化使用PA0作为数据引脚 void DHT11_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_0; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; // 先设为推挽输出用于发送起始信号 GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, GPIO_InitStructure); } // 读取单字节数据MSB先行 uint8_t DHT11_ReadByte(void) { uint8_t i, byte 0; for(i 0; i 8; i) { while(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) RESET); // 等待50us低电平结束 delay_us(30); // 延时30us后采样 if(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) SET) { byte | (uint8_t)(1 (7 - i)); // 高电平持续较长则为1 } while(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) SET); // 等待高电平结束 } return byte; } // 完整读取40位数据校验通过才返回1 uint8_t DHT11_ReadData(uint8_t *humidity, uint8_t *temperature) { uint8_t buf[5] {0, 0, 0, 0, 0}; GPIOA-CRL ~(GPIO_CRL_MODE0 | GPIO_CRL_CNF0); // 配置PA0为开漏输入 GPIOA-CRL | GPIO_CRL_CNF0_0; // 主机拉低起始信号 GPIOA-CRL ~GPIO_CRL_CNF0; GPIOA-CRL | GPIO_CRL_MODE0_1; // 推挽输出 GPIO_ResetBits(GPIOA, GPIO_Pin_0); delay_ms(20); // 至少18ms GPIO_SetBits(GPIOA, GPIO_Pin_0); delay_us(30); // 释放总线30us // 切换为输入模式等待DHT11响应 GPIOA-CRL ~(GPIO_CRL_MODE0 | GPIO_CRL_CNF0); GPIOA-CRL | GPIO_CRL_CNF0_0; // 等待响应信号 while(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) SET); while(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) RESET); while(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) SET); // 连续读5字节 for(uint8_t i 0; i 5; i) { buf[i] DHT11_ReadByte(); } // 校验前4字节之和等于第5字节 if((buf[0] buf[1] buf[2] buf[3]) buf[4]) { *humidity buf[0]; *temperature buf[2]; return 1; } return 0; }这段代码的关键在于时序起始信号必须拉低20ms以上释放总线后要等DHT11主动拉低响应读取每位数据时必须在低电平结束后的30us窗口内采样。如果你发现读数偶尔跳变或者老是超时优先用逻辑分析仪抓波形看低电平时间是否在协议允许的范围内。另外每次读取完必须把GPIO重新配置为推挽输出否则下一次的起始信号发不出去。BH1750就简单多了走标准I2C协议地址固定为0x23ADDR引脚接低电平或0x5C接高电平。上电后先发一条Power On命令0x01再发连续高分辨率模式命令0x10等待180ms转换完成后连续读2字节。这里有个实用的小技巧BH1750的测量范围是1到65535 lx但室内光照一般在0到1000 lx之间可以把它放在窗帘边或窗台上测环境光这样数据变化更明显演示效果也更好。3.2 串口通信协议设计给STM32和ESP8266之间定规矩STM32和ESP8266之间到底传什么格式的数据必须在写代码之前定死。常见的做法是自定义一个轻量协议帧头加功能码加长度加数据加校验。比如下行数据传感数据上传可以设计成ATMQTTPUB0,topic,1,{\T\:26,\H\:60,\L\:300}这样的形式但实际建议用更结构化的方式封装方便后面扩展。我一般这样设计上下行协议上行数据帧格式为$DATA,温度,湿度,光照,人体感应#例如$DATA,26.5,60.3,320,0#以$开头表示新帧逗号分隔字段#表示帧结束。下行控制帧格式为$CTRL,设备编号,动作#比如开客厅灯就是$CTRL,1,1#关就是$CTRL,1,0#。STM32在串口接收中断里逐字节解析攒到#就认为一帧收完然后丢给状态机处理。// 串口接收状态机逐字节解析遇到帧尾才处理 void USART1_IRQHandler(void) { uint8_t byte; if(USART_GetITStatus(USART1, USART_IT_RXNE)) { byte USART_ReceiveData(USART1); if(parse_state 0 byte $) { parse_state 1; // 收到帧头开始接收 frame_len 0; } else if(parse_state 1) { if(byte #) { parse_state 2; // 收到帧尾标记一帧完成 rx_frame[frame_len] \0; } else if(frame_len 63) { rx_frame[frame_len] byte; } else { parse_state 0; // 超长帧丢弃重新等帧头 } } } } // 主循环里处理完整帧 void Process_Frame(void) { if(parse_state 2) { parse_state 0; // 用sscanf按格式解析比手写字符串分割省代码 if(strncmp(rx_frame, CTRL, 4) 0) { int device_id, action; sscanf(rx_frame, CTRL,%d,%d, device_id, action); GPIO_WriteBit(GPIOB, 1 device_id, action ? Bit_SET : Bit_RESET); } } }这段代码的要点是接收中断里只做状态迁移和存字节不做业务解析这样串口在高数据量时不会阻塞中断。sscanf解析虽然不如手写解析高效但在这套系统里完全够用而且代码可读性好答辩时也更容易解释。注意帧长度上限设了64字节防止恶意数据撑爆缓冲区。3.3 继电器控制与GPIO分配预留扩展性是加分项继电器控制是智能家居的执行末端STM32的GPIO输出高电平或低电平驱动继电器线圈继电器再控制220V交流电路的通断。这里必须注意电气隔离——STM32和继电器模块之间要用光耦隔离或者直接买自带光耦的继电器模块否则继电器吸合瞬间产生的反向电动势可能把STM32打死。另外一个经验是继电器控制引脚不要跟传感器引脚共用一个GPIO组避免继电器动作时拉低电源电压干扰传感器读数。GPIO分配建议如下PA0接DHT11PB6和PB7接BH1750的I2C注意F103的I2C1硬件bug建议直接用GPIO模拟I2CPB0到PB3接四个继电器PA2和PA3接ESP8266的串口USART2PB10接HC-SR501人体红外输出。这样分配的好处是传感器和控制设备分属不同GPIO组调试时互不干扰而且后续如果想加按键或者OLED屏幕还有足够的空闲引脚。4. ESP8266接入OneNET从AT指令到MQTT协议4.1 在OneNET创建产品和设备新版控制台的操作路径OneNET平台这几年改版了好几次很多网上教程还是老版本的界面照着做容易卡住。现在的新版OneNET控制台的创建路径是登录后进入控制台选择“多协议接入”或“设备接入”创建产品时选择“MQTT”协议其他选项按默认即可。创建完产品后会生成一个产品ID再在设备列表里添加设备得到设备ID和设备密钥。这三样东西是后面接入的核心参数建议先存到记事本里。新版OneNET的鉴权方式和老版不太一样老版要填APIKey新版用的是设备密钥衍生出来的token。好在ESP8266的AT固件里MQTT接入只需要填产品ID、设备ID和设备密钥平台会自动完成token计算。如果你看到网上教程让你在代码里手工算token那是给非AT固件设备用的AT固件不需要这步。4.2 用串口助手验证AT指令先打通链路再写STM32代码很多人的习惯是直接写代码然后上电调试结果出了问题分不清是STM32的问题、ESP8266的问题还是平台的问题。我的做法是先用USB转TTL把ESP8266接到电脑上用串口助手手动发AT指令验证每一步全部通过了再回到STM32工程开发。这个习惯能帮你省下至少两天的调试时间。下面是最小接通的AT指令序列用串口助手挨条发送每条等返回OK再发下一条AT // 测试模块是否响应 ATRST // 软复位重启后等待ready ATCWMODE1 // 设置为Station模式连接外部路由器 ATCWJAP你的WiFi名,你的WiFi密码 // 连接路由器返回WIFI GOT IP即成功 ATMQTTUSERCFG0,1,设备ID,产品ID,设备密钥,0,0, // 配置MQTT用户名密码 ATMQTTCONN0,mqtts.heclouds.com,1883,1 // 连接OneNET的MQTT服务器注意上面ATMQTTUSERCFG里参数的顺序AT固件版本的MQTT配置命令是先设备ID、产品ID、密钥每个固件版本可能有细微差异输错了会报参数错误。连接成功后把数据往OneNET推的命令是ATMQTTPUB0,$sys/产品ID/设备ID/dp/post/ojbk,1,{\datastreams\:[{\id\:\temp\,\datapoints\:[{\value\:26}]}]}这里的Topic格式也是新版平台特有的老版教程里的Topic在新平台下会报订阅失败。上面这些指令在串口助手里逐条验证通过后把同样的AT指令序列写进STM32的代码里用延时和OK应答做握手。代码流程如下// 向ESP8266发送一条AT指令并等待OK应答 uint8_t ESP8266_SendCmd(char *cmd, char *expect, uint32_t timeout_ms) { USART2_SendString(cmd); // 通过USART2发出指令 uint32_t tick GetTickMs(); while(GetTickMs() - tick timeout_ms) { if(strstr(rx_buffer, expect) ! NULL) // 在接收缓冲区里找期望的应答 return 1; } return 0; } // 初始化ESP8266并接入OneNET每步都确认成功后继续下一步 uint8_t ESP8266_Init(void) { if(!ESP8266_SendCmd(AT\r\n, OK, 500)) return 1; delay_ms(1000); ESP8266_SendCmd(ATRST\r\n, ready, 3000); delay_ms(2000); if(!ESP8266_SendCmd(ATCWMODE1\r\n, OK, 1000)) return 2; if(!ESP8266_SendCmd(ATCWJAP\your_wifi\,\your_pass\\r\n, WIFI GOT IP, 8000)) return 3; if(!ESP8266_SendCmd(ATMQTTUSERCFG0,1,\device_id\,\product_id\,\device_secret\,0,0,\\\r\n, OK, 1000)) return 4; if(!ESP8266_SendCmd(ATMQTTCONN0,\mqtts.heclouds.com\,1883,1\r\n, OK, 3000)) return 5; return 0; // 全部成功 }这段代码在串口助手里验证过的指令基础上加了一层超时握手。这里的strstr查找应答字符串有个隐含风险如果上一次的指令应答还残留在缓冲区里新指令的匹配可能会误判成功。所以在每条指令发送前先把接收缓冲区清空否则可能会出现建连成功的假象后面发布消息却一直超时。4.3 数据上报与命令下发OneNET可视化面板背后的Topic机制OneNET平台的MQTT Topic机制是整个系统的数据通道。数据上报走的Topic是$sys/{产品ID}/{设备ID}/dp/post/ojbk命令下发走的Topic是$sys/{产品ID}/{设备ID}/cmd/request/{msgid}其中{msgid}是平台下发时自动生成的流水号。这跟MQTT标准里的主题订阅不太一样前面带着$sys说明是系统保留TopicESP8266收到下行消息时会在串口输出MQTTSUB: 0, $sys/..., 16, JSON数据这样的信息。OneNET的数据展示不需要自己开发网页——平台自带“设备管理-数据流”和“可视化开发”功能设备上报的数据流会自动生成折线图你还可以用可视化编辑器拖拽出一个手机适配的面板把温湿度、光照、开关状态做成仪表盘。这个功能对毕设答辩来说非常加分但有个前提上报的JSON格式必须跟数据流模板对上。如果模板里定义了temp和hum两个数据流上报格式就必须是{datastreams:[{id:temp,datapoints:[{value:26}]},{id:hum,datapoints:[{value:60}]}]}别自作主张改成别的字段名否则数据流里永远是空的。5. 系统联调与四大避坑指南5.1 坑一ESP8266上电后串口打印乱码现象给ESP8266单独供电后串口助手收到的全是乱码AT指令没反应。原因最典型的问题就是上电时序。ESP8266要求VCC和CH_PDEN引脚同时上电如果CH_PD悬空或者上电慢了模块会进入奇怪的启动模式。另一个常见原因是串口助手的波特率跟模块固件设定不一致——早期固件默认是115200有些模块出厂被改成9600你按115200收就全是乱码。解决先检查接线CH_PD必须接3.3V高电平。然后依次试115200、9600、74880ESP8266特有的启动打印波特率三个波特率在74880下能看到正常的启动日志。如果每个波特率都是乱码考虑模块本身坏了或者串口芯片的电平不匹配。5.2 坑二ESP8266连接路由器成功但MQTT一直连不上现象ATCWJAP返回WIFI GOT IP但ATMQTTCONN超时或返回ERROR。原因这个坑多半出在MQTT参数上。新版OneNET的MQTT接入地址是mqtts.heclouds.com走1883端口但如果你用的是老版教程里的地址或端口连接肯定失败。另外ATMQTTUSERCFG命令里参数顺序错了也会静默失败固件不会明确告诉你是哪个字段不对。解决用串口助手重新对照4.2节里面的指令序列确保ATMQTTUSERCFG里设备ID、产品ID、设备密钥的顺序一致。还有一个隐藏限制OneNET要求产品必须开启了MQTT协议才能接入如果你的产品创建时选的是HTTP或其他协议在控制台是加不了MQTT设备的需要重新创建产品。另外如果你改了设备密钥ESP8266必须重启后再配置一次旧的token缓存会导致401错误。5.3 坑三DHT11读数偶尔为0或者恒温恒湿不变化现象温度湿度数据看起来“正常”但数值常年不变或者每隔一段时间读出一个0。原因DHT11的采样周期最低是1秒如果你在1秒内读多次第二次读取它还不准备好就会返回0。另外一个容易被忽略的问题是GPIO配置——PA0在推挽输出和输入模式之间切换时如果总线没有上拉电阻开漏模式下读到的电平不稳定会导致时序错乱。解决主循环里DHT11两次读取之间必须间隔至少1.5秒最简单的方法是加一个时间戳判断。同时在PA0上外接一个4.7kΩ上拉电阻到3.3V这样单总线在空闲时是高电平时序更稳定。如果你用了杜邦线连接尽量缩短到10厘米以内DHT11对线长很敏感。5.4 坑四继电器一动作STM32就重启现象手动控制继电器时STM32偶尔重启或者传感器读数突然跳变。原因继电器的线圈是一个感性负载断开瞬间会产生很高的反向电动势如果这部分能量串回电源STM32的供电就会被拉垮。另外如果你的继电器模块是5V供电而STM32是3.3V逻辑控制信号的电压不匹配也可能导致继电器误动作。解决继电器模块的供电不要跟STM32共用一路稳压输出要用独立的5V电源两者共地即可。控制引脚和继电器模块之间串一个1kΩ限流电阻同时在继电器线圈两端反并联一个1N4007二极管吸收反向电动势。如果你买的是光耦隔离继电器模块这个问题基本不会出现但前提是得真的通电验证过光耦方向接对了。5.5 坑五数据上传不稳定OneNET设备反复上下线现象设备数据时有时无平台上的在线状态一直闪烁。原因ESP8266的MQTT保活机制没有配好。OneNET要求设备在保活周期内发送心跳否则会主动断开连接。AT固件里打开MQTT时默认可能不启用keepalive或者保活时间设置太长WiFi稍有不稳定就会被平台踢下线。解决在ATMQTTCONN参数里显式设置keepalive为60秒同时STM32端每30秒主动发布一次心跳数据双保险。如果WiFi信号本来就差建议在ATCWJAP后加一条ATCWQOS1命令把WiFi的QoS级别设为1减少丢包。另外检查ESP8266的供电电流——模块在WiFi发射时瞬间电流能到300mA如果用的USB转TTL供电能力不足模块会直接无响应建议用独立的AMS1117-3.3稳压模块供电。6. 系统联调验证与进阶玩法6.1 用OneNET设备日志反查数据链路问题整套系统跑起来之后怎么验证它真的“通”了OneNET控制台的“设备日志”功能非常好用。进入设备详情页点开日志能看到设备从连接、订阅、发布到断开的完整事件流。如果日志里显示“连接已建立”但看不到数据上报问题出在STM32的传感器采集或串口发送上如果日志里连连接都没有问题出在ESP8266的AT指令配置上。这比拿万用表瞎猜高效多了。实地跑通后我建议做一件加分的事把OneNET的数据上报时间戳和家里的实际温湿度变化做一张对比表。比如打开空调后平台上的温度曲线应该在5到10分钟内出现明显下降用手掌握住DHT11湿度读数应该在一两秒内上升。这组对比数据放进毕设论文的实验章节比你写十页理论分析都有说服力。6.2 调优方向从毕设级到产品级的三个升级点如果你做完基础版还有余力这里有三个性价比很高的进阶方向。第一把连接的传感器从DHT11换成SHT30精度从±2℃提升到±0.3℃而且I2C接口和BH1750共用一条总线硬件改动极小。第二在STM32端加一个AT24C02存储芯片把设备ID和WiFi密码存在EEPROM里以后改网络不用重新烧录程序。第三利用OneNET的“应用触发器”功能当温度超过阈值时平台自动给微信推送告警——这个功能在论文里能单独当一章写。关于数据格式再多说一句如果你想让OneNET可视化面板的仪表盘看起来更专业上报时可以把温度、湿度、光照分三个数据流上报每个数据流独立配置量程和单位面板上就能直接显示“温度/℃”“湿度/%RH”“光照/lx”这样的带单位仪表盘。别把三个值塞到一个JSON字符串里上报那样在可视化编辑器里拖拽组件时找不到对应的数据映射。6.3 一个值得养成的调试习惯这套系统从硬件到平台链路很长任何一环出问题都可能表现为“数据看不到”或“设备不上线”。我的个人习惯是每次调试只改一个变量。比如先确保串口助手里AT指令全通再烧STM32代码先确认STM32能通过ESP8266发数据到OneNET再开始调传感器精度。不要一次性把传感器采集、AT指令、MQTT配置全部改完再上电那样出了bug根本无从下手。另外强烈建议买一个逻辑分析仪二三十块钱的就行。当DHT11时序不对、ESP8266串口数据错位时逻辑分析仪能直接把波形拉出来看一次就能定位问题比靠猜和反复试快得多。还有串口助手的收发缓冲区记得调大一点别用默认的几百字节否则ESP8266返回的长JSON消息会被截断看着就像丢了数据。这套智能家居方案做完你学到的其实不只是几个芯片怎么用而是一套完整的物联网系统设计方法从设备端的数据采集、到通信协议的选择与封装、再到云平台的接入和呈现。这个思路换任何其他云平台、其他通信模组都适用。希望这篇笔记能帮你把板子点亮、数据上传、面板跑通少走几个我当年绕过的弯路。提示烧录STM32时如果需要同时给ESP8266供电建议先拔掉ESP8266的VCC等程序烧完再插回去否则容易出现SWD连接不稳定、烧录失败的问题。本文还有配套的精品资源点击获取