基于ESP8266 WiFi嗅探与MQTT的物联网接近检测系统实战-平芜编程栈

1. 项目概述：一个基于WiFi信号强度的非接触式设备感知系统

在智能家居和物联网项目中，我们常常需要知道某个设备或人是否在特定区域内。传统的方案，比如红外传感器或摄像头，要么有方向性限制，要么涉及隐私问题。今天分享的这个项目，则提供了一种更灵活、非接触且成本极低的思路：利用无处不在的WiFi信号来实现接近检测。

这个系统的核心原理并不复杂。每一台支持WiFi的设备，无论是手机、电脑还是智能手表，都会定期向外广播一种叫做“探测请求”的数据包，用来寻找可用的网络。即使设备没有连接到某个WiFi，这个广播行为也在持续。我们的主角——一块售价仅二三十元的ESP8266开发板（比如NodeMCU），可以进入一种特殊的“混杂模式”，监听空气中所有的WiFi数据包，并从中提取出发送设备的MAC地址（可以理解为设备的唯一硬件身份证）以及一个关键的参数：RSSI。

RSSI，即接收信号强度指示器，单位通常是dBm。简单理解，它就像你说话时我听到的音量。你离我越近，我听到的声音越大，RSSI值就越高（负得越少，比如-30dBm比-80dBm信号强）。通过持续监测特定MAC地址设备的RSSI值，并设定一个阈值（比如-70dBm），我们就能判断这台设备是否进入了我们关注的“接近”区域。

本项目的完整流程是：ESP8266扫描环境中的WiFi设备，将目标设备的接近状态通过MQTT协议发送到后端服务器和Ubidots物联网云平台。同时，我们搭建了一个简单的React前端页面，用于添加需要追踪的设备MAC地址，并可视化查看它们的最后在线时间和信号强度。整个系统从硬件接线、固件烧录，到后端API、前端界面和云端看板，形成了一个完整的、可复现的物联网应用闭环。无论你是想做一个“人来自动开灯”的智能感应器，还是想监控重要资产是否离开特定范围，这个项目都能提供一个扎实的起点。

2. 系统核心设计与技术选型解析

2.1 为什么选择ESP8266与WiFi嗅探方案？

在考虑接近检测方案时，市面上有蓝牙（如BLE Beacon）、红外、超声波等多种选择。最终选择ESP8266配合WiFi嗅探，主要基于以下几点考量：

成本与普及率的极致平衡：ESP8266是目前性价比最高的WiFi物联网芯片之一。一个NodeMCU开发板集成了MCU、WiFi和GPIO，价格低廉。更重要的是，WiFi几乎是现代智能设备的标配，无需为目标设备添加任何额外硬件或应用，实现了真正的无感检测。相比之下，蓝牙方案通常需要设备开启蓝牙并配合特定APP，红外和超声波则有方向性和遮挡问题。

“混杂模式”的技术优势：ESP8266的SDK支持将WiFi芯片设置为混杂模式。在此模式下，芯片可以捕获所有信道上的802.11数据帧，而不仅仅是发给自己的数据。这就像是一个无线电监听器，能“听到”区域内所有WiFi设备的“交谈”（广播的探测请求和管理帧）。这为我们获取非关联设备的MAC地址和RSSI提供了可能。

完整的物联网生态支持：ESP8266拥有极其成熟的Arduino核心和丰富的库支持，使得开发门槛大大降低。它能轻松连接MQTT Broker，与Node.js后端、React前端以及Ubidots这类云平台无缝集成，非常适合用来演示一个从端到云的全栈物联网应用架构。

注意：WiFi嗅探方案的精度属于“区域级”而非“厘米级”。它擅长判断设备是否在某个房间或一定范围内（例如半径10-20米），但无法进行精确定位。如果你的项目需要厘米级精度，可能需要考虑UWB（超宽带）等技术。

2.2 系统架构与数据流拆解

整个系统可以分为四个逻辑层，数据在其中单向流动，形成一个清晰的闭环。

