企业官网建设流程全解析

简介：这是一套基于STM32的智能停车场车位检测系统开发资料，覆盖车位状态实时采集、传感器网络协同、通信与显示模块等完整实现，适合电子信息技术、物联网应用、自动化控制等专业学生用于课程实践或毕业设计，也便于嵌入式初学者对照学习整个技术路径。压缩包共1027个文件，约32.34MB，以c、h源码文件为主，辅以zbak备份、o目标文件、s汇编及uvprojx工程配置、icf链接脚本等，可对应查看程序逻辑、编译中间产物与硬件工程结构，便于按模块检索。已有53人学习下载。资料包含核心控制器程序、硬件设计文档与实施指导手册，整体采用模块化设计，数据采集、通信传输、状态显示模块通过标准化接口交互；系统代码经过系统化测试且运行稳定，具备编程基础者可根据实际需求扩展功能，也可直接作为学术研究或工程实训的参考案例。

1. 基于STM32的车位检测项目：为什么值得自己从源码做一套

停车难是老话题，但真正让车位检测系统翻车的从来不是算法，而是传感器被干扰、通信掉线、供电不稳这些“脏活”。基于STM32的智能停车场车位检测系统源码与实现方案，本质上是让你用一颗主流廉价主控，配合地磁、超声波或红外传感器，自己搭出能稳定上报车位占用状态的嵌入式节点，并打通从采集到上报的完整链路。适合正在做课程设计、毕业设计，或者想把手里的STM32开发板变成真实物联网设备的开发者。

很多人会问：现成的停车场系统那么多，为什么还要自己写源码？答案很直接——现成方案要么是黑匣子，出了问题只能重启；要么是私有协议，根本接不进自己的平台。而基于STM32自己做，所有行为都在你手里可控：状态判断逻辑可以调，通信帧格式可以改，电源挂了能通过日志定位，一套代码改改传感器型号就能复用。这篇文章按“方案选型→核心检测逻辑→通信联动→避坑→进阶验证”展开，每一步都给出能直接抄的代码和参数。

2. 检测方案选型：地磁、超声波与红外，先想清楚用在哪再买传感器

2.1 三种主流检测原理的对比：准确率、功耗、施工成本

智能停车场车位检测，传感器选型决定了一半的成败。常见做法有三种：地磁检测、超声波检测、红外对射检测。地磁检测利用车辆铁质部件改变地球磁场分布的原理，传感器埋在车位中央地面下，施工要切割地面；超声波检测是探头朝下发射超声波，根据回波时间差判断车位上是否有车，探头装在车位正上方，无需破路面；红外对射则是发射红外光束，车辆阻断光束即判定占用，同样装在上方或侧面支架。

从实测角度说三者的表现差异很大。地磁方案准确率最高，在有遮挡、天气恶劣时依然稳定，但受相邻车位大车影响，且埋地后调试不便；超声波方案安装维护最方便，但对安装高度和角度敏感，探头必须垂直对准车位中心，落叶、灰尘堆积会误报；红外对射成本最低，但容易受阳光、雨雾干扰，且对摩托车、三轮车这类低矮目标不敏感。

很多初学者一上来就买最便宜的红外对射模块，装上去晴天很准，一到傍晚阳光斜射就疯狂误报。我的经验是：室内停车场优先地磁，室外且安装支架方便时选超声波，红外只推荐用于室内短距离闸机辅助。下面这张表可以帮你在前期就把方案定下来，省得后面返工：

2.2 STM32选型边界：F103够不够，什么时候必须上F4/H7

确定传感器后就是主控选型。标题里写的是STM32，但具体到F1还是F4，很多人拿不准。我一般这样定的：车位检测这种低速物联网节点，每个车位就一个传感器加一个通信模块，工作量很小，STM32F103C8T6是绝对主流，价格低、资料多、坏了不心疼。它的72MHz主频、64KB Flash、20KB RAM，跑地磁采样、状态机判断和串口上报完全够用。

