1. 为什么选小熊派做硬件接入这件事小熊派这块板子在我手上躺了快两个月最初买它就是想找个能跑通端到端物联网链路的硬件平台。市面上常见的开发板要么太贵要么资料零散小熊派算是平衡得比较好的一个选择——基于STM32主控板载了温湿度传感器、光照传感器、LCD屏、按键、LED还有一块Wi-Fi模组或者NB-IoT模组可选。对于想验证“设备采集数据→上报云端→云端下发指令→设备响应”这条完整链路的人来说它省去了大量外围电路的搭建时间。这次要做的项目目标很明确把小熊派采集到的温湿度数据通过MQTT协议上报到EMQX消息服务器同时在本地用Node-RED做数据流转和可视化最终把数据落到时序数据库里做长期存储。整个链路涉及硬件端、消息中间件、流处理和存储四个环节每个环节都有各自的坑。关键词里提到的小熊派、IoT、MQTT、硬件接入、EMQX基本覆盖了这条链路的核心要素。MQTT是设备与云端通信的协议EMQX是MQTT消息服务器小熊派是硬件终端IoT是整个应用场景。把这几个东西串起来就是一个典型的物联网数据采集与上报系统。这篇文章适合谁看如果你手上有小熊派或者类似的STM32开发板想把它接入一个自建的MQTT服务器同时希望了解从设备端到云端再到数据存储的完整流程那这篇内容应该能帮你省下不少查资料的时间。如果你只是想了解MQTT协议在嵌入式设备上怎么用也可以跳过硬件部分直接看协议实现那几节。我尽量把每个环节的“为什么这么做”讲清楚而不是只给一堆配置代码。因为物联网项目最麻烦的地方往往不是代码本身而是环境配置、网络调试和协议细节上的各种意外。2. 硬件端的环境搭建与第一个坑2.1 开发环境的选择与配置小熊派的开发环境主要有两种选择Keil MDK和STM32CubeIDE。Keil的优势是编译速度快、调试方便缺点是License问题比较麻烦STM32CubeIDE免费且跨平台但编译速度偏慢。我最终选了Keil MDK因为之前用惯了而且小熊派官方提供的例程大多是Keil工程。安装Keil之后需要装STM32F4系列的Device Pack小熊派的主控是STM32F407这个Pack大概有几百兆下载速度取决于网络状况。装完Pack之后还要确认编译器版本Keil MDK 5.36之后的版本对C99标准的支持更完整如果用的是老版本可能会遇到一些语法报错。串口驱动是另一个容易忽略的点。小熊派板载了CH340串口芯片Windows 10/11一般能自动识别但如果设备管理器里出现黄色感叹号就需要手动装CH340驱动。我建议提前装好驱动因为后面调试MQTT连接状态时串口打印是最直接的调试手段。2.2 第一个坑Wi-Fi模组的固件版本小熊派板载的Wi-Fi模组通常是ESP8266或者ESP32具体型号取决于你买的版本。我手上这块是ESP8266出厂固件是AT指令版本。这里遇到的第一个坑是固件版本太老不支持MQTT AT指令。ESP8266的AT固件有几个版本分支早期版本只支持TCP/UDP透传MQTT指令是后来才加进去的。如果你拿到板子之后直接用ATMQTTUSERCFG这类指令模组返回ERROR大概率就是固件版本的问题。解决办法是重新烧录AT固件。需要一根USB转TTL线把ESP8266的TX/RX/GND/EN引脚接出来用乐鑫官方的Flash Download Tool烧录。固件可以从乐鑫官网下载选支持MQTT的AT固件版本比如ESP8266-IDF-AT_V2.2.0.0或者更新的版本。烧录的时候注意几个参数Flash大小选8Mbit或者16Mbit取决于模组型号SPI Mode选DIO波特率用115200。烧录完成后用ATGMR确认版本号如果看到AT version后面有MQTT相关的支持说明就说明固件没问题了。提示烧录AT固件之前先用AT指令确认模组能正常通信如果连AT都返回不了先检查串口接线和波特率别急着烧固件。2.3 传感器数据的读取与格式化小熊派板载的温湿度传感器是AHT10或者SHT30具体型号看批次。这两个传感器都是I2C接口读取流程差不多初始化I2C外设→发送测量命令→等待转换完成→读取原始数据→转换成物理量。AHT10的转换公式在数据手册里有温度是原始值除以2的20次方乘以200再减去50湿度是原始值除以2的20次方乘以100。实际写代码的时候要注意整数溢出的问题原始值是20位的用uint32_t接收转换的时候先转成float再算。数据格式化这块我建议在设备端就把数据拼成JSON字符串比如{temp:25.3,humi:60.2}。这样云端收到之后不需要额外解析直接就能用。拼JSON的时候注意浮点数的精度保留一位小数就够了太多位数反而增加传输负担。3. MQTT协议在小熊派上的落地细节3.1 为什么选MQTT而不是HTTP物联网设备上报数据HTTP和MQTT都能做但两者的适用场景差别很大。HTTP是请求-响应模式设备每次上报都要建立连接、发送请求、等待响应、断开连接开销大且实时性差。MQTT是发布-订阅模式设备与服务器之间保持长连接数据可以随时推送开销小且实时性好。对于温湿度采集这种场景数据量小但频率高MQTT的优势很明显。而且MQTT支持QoS等级可以根据数据重要性选择不同的可靠性级别。比如温度数据用QoS 0就够了丢一两条无所谓但报警信息用QoS 1确保服务器能收到。另一个考虑是功耗。MQTT的长连接虽然需要维持心跳但相比HTTP每次重建连接整体功耗还是低不少。如果后续要切换到NB-IoT模组做低功耗场景MQTT的适配成本也更低。3.2 AT指令实现MQTT连接的完整流程ESP8266的MQTT AT指令有一套固定的调用顺序顺序错了就会返回ERROR。我整理了一下完整的连接流程ATRST重启模组等待readyATCWMODE1设置为Station模式ATCWJAPSSID,password连接Wi-Fi等待WIFI GOT IPATMQTTUSERCFG0,1,client_id,username,password,0,0,配置MQTT客户端参数ATMQTTCONN0,broker_address,1883,0连接MQTT服务器ATMQTTSUB0,topic,0订阅主题ATMQTTPUB0,topic,payload,0,0发布消息每一步都要等模组返回OK或者对应的成功提示不能连续发送。我一开始就是连续发指令结果模组直接卡死后来加了等待才正常。client_id的格式有讲究EMQX默认要求client_id唯一如果两个设备用同一个client_id连接后连接的会把先连接的踢掉。我建议用设备MAC地址或者芯片ID作为client_id的一部分确保唯一性。username和password如果EMQX没开认证可以留空。但生产环境一定要开认证否则任何人都能往你的服务器发数据。3.3 心跳与断线重连的处理MQTT的心跳间隔Keep Alive默认是60秒ESP8266的AT固件里可以通过ATMQTTCFG设置。心跳太短会增加功耗和流量太长则服务器可能误判设备离线。60秒是个比较平衡的值。断线重连是必须处理的。网络波动、服务器重启、路由器重启都会导致连接断开。我的做法是在主循环里检测MQTT连接状态如果发现断开就重新执行连接流程。检测方式可以用ATMQTTCONN?查询状态或者监听模组主动上报的断开消息。重连的时候要注意退避策略不要一断开就立刻重连否则服务器压力大且可能被限流。我一般用指数退避第一次等1秒第二次等2秒第三次等4秒最多等到30秒。这样既能快速恢复又不会造成风暴。4. EMQX服务端的部署与配置4.1 Windows下EMQX的安装与启动EMQX在Windows下的安装比较简单官网下载zip包解压就行。解压之后进入bin目录用emqx start启动emqx stop停止emqx console可以前台运行并查看日志。启动之后默认监听几个端口1883是MQTT协议端口8083是WebSocket端口18083是Dashboard端口。Dashboard的默认账号是admin密码是public第一次登录之后一定要改密码。如果1883端口被占用可以在etc/emqx.conf里修改。我遇到过几次端口冲突都是因为之前装的MQTT服务没卸载干净。用netstat -ano | findstr 1883可以查是哪个进程占用了端口。注意Windows防火墙可能会拦截1883端口的外部访问如果设备连不上服务器先检查防火墙规则。可以在防火墙里添加入站规则放行1883端口。4.2 Dashboard的常用功能与调试技巧EMQX的Dashboard是我用得最多的调试工具。在“客户端”页面可以看到所有已连接的设备包括client_id、IP地址、连接时间、心跳状态。如果设备显示在线但收不到数据可以在这里确认设备是否真的连上了。“主题”页面可以查看当前所有订阅关系能看到哪个客户端订阅了哪个主题。这个功能在排查订阅失败时特别有用比如设备订阅了device/001/data但服务器上显示没有这个订阅那就说明订阅指令没发成功。“消息”页面可以查看最近的消息记录包括主题、payload、QoS、时间戳。调试阶段我经常在这里确认设备发上来的数据格式对不对。不过这个页面默认只保留最近的消息历史消息需要配置持久化。Dashboard还支持WebSocket客户端可以直接在浏览器里模拟设备发消息。测试云端下发指令的时候我经常用这个功能往设备订阅的主题发消息看设备能不能收到并响应。4.3 认证与ACL的配置要点生产环境一定要开认证和ACL。EMQX支持多种认证方式最简单的用户名密码认证可以在Dashboard里配置。在“访问控制”→“认证”里添加一个Password-Based认证然后创建用户。ACL是访问控制列表用来限制哪个客户端能发布/订阅哪些主题。比如设备A只能发布device/A/data不能订阅device/B/data。ACL规则可以在Dashboard里配也可以写在配置文件里。我建议至少配置两条ACL规则一条允许设备发布自己的数据主题一条允许设备订阅自己的指令主题。其他主题一律拒绝。这样即使某个设备的凭证泄露影响范围也可控。5. Node-RED与数据持久化的衔接5.1 Node-RED订阅EMQX数据的配置Node-RED连接EMQX用node-red-contrib-mqtt节点就行。配置的时候填EMQX的地址和端口如果开了认证就填用户名密码。订阅主题可以用通配符比如device//data可以匹配所有设备的数据主题。订阅之后建议加一个json节点做解析把payload从字符串转成对象。这样后续节点可以直接用msg.payload.temp取温度值不用手动解析。调试阶段可以在MQTT节点后面接一个debug节点确认数据能正常收到。如果收不到先检查主题是否匹配再检查EMQX的ACL是否允许订阅。5.2 数据写入时序数据库的方案时序数据库我选的是IoTDB主要是因为它对物联网场景的适配比较好支持高并发写入和高效的时间范围查询。Node-RED里可以用node-red-contrib-iotdb节点或者直接用HTTP接口写入。写入的数据结构一般是设备ID、时间戳、温度、湿度。IoTDB的存储组可以按设备ID划分比如root.device001这样查询的时候可以按设备过滤。如果数据量不大也可以先用InfluxDB或者直接写MySQL。但时序数据库在时间范围查询和聚合计算上的优势很明显长期来看还是值得的。5.3 可视化面板的快速搭建Node-RED的Dashboard节点可以快速搭一个可视化面板。用ui_gauge显示实时温度ui_chart显示历史曲线ui_text显示当前状态。布局用ui_group和ui_tab组织几分钟就能搭出一个能看的监控页面。Dashboard的数据源直接接MQTT节点的输出就行不需要额外的后端。如果要做历史查询可以在Node-RED里加一个HTTP请求节点调用IoTDB的查询接口把结果传给chart节点。6. 联调过程中遇到的典型问题与排查思路6.1 设备显示在线但数据不上报这个问题我遇到过好几次排查下来原因各不相同。最常见的是主题不匹配设备发布到device/001/data但Node-RED订阅的是device/001/Data大小写不一致导致收不到。MQTT的主题是大小写敏感的这点一定要注意。另一个原因是QoS不匹配。如果设备用QoS 0发布但服务器端配置了只接收QoS 1以上的消息数据就会被丢弃。EMQX默认不限制QoS但如果ACL里配了QoS规则就可能出现这个问题。还有一种情况是payload格式问题。设备发的是JSON字符串但Node-RED的MQTT节点配置了“解析JSON”选项解析失败就会丢弃消息。这种问题在debug节点里能看到报错信息。6.2 连接频繁断开的根因分析连接频繁断开一般有三个原因心跳超时、网络不稳定、client_id冲突。心跳超时的话检查Keep Alive设置是否太短或者设备端是否按时发送PINGREQ。ESP8266的AT固件一般会自动处理心跳但如果主循环阻塞时间太长可能导致心跳发送延迟。网络不稳定的话看设备端的信号强度。ESP8266可以用ATCWJAP?查询当前Wi-Fi信号RSSI值低于-80dBm就说明信号太弱需要考虑调整路由器位置或者换用外置天线。client_id冲突的话EMQX的Dashboard里能看到同一个client_id的多个连接记录。解决办法就是确保每个设备的client_id唯一用MAC地址或者芯片ID做后缀。6.3 数据乱序与时间戳同步多设备上报数据时如果设备端没有RTC或者RTC不准时间戳就会乱。我建议在设备端用NTP同步时间或者干脆在云端统一打时间戳。EMQX支持在消息里附加接收时间戳Node-RED里可以用msg.timestamp获取。如果设备端一定要打时间戳至少要在上电时通过NTP同步一次然后靠RTC维持。STM32的RTC精度一般一天差几秒是正常的对温湿度采集来说够用了。7. 从模拟到真实的经验沉淀7.1 模拟阶段应该验证什么在硬件到位之前我建议先用MQTTX或者EMQX的WebSocket客户端做模拟测试。模拟阶段要验证的东西包括EMQX是否能正常启动、认证和ACL是否配置正确、Node-RED是否能订阅到数据、IoTDB是否能正常写入。模拟测试的好处是排除硬件和网络因素先把服务端链路跑通。这样硬件接入的时候如果出问题就能快速定位是设备端的问题还是服务端的问题。模拟的时候要注意payload格式要和真实设备一致否则服务端配置好了设备接进来又要改。我一般会先定义好数据格式然后模拟端和真实端都按这个格式来。7.2 硬件接入后的性能观察硬件接入之后要观察几个指标消息延迟、丢包率、设备在线时长。消息延迟可以在设备端打时间戳云端收到后算差值。丢包率可以看EMQX的消息统计或者设备端发序列号云端检查连续性。设备在线时长主要看断线重连的频率。如果一天断好几次就要排查网络或者心跳配置。如果几天都不断说明链路比较稳定。性能观察至少持续24小时因为有些问题只在特定时间段出现比如晚上网络高峰期丢包率升高或者路由器定时重启导致断线。7.3 后续扩展的方向这条链路跑通之后可以扩展的方向不少。比如加一个规则引擎在EMQX里配置规则当温度超过阈值时自动触发告警。或者接入Grafana做更专业的可视化替代Node-RED的Dashboard。设备端也可以扩展比如加一个继电器控制实现远程开关。或者换用NB-IoT模组做低功耗的室外部署。协议上也可以考虑MQTT over TLS提升传输安全性。我个人觉得最有价值的扩展是数据分析和预测。温湿度数据积累到一定量之后可以做趋势分析、异常检测甚至用机器学习做预测。这些都需要先把数据采集和存储的链路跑通所以前期的基础工作还是很重要的。最后分享一个小技巧调试MQTT的时候在设备端加一个LED指示连接状态连上了常亮断开了闪烁。这样不用看串口日志就能知道设备状态现场调试的时候特别方便。
