基于ESP32的智慧卫生间控制器：物联网硬件实战与传感器应用

1. 项目概述：从“智慧”到“务实”的公共卫生间管理

最近在做一个挺有意思的硬件项目，叫“Smart-Restroom Controller”，翻译过来就是“智慧卫生间控制器”。这名字听起来有点高大上，但说白了，它的核心目标非常务实：用一套低成本的硬件方案，解决公共卫生间里那些让人头疼的管理问题。比如，你肯定遇到过商场或高速服务区的卫生间，要么是排长队，要么是某个隔间门锁坏了没人知道，要么是洗手液、纸巾用完了也没人及时补充，清洁状况更是全凭保洁员“感觉”。这个控制器，就是想把这些“感觉”变成“数据”，把“被动响应”变成“主动管理”。

它的核心思路并不复杂，就是通过各种传感器（像人体红外、门磁、液位、气体传感器等）把卫生间里各个关键节点的状态实时采集上来，然后通过一个主控板（也就是这个“Controller”）进行集中处理和判断，最后将数据通过无线网络（比如Wi-Fi、4G Cat.1或NB-IoT）上传到云端或本地服务器。管理人员通过一个后台管理界面或者手机App，就能远程、实时地掌握整个卫生间群的运行状况：哪个蹲位正在使用、哪个空闲了多久、哪个隔间的门锁异常、洗手液余量还剩多少、环境氨气浓度是否超标等等。这样一来，保洁调度可以更精准（只在需要的时候去清洁特定的位置），物料补给可以更及时（避免缺纸的尴尬），设施报修可以更快速（门锁坏了立刻知道），甚至能通过数据分析优化卫生间布局和人流引导。

这个项目之所以值得一做，是因为它踩在了一个很实在的需求点上——提升公共服务的质量和效率。它不追求酷炫的AI识别，而是用稳定可靠的传感器和扎实的嵌入式开发，去解决那些高频发生却又容易被忽视的“小问题”。对于硬件开发者、物联网爱好者或者从事物业、市政相关工作的朋友来说，这是一个能完整串联起传感器技术、嵌入式编程、无线通信和简单后端开发的绝佳练手项目。接下来，我就把自己在设计和实现这个控制器过程中趟过的路、踩过的坑，以及一些关键的思考，详细拆解一遍。

2. 核心需求解析与方案选型

做一个项目，最怕一开始就想得太复杂，或者方向跑偏。对于智慧卫生间控制器，我们必须先抛开“智慧”这个词的光环，回归到卫生间这个具体场景，拆解出最核心、最刚需的几个管理痛点。

2.1 核心管理痛点拆解

首先，从用户（如厕者）和管理者两个角度出发，我们可以梳理出以下几类核心需求：

1. 厕位状态监测与引导：这是最直观的需求。用户需要快速找到空闲厕位，避免盲目排队和尴尬的敲门。管理者需要知道每个厕位的使用频率和时长，用于分析拥堵时段和优化保洁计划。
2. 设施状态监控与预警：包括门锁是否正常锁闭/开启，冲水装置是否工作，洗手池水龙头是否漏水等。提前预警故障，能极大提升用户体验并减少水资源浪费。
3. 耗材余量监测：主要是洗手液、擦手纸、卫生纸的余量。缺纸是卫生间体验最差的情况之一，实现低余量预警，能实现精准补给，避免浪费和缺货。
4. 环境质量监测：包括异味（通常监测氨气、硫化氢等气体浓度）、温湿度、烟雾（防火）。这不仅关乎舒适度，更是健康和安全的要求。异味浓度超标可以自动触发排风扇，烟雾报警则直接关联消防安全。
5. 人流量与保洁监管：统计进入卫生间的人次，结合厕位使用数据，可以科学安排保洁频次。甚至可以配合简单的按钮或二维码，实现“一键报洁”或“保洁打卡”，让保洁工作可量化、可追溯。

2.2 控制器核心功能定义

基于以上痛点，我们的控制器需要具备以下核心功能：