什么时候需要往上升到F4或H7？两种场景。第一种是你要在节点本地跑更复杂的算法，比如同时接8路超声波探头做多车位管理，或者要对地磁数据进行FFT频谱分析来过滤干扰，F103的算力会吃紧；第二种是通信方式升级到以太网或复杂协议栈，比如接入Modbus TCP、CANopen，F103的RAM跑协议栈会很吃力。但绝大多数停车场车位检测场景用不到这些，一颗F103C8T6加一个地磁传感器，也就是入门级成本，就能挑起整个节点的全部工作。

选型还要考虑一个常被忽略的维度：开发环境你自己的熟悉程度。如果你手头已经有F103最小系统板，就别为了“听起来高级”去换H750，围绕F103把方案打通，比盲目追新更有价值。如果是从零开始买板子，我建议买带排针引出的最小系统板，方便插接传感器和无线模块，别买那种所有外设都焊死的评估板。

2.3 传感器I2C地址与初始化代码：以地磁模块为例

确定地磁方案后，第一步是让STM32能够稳定读取传感器数据。以主流的三轴地磁传感器为例，它通过I2C接口与MCU通信，I2C地址一般是0x0D或0x1E，具体看模块原理图。初始化流程不外乎复位、设置采样率、设置量程、使能测量。我一般用STM32的硬件I2C外设，虽然网上很多人抱怨硬件I2C不稳定，但多半是没做超时保护，后面避坑章细说。

// I2C读取地磁传感器XYZ数据的核心代码 #include "i2c.h" #include "stdio.h" #define MAG_ADDR 0x1E << 1 // 7位地址0x1E，左移1位变为8位写地址 void MAG_Init(void) { uint8_t data = 0x70; // 复位传感器 HAL_I2C_Mem_Write(&hi2c1, MAG_ADDR, 0x0A, I2C_MEMADD_SIZE_8BIT, &data, 1, 100); HAL_Delay(20); data = 0x20; // 设置采样率：75Hz，量程±1.3Ga HAL_I2C_Mem_Write(&hi2c1, MAG_ADDR, 0x00, I2C_MEMADD_SIZE_8BIT, &data, 1, 100); data = 0x00; // 连续测量模式 HAL_I2C_Mem_Write(&hi2c1, MAG_ADDR, 0x02, I2C_MEMADD_SIZE_8BIT, &data, 1, 100); } void MAG_ReadXYZ(int16_t *x, int16_t *y, int16_t *z) { uint8_t buf[6]; // 从寄存器0x03开始连续读6个字节，对应X、Y、Z轴高低位 HAL_I2C_Mem_Read(&hi2c1, MAG_ADDR, 0x03, I2C_MEMADD_SIZE_8BIT, buf, 6, 100); *x = (buf[0] << 8) | buf[1]; // 高字节在前，拼出16位有符号值 *y = (buf[2] << 8) | buf[3]; *z = (buf[4] << 8) | buf[5]; }

代码里用了HAL库的HAL_I2C_Mem_Read，函数内部会处理起始信号、设备地址、寄存器地址、数据和停止信号，我们只需要传入从设备地址、寄存器地址、数据长度和超时时间即可。超时参数设100毫秒，如果I2C总线上设备没应答，函数会返回超时错误，避免程序卡死。

一个小坑是很多模块原理图上给的I2C地址是8位模式，也就是0x3C这样的，而HAL库接口需要7位地址左移一位，换算错误会导致通信一直失败。遇到这种情况，可以用逻辑分析仪抓一下I2C波形，看实际发送的地址字节是多少，比对着数据手册猜要高效得多。

3. 车位状态判断核心逻辑：迟滞比较、滑动窗口与抗干扰校准

3.1 为什么不能只用一个固定阈值：车辆磁干扰的随机性