感知层（ESP8266）：这是系统的“眼睛”和“初级大脑”。ESP8266上运行着核心检测固件。它首先连接到一个已知的WiFi路由器以接入互联网。然后，它开启WiFi混杂模式，扫描并捕获空中的WiFi数据包。固件中预设了一份需要关注的MAC地址列表（从后端获取）。每当捕获到一个数据包，它就检查其源MAC地址是否在关注列表中。如果是，则记录其RSSI值。固件会周期性地（例如每10秒）将扫描结果（MAC地址和对应的RSSI）打包，通过MQTT协议发布到指定的主题。
传输与逻辑层（MQTT Broker + Node.js后端）：MQTT Broker（如HiveMQ公共Broker或自建Mosquitto）充当了消息中转站，负责接收ESP8266上报的数据，并将其分发给订阅了相关主题的后端服务。Node.js后端服务扮演了“中枢神经”的角色。它主要做三件事：一是订阅MQTT主题，接收来自ESP8266的接近数据；二是提供RESTful API给前端，用于管理MAC地址列表（增删改查）；三是将接收到的数据处理后，可能转发给Ubidots云平台，也可能存储到本地数据库（原项目未强调存储，但可以扩展）。
云平台层（Ubidots）：这是一个可选的、但非常实用的可视化层。Ubidots是一个物联网应用开发平台，它提供了数据接入、存储、可视化图表和事件触发等功能。后端服务将ESP8266上报的RSSI数据发送到Ubidots，我们就能在Ubidots上创建一个仪表板，实时看到每个被追踪设备的信号强度曲线图，直观了解其接近状态的变化历史。
应用层（React前端）：这是给用户操作的界面。一个简单的Web页面，允许用户输入新的设备MAC地址并将其提交到后端，从而将其加入追踪列表。同时，前端页面会从后端获取最新的设备状态（最后出现时间、最佳RSSI值），并以列表或卡片的形式展示出来，让用户一目了然。

数据流可以概括为：ESP8266 扫描 -> MQTT 发布 -> Node.js 后端订阅/处理 -> (可选)Ubidots 可视化 & React 前端展示/管理。

2.3 关键组件选型理由

通信协议：MQTT：在物联网领域，MQTT协议因其轻量、低功耗、基于发布/订阅模型的特点而成为事实标准。它非常适合像ESP8266这样资源受限的设备与服务器进行异步通信。ESP8266只需要知道Broker的地址和主题，就可以上报数据，无需维护复杂的HTTP连接状态。
云端可视化：Ubidots STEM：对于快速原型开发，Ubidots的免费STEM账户提供了足够的数据点数和丰富的控件（图表、开关、地图等），让我们在几分钟内就能搭建一个专业的监控仪表板，省去了从零开发前端图表和搭建数据库的麻烦。
前端框架：React：选择React构建前端，主要是考虑到其组件化特性适合构建动态交互界面（如实时更新设备状态列表），并且生态丰富，与Node.js后端配合顺畅。对于这样一个管理界面，React能提供良好的开发体验和用户界面。
开发环境：Arduino IDE：虽然对于复杂项目，PlatformIO是更专业的选择，但Arduino IDE对于初学者和快速上手ESP8266开发来说门槛最低，库管理也相对直观，符合本项目作为教学示范项目的定位。

3. 硬件连接与核心库详解

3.1 硬件清单与接线图

这个项目对硬件需求极为简单，核心就是一块NodeMCU ESP8266开发板和一个共阳极RGB LED灯（用于状态指示）。

必需硬件：
- NodeMCU ESP8266 开发板 x1
- 共阳极RGB LED灯 x1
- 220Ω 电阻 x3（用于限流，保护LED和ESP8266的GPIO口）
- 面包板 x1（可选，方便接线）
- 杜邦线（跳线）若干
- Micro-USB 数据线 x1（用于供电和烧录程序）

RGB LED与NodeMCU连接方法：共阳极RGB LED有4个引脚：最长的引脚是公共阳极（接正极），另外三个较短的引脚分别对应红色（R）、绿色（G）、蓝色（B）的阴极。接线时，公共阳极引脚需要连接到NodeMCU的3.3V引脚。三个阴极引脚则需要分别通过一个220Ω的电阻，连接到NodeMCU的数字GPIO引脚上。具体的引脚定义可以在代码中灵活配置，一个常见的接法如下（请务必以你代码中的#define语句为准）：

RGB LED 引脚	连接至 NodeMCU	说明
公共阳极 (最长脚)	3.3V 引脚	提供电源正极
红色 (R) 阴极	GPIO 5 (D1)	通过220Ω电阻连接
绿色 (G) 阴极	GPIO 4 (D2)	通过220Ω电阻连接
蓝色 (B) 阴极	GPIO 0 (D3)	通过220Ω电阻连接