• 多路传感器数据采集与处理：能同时接入并稳定读取多种类型的传感器信号（数字量、模拟量、I2C/SPI总线等）。
• 本地逻辑判断与联动控制：不能完全依赖云端。例如，检测到有人进入厕位且关门后，应能本地联动点亮“有人”指示灯；检测到氨气浓度超标，应能自动启动排风扇。
• 稳定可靠的无线数据传输：将处理后的状态数据、报警信息上传至管理平台。
• 较低的功耗与成本：公共卫生间数量多，部署量大，必须控制单点成本。对于电池供电的传感器节点，低功耗设计是关键。
• 较强的环境适应性：卫生间环境潮湿，可能有腐蚀性气体，设备外壳需要一定的防护等级（如IP65），电路板最好做三防漆处理。

2.3 硬件方案选型背后的思考

明确了需求，就可以开始选型了。这里没有唯一答案，只有更适合当前场景的权衡。

主控芯片（MCU）选型： 这是控制器的大脑。常见的选项有STM32、ESP32、树莓派Pico等。

• STM32（如STM32F103/F4系列）：经典工业级选择，外设丰富，实时性强，可靠性高，但通常需要额外搭配无线通信模块（如Wi-Fi或4G模块），开发门槛稍高，成本也略高。适合对稳定性和实时控制要求极高的项目。
• ESP32系列：这是本项目我最终选择的核心。理由很充分：它集成了双核处理器、Wi-Fi和蓝牙，单芯片解决了通信问题；功耗控制优秀，支持深度睡眠；有丰富的GPIO和ADC，能连接足够多的传感器；社区生态极其庞大，Arduino框架和ESP-IDF框架让开发快速便捷；成本非常有竞争力。对于智慧卫生间这种对实时性要求不是极端苛刻（微秒级），但需要快速联网、快速原型验证的场景，ESP32几乎是首选。
• 树莓派Pico：性价比高，但本身不带无线功能，需要外接模块。其MicroPython生态对初学者友好，但在复杂逻辑和稳定性上，感觉不如ESP32或STM32纯C/C++环境扎实。

注意：选型时一定要考虑采购渠道和长期供货稳定性。ESP32模块（如ESP32-S3）目前货源充足，价格稳定，是稳妥之选。

无线通信方案选型： 数据上传是关键。卫生间通常位于建筑内部，信号环境复杂。

• Wi-Fi：如果卫生间附近有可用的企业级Wi-Fi网络（且能获取接入权限），这是最经济、速率最高的方案。ESP32自带Wi-Fi，可以直接使用。但需考虑Wi-Fi网络的稳定性、覆盖范围以及大量设备接入对路由器的压力。重要心得：务必使用企业级或高性能路由器，并合理设置信道、关闭WMM等功能，以减少干扰和掉线。在代码中必须加入强大的重连机制和心跳包。
• 4G Cat.1：在无Wi-Fi覆盖或Wi-Fi不稳定的场景（如高速服务区、公园），Cat.1是完美选择。它比传统的4G全功能模块便宜，比NB-IoT速率快，支持TCP/IP协议栈，可以直接socket编程，网络延迟和可靠性远胜NB-IoT。通过串口连接一个Cat.1模块（如移远EC200S、合宙Air724）到ESP32，即可实现。缺点是会产生SIM卡流量费用。
• NB-IoT：超低功耗，广覆盖，适合那些数据量极小、更新频率低（如一天报几次耗材余量）且对延迟不敏感的场景。但对于需要实时显示厕位状态（变化可能在几秒内）的需求，NB-IoT的延迟和功耗在频繁上报时并无优势，反而可能因为PSM、eDRX等机制导致数据延迟。个人建议：智慧卫生间场景下，除非只做纯环境监测，否则优先考虑Wi-Fi或Cat.1。

传感器选型清单与接口：