传感器能读到数据只是第一步，真正的核心是“怎么判断车位上有没有车”。很多新手写的第一版逻辑非常简单：读Z轴磁场强度，大于某个阈值就判定有车，否则无车。这个逻辑在实验室里跑没问题，装到真实停车场就频繁误报，原因在于地磁信号不是一个稳定的绝对值，而是随环境变化的。

地磁传感器测的是地球磁场叠加周围铁磁物体的扰动。一辆车开进车位，车的铁质外壳会改变磁力线分布，传感器测到的三个轴数值都会偏移。但不同车型的铁含量不同，SUV和轿车的偏移量差好几倍；同一种车停在车位正中和偏左偏右，偏移量也不同。如果用一个固定阈值，轿车压线时可能触发不了，大货车在旁边车道经过时磁场的瞬变又会造成误触发。

我踩过最典型的坑是：正前方5米货车驶过，地磁Z轴瞬间跳变，系统判定车位从“空”变成“占”，等货车走远才恢复。这个误报的直接原因就是没有做干扰过滤。真正能用的检测逻辑必须克服这种随机性，常见做法有两个：迟滞比较和滑动窗口滤波。

3.2 迟滞比较消除临界抖动：代码实现与参数设定

迟滞比较的思路是：设置两个阈值，一个判定“从空到占”的高阈值，一个判定“从占到空”的低阈值，两个阈值之间留一个滞回区间。这样当磁场强度在高阈值附近反复波动时，不会导致状态在空/占之间高频切换。比如无车时Z轴基准值是35，有车时能到75，高阈值可以设为55，低阈值设为45，车辆进入时超过55判定有车，之后即使信号回落到50，依然保持有车状态，只有跌到45以下才判定无车。

// 地磁车位检测状态机，含迟滞双重阈值 #define THRESHOLD_OCCUPIED 55 // 由空转占的高阈值 #define THRESHOLD_EMPTY 45 // 由占转空的低阈值 typedef enum { STATE_EMPTY = 0, STATE_OCCUPIED = 1 } ParkingState; void UpdateParkingState(int16_t z_value, ParkingState *state) { if (*state == STATE_EMPTY) { // 当前为空，必须超过高阈值才转占用 if (z_value > THRESHOLD_OCCUPIED) { *state = STATE_OCCUPIED; } } else { // 当前为占用，必须低于低阈值才转空 if (z_value < THRESHOLD_EMPTY) { *state = STATE_EMPTY; } } }

这段代码的核心逻辑是只有明确越过阈值才翻转状态，滞回区间就是55和45之间的10个单位。这个区间大小怎么定？太窄起不到抗抖作用，太宽会导致车辆停入后短暂离开（比如挪车）系统反应迟钝。我一般先连续采集几百组空车和占用后的数据，画出波形，取两组数据中位数的中间值作为判定核心，再往两边各扩展20%作为滞回边界。

还要说明的是，这里用的z_value是相对基准值的偏移量，不是传感器原始绝对值。每次上电时要先采集50组数据取平均作为基准，之后每次采样都减掉基准，得到偏移值。如果直接把原始值拿来做判断，早晚基准线会因为温度漂移偏到阈值外，导致系统性误判。

3.3 滑动窗口滤波：应对瞬时尖峰与车辆驶过邻近车位的磁扰动

迟滞比较能解决状态抖动，但解决不了瞬时尖峰。货车从旁边车道快速驶过，或者隔壁车位车辆启动的瞬间，地磁信号会出现一个持续几百毫秒的尖峰，如果采样周期是200毫秒，正好采到尖峰上就会误判。处理方法是把最近N次采样做平均或者取中位数，用平滑后的值再做迟滞判断。