实操心得：电阻必不可少。ESP8266的GPIO引脚最大输出电流有限（约12mA），直接驱动LED可能导致引脚损坏或板子重启。串联一个220Ω电阻可以将电流限制在安全范围内（约10mA）。如果手头没有精确的220Ω电阻，使用330Ω或470Ω也可以，只是LED亮度会稍暗。

3.2 核心Arduino库功能解析

在Arduino IDE中，你需要通过“库管理器”或手动安装以下四个库，它们是项目正常运行的基石：

ESP8266WiFi.h：这是ESP8266 Arduino核心自带的库，提供了连接WiFi、配置WiFi模式（STA/AP/混杂模式）等所有基础网络功能。本项目正是利用它提供的WiFi.mode(WIFI_STA)和wifi_promiscuous_enable()等函数来实现WiFi连接和嗅探模式切换。
PubSubClient.h：这是一个非常流行的MQTT客户端库。它封装了MQTT协议通信的细节，让我们可以用简单的client.publish()和client.subscribe()函数来向Broker发布消息或订阅主题。你需要配置Broker地址、端口、客户端ID以及回调函数（用于处理接收到的订阅消息）。
ArduinoJson.h：在物联网项目中，设备与服务器之间经常需要传递结构化的数据（如JSON格式）。这个库提供了高效、易用的方法来在Arduino上序列化和反序列化JSON数据。例如，ESP8266需要将从后端获取的MAC地址列表（JSON数组）解析出来，也会将扫描结果封装成JSON字符串发布出去。
Ubidots.h：这是Ubidots官方提供的ESP8266专用库，它基于PubSubClient，进一步封装了与Ubidots平台通信的细节。使用这个库，你可以用一两行代码就将数据发送到你在Ubidots上创建的变量中。虽然原项目代码中可能直接使用了PubSubClient与Ubidots的MQTT端点通信，但使用这个官方库通常更稳定便捷。

注意事项：库版本兼容性。Arduino库的版本更新有时会引入不兼容的改动。建议在安装时，如果不确定，可以选择已知与ESP8266核心版本兼容的较稳定版本。例如，对于PubSubClient.h，确保其版本支持ESP8266的WiFi客户端。如果遇到编译错误，首先检查库的示例代码能否正常编译，这是排查库问题的好方法。

4. 固件代码深度剖析与配置要点

4.1 主程序逻辑与状态机

ESP8266的固件程序（.ino文件）遵循一个清晰的状态机逻辑，确保设备有序地完成初始化、连接、检测和数据上报。其核心流程如下：

初始化 (setup())：
- 引脚与串口：初始化串口用于调试输出，配置RGB LED引脚为输出模式。
- WiFi连接：以工作站模式连接至预设的WiFi路由器。这里会有一个等待过程，连接成功后串口会打印本地IP地址。
- MQTT连接：设置MQTT服务器地址、端口、回调函数，然后尝试连接。回调函数用于处理来自后端（比如下发新的MAC地址列表）的消息。
- 订阅主题：连接Broker成功后，立即订阅macTopic主题，以接收后端下发的MAC地址列表。
- 初始化嗅探：调用wifi_promiscuous_enable()等函数，启动WiFi混杂模式，并注册一个数据包接收回调函数。任何WiFi数据包被捕获时，都会触发这个回调函数。
主循环 (loop())：
- 维持MQTT连接：首先检查MQTT客户端连接是否活跃，如果断开则尝试重连。这是保证通信可靠性的关键一步。
- 处理MQTT消息：调用client.loop()函数，让PubSubClient库有机会处理网络数据，并执行之前注册的回调函数。
- 执行周期任务：
  - 状态指示：根据当前系统状态（连接中、扫描中、设备接近），控制RGB LED显示不同颜色。
  - 数据上报：每隔一个固定的时间间隔（例如10秒），程序会检查在上一周期内是否扫描到目标设备。如果有，则计算其平均或最佳RSSI值，将其与设备MAC地址一起，封装成JSON格式，通过MQTT发布到statusTopic主题。
  - 列表同步：可以设置一个更长的时间间隔（如5分钟），主动通过MQTT向后端请求最新的MAC地址列表，确保追踪列表是最新的。

4.2 关键配置参数详解

在代码开头的配置区域，你需要仔细填写以下信息，这是项目能否跑通的第一步：