• 厕位占用：人体红外热释电传感器（HC-SR501）。安装在天花板斜对厕位门或隔间内上方，检测人体移动。成本低，但存在静止时检测不到的盲区。更可靠的方案是门磁传感器（干簧管+磁铁）结合超声波或毫米波雷达传感器。雷达传感器（如LD2410）可以检测静止人体，精度高，但成本也高。折中方案：门磁 + HC-SR501。关门且检测到人体移动则判为“有人”；关门但无人移动超时（如10分钟）则报警“可能异常”；开门则判为“无人”。
• 耗材余量：超声波测距模块（HC-SR04）或压力传感器。将超声波模块固定在洗手液瓶、纸盒上方，测量液面/纸面高度，换算余量。这是非接触式测量，避免污染。需要注意容器形状对声波反射的影响，最好在容器内壁加装导波管。
• 环境气体：MQ-135模拟气体传感器。它对氨气、硫化氢、苯等多种气体有响应，常用于空气质量定性检测。通过ESP32的ADC读取其电压值，设定阈值判断异味等级。注意，这类传感器需要预热稳定，且受温湿度影响大，需要定期校准或采用温湿度补偿算法。更高精度可选电化学传感器，但价格昂贵。
• 温湿度：DHT22或SHT30。SHT30精度更高，采用I2C接口，更推荐。
• 水浸/漏水：水浸传感器，输出开关量信号，安装在地漏附近。

电源设计： 控制器通常部署在吊顶内或设备间，有条件接220V市电。推荐使用高品质的5V或12V开关电源适配器，然后通过DC-DC降压模块（如LM2596）或LDO（如AMS1117-3.3）为ESP32和传感器提供稳定的3.3V电源。千万注意：ESP32的供电必须稳定，电压跌落极易导致重启。传感器如果工作电压是5V，需要注意与ESP32（3.3V GPIO）的电平转换。

3. 系统架构设计与通信协议

一个可靠的系统，光有硬件堆砌不够，必须有清晰的软件架构和稳定的通信协议作为骨架。

3.1 整体系统架构

我设计的系统采用分层架构，分为终端层、网络层、平台层和应用层。

1. 终端层：即部署在每个卫生间的“Smart-Restroom Controller”硬件主体，以及分布在各个厕位、洗手池的传感器子节点。为了简化布线，传感器尽量通过导线直接连接主控制器（ESP32）。对于距离较远的传感器，可以考虑用RS-485总线串联，或者用433MHz/LoRa无线模块做子节点，但这样会增加复杂性和成本。本项目为求稳定和简单，采用有线直连。
2. 网络层：控制器通过内置Wi-Fi或外接Cat.1模块，接入互联网。我强烈建议在代码中实现双网络链路备份（如果硬件支持）：优先使用Wi-Fi，当Wi-Fi连续多次连接失败时，自动切换至Cat.1网络。这能极大提升系统的在线率。
3. 平台层：即云端服务器或本地服务器。负责接收、存储所有控制器上报的数据，并提供WebSocket或HTTP API供前端调用。可以选择自建服务器（用Node.js、Python Django/Flask等），也可以使用现成的物联网平台（如阿里云物联网平台、ThingsBoard开源平台）。使用公有云平台能快速搭建，省去服务器运维的麻烦，但可能有数据安全和长期费用考量。
4. 应用层：包括Web管理后台和移动端App。后台用于物业人员查看所有卫生间状态、接收报警、管理设备。App可以提供给保洁人员，接收具体的保洁任务推送。数据展示的核心是一张平面图，上面实时显示每个厕位、每个洗手池、每个耗材点的状态（用红绿黄等颜色标识）。

3.2 上下行通信协议设计

协议是设备与平台对话的语言。必须简单、高效、易于解析。

上行数据（设备->平台）： 采用JSON格式，通过MQTT协议发布到指定主题，或者通过HTTP POST发送到API接口。MQTT更适合实时性要求高的场景（如状态变化立即上报），且更省电。

一个典型的上行数据包示例：

{ "device_id": "restroom_001_controller_01", "timestamp": 1717589123, "data": { "toilet_stalls": [ {"id": 1, "occupied": true, "door_locked": true, "duration": 120}, {"id": 2, "occupied": false, "door_locked": false, "duration": 0} ], "consumables": { "soap_1": {"level": 65, "alert": false}, "paper_towel_1": {"level": 20, "alert": true} }, "environment": { "temperature": 26.5, "humidity": 55, "nh3_concentration": 12 }, "alerts": ["paper_towel_1_low"] } }

• device_id：设备唯一标识。
• timestamp：数据采集的Unix时间戳。
• data：包含所有传感器数据的分组。
• alerts：当前活动的报警列表。

下行指令（平台->设备）： 同样使用JSON，通过MQTT订阅或HTTP响应下发。例如：