// 滑动窗口求平均，窗口大小由SAMPLE_WINDOW控制 #define SAMPLE_WINDOW 5 int16_t filterBuf[SAMPLE_WINDOW]; uint8_t filterIndex = 0; uint8_t filterCount = 0; int16_t SlidingWindowFilter(int16_t new_sample) { int32_t sum = 0; filterBuf[filterIndex] = new_sample; filterIndex = (filterIndex + 1) % SAMPLE_WINDOW; if (filterCount < SAMPLE_WINDOW) { filterCount++; } for (uint8_t i = 0; i < filterCount; i++) { sum += filterBuf[i]; } return (int16_t)(sum / filterCount); }

窗口大小选5，意味着判断一次车位状态需要5次采样的平均值，每次采样间隔200毫秒的话，状态判断约滞后1秒。对停车场来说，1秒的判定延迟完全可接受，换来的是对瞬时干扰的高免疫能力。如果你想更快响应，可以缩小窗口到3，但干扰过滤能力会下降；想更稳就放大到7，代价是车辆驶离后系统要过约1.4秒才上报“空车位”。

这里有一个低成本测试方法：把传感器贴在金属脸盆上，模拟车辆压过的地磁变化，然后用手拿一块大铁板从旁边快速靠近再远离，观察串口打印的状态有没有误翻转。如果铁板快速划过导致状态误翻转一次，就说明滑动窗口还不够大，或者采样频率太低。

3.4 上电自动校准与环境漂移补偿：一个可复用的自学习思路

地磁传感器最烦人的就是温漂和安装应力带来的基准漂移。同一个小区的停车场，夏天和冬天的地磁基准能差10多个单位，如果基准值是写死在代码里的，这个项目注定要隔三差五被人叫去重新校准。

我一般会在代码里单独实现一个AutoCalibrate函数，位置放两个逻辑：上电后的30秒内不能判定车位状态，而是连续采样取均值作为动态基准；运行过程中如果系统连续超过10分钟检测为“空”，就缓慢把当前采样值纳入基准更新，使用加权方式让基准慢慢跟随环境变化。这个方案的核心思想是“空车位时的读数就是当前环境下的基准线”，比任何写死的值都可靠。

加权更新基准时要注意：每次更新只能挪动原基准1/16的距离，不能一步到位，否则停在车位上的车被误更新为“空”基准后，本来正确的占用读数会变得很低，直接击穿阈值。下面这段代码展示了加权基准更新的逻辑：

// 动态基准更新：仅在长期空置状态下调用 uint16_t baseline = 0; // 基准值 uint16_t sample_sum; uint8_t sample_count; void BaselineUpdate_poll(void) { static uint32_t lastUpdateTick = 0; // 系统已连续10分钟为空，且单次采样值变化不大 if (currentState == STATE_EMPTY && HAL_GetTick() - lastUpdateTick > 600000) { // 逐步逼近当前空置读数 baseline = baseline + ((uint16_t)currentSample - baseline) / 16; lastUpdateTick = HAL_GetTick(); } }

每次更新都是把基准向当前读数方向挪动十六分之一，既不会因为一次异常数据就大幅偏移，也不会因为长期无人车导致基准严重偏离。这个参数“16”就是一个典型的工程取值，想让基准慢一点跟手就调大分母，想让基准更敏感就调小。需要注意的是，只有在确认当前状态是空且持续时间足够长时才能做这个更新，否则停着车的时候基准被拉上去，后面撤掉车后新的空车读数就会被误判为占用。

4. 通信与联动：从串口打印到MQTT上报的完整链路

4.1 上报协议设计：三字节帧vs JSON，低功耗节点该怎么选

车位检测节点采集到状态后要上报给网关或云平台，协议怎么定直接关系功耗和调试效率。很多初学者直接把传感器数据打出来通过串口发到电脑，但在真实场景中，节点大多使用电池供电加无线模块，每多发一个字节就多一分功耗和无线占用。我的建议是“状态上报用三字节定长帧，调试诊断才用JSON”。

三字节帧可以这样定：第一字节是车位节点ID，第二字节是状态（0空1占），第三字节是CRC校验值。如果以后要多传电量信息，可以扩展成四字节帧，把电量百分比放在ID后面。这种做人肉解析就够了，不依赖任何第三方库，任何一个上位机脚本都能解析出来。