// 网络配置 const char *ssid = "Your_WiFi_SSID"; // 你的WiFi名称 const char *password = "Your_WiFi_Pass"; // 你的WiFi密码 // MQTT Broker配置 const char *mqtt_broker = "broker.hivemq.com"; // Broker地址 const int mqtt_port = 1883; // 端口，通常1883是明文，8883是SSL const char *mqtt_clientId = "ESP8266_Client_01"; // 客户端ID，需唯一 // MQTT主题配置 (非常重要！前后端必须一致) const char *macTopic = "myhome/proximity/maclist"; // 用于订阅MAC地址列表的主题 const char *statusTopic = "myhome/proximity/status"; // 用于发布设备状态的主题 // Ubidots配置 (如果使用Ubidots.h库) char ubidotsToken[] = "BBFF-YourUbidotsTokenHere"; // 你的Ubidots Token char deviceLabel[] = "esp8266-proximity"; // 在Ubidots中代表此设备的标签

主题命名建议：macTopic和statusTopic是通信的“频道”名称，前后端必须完全一致。建议采用有层次结构的命名，如项目名/功能/具体主题，避免与公共Broker上其他用户的主题冲突。不要使用过于简单或常见的词。
RSSI阈值：在代码中会有一个RSSI_THRESHOLD常量（如#define RSSI_THRESHOLD -70）。这个值决定了“接近”的判断标准。数值需要根据实际环境测试调整。在开放空间，-50dBm可能意味着设备就在几米内，而-80dBm可能意味着在隔壁房间或距离较远且有墙体阻隔。
扫描信道与间隔：ESP8266一次只能监听一个WiFi信道。为了覆盖更广，代码中可能会实现信道切换逻辑，每隔几百毫秒切换一次信道（如1, 6, 11）。扫描间隔（上报数据的频率）也需要平衡：太频繁耗电且产生大量数据，太慢则实时性差。通常5-15秒是一个合理的范围。

4.3 WiFi嗅探回调函数解析

这是整个固件的“心脏”。当WiFi混杂模式启用后，每个捕获到的数据包都会触发此函数。

