简介：这是一份基于STM32与有人LET-7S1 4G模块接入阿里云平台的完整工程资源，适合物联网开发者和嵌入式学习者参考。内容围绕透传模式下串口通信、阿里云物联网产品创建、设备凭证配置及SDK对接展开，覆盖从硬件接线、程序初始化到云端双向通信与异常重连的完整链路。压缩包共772个文件，以526个C源码、191个H头文件为主，另含少量汇编、链接脚本、IAR/Keil工程文件、CubeMX配置及说明文档，整体仅6.84MB，便于快速下载和对照学习。已有864人学习下载。通过这套工程，读者可以直接获取可编译的固件源码和工程配置，理解STM32如何通过串口控制4G模块发送数据，并按阿里云协议完成设备认证、消息上报和指令解析，适合用于远程监控、智能家居、工业自动化等场景的快速原型开发。 STM32项目我做过不少，但每次把设备真正连上云平台，都还是会有一种“终于通了”的踏实感。这篇就专门聊聊最近做的一个实际项目：用STM32主控，搭配有人4G模块，把设备数据接入阿里云物联网平台。整个过程从选型、接线、配置、编码到最后的联调排障，我把能踩的坑和值得留存的细节都整理出来了，希望对正在做类似物联网项目的朋友有帮助。
1. 方案选型与整体架构
1.1 为什么选“STM32+有人4G模块”
先说结论：这套组合非常适合做M2M设备远程监控类项目，尤其是设备分布在多个地点、不方便布网线、又有实时在线需求的场景。
选有人4G模块，主要看中三点：一是模块内置协议栈，支持TCP/UDP透传、MQTT等常用协议，STM32侧不需要自己实现复杂的网络协议栈，只需要通过串口AT指令控制；二是模块自带SIM卡座和天线接口，信号状态可以通过指令查询，工程上调试起来很直接；三是这类模块一般是工业级封装，工作温度范围宽，常用于无人值守的现场设备。
STM32作为主控，处理传感器数据采集、控制逻辑、本地显示这些任务足够，而且市面上资料多、库函数成熟，开发效率高。相比用Linux工控机或者带系统级SoC的方案，这套的成本和功耗都低很多。
1.2 整体架构和核心链路
整个系统的数据链路大概是这样的：
传感器数据由STM32采集，本地做初步处理和缓存，然后通过串口把数据打包成帧发给有人4G模块，4G模块负责把数据通过移动网络发出，经过运营商NAT后和阿里云物联网平台建立长连接，云平台侧通过产品、设备、Topic的结构管理设备，数据可以再流转到业务后台或者应用端展示。
这个架构里，STM32只关心“数据从串口发出去”，4G模块只关心“串口数据走TCP/MQTT发到云端”，云端只负责“设备接入和数据转发”，各层解耦很清晰。项目调试的时候，任何一环出问题都能快速定位到具体模块。
1.3 两种接入方式怎么选
有人4G模块接入阿里云，实际操作中有两种主流玩法，这里提前说清楚区别：
第一种是模块以透传模式工作，STM32直接把MQTT报文通过AT指令或者透传通道发给模块，模块只负责把TCP数据包转发到阿里云服务器。这种方式自由度最高，但STM32侧要自己完成MQTT报文封包、解析、心跳维护，代码量要大一些。
第二种是模块自身支持MQTT，直接用AT指令配置模块连接阿里云，模块内部帮我们维护MQTT连接。这种方式STM32侧代码简单很多，只要通过串口发AT指令配置好参数，然后直接往串口里填数据就行，模块会自动完成MQTT publish等操作。
我这次用的是第二种，原因是项目时间紧、设备端逻辑不复杂，把网络协议交给模块来处理，能减少很多坑。如果后续需要非常细粒度地控制会话层逻辑，再考虑切回第一种方式也不迟。
2. 阿里云平台侧的配置
2.1 创建产品和设备
登录阿里云物联网平台控制台以后，第一步是创建产品。产品类型选择“基础产品”，节点类型根据设备情况选择“直连设备”，联网方式选“蜂窝”或者“其他”，数据格式建议直接选“ICA标准数据格式（JSON）”，这样后续数据流转和AMQP订阅都很方便。
创建完产品之后，要给产品定义功能。比如我这个项目里设备会上报“温度”和“湿度”，就分别定义两个属性，标识符为Temperature和Humidity，数据类型float，读写类型选“只读”，因为这是设备上报数据。定义功能这步不能偷懒，后续云端可以自动生成物模型，设备端按这个数据规范上传，云平台解析时才不会乱套。
接着在产品下添加设备，设备名称取设备唯一标识，比如dev_001。添加完成后，控制台会显示该设备的三元组信息：ProductKey、DeviceName、DeviceSecret。这三个参数是设备接入云端的身份凭证，后面配置4G模块或者设备端程序时都要用到。
2.2 设备身份鉴权与Topic规划
阿里云物联网平台设备接入的鉴权方式有两种：一机一密和一型一密。项目里建议用一机一密，每个设备拿自己的三元组独立连接，互不干扰。如果设备数量特别大，再考虑一型一密加动态注册。
Topic规划也很关键。阿里云每个产品下预置了若干标准Topic，比如/sys/{productKey}/{deviceName}/thing/event/property/post是属性上报，/sys/{productKey}/{deviceName}/thing/service/property/set是云端设置属性下发。配置4G模块时，就是把MQTT的CONNECT报文参数按这些Topic规则准备。
这里需要特别提醒：阿里云的Topic结构里，前两段是/sys/{productKey}/{deviceName}，后面才是具体的操作类型。凡是涉及到Topic的配置，全部要替换成自己设备实际的productKey和deviceName，不能直接照抄文档模板，否则云端会拒绝连接。
2.3 云端其他准备
平台侧还需要创建产品对应的物模型。物模型本质上是一份JSON Schema，定义属性、事件、服务。上一节定义功能其实就是在创建物模型的基础属性。物模型创建好以后，可以在控制台“设备模拟器”功能里先用虚拟设备测试一遍数据上报和指令下发，确认云端的Topic格式、payload格式没问题，再去调实体设备。
另外，如果需要把设备数据对接到自己业务后台，通常是用服务端订阅的方式。在控制台“消息转发”里，可以配置数据流转规则，把设备上报的数据转发到AMQP消费组，后台程序用AMQP Java客户端或者阿里云提供的SDK去消费数据。这一步我建议放到设备端联调通过之后再搞，先保证设备端到云端的链路是通的。
3. 有人4G模块配置与连接调试
3.1 模块选型与接口准备
有人4G模块的型号比较多，我手头这块是USR-LTE-7S4，支持移动/联通/电信4G全网通，工作电压5V，通信接口是串口TTL。模块侧面有网络状态指示灯，还有电源指示灯，调试的时候看灯的颜色能大概判断模块有没有注册上网络。
接线方面，STM32主控的USART2连接模块的串口RXD/TXD，注意交叉连接，地线共地。模块的RST引脚接STM32的一个GPIO，用来做硬件复位控制；模块还有个LINK引脚可以输出网络连接状态指示，如果不想浪费IO口，可以悬空不接。
供电这块要特别注意：4G模块在发射瞬间电流峰值可能到2A左右，如果用STM32开发板的3.3V引脚直接给模块供电，大概率会复位或者通讯异常，必须用外部5V/2A及以上的电源给模块供电，STM32的串口如果能容忍5V电平，就直接和模块对接；如果STM32是3.3V电平，建议加一个电平转换芯片，或者用模块引出的TTL电平做电平匹配。
3.2 AT指令初始化配置
模块上电后，通过串口调试助手，先发AT回车，看模块是否返回OK。如果没反应，检查串口参数（一般是115200-8-N-1）和供电，或者发一个“+++”让模块退出透传状态。
查询SIM卡和网络状态的指令：
- AT+CPIN? 查询SIM卡是否识别，返回READY说明卡正常。
- AT+CSQ 查询信号强度，返回+CSQ: 20,0表示信号一般在20左右，小于10就要考虑换位置或者加天线。
- AT+COPS? 查询当前运营商注册状态，返回0,0表示自动注册成功。
这几条指令是判断4G链路是否正常的第一道关卡，很多时候云平台连不上，并不是MQTT的问题，而是卡没注册或信号太差。
3.3 配置MQTT连接参数
有人模块内置MQTT透传模式的配置入口，我用的方式是先进入配置模式（发送“AT+MQTTCFG”相关指令），把阿里云的MQTT连接地址、端口、ClientID、Username、Password、Topic、QoS等参数填进去。
这里有一个最核心的点：阿里云MQTT连接参数不是随便填的，需要按特定规则生成。阿里云物联网平台的标准MQTT接入地址形如${productKey}.iot-as-mqtt.${regionId}.aliyuncs.com，端口一般是1883（TLS加密是8883）。
Username是${deviceName}，Password需要自己用工具计算，计算规则是：对productKey=deviceName的字符串做HMAC-SHA1签名，签名的密钥是deviceSecret，然后把签名结果转换成十六进制字符串作为密码。ClientID的格式一般是abc.securemode=3,signmethod=hmacsha1，其中abc是设备自定义标识，securemode=3表示TLS不加密，signmethod=hmacsha1指定签名算法。
我当时算Password的时候差点踩坑，网上有些教程给的工具能直接用，但有的工具其实默认加了换行符或者空格，导致签名结果不对。建议大家都自己写一个小工具或者用Postman的Crypto功能，把参与签名的字符串精确控制好，避免不可控的差异。
模块配置完之后，保存参数并重启模块，让配置生效。这一步完成以后，再用电脑连模块的串口，观察模块主动上报的网络连接日志，如果看到“MQTT Connected”或者类似的关键字，说明云端链路已经打通了。
3.4 STM32端AT指令控制代码
STM32端要做的事情其实可以概括成两句话：初始化串口，把要发的AT指令和数据包按协议发给模块；接收串口数据，解析模块回显和云端下行指令。
配模块参数这一步，我建议做成一个“本地配置模式”：开发调试时，STM32的串口直接输出AT指令给模块，由电脑串口助手辅助观察；正式运行后，这段配置代码可以加一个条件编译开关，只在首次上电或者模块报参数错误时执行。
下面是一段精简的设备联网初始化伪代码，实际项目中可以根据自己的串口驱动封装修改：
void Device_Init_4G(void) { // 1. 复位模块 HAL_GPIO_WritePin(RST_PORT, RST_PIN, GPIO_PIN_RESET); HAL_Delay(200); HAL_GPIO_WritePin(RST_PORT, RST_PIN, GPIO_PIN_SET); HAL_Delay(3000); // 等待模块启动 // 2. 查询网络状态 Send_AT_Command("AT+CPIN?\r\n"); HAL_Delay(500); Send_AT_Command("AT+CSQ\r\n"); HAL_Delay(500); // 3. 进入MQTT模式并连接阿里云 Send_AT_Command("AT+MQTTCFG=...\r\n"); // 按实际模块指令格式 HAL_Delay(1000); Send_AT_Command("AT+MQTTSTART\r\n"); HAL_Delay(2000); // 4. 订阅云端下发Topic Send_AT_Command("AT+MQTTSUB=...\r\n"); HAL_Delay(1000); }代码注释里省略了具体的AT指令细节，因为不同模块的指令集会有一点差异，以产品手册为准。核心是操作顺序：先保证模块在线，再配置MQTT参数，再启动连接，最后订阅Topic。
4. 数据上报与下发实现
4.1 设备属性上报的报文格式
阿里云平台上报数据的报文格式是JSON串，比如上报温度和湿度：
{ "params": { "Temperature": 25.6, "Humidity": 60.2 } }STM32通过串口把这串JSON发给4G模块，模块自动封装成MQTT PUBLISH消息，发到topic为/sys/{productKey}/{deviceName}/thing/event/property/post的地址。云平台收到以后，如果返回success，说明数据已经正常入库。
填JSON字符串的时候，有个容易出错的地方：里面的key必须和产品定义的功能标识符完全一致，大小写都不能错；value必须是数字类型，不能加引号，否则物模型会拒绝解析或者类型转换失败。项目里我建议先用调试助手手动发一次标准报文，到控制台的“物模型数据”里确认能查到数据，再写进STM32程序，这样可以避免很多编码过程中的低级错误。
4.2 云端下发指令的处理
阿里云还支持云端向设备下发指令，比如远程开关设备。云端调用SetDeviceProperty接口下发属性设置请求，或者使用自定义Topic做服务调用。设备订阅了system/set类型的Topic以后，会收到如下格式的指令：
{ "method": "thing.service.property.set", "params": { "PowerSwitch": 1 } }STM32收到指令之后，要解析JSON里的method和params，然后执行本地控制逻辑。由于4G模块已经把MQTT层处理好了，STM32收到模块推过来的串口数据，只需要做字符串判断和简单解析就能拿到控制信息。如果需要非常复杂的JSON解析，可以用cJSON库，小内存芯片也能跑得很流畅。
4.3 心跳和保活策略
长连接最怕的就是断线，MQTT本身有心跳保活机制，阿里云默认的保活周期是60秒到120秒，建议设备端设置的keepalive不超过90秒。4G模块在透传模式下会自动处理心跳包，但设备端最好还是定期发心跳数据，既能上报状态，也能维持链路活跃。
另外还要考虑异常断网后的自动重连。我这边设置了一个简单的状态机：STM32每隔一定时间检查模块网络状态，如果发现异常次数累计超过阈值，就对4G模块做一次硬件复位，然后重新执行MQTT连接流程。实测下来，这种策略在弱信号环境或者运营商基站切换的时候很有用，能避免模块假死。
4.4 数据缓存和离线补偿
如果现场网络不稳定，设备数据可能在上报时失败。项目里我设计了一级环形缓冲：把采集到的数据和时间戳先写入RAM缓存，上报成功以后才清除；如果上报失败，等下次连接成功后重传。设备重启时，可以把未上报的数据存到STM32内部的Flash里，防止掉电丢失。
这里要提醒一点，缓存区一定要做上限保护，不能无限增长。如果网络长期不通，缓存满了以后必须丢弃最老的数据，优先上报新数据，不然会占满内存，导致系统卡死。
5. 常见问题与排查技巧实录
5.1 连接不上云平台
这是碰到最多的问题，基本可以按下面顺序排查：
- 模块是否注册上网络。AT+CPIN?、AT+CSQ、AT+COPS?这几条指令先确认SIM卡和信号正常，这一步不通过，后面全是白搭。
- MQTT参数是否拼写正确。重点检查ClientID、Username、Password的计算规则；Password要用HMAC-SHA1生成，且签名内容中的等号前后不能有空格。
- Topic是否填对。很多模块配置界面里，发布Topic和订阅Topic分别对应不同的输入框，填错会造成数据发上去了云端收不到，或者云端发指令设备收不到。
- 端口和地址。阿里云标准接入地址中的regionId必须和产品所在区域一致，不然连接会超时。
5.2 串口通讯异常导致指令失效
有时候模块上电后，发送AT指令没有回复，大概率是串口线接反了或者电平不匹配。我之前犯过一个低级错误，用USB转TTL和模块调试时，RX/TX没有交叉，结果怎么发都没反应。另外，有人部分模块支持5V供电，如果接到3.3V就带不动，会导致模块启动后又掉电，现象就是串口偶尔有输出，偶尔没有。
5.3 云端数据上报出现格式错误
数据到云端以后一直提示格式错误，除了检查JSON里的key和value类型，还有一个常见的隐藏问题：设备数据里带了不可见字符，比如换行符。数据帧末尾多于的0x0A、0x0D都可能被当成消息的一部分，导致解析失败。STM32串口发送时，尽量只发送规定的JSON数据，不要追加\r\n。
5.4 频繁掉线
模块频繁掉线，第一个看网络环境，第二看SIM卡状态，第三个看设备端的重连机制是否过于激进。
有一次排查发现是模块的socket连接因为没有发送心跳包被云端断开，但是模块本身没有感知到，直到下一次主动上报数据时才报错。后来的做法是模块侧设置短一点的心跳间隔（比如30秒），同时STM32端做15秒级别的数据上报周期，保证链路里始终有流量经过。
这里贴一张我常用的排查步骤表，照着做一般都能找到问题在哪：
| 现象 | 排查点 | 验证方法 |
|---|---|---|
| 模块无响应 | 供电、串口连线 | 测模块供电电压，用USB转TTL单独连模块发AT |
| 无法注册网络 | SIM卡、天线 | AT+CPIN?、AT+CSQ、AT+COPS? |
| MQTT连接失败 | 鉴权参数、地址、端口 | 对比工具计算的Password，确认regionId |
| 能连接但收不到数据 | Topic订阅 | 用设备模拟器测试云端下发，确认订阅Topic |
| 数据上报格式错误 | JSON格式 | 先在调试助手里发固定报文，再核对设备端代码 |
| 频繁断线 | 心跳、网络质量 | 缩短命令周期，观察CSQ值，调整重连策略 |
6. 稳定性优化与扩展建议
项目上线以后，稳定性往往比功能本身更考验人。说说我后续做的几个优化：
第一，设备端加入看门狗。如果主程序因为死循环或者其他因素跑飞，看门狗能把系统拉回来，重新初始化外设和网络。实际运行下来，这块能避免很多无法预知的现场故障。
第二，4G模块的供电独立设计。前端加一个大电容和TVS管，可以有效抑制电压跌落和浪涌。现场环境如果电源质量不好，模块特别容易出现重复重启的问题。
第三，代码里增加运行日志功能。把上电时间、网络连接耗时、数据上报成功失败次数等关键信息记录到本地，既方便现场排查问题，也为后续优化提供数据支撑。
扩展方面，这套架构其实可以很方便地对接阿里云的其他服务。比如通过规则引擎把数据转发到表格存储、时序时空数据库或者函数计算，实现数据持久化和实时处理。如果设备数量增长到百台以上，还可以考虑设备分组、OTA升级、固件远程更新这些高级功能，这些都建立在设备已经稳定接入云端的基础之上。
另外提一个很多人会忽略的点：如果部署现场有多台设备，每台设备的标识尽量做到有规律可循，比如包含地市代码、设备类型、序号，这样在云平台上管理起来方便很多，数据分析和告警配置也能更准确。
我在实际做这个项目的时候，最大的感受是：硬件连云的链路本身不复杂，串口到模块再到云端，每一步都有成熟方案；难点在于细节的掌控，比如MQTT签名参数的计算、模块和云端的时序配合、断线后的状态恢复，这些都是在反复调试中慢慢磨出来的。希望这篇内容能帮你少走一些弯路，把宝贵的时间花在真正有创造性的部分。
本文还有配套的精品资源，点击获取