{ "cmd": "set_relay", "params": {"relay_id": 1, "state": "on"} }

用于远程控制排风扇、照明等继电器设备。

心跳与保活： 设备必须定时（如每60秒）向平台发送心跳包，内容可以很简单，只包含设备ID和在线状态。平台侧根据心跳判断设备是否离线。ESP32在Wi-Fi断开时，要有自动重连逻辑，并尝试恢复MQTT连接。

3.3 本地联动逻辑设计

网络不可能100%可靠，因此本地自治能力很重要。这部分逻辑在ESP32上实现。

例如，一个简单的本地联动流程：

1. 门磁传感器检测到门关闭（door_closed == true）。
2. 人体红外传感器在随后3秒内检测到移动（motion_detected == true）。
3. ESP32立即控制该厕位门口的“有人”指示灯亮起（通过GPIO控制一个LED），并将“占用”状态标记。
4. 同时，启动一个定时器。如果门一直关闭，但人体红外在连续15分钟内再无任何触发，则ESP32本地触发一个“异常占用”报警（通过蜂鸣器或指示灯闪烁），并尝试将这条报警信息优先上报给平台。
5. 当门磁检测到门打开时，立即熄灭“有人”指示灯，重置定时器，并将状态改为“空闲”。

这套逻辑完全在本地运行，即使网络暂时中断，也能保证基本的指示功能。网络恢复后，再将最终的状态同步到平台。

4. 硬件电路设计与PCB布局要点

有了方案，就要动手画板子了。硬件设计是稳定性的基石。

4.1 核心电路设计

1. 电源电路：输入可能是12V DC。首先经过一个防反接二极管（如1N4007），防止电源接反烧毁。然后使用DC-DC降压芯片（如MP1584EN）将12V降至5V，给部分5V传感器供电。再用一颗LDO（如AMS1117-3.3）将5V转为3.3V，给ESP32和3.3V传感器供电。在每级电源的输入输出端，都要并联足够的滤波电容（如10uF电解电容 + 0.1uF陶瓷电容），以滤除纹波。
2. ESP32最小系统：包括使能引脚（EN）的上拉电阻和复位按钮，以及电源去耦电容（通常每个电源引脚附近放一个0.1uF电容）。特别重要：ESP32的射频性能对电源纹波非常敏感，必须保证3.3V电源干净、稳定。如果使用外部天线，记得设计天线匹配电路和馈线接口（如IPEX座子）。
3. 传感器接口电路：
   • 数字输入：如门磁、水浸传感器。直接连接GPIO，但一定要加上拉或下拉电阻（通常10kΩ），确保在传感器开路时GPIO处于确定状态。为了防静电和过压，可以在GPIO入口串联一个100-500Ω电阻，并并联一个TVS管到地。
   • 模拟输入：如MQ-135气体传感器。连接ESP32的ADC引脚（如GPIO32）。ADC引脚非常脆弱，必须在信号线靠近ESP32端加一个RC低通滤波（如1kΩ电阻串联，对地接一个0.1uF电容），滤除高频噪声。ADC的参考电压要稳定，可以使用ESP32内部的VREF，但更推荐使用一个精密基准电压源。
   • I2C总线：连接SHT30等传感器。SCL和SDA线上都必须有上拉电阻（通常4.7kΩ），即使传感器模块本身带了，在主板上也最好预留位置。总线走线尽量短。
4. 执行器驱动电路：控制“有人”指示灯、排风扇继电器等。ESP32的GPIO驱动能力有限（通常12mA），不能直接驱动继电器或大功率LED。必须使用三极管（如S8050）或MOS管（如SI2302）作为开关驱动。驱动继电器时，必须在继电器线圈两端反向并联一个续流二极管（如1N4148），防止关断时产生的反向电动势击穿三极管。
5. 通信接口：如果使用外置4G Cat.1模块，通常通过UART串口连接。注意电平匹配（通常是3.3V TTL）。为防干扰，可以在UART的TX、RX线上串联小电阻（如22Ω）。

4.2 PCB布局与布线注意事项