4.2 STM32串口DMA发送车位状态：中断占空比更低的写法

车位节点的单片机任务很轻，但无线模块发送数据时如果占用CPU太久，会造成采样延迟。我习惯用串口DMA发送，把要发的数据交给DMA控制器，CPU转头继续做传感器采样和状态判断。下面是一段基于HAL库的串口DMA发送示例，配合空闲中断上报状态变化。

// 串口DMA发送车位状态帧，发送后释放发送标志 uint8_t reportFrame[3]; void ReportState(uint8_t nodeId, uint8_t state) { reportFrame[0] = nodeId; reportFrame[1] = state; // 0x00空，0x01占 reportFrame[2] = reportFrame[0] ^ reportFrame[1]; // 简单异或校验 // 发送前清零DMA发送完成标志，防止上次发送未完成 __HAL_UART_CLEAR_FLAG(&huart1, UART_FLAG_TC); HAL_UART_Transmit_DMA(&huart1, reportFrame, 3); }

发送用DMA方式时要注意一个坑：HAL_UART_Transmit_DMA是非阻塞的，函数返回后数据可能还没发送完，如果你立刻修改reportFrame的内容，就会发出去错误数据。所以要么在发送完成回调里加标志，要么确保reportFrame在发送期间不被修改。上面代码里没有加等发送完的信号，实际项目中我在调用处会加一个信号量等待，确保帧是真实发出去了才进行下一次采样。

还有一个细节是发送完后需要清一下TC标志，否则第二次发送时可能因为上次的标志残留导致DMA模式异常。这个坑很隐蔽，表现为第一次发送正常，第二次串口助手收不到数据，清一下标志就好。

4.3 无线模块与MQTT桥接：STLink串口助手到云端的数据通路

车位节点本身一般不带网口，最常见的联网方式是加一个WiFi或者LoRa模块，再通过网关把数据推到云端。以ESP8266为例，STM32通过串口与ESP8266通信，模块负责TCP连接和MQTT协议栈，STM32只收发三字节帧，结构非常清晰。

我一般会在网关侧用Python脚本做桥接，监听串口收到的三字节帧，解析出车位状态后通过paho-mqtt库发布到指定Topic。下面是这个桥接脚本的关键段，它主要做了帧头校验和数据封装：

import serial import paho.mqtt.client as mqtt ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=1) client = mqtt.Client() def on_connect(client, userdata, flags, rc): print("MQTT connected") client.on_connect = on_connect client.connect("127.0.0.1", 1883, 60) client.loop_start() while True: data = ser.read(3) # 读三字节定长帧 if len(data) == 3: node_id = data[0] state = data[1] checksum = data[2] if checksum == (node_id ^ state): # 校验通过才发布 topic = f"parking/{node_id}/status" payload = "occupied" if state == 1 else "empty" client.publish(topic, payload, qos=1) print(f"Node {node_id} -> {payload}")

这段脚本的价值在于它把串口物理数据流和上层业务解耦了，上层只需要订阅MQTT主题，不需要关心底层是地磁还是超声波。qos设成1确保消息至少送达一次，但会存在少量重复，在云端做幂等处理即可。

4.4 用STM32巴法云或本地MQTT自建云平台：两种路径的取舍

说到云端，现在的物联网平台选择太多了。如果你只是自己调试，本地局域网用mosquitto自建MQTT服务器就够用；如果想做一个真正能远程查看车位状态的演示，可以考虑直接对接巴法云这类物联网平台，它们免备案、有免费额度、对接文档也简单。地道做法是先用本地MQTT打通全部链路，再去对接云平台，这样问题定位更清晰。

