1. 项目背景与需求分析：电梯运行监测的痛点、LoRa技术选型理由、系统整体架构概览

1.1 电梯监测，到底难在哪？

做物联网这些年，我接触过不少工业场景。但说实话，电梯这个领域，一开始真让我头疼。

你想想看，一栋30层的高楼，电梯井道就是个封闭的金属笼子。信号进去就出不来，出来就进不去。我有个朋友在物业公司做技术主管，他跟我吐槽过：

• 故障发现滞后——电梯卡人了，往往是乘客按了紧急按钮，值班室才知道。等维修工赶到，黄花菜都凉了。
• 维保记录靠手写——很多老旧电梯，维保人员来了，在纸质单子上打个勾就走。到底修没修？修了哪里？没人知道。
• 数据孤岛严重——电梯厂家、维保公司、物业公司，各管各的系统。信息不互通，出了事互相推诿。

我在一个旧改项目里遇到过更夸张的事：某写字楼的电梯，平均每天困人2次。物业经理急得团团转，但就是查不出原因。后来我们装了监测设备才发现——是门锁触点氧化，接触不良导致的。这种间歇性故障，靠人工巡检根本发现不了。

1.2 为什么选LoRa？

好，问题摆在这了。那用什么技术来解决？

我个人习惯，选型前先列需求：

• 要能穿透几层楼板，覆盖整个井道
• 功耗要低，最好电池能撑一年以上
• 成本要可控，不能比电梯本身还贵
• 部署要简单，不能大动干戈改线路

Wi-Fi？穿一层楼板就剩一格信号了。蓝牙？距离撑死10米。ZigBee？组网复杂，而且穿透力也一般。4G？功耗太高，一个传感器天天换电池，谁受得了？

LoRa的优势就出来了：

技术指标	LoRa	Wi-Fi	蓝牙	4G Cat.1
通信距离（空旷）	2-5 km	50-100 m	10-20 m	基站覆盖
穿墙能力	强（可穿3-5层楼板）	弱	弱	中等
接收灵敏度	-148 dBm	-90 dBm	-96 dBm	-105 dBm
休眠功耗	1-2 μA	100 μA+	10 μA+	1 mA+
模组成本	15-30 元	10-20 元	5-15 元	40-80 元

你看，LoRa在穿透力和功耗上，几乎是碾压级的。我曾经在一个地下3层的停车场做过测试，LoRa网关放在1楼，传感器放在B3电梯井道里，数据照样能传上来。换成Wi-Fi？想都别想。

1.3 系统整体架构，长什么样？

嗯，技术选型定了，接下来就是搭架子了。

整个系统分四层，我习惯从下往上讲：

第一层：感知层

就是那些贴在电梯上的传感器。我们主要采集三类数据：

• 加速度/振动——判断电梯运行平稳度，有没有异常抖动
• 门磁/光电开关——检测电梯门开关状态，开关次数统计
• 温湿度/噪声——辅助判断机房环境，有没有过热或异常噪音

每个传感器都带一个LoRa模块，负责把数据发出去。

第二层：网络层

LoRa网关是核心。它负责接收所有传感器的数据，然后通过4G或有线网络，上传到云平台。

这里有个细节：一个网关能带多少传感器？我实测过，在电梯场景下，一个网关带50-80个节点没问题。数据上报间隔建议设5-10分钟一次，太频繁反而容易丢包。

第三层：平台层

云平台负责数据存储、处理、展示。我们用的是阿里云IoT套件，当然你也可以用腾讯云、华为云，或者自己搭EMQX。

平台要做的事：

• 数据解析——把LoRa的原始报文转成可读的JSON
• 规则引擎——比如连续3次检测到异常振动，自动生成告警工单
• 可视化大屏——让物业经理一眼看清所有电梯的运行状态

第四层：应用层

这是用户直接接触的部分。包括：

• 手机APP——维保人员现场查看、拍照上传
• Web管理后台——物业公司查看报表、导出数据
• 短信/电话告警——紧急情况自动通知相关人员

这个架构的好处是——松耦合。哪一层出了问题，不影响其他层。比如网关坏了，传感器数据会本地缓存，等网关恢复后再补传。我在项目中就遇到过网关断电的情况，幸好设计了缓存机制，数据一点没丢。

1.4 写在后面的话

好了，背景和需求分析就聊到这。说白了，电梯监测这个事，技术难度不算高，但坑不少。选对通信技术，搭好系统架构，后面的事就顺了。

下一章，我会带大家从零开始，搭建LoRa网关的硬件平台。到时候咱们聊聊怎么选主控芯片、怎么设计射频电路、怎么调试天线匹配。嗯，那才是真正动手的时候。