1. 分区布局：将板子划分为电源区、数字区、模拟区、射频区。电源模块（特别是DC-DC）远离模拟和射频部分。
2. 电源路径：电源走线要宽，形成“星型”或“树干型”拓扑，避免数字电路的大电流波动影响模拟电路供电。地平面要完整，特别是ESP32下方，需要保持完整的地平面作为射频地。
3. 射频部分：这是ESP32 PCB设计的重中之重。天线周围（包括天线馈线）必须净空，即所有层（包括丝印层）都不要走线或覆铜，保持一个干净的扇形区域。天线匹配元件（电感电容）必须严格按照芯片手册的推荐值和布局要求放置，尽量靠近芯片的RF引脚。晶振及其负载电容必须紧靠芯片相关引脚，下方不要走线。
4. 传感器走线：模拟信号线尽量短，并用地线包裹或与数字信号线隔离。I2C等总线走线等长不是必须，但尽量短且粗。
5. 过孔与敷铜：适当使用过孔连接多层板的地平面。敷铜时使用网格状敷铜（Grid Pour）而非实心敷铜，有利于PCB加工时的散热均匀和减少翘曲。

实操心得：第一次打样，不妨把ESP32核心部分做成一个可插拔的模块（比如使用邮票孔或连接器），这样即使射频部分没调好，或者ESP32烧了，可以只更换模块，不用重做整板。另外，所有外部接口（电源、传感器、通信）最好都加上ESD保护器件（如TVS阵列），卫生间的环境可能存在静电风险。

5. 嵌入式软件设计与关键代码实现

硬件是躯体，软件是灵魂。ESP32的编程，我选择使用Arduino框架，因为它生态丰富，开发速度快。对于更复杂的项目，ESP-IDF（官方IoT开发框架）能提供更精细的控制。

5.1 软件整体框架

程序采用“状态机” + “事件驱动”的思想，避免使用delay()进行阻塞，保证系统能及时响应各种传感器事件和网络事件。

// 伪代码框架示意 #include <WiFi.h> #include <PubSubClient.h> // MQTT客户端库 #include <ArduinoJson.h> // 定义全局状态结构体 struct ToiletStall { int id; bool doorClosed; bool motionDetected; bool occupied; unsigned long occupiedStartTime; bool alertTimeout; }; ToiletStall stalls[4]; // 网络相关对象 WiFiClient wifiClient; PubSubClient mqttClient(wifiClient); void setup() { Serial.begin(115200); initGPIO(); // 初始化所有GPIO引脚模式 initSensors(); // 初始化传感器（如I2C） connectToWiFi(); setupMQTT(); // 配置硬件定时器，用于定时扫描和心跳 setupHardwareTimer(); } void loop() { // 1. 处理网络事件（非阻塞） if (!mqttClient.connected()) { reconnectMQTT(); } mqttClient.loop(); // 2. 检查传感器状态变化（事件驱动） checkDoorSensors(); // 读取门磁，如有变化触发事件处理函数 checkMotionSensors(); checkAnalogSensors(); // 读取气体、超声波等模拟量 // 3. 执行本地状态机逻辑 updateStallStateMachine(); // 4. 定时任务（由硬件定时器中断触发标志位） if (heartbeatFlag) { sendHeartbeat(); heartbeatFlag = false; } if (uploadDataFlag) { uploadSensorData(); uploadDataFlag = false; } // 5. 低功耗处理（如果需要） // 在无事件处理时，可以调用 delay(10) 或进入 light-sleep }

5.2 关键功能模块实现

1. 厕位状态判断逻辑：这是核心逻辑，要避免误判（如人不动就判为空）和漏判。

