1. 项目缘起与整体设计思路
1.1 这个项目到底在解决什么问题
科技园区里配几台有氧健身设备，跑步机、椭圆机、动感单车，这事本身不新鲜。真正让人头疼的是后续运营：设备有没有人在用、用了多久、有没有故障、耗材什么时候该换、高峰时段够不够用、要不要再加两台。传统做法要么靠人工巡检登记，要么干脆没人管，设备坏了半个月才被发现是常态。
这个项目的核心目标很明确：给园区里的共享有氧健身设备装上一套基于 WiFi 的物联网监测系统，把每台设备的运行状态、使用频次、实时姿态数据采集上来，集中到一个后台看板，让运营方随时掌握设备健康状况和使用热度。关键词里出现的 WiFi、物联网、传感器、智能监测、姿态传感器，基本勾勒出了整套方案的技术轮廓。
适合谁来参考这份总结？三类人。第一类是做园区智慧化改造的工程实施人员，需要一套能直接落地的方案；第二类是做物联网课程设计或毕业设计的学生，想找一个有真实场景、有完整链路、不是玩具级别的项目；第三类是对传感器数据采集和无线传输感兴趣的技术爱好者，想搞清楚从硬件到云端这条链路到底怎么打通。
1.2 为什么选 WiFi 而不是别的无线方案
无线传输方案的选择，直接决定了整个系统的成本和部署难度。常见的选项有 WiFi、蓝牙、ZigBee、LoRa、NB-IoT 这几种。我当时的选型逻辑是这样的：
园区本身已经有全覆盖的 WiFi 网络，这是最大的先天优势。健身设备安装在室内或半室内的健身区，距离 AP 不会太远，信号覆盖没问题。WiFi 的带宽足够支撑姿态传感器这种需要较高采样率的数据回传，而 LoRa 和 NB-IoT 虽然覆盖远、功耗低，但带宽太小，传姿态数据会很吃力。蓝牙的覆盖范围又太短，一台设备配一个网关不现实。
| 方案 | 带宽 | 覆盖 | 功耗 | 部署成本 | 本项目适配度 |
|---|---|---|---|---|---|
| WiFi | 高 | 中 | 高 | 低（复用现有网络） | 最合适 |
| 蓝牙 | 中 | 短 | 低 | 中 | 不适合 |
| ZigBee | 低 | 中 | 低 | 中 | 带宽不足 |
| LoRa | 极低 | 远 | 极低 | 高 | 带宽不足 |
| NB-IoT | 低 | 远 | 低 | 高 | 带宽不足 |
选 WiFi 的代价是功耗偏高，设备需要持续供电。但健身设备本身就是插电的，这个代价可以忽略。所以最终方案定为：传感器采集 + 单片机处理 + WiFi 模块上传 + 云端存储与展示。
1.3 系统整体架构怎么搭
整套系统按物联网经典的三层架构来组织，这个分层不是照搬教科书，而是实际开发中确实能帮你理清思路。
感知层负责数据采集。每台健身设备上装三类传感器：姿态传感器（MPU6050 这类六轴传感器）监测设备运动部件的角度和加速度，用来判断设备是否在被使用、运动幅度是否正常；电流传感器（霍尔式或互感式）监测电机负载，判断设备是否卡顿、阻力是否异常；红外或超声波传感器做人体存在检测，辅助判断有没有人在用。
网络层负责数据传输。每台设备配一个 ESP32 模组，它自带 WiFi 功能，把传感器数据打包后通过 MQTT 协议发到园区内网的 MQTT Broker。选 MQTT 而不是 HTTP，是因为 MQTT 长连接开销小、支持发布订阅、断线重连机制成熟，非常适合这种多设备持续上报的场景。
应用层负责数据存储和展示。MQTT Broker 后面接一个数据入库服务，把数据写进时序数据库（InfluxDB 或 TDengine），再用 Grafana 或自研的 Web 看板做可视化。运营人员打开浏览器就能看到每台设备的实时状态和历史曲线。
提示：三层架构听起来简单，但实际开发中最容易出问题的是层与层之间的接口约定。建议在动手写代码之前，先把数据格式、上报频率、字段含义用一张表定死，后面所有人按这个表来，能省掉大量联调时间。
2. 核心硬件选型与传感器细节解析
2.1 主控为什么选 ESP32 而不是 STM32 加独立 WiFi 模块
这是很多人纠结的第一个问题。STM32 加 ESP8266 的组合是经典方案，资料多、社区大。但我最终选了 ESP32 单芯片方案，理由有三条。
第一，集成度高，省掉一个模块的硬件设计和调试成本。ESP32 本身是双核 240MHz，跑传感器采集和 WiFi 通信绰绰有余，不需要外挂主控。第二，ESP32 自带 WiFi 和蓝牙，开发时可以用蓝牙做本地调试，WiFi 做数据上传，两条通道互不干扰。第三，ESP-IDF 和 Arduino 框架都支持得很好，开发效率高。
当然，如果你的项目对实时性要求极高，或者需要大量模拟量采集，STM32 的 ADC 性能和定时器精度确实更好。但健身设备监测这个场景，采样率要求不高（姿态数据 50Hz 足够），ESP32 完全够用。
2.2 姿态传感器 MPU6050 的安装位置与数据解读
姿态传感器是整个系统里最能体现"智能监测"的部分。MPU6050 集成了三轴加速度计和三轴陀螺仪，通过 I2C 接口和 ESP32 通信，默认地址 0x68。
安装位置很关键。以跑步机为例，传感器应该固定在跑带下方的减震结构上，而不是直接贴在跑带上。贴在跑带上会跟着跑带一起运动，数据全是噪声。固定在减震结构上，采集到的是设备整体的振动特征，这个特征和跑步速度、使用者体重、跑带松紧都有关系。
数据解读方面，我主要看三个指标：加速度的均方根值（RMS）反映振动强度，用来判断设备是否在运行；陀螺仪的 Z 轴角速度积分反映跑带倾斜角度变化；加速度的频谱特征用来判断跑带是否跑偏或轴承是否磨损。这些判断逻辑不是拍脑袋定的，是先在正常设备上采集一周基线数据，再用异常设备的数据做对比得出的阈值。
2.3 电流传感器的选型与接线要点
电流监测用来判断电机负载。我选的是霍尔式电流传感器，型号类似 ACS712 或国产替代品。相比互感式，霍尔式的优点是隔离性好、响应快、可以直接测直流。
接线时要注意三点。第一，传感器的供电要和 ESP32 共地，否则读数会漂。第二，被测电流的火线要穿过传感器的穿孔，方向要和传感器标注的箭头一致，反了读数会变成负值。第三，ESP32 的 ADC 参考电压是 3.3V，而 ACS712 的输出是以 2.5V 为中心的，所以需要做分压或选择 3.3V 供电版本的传感器。
注意：电流传感器附近如果有大功率电机或变频器，读数会受到明显干扰。实测下来，在传感器输出端并联一个 0.1uF 的陶瓷电容，能有效滤掉高频噪声。这个技巧在数据手册里不会写，是踩坑踩出来的。
2.4 传感器数据采集的时序设计
多个传感器共用 ESP32，采集时序要设计好，否则会出现数据错位或丢包。我的做法是用一个 20ms 的定时器中断作为采集节拍，每个节拍里依次读取 MPU6050 的加速度和角速度、读取电流传感器的 ADC 值、读取人体存在传感器的状态。所有数据先存进一个环形缓冲区，主循环再从缓冲区取数据打包上传。
这样做的好处是采集和上传解耦，WiFi 发送偶尔阻塞不会影响采集的连续性。缓冲区大小设成 100 个样本，按 50Hz 采样率算能缓冲 2 秒的数据，足够应对短暂的网络抖动。
3. 从传感器到云端：完整实操流程
3.1 硬件连接与供电方案
先列一下单台设备的物料清单，方便你直接抄作业：
| 物料 | 型号参考 | 数量 | 说明 |
|---|---|---|---|
| 主控模组 | ESP32-WROOM-32 | 1 | 自带 WiFi |
| 姿态传感器 | MPU6050 | 1 | I2C 接口 |
| 电流传感器 | ACS712-20A | 1 | 模拟输出 |
| 人体存在传感器 | HC-SR501 | 1 | 数字输出 |
| 电源模块 | 220V 转 5V 2A | 1 | 隔离型 |
| 外壳 | 防水接线盒 | 1 | IP54 以上 |
供电直接从健身设备的电源取电，经过隔离电源模块转成 5V 给 ESP32 和传感器供电。这里强调"隔离型"是因为健身设备电机启停时会有较大的电压波动，非隔离电源容易把 ESP32 烧掉。我第一批样机就因为这个原因烧了两块板子，后来全部换成隔离电源才稳定。
3.2 ESP32 端固件开发要点
固件用 Arduino 框架开发，主要逻辑分三块：WiFi 连接管理、传感器采集、MQTT 上报。
WiFi 连接管理要处理断线重连。我的做法是每 30 秒检查一次连接状态，断开就重连，重连失败超过 5 次就重启 ESP32。这个逻辑看起来粗暴，但实测最有效，比复杂的重连状态机靠谱。
传感器采集用定时器中断驱动，前面说过是 20ms 一次。MPU6050 的读取要注意先读加速度再读角速度，中间不要插入其他 I2C 操作，否则数据会错位。
MQTT 上报用 PubSubClient 库，主题设计成gym/device/{设备ID}/data这种格式，方便后台按设备订阅。上报频率是每秒 5 次，每次上报一个包含时间戳、加速度三轴、角速度三轴、电流值、人体存在状态的 JSON 包。
// 数据打包示例 String buildPayload(float ax, float ay, float az, float gx, float gy, float gz, float current, bool presence) { StaticJsonDocument<256> doc; doc["ts"] = millis(); doc["ax"] = ax; doc["ay"] = ay; doc["az"] = az; doc["gx"] = gx; doc["gy"] = gy; doc["gz"] = gz; doc["cur"] = current; doc["pres"] = presence; String out; serializeJson(doc, out); return out; }3.3 MQTT Broker 与数据入库配置
Broker 我用的是 Mosquitto，部署在园区内网的一台服务器上。配置要点是开启持久化、设置最大连接数、配置 ACL 限制每个设备的发布权限。
数据入库服务用 Python 写，订阅gym/device/+/data这个通配主题，收到消息后解析 JSON，写入 InfluxDB。InfluxDB 的 measurement 名用device_data，tag 用设备 ID，field 用各个传感器值。这样查询时按设备 ID 过滤非常快。
# 入库核心逻辑 def on_message(client, userdata, msg): data = json.loads(msg.payload) device_id = msg.topic.split('/')[2] point = Point("device_data") \ .tag("device", device_id) \ .field("ax", data["ax"]) \ .field("ay", data["ay"]) \ .field("az", data["az"]) \ .field("current", data["cur"]) \ .field("presence", int(data["pres"])) write_api.write(bucket="gym", record=point)3.4 可视化看板搭建
看板用 Grafana 搭，连 InfluxDB 数据源。我配了三个面板：实时状态面板显示每台设备当前是否在用、电流值、振动强度；历史趋势面板显示过去 24 小时的使用时长统计；告警面板显示振动异常或电流异常的设备列表。
告警规则是这样设的：振动 RMS 值连续 10 秒超过基线 3 倍，判定为异常振动；电流值连续 5 秒超过额定值 1.5 倍，判定为过载。告警触发后通过 Webhook 推送到运营群，运营人员收到后安排检修。
4. 常见问题排查与避坑经验实录
4.1 数据丢包和延迟问题怎么定位
这是部署后遇到的第一个大问题。现象是看板上某些设备的数据时有时无，延迟忽大忽小。排查思路按从下到上的顺序来。
先查 WiFi 信号强度。用 ESP32 打印 RSSI 值，发现信号弱的设备 RSSI 在 -80dBm 左右，这个值已经接近可用边缘。解决办法是在健身区加装了一个 AP，把 RSSI 拉到 -60dBm 以上，丢包率立刻降下来。
再查 MQTT 的 QoS 设置。默认 QoS 0 是"最多一次"，网络抖动时消息会丢。改成 QoS 1"至少一次"，配合消息去重逻辑，数据完整性明显改善。
最后查入库服务的处理能力。Python 单线程处理每秒几百条消息时会出现积压，改成批量写入（每 100 条或每 1 秒写一次）后问题解决。
4.2 传感器数据漂移的处理
MPU6050 的陀螺仪存在零偏，长时间运行后积分角度会漂移。解决办法是每次设备启动时做一次静态校准，采集 100 个样本取平均值作为零偏，后续数据都减去这个零偏。如果设备运行环境温度变化大，还需要做温度补偿，但健身区温度相对稳定，静态校准就够了。
电流传感器的漂移主要来自供电电压波动。我在固件里加了一个参考电压采集通道，每次读电流值时同时读参考电压，用比例计算实际电流值，这样即使供电电压有波动，读数也能保持准确。
4.3 设备离线与重连的实战经验
设备离线是运维中最常见的问题。我整理了一张排查速查表，按现象查原因：
| 现象 | 可能原因 | 排查方法 | 解决措施 |
|---|---|---|---|
| 设备完全离线 | 供电故障 | 检查电源指示灯 | 更换电源模块 |
| 频繁掉线 | WiFi 信号弱 | 查看 RSSI 日志 | 增加 AP 或调整位置 |
| 能连 WiFi 但不上报 | MQTT 认证失败 | 查看 Broker 日志 | 检查用户名密码 |
| 数据时有时无 | 网络抖动 | ping 测试 | 提高 QoS 等级 |
| 设备重启 | 电源波动 | 监测供电电压 | 更换隔离电源 |
提示：建议在固件里加一个看门狗定时器，ESP32 自带硬件看门狗，配置成 30 秒超时。这样即使程序跑飞，设备也能自动重启恢复，不用人工去现场断电重启。
4.4 关于 WiFi 安全配置的几点说明
园区 WiFi 是运营方统一管理的，设备接入用的是独立的 SSID 和预共享密钥。这里要强调的是，物联网设备的安全配置和普通用户设备不一样。建议给物联网设备单独划分 VLAN，限制它们只能访问 MQTT Broker 的端口，不能访问其他内网资源。这样即使某个设备被攻破，影响范围也可控。
另外，ESP32 的固件里不要把 WiFi 密码硬编码在代码里，建议存在 NVS 分区里，首次配网时通过蓝牙或串口写入。这样固件升级时不用重新编译，也降低了密码泄露的风险。
5. 系统扩展与后续优化方向
5.1 从单园区到多园区的架构演进
单园区部署时，所有设备连同一个 Broker，架构简单。如果要扩展到多个园区，有两种思路。一种是每个园区部署独立的 Broker 和数据库，各园区数据独立管理，总部通过 API 聚合数据。另一种是所有园区设备连总部的 Broker，集中存储。前者网络依赖小、故障隔离好，后者管理简单、数据统一。我倾向于前者，因为园区网络环境差异大，集中式架构对网络质量要求太高。
5.2 姿态数据的深度利用
目前姿态数据主要用来判断设备是否在用和振动是否异常。其实这些数据还能做更多事。比如通过分析跑步机的振动频谱，可以判断跑带磨损程度，提前预警更换。通过分析椭圆机的运动轨迹，可以判断轴承是否缺油。这些都需要积累足够的历史数据，用简单的机器学习模型做分类。我目前还在数据积累阶段，等数据量够了再上模型。
5.3 低功耗与边缘计算的取舍
ESP32 在这个项目里是持续供电的，功耗不是问题。但如果未来要加装电池供电的传感器节点，就需要考虑低功耗设计。ESP32 支持深度睡眠模式，睡眠电流可以做到 10uA 级别，配合定时唤醒采集，一块电池能用几个月。代价是数据不是实时的，需要接受分钟级的延迟。这个取舍要根据具体监测需求来定。
我个人在实际操作中的体会是，物联网项目最难的不是技术本身，而是把技术、场景、成本三者平衡好。传感器选贵了成本下不来，选便宜了数据质量不行；上报频率高了网络扛不住，低了又失去监测意义。这个平衡点没有标准答案，只能在实际部署中不断调整。我第一批部署的 10 台设备，参数改了至少五轮才稳定下来。所以如果你也在做类似的项目，建议先小规模试点，跑通了再批量复制，别一上来就铺开。