我踩过多平台对接的坑：不同平台的Topic格式、鉴权方式、心跳间隔要求都不一样，直接拿本地MQTT的代码去改云端，经常会卡在连接上被服务器拒绝。建议先看平台的设备接入文档，重点找三样东西：ClientID格式、用户名密码鉴权、心跳保活周期，先按平台的规则把连接建起来，再谈业务数据。

5. 避坑清单：地磁误报、I2C卡死、无线丢帧的实战排查记录

5.1 现象：车位状态频繁跳空/占，最后发现是采样线程被DMA发送拖垮

这是我早期做车位检测时遇到的最隐蔽问题。现象是车位明明空着，系统每隔几分钟就会上报一次“占用”，持续两三秒后恢复。排查时看串口日志，发现跳变时刻正好是无线模块上报数据的时刻。最终跟踪代码发现，DMA发送虽然是异步的，但发送前清TC标志和调用HAL函数本身需要时间；更关键的是，采样线程在发送期间被调度器挤占，导致某次采样间隔拉长到1秒以上，地磁数据多采了一个尖峰值。

原因：无线发送占用了CPU时间片，采样周期不再均匀，滑动窗口的时序被破坏。解决：把采样放到定时器中断里做，定时器每次触发硬采数据，只做入队操作，状态判断放到主循环里执行。定时器优先级设最高，发送动作哪怕稍慢，也不会影响采样的均匀性。

5.2 现象：车辆驶离后上报“空”要等十几秒，原因在滑动窗口和上报策略叠加了

有段时间客户反馈“车走之后手机上看还是占用”，排查发现不是无线问题，而是判定和上报两个逻辑存在叠加延迟。滑动窗口设了7次，每次采样间隔300毫秒，判定空需要2.1秒；但代码里上报动作只在状态翻转时触发，翻转后还做了一次延时确认，等确认功能后信息再无线发送，又消耗了2~3秒。连续几个环节叠加，用户感知就是“好慢”。

原因：判定延迟和上报延迟没有做整体预算。解决：把滑动窗口从7降到3，采样间隔从300降到200毫秒，同时去掉翻转后的二次确认（因为迟滞比较已经做了抗抖），整体判定加上报时间控制在1秒以内。这个案例也说明，参数优化要站在用户可感知的时延上，不能只看单个环节的可靠性。

5.3 现象：I2C读取卡死在HAL_I2C_Mem_Read里，程序无法继续

地磁传感器是I2C设备，调试时发现程序跑几分钟就卡住，串口不再打印数据。一开始怀疑传感器坏了，换了一个还是复现。用调试器看断点位置，卡在HAL_I2C_Mem_Read里等待总线释放，但信号量一直是忙状态。原因是没有处理I2C通信失败时的重新初始化。

解决：每次HAL_I2C_Mem_Read返回非HAL_OK时，调用HAL_I2C_DeInit和HAL_I2C_Init重新初始化外设，同时把超时时间从100毫秒降到50毫秒，减少卡住的时间窗口。另外在硬件上，我做了个小改进：SDA和SCL各接一个4.7K上拉电阻到3.3V，这个电阻是I2C总线必需的，很多学习板自带，但如果自己做板子漏了上拉，就会出现“时好时坏”的玄学问题。

5.4 现象：无线帧偶发丢失，网关收到的状态和车位实际不符

现场用了ESP8266做无线透传，发现网关偶尔会漏帧，但漏帧没有规律。起初怀疑是WiFi干扰，后来把两个模块放到一个桌面上测试，依然有微小概率丢包。查了ESP8266的透传缓存区，原因是STM32发送速度过快，串口TX速度是115200，但ESP8266内部在建立WiFi连接时处理慢，缓存区溢出，直接丢掉了后面带数据。

解决：把STM32串口波特率从115200降到9600，同时在上报逻辑中加上一个简易的“待确认”机制：发完一帧后等网关回一个ACK，超过300毫秒没收到就重发一次。这样一来一条状态上报可能重复发三遍，但网关侧按车位ID和状态做幂等处理，最后用户看到的是稳定不丢的状态。