void updateStallState(int stallIndex) { ToiletStall &s = stalls[stallIndex]; bool currentDoorClosed = digitalRead(doorPin[stallIndex]) == DOOR_CLOSED_LOGIC; bool currentMotion = digitalRead(motionPin[stallIndex]) == MOTION_LOGIC; // 事件：门关上了 if (currentDoorClosed && !s.doorClosed) { s.doorClosed = true; s.occupiedStartTime = millis(); // 启动一个“等待移动”的宽容期，比如3秒 s.waitingForMotion = true; s.motionGracePeriodStart = millis(); } // 事件：门打开了 else if (!currentDoorClosed && s.doorClosed) { s.doorClosed = false; s.occupied = false; s.alertTimeout = false; digitalWrite(occupiedLedPin[stallIndex], LED_OFF); // 上报状态：空闲 publishStallStatus(stallIndex); } // 在门关闭状态下，检测到移动 if (s.doorClosed && currentMotion) { s.motionDetected = true; s.waitingForMotion = false; // 取消等待期 if (!s.occupied) { s.occupied = true; digitalWrite(occupiedLedPin[stallIndex], LED_ON); // 上报状态：占用 publishStallStatus(stallIndex); } s.lastMotionTime = millis(); // 更新最后活动时间 } // 状态机检查：门关着，但人可能不动了 if (s.doorClosed && s.occupied) { unsigned long idleTime = millis() - s.lastMotionTime; if (idleTime > OCCUPIED_TIMEOUT_MS) { // 例如15分钟 // 可能发生异常（如晕倒、设备遗留），触发本地报警 if (!s.alertTimeout) { s.alertTimeout = true; triggerLocalAlert(stallIndex); publishAlert(stallIndex, "occupancy_timeout"); } } } // 检查“等待移动”宽容期是否超时 if (s.waitingForMotion && (millis() - s.motionGracePeriodStart > MOTION_GRACE_PERIOD_MS)) { s.waitingForMotion = false; // 门关了但一直没检测到移动，可能是误关门或清洁状态，不标记为占用 // 可以上报一个“门关闭但无人”的特殊状态 } }

2. 稳定的Wi-Fi与MQTT连接：网络稳定性是物联网设备的命门。

void connectToWiFi() { WiFi.mode(WIFI_STA); WiFi.setAutoReconnect(true); WiFi.persistent(true); // 尝试连接，并设置超时 WiFi.begin(ssid, password); int retries = 0; while (WiFi.status() != WL_CONNECTED && retries < 30) { // 最多尝试30次，约15秒 delay(500); Serial.print("."); retries++; } if (WiFi.status() == WL_CONNECTED) { Serial.println("\nWiFi Connected."); Serial.print("IP: "); Serial.println(WiFi.localIP()); } else { Serial.println("\nWiFi FAILED."); // 可以在这里触发切换到4G备份网络的逻辑 } } void setupMQTT() { mqttClient.setServer(mqtt_server, 1883); mqttClient.setCallback(mqttCallback); // 设置接收消息的回调函数 mqttClient.setBufferSize(1024); // 根据消息大小调整缓冲区 mqttClient.setKeepAlive(60); // 保持连接心跳 } void reconnectMQTT() { while (!mqttClient.connected()) { Serial.print("Attempting MQTT connection..."); String clientId = "ESP32Client-" + String(random(0xffff), HEX); if (mqttClient.connect(clientId.c_str(), mqtt_user, mqtt_password)) { Serial.println("connected"); mqttClient.subscribe("cmd/restroom_001/#"); // 订阅控制命令主题 } else { Serial.print("failed, rc="); Serial.print(mqttClient.state()); Serial.println(" try again in 5 seconds"); delay(5000); } } }

3. 传感器数据读取与滤波：传感器数据常有噪声，需要软件滤波。

// 用于模拟量（如气体传感器）的滑动平均滤波 #define FILTER_SIZE 10 int analogFilterBuffer[FILTER_SIZE]; int filterIndex = 0; int readFilteredAnalog(int pin) { analogFilterBuffer[filterIndex] = analogRead(pin); filterIndex = (filterIndex + 1) % FILTER_SIZE; long sum = 0; for (int i = 0; i < FILTER_SIZE; i++) { sum += analogFilterBuffer[i]; } return sum / FILTER_SIZE; } // 读取超声波传感器距离（HC-SR04） long readUltrasonicDistance(int trigPin, int echoPin) { digitalWrite(trigPin, LOW); delayMicroseconds(2); digitalWrite(trigPin, HIGH); delayMicroseconds(10); digitalWrite(trigPin, LOW); long duration = pulseIn(echoPin, HIGH, 30000); // 超时30ms // 计算距离（声速340m/s），单位厘米 long distance = duration * 0.034 / 2; if (distance == 0 || distance > 500) { // 超出量程或无效值 return -1; } return distance; }

6. 云端平台搭建与数据可视化简易方案

对于个人项目或小规模部署，完全自建服务器可能负担较重。这里推荐两个快速上手的方案。

方案一：使用开源物联网平台ThingsBoard（推荐）ThingsBoard功能强大，支持设备管理、数据可视化、规则链（联动报警）、租户管理，而且社区版免费。

1. 部署：可以按照官方文档，在Linux服务器上用Docker快速部署。
2. 设备接入：在ThingsBoard创建设备，获取设备访问令牌（Access Token）。
3. ESP32端：使用PubSubClient库，以MQTT方式，用该令牌作为用户名（密码为空）连接到ThingsBoard的MQTT broker。上传数据的主题格式为v1/devices/me/telemetry， payload就是之前定义的JSON数据。
4. 仪表盘：在ThingsBoard的Dashboard里，可以轻松拖拽部件（Widget），比如用“实体别名”绑定到你的设备，然后用“最新值”部件显示厕位状态，用“图表”部件显示历史气体浓度，用“报警”部件显示当前报警。可以做出非常专业的可视化界面。

方案二：使用云服务商物联网平台（如阿里云物联网平台）各大云厂商都有成熟的物联网平台，提供从设备接入、管理、到数据分析的全套服务，通常有一定免费额度。

1. 创建产品与设备：在阿里云物联网平台创建一个“智慧卫生间控制器”产品，定义好物模型（即数据格式，相当于JSON的schema）。然后创建设备，获取三元组（ProductKey, DeviceName, DeviceSecret）。
2. ESP32端：使用阿里云提供的IoT Device SDK for C，或者按照其MQTT协议规范，用PubSubClient库自行实现连接和数据上报。需要根据三元组计算MQTT连接参数，稍微复杂一点，但官方有详细示例。
3. 数据流转：平台收到数据后，可以通过规则引擎将数据转发到你的自有服务器，或者直接使用平台提供的“数据可视化”功能（DataV）制作大屏。

方案三：极简自建（用于原型验证）如果你只想快速看到数据，可以用Python Flask搭建一个简单的HTTP服务器。

1. 服务器端（Python Flask）：

   from flask import Flask, request, jsonify app = Flask(__name__) @app.route('/upload', methods=['POST']) def upload_data(): data = request.json device_id = data.get('device_id') # 将data存入数据库（如SQLite）或直接打印 print(f"Data from {device_id}: {data}") return jsonify({"status": "ok"}) if __name__ == '__main__': app.run(host='0.0.0.0', port=5000)

2. ESP32端：使用HTTPClient库，将JSON数据POST到服务器的http://你的服务器IP:5000/upload地址。
3. 前端：可以再写一个简单的HTML页面，用JavaScript定时轮询服务器获取最新数据，并更新页面显示。这种方法最简单，但功能也最有限，不适合生产环境。

7. 实地部署、调试与避坑指南

实验室里跑得顺，不等于现场能稳定。卫生间环境是真正的试金石。

7.1 部署安装要点

1. 设备安装位置：主控制器应安装在吊顶内通风、干燥、便于接电和接网线（如果走有线网络）的位置。传感器走线尽量穿管，避免裸露。
2. 传感器安装：
   • 人体红外：安装角度要能覆盖厕位内大部分区域，避免正对门口或排风扇，防止因空气流动导致误触发。调整好延时和灵敏度旋钮。
   • 门磁：磁铁和干簧管对齐要精确，间隙尽量小（1-2mm内），确保关门时能可靠触发。
   • 超声波测距（用于耗材）：安装要垂直向下，下方测量区域避免有障碍物。对于液体，容器表面可能不平，最好取多次测量平均值。
   • 气体传感器：不要安装在正对排风扇出口或门窗风口的位置，避免测量值失真。应安装在能代表卫生间中间区域空气状况的位置，离地1.5米左右。
3. 供电与接地：务必使用稳定的开关电源。如果从卫生间照明电路取电，注意区分零火线，做好绝缘。设备外壳如果金属，应可靠接地。

7.2 现场调试与问题排查

这是最考验人的环节。准备好万用表、串口调试工具和耐心。

问题1：ESP32不断重启。

• 可能原因：电源功率不足或电压跌落。ESP32在发射Wi-Fi信号时瞬时电流可达500mA。
• 排查：用万用表测量3.3V电源引脚，在ESP32启动和Wi-Fi连接时观察电压是否跌落到3.0V以下。如果是，检查前级DC-DC或LDO的输入输出电容是否足够，线径是否太细。
• 解决：更换输出电流更大的电源模块（如1A以上），加大电源滤波电容，缩短电源走线。

问题2：Wi-Fi连接不稳定，经常断线。

• 可能原因：卫生间位置信号弱；2.4G频段干扰严重（蓝牙、微波炉、其他Wi-Fi）；ESP32射频电路布局不佳。
• 排查：用手机在设备安装点测试Wi-Fi信号强度。查看路由器后台，检查信道拥堵情况。
• 解决：
  • 调整路由器天线方向或增加AP。
  • 将路由器信道固定在1、6、11这三个互不干扰的信道之一。
  • 在ESP32代码中增加Wi-Fi断开重连机制，并尝试降低Wi-Fi发射功率（WiFi.setTxPower(WIFI_POWER_19_5dBm)）有时反而能提高稳定性。
  • 检查PCB天线区域是否被金属物体遮挡。

问题3：传感器数据跳动大，误报多。

• 可能原因：电源噪声、信号干扰、传感器本身不稳定、判断逻辑阈值不合理。
• 排查：
  • 模拟量：用示波器或ADC连续读取查看波形。
  • 数字量：检查上拉/下拉电阻，用逻辑分析仪抓取信号。
• 解决：
  • 加强软件滤波（如中位值平均滤波、卡尔曼滤波）。
  • 优化硬件滤波电路（RC滤波）。
  • 调整传感器判断的延时和阈值，加入“去抖动”逻辑。例如，门磁状态变化后，延迟50ms再读取，如果状态稳定才确认。

问题4：MQTT消息发送失败或延迟大。

• 可能原因：网络延迟；MQTT服务器性能；客户端缓冲区不足；代码中mqttClient.loop()调用不及时。
• 排查：在服务器端查看连接和消息日志。在ESP32端打印MQTT状态码。
• 解决：
  • 确保loop()函数在main loop中频繁被调用。
  • 增大PubSubClient的缓冲区大小（setBufferSize）。
  • 对于非紧急数据，可以采用批量上报或定时上报，减少连接压力。
  • 使用QoS 0（最多一次）而非QoS 1（至少一次），以提升速度，对状态数据可接受少量丢失。

问题5：设备在无人时，偶尔误报“有人”。

• 可能原因：人体红外被飞虫、飘动的织物或温度变化触发；雷达传感器被水管振动或通风气流干扰。
• 解决：
  • 清洁传感器透镜。
  • 调整传感器灵敏度，降低增益。
  • 在软件逻辑中增加“持续触发时间”判断，例如，只有连续检测到移动超过2秒，才判定为有效事件。对于雷达，可以设置合适的静止超时时间和存在阈值。

7.3 长期维护与优化

1. 固件远程升级（OTA）：务必实现OTA功能。可以通过HTTP服务器或MQTT下发固件链接，让设备自行下载更新。这是后期修复bug、升级功能的生命线。
2. 配置参数云端可调：将判断超时时间（如占用超时15分钟）、报警阈值（如气体浓度阈值）等参数设计为可通过云端下发配置，这样无需现场刷机就能调整设备行为。
3. 增加设备自检与诊断：设备上电时，可以自动检测关键传感器是否连接正常（如读取I2C设备地址），并将自检结果上报。定期上报设备运行时长、内存剩余量等信息。
4. 数据本地缓存与断点续传：在网络中断时，将重要报警和状态变化数据暂存到SPIFFS文件系统或EEPROM中，待网络恢复后补发。

做这样一个项目，从需求分析、方案选型、画板打样、焊接调试、代码编写、云端对接，到最后现场安装和问题排查，是一个完整的闭环。它不仅仅是一个“控制器”，更是一套针对特定场景的物联网解决方案。过程中你会遇到无数细节问题，每一个问题的解决都是经验的积累。最终，当你看到管理后台上一个个卫生间的状态清晰可见，报警信息及时弹出，保洁人员的工作因你的设备而变得更高效时，那种成就感是实实在在的。这个项目涉及的技术点很广，可以作为嵌入式物联网入门到进阶的一个非常好的综合实践。