void promiscuous_callback(uint8_t *buffer, uint16_t length) { // 1. 从buffer中解析出数据帧的帧控制头 // 2. 检查帧类型，我们只关心管理帧（如信标帧、探测请求）或数据帧 // 3. 从帧头中提取源MAC地址（SA） // 4. 从帧头中提取RSSI值（信号强度） // 5. 将提取的MAC地址与我们关注列表中的地址进行比对 // 6. 如果匹配，则更新该MAC地址对应的最新RSSI值和时间戳 }

在这个函数里，我们直接操作原始的802.11数据帧缓冲区。你需要了解基本的WiFi帧结构，特别是如何定位MAC地址字段。网络上有很多开源代码片段（如wifi_promiscuous_pkt_t结构体定义）可以参考。核心技巧：为了提高效率，比对MAC地址时可以使用哈希表或将MAC地址转换为字符串后直接进行字符串比较。由于这个回调函数执行频率极高，其代码必须尽可能高效，避免使用Serial.print等耗时操作。

5. 后端与前端服务搭建实操

5.1 Node.js后端服务配置与运行

后端服务的作用是承上启下，它使用Node.js的mqtt库连接Broker，使用express框架提供REST API。

环境准备：确保你的电脑已安装Node.js（建议使用LTS版本）。在项目根目录的Backend文件夹下，打开终端。
安装依赖：运行npm install。这会根据package.json文件安装所有必需的包，主要是express,mqtt,cors等。

关键配置 (index.js)：打开Backend/index.js文件，找到配置部分，填入与ESP8266固件中完全一致的参数。

const mqttHost = 'broker.hivemq.com'; const mqttPort = 1883; const macTopic = 'myhome/proximity/maclist'; const statusTopic = 'myhome/proximity/status'; // 用于存储设备状态的简单内存对象，生产环境应换为数据库 let deviceStatusMap = {};

MQTT消息处理：后端服务启动后，会连接MQTT Broker并订阅statusTopic。当收到ESP8266发来的状态消息时，会解析JSON，更新deviceStatusMap中对应设备的状态（最后时间、RSSI）。同时，它也订阅macTopic？这里需要厘清：通常，后端是macTopic的发布者。前端通过API添加MAC地址后，后端将其加入列表，并通过MQTT发布到macTopic，ESP8266订阅这个主题从而更新它的本地列表。
REST API设计：后端会暴露几个简单的API端点供前端调用：
- GET /api/devices：获取当前所有被追踪设备的最新状态列表。
- POST /api/devices：前端发送一个{“macAddress”: “AA:BB:CC:DD:EE:FF”}的JSON请求体，后端将其加入追踪列表，并通过MQTT发布新的完整列表到macTopic。
- DELETE /api/devices/:mac：从列表中移除指定设备，并同样更新发布。
启动服务：配置完成后，在Backend目录运行npm start或node index.js。看到“Server started at port 4000”即表示成功。

避坑指南：MQTT连接与重连。在网络不稳定的环境下，后端服务与MQTT Broker的连接也可能中断。一个健壮的后端应该在MQTT客户端的on(‘close’)或on(‘offline’)事件中实现重连逻辑，确保服务持续运行。

5.2 React前端界面构建与交互

前端的作用是提供一个用户友好的管理界面。

安装与启动：进入Frontend目录，运行npm install安装依赖。由于依赖包版本问题，原项目使用了--legacy-peer-deps参数。启动开发服务器使用npm start，默认在http://localhost:3000打开。
界面组件：前端通常包含两个主要部分：
- 设备状态列表：一个表格或卡片列表，每行显示一个设备的MAC地址、最后在线时间、最近一次检测到的RSSI值。这个数据通过周期性地调用后端的GET /api/devices接口获取。
- 添加设备表单：一个输入框和一个按钮，用于输入新的MAC地址，提交时调用后端的POST /api/devices接口。
状态实时更新：为了达到更好的用户体验，前端可以采用两种方式更新状态：
- 短轮询：使用setInterval每隔几秒（如5秒）调用一次后端API获取最新设备状态。实现简单，但有一定延迟和网络开销。
- WebSocket (更优)：后端集成WebSocket服务。当后端从MQTT收到ESP8266的新状态时，除了更新自身内存，还通过WebSocket主动推送给所有已连接的前端页面。这样可以实现真正的实时更新。这需要对后端和前端代码进行更多改造，但体验最佳。
构建与部署：开发完成后，运行npm run build会生成一个优化的、静态的build文件夹。你可以将这个文件夹的内容部署到任何静态网站托管服务（如Netlify, Vercel, Nginx）上。此时前端不再依赖Node.js运行环境。

6. 系统集成测试与故障排查手册

6.1 完整联调步骤

按照以下顺序进行系统联调，可以帮你快速定位问题所在环节：

硬件与基础网络：给NodeMCU上电，打开Arduino IDE的串口监视器（波特率通常为115200）。观察输出，确认ESP8266是否成功连接到你配置的WiFi，并获取到IP地址。这是所有后续步骤的基础。
MQTT连接测试：在串口监视器中，查看ESP8266是否报告成功连接到了你配置的MQTT Broker（如Connected to MQTT Broker!）。同时，你可以在电脑上使用MQTT客户端工具（如MQTTX、Mosquitto自带的mosquitto_sub命令）订阅statusTopic主题。如果ESP8266连接成功并开始发布数据，你应该能在工具中看到JSON格式的消息。
后端服务验证：启动Node.js后端，观察控制台是否有错误。尝试用浏览器或Postman访问http://localhost:4000/api/devices，应该能返回一个空的JSON数组[]（或你预设的初始列表）。尝试用POST方法添加一个测试MAC地址，观察后端控制台是否打印出发布MQTT消息的日志。
ESP8266列表更新：在完成上一步POST操作后，观察ESP8266的串口输出。它应该打印出类似Received new MAC list via MQTT的消息，并列出接收到的MAC地址。这证明“后端->MQTT->ESP8266”这个下行通道是通的。
接近检测触发：将你添加到列表中的那个测试设备（比如你的手机）的WiFi打开，并确保其MAC地址随机化功能已关闭（见下文）。让该设备靠近ESP8266。观察串口输出，应该能看到打印出捕获到该MAC地址及RSSI值的日志。同时，你的MQTT客户端工具应该能收到包含该设备状态的上报消息。
前端界面检查：启动React前端，在浏览器中打开。它应该能显示设备列表（初始为空或包含测试设备）。尝试通过前端界面添加一个新设备，然后重复步骤5，观察前端列表中的“最后在线时间”和“RSSI”是否随之更新。
Ubidots仪表板：登录Ubidots，检查你创建的数据源和设备变量是否收到了数据。创建一个折线图控件，绑定到对应的变量，你应该能看到RSSI值随时间变化的曲线。

6.2 常见问题与解决方案速查表

问题现象	可能原因	排查步骤与解决方案
ESP8266无法连接WiFi	SSID/密码错误；路由器设置限制（如MAC过滤）；信号太弱。	1. 检查代码中SSID/密码大小写和特殊字符。 2. 用手机/电脑确认可连接该WiFi。 3. 将串口波特率设为115200，查看详细错误信息。 4. 尝试将ESP8266靠近路由器。
ESP8266无法连接MQTT Broker	Broker地址/端口错误；网络防火墙阻止；客户端ID冲突。	1. 确认Broker地址和端口（公共Broker如HiveMQ地址正确）。 2. 在电脑上用MQTT客户端工具测试能否连接同一Broker。 3. 在代码中为每个ESP8266设置唯一的`clientId`。
串口显示已连接，但收不到MQTT消息	订阅的主题不匹配；网络不稳定导致短暂断开。	1.仔细核对前后端代码中所有`macTopic`和`statusTopic`的字符串，必须完全一致，包括大小写。 2. 在ESP8266代码中增加连接保持和重连逻辑，并在`loop()`中坚持调用`client.loop()`。
检测不到目标设备	目标设备WiFi关闭；MAC地址随机化开启；设备处于深度休眠；RSSI阈值设置过高。	1.最重要：在目标设备（如iPhone/安卓新版本）的WiFi设置中，对当前网络关闭“私有地址”或“随机MAC”功能。 2. 确保设备WiFi已开启，即使未连接任何网络。 3. 适当降低`RSSI_THRESHOLD`值（如从-65改为-80）进行测试。 4. 在代码中打印所有扫描到的MAC地址，确认是否能看见目标地址。
后端收不到ESP8266数据	MQTT主题发布/订阅关系弄反；后端未正确订阅主题；Broker问题。	1. 确认ESP8266发布到`statusTopic`，后端订阅的是`statusTopic`。 2. 使用MQTT客户端工具同时订阅`statusTopic`，看能否收到数据，以区分是ESP问题还是后端问题。 3. 检查后端MQTT连接和订阅代码，确保在连接成功回调中执行订阅。
前端不更新设备状态	前端API调用地址错误；后端API未正确返回数据；前端轮询逻辑未生效。	1. 打开浏览器开发者工具（F12）的“网络”标签，查看前端对`/api/devices`的请求是否成功，响应是什么。 2. 直接用Postman测试后端API，确认其正常工作。 3. 检查前端JavaScript代码中的轮询间隔或WebSocket连接逻辑。
RGB LED不亮或颜色不对	接线错误（共阴/共阳弄反）；引脚定义错误；电阻未接或损坏。	1. 确认你的RGB LED是共阳还是共阴。本项目默认共阳，长脚接3.3V。如果LED不亮，尝试将长脚接GND（共阴），并修改代码中点亮LED的逻辑（输出高电平点亮）。 2. 用万用表或简单程序测试GPIO引脚是否能正常输出高低电平。 3. 检查电阻是否焊接牢固或接触良好。

6.3 性能优化与扩展思路

降低功耗：ESP8266在持续WiFi嗅探下功耗不低。如果使用电池供电，可以考虑让设备间歇性工作：例如，工作10秒（扫描+上报），然后进入深度睡眠5分钟。这需要连接GPIO16 (D0)到RST引脚来实现定时唤醒。
多设备组网：可以在不同位置部署多个ESP8266探测点，它们都将数据上报到同一个后端。后端综合多个点的RSSI值，可以进行简单的三角定位，更精确地判断设备位置。
状态持久化：目前后端的设备列表和状态存储在内存中，服务重启会丢失。可以集成一个轻量级数据库（如SQLite或Redis）来持久化存储。
添加报警功能：在Ubidots或后端逻辑中，可以设置规则。例如，当某个设备的RSSI值持续低于阈值超过5分钟（表示离开），则触发一个动作，比如发送一封邮件或一个HTTP请求到智能家居平台（如Home Assistant）来关闭房间的灯。
改善前端体验：将RSSI值映射为直观的“信号格”显示；在地图上标记设备的大致位置（如果有多探测点）；添加设备备注名（如“张三的手机”），而不仅仅是显示MAC地址。

这个项目就像一把瑞士军刀，展示了用最简单廉价的硬件解决一个实际感知问题的完整路径。从硬件信号采集、无线通信协议，到后端逻辑处理、前端交互和云端可视化，它触及了物联网开发的多个核心层面。在实际部署中，你可能会遇到各种网络环境和设备兼容性问题，但解决问题的过程本身，就是最宝贵的经验积累。