5.5 现象：车辆停入后状态正常，但再次启动时基准线漂了，全盘误判

有一个现场在东北，冬天户外停车场，早上开机时地磁数据正常，到中午温度升高后误报频发。原因很直接：地磁传感器的零漂随温度变化，早上的基准线到了中午已经偏移了十多个单位，迟滞区间被整体抬高，空车信号触发了占用判定。

解决：把上电校准改成“运行中自动校准”，而且校准必须在无车状态下执行，即系统处于空状态超过10分钟后，把当前采样值按十六分之一权重融入基准。这样即使温度慢慢变化，基准跟随环境调整，误报就会消失。如果使用环境在山区或温差特别大的地方，建议多采几组数据做温度拟合标定，但这对大多数停车场场景来说有点过度设计了。

6. 把系统调到能真正上线的进阶验证方法：多车位联调与可靠性压测

源码能跑起来只是起点，真正敢把系统放到现场才是考验。我自己的习惯是拿一套简单的灯光模拟盘做整链路验证：用几个LED代表车位，把地磁传感器放桌面，拿一块铁板模拟车辆压车，然后检查LED、串口日志和MQTT主题是否同步变化。

验证要覆盖的不只是单节点，还有多车位并发。我在测试中同时放5个节点，每个节点用不同的ID，让它们以随机时间间隔上报状态，观察网关解析时有没有错位。这里最实用的是一个压测脚本，它周期性改变车位状态，并统计从改变到MQTT收到消息的延迟：

import time import random import paho.mqtt.client as mqtt node_ids = [1, 2, 3, 4, 5] latency_records = [] def on_message(client, userdata, msg): node_id = int(msg.topic.split('/')[1]) recv_time = time.time() payload = msg.payload.decode() for record in userdata['pending']: if record['node_id'] == node_id and record['state'] == payload: latency_records.append(recv_time - record['send_time']) userdata['pending'].remove(record) break client = mqtt.Client() client.user_data_set({'pending': []}) client.on_message = on_message client.connect("127.0.0.1", 1883, 60) client.subscribe("parking/+/status") client.loop_start() for i in range(200): node_id = random.choice(node_ids) state = random.choice(["occupied", "empty"]) pending = {'node_id': node_id, 'state': state, 'send_time': time.time()} client.user_data['pending'].append(pending) client.publish(f"parking/{node_id}/status", state, qos=1) time.sleep(0.1) time.sleep(5) latency_records_only = [r for r in latency_records if r >= 0] print(f"成功上报 {len(latency_records_only)}/{len(client.user_data['pending'])}") print(f"平均延迟 {sum(latency_records_only)/len(latency_records_only):.3f} 秒")

脚本的写法是先发布200条随机状态，同时记录发布时刻，收到回包后减去发布时刻即为端到端延迟。这个测试能暴露两个问题：一是无线模块是不是存在周期性卡顿，二是MQTT通道是否在高频消息下出现排队。当平均延迟超过1秒时，就要回头检查网关脚本的处理循环和无线模块的串口波特率匹配了。

可靠性压测之外，还要验证断电重启的恢复能力。版本迭代过程中我发现，如果设备在“占用”状态下断电，重新上电后要重新校准基准，而校准期间恰好看不到车辆状态，这个窗口期如果被上位机轮询到，会误报为“空”。现在的处理方案是把最后一次可靠状态存入Flash，上电恢复后先上报Flash中的旧状态，完成校准后再上报真实状态。

总结一句个人经验：这套用STM32做车位检测的方案技术上不复杂，节点端、网关、云端三层拆开后每一层都能单独排查，问题也往往出在层与层的交接处而不是单点。拿着这个源码框架，你完全可以根据自己的传感器和云平台替换掉局部模块，它最大的价值就是让你在没有供应商技术支持时，依然能自己定位、自己修。希望帮到你。

本文还有配套的精品资源，点击获取