基于ESP32的鱼缸智能监控系统：GitHub项目dz-1032完整实战

做过物联网或者嵌入式DIY的朋友应该都有这种感觉：真正难的不是写代码，而是把一堆传感器、执行机构、通信协议组合成一个能持续稳定运行的小系统。这个代号为“dz-1032”的鱼缸智能监控系统，恰好就是这样一个足够典型、又足够落地的项目。它把水温检测、水位预警、灯光控制、远程告警全部装进一个常规尺寸的鱼缸里，花两周业余时间就能跑通。这篇文章就按这个项目的完整落地过程展开，从需求拆解到硬件选型，从接线到代码，最后是实际调试现场和踩坑记录。不论你是想给家里的鱼缸加装一套监控，还是准备做类似的物联网课程设计，这套思路都能直接复制。

1. 鱼缸监控到底要管什么：先从养鱼翻缸的教训说起

项目立项之前，我先盘了一遍日常养鱼最让人焦虑的几个场景：出差三天回来发现加热棒坏了，水温掉到二十度以下；夏天蒸发量大，水位降到水泵空转；喂食时间不固定，要么饿着要么猛喂坏水。这几件事单独看都不大，但凑在一起就足以毁掉一缸状态不错的鱼。所以“dz-1032”要解决的，其实不是某一个单一指标，而是把鱼缸变成一套可以被实时观测、自动干预的环境系统。

1.1 监控对象与优先级划分

一个合格的鱼缸监控系统，监控对象要分优先级。水温排在第一位，因为绝大多数热带鱼对环境温度突变极其敏感，温度波动超过两三度就可能引发白点病或者拒食。水位排在第二位，蒸发和过滤溅水都会让水位持续下降，轻则影响过滤效率，重则让水泵空转烧毁。再往后是pH值和水体浑浊度，这两个参数变化慢，但长期偏离正常范围往往意味着硝化系统出了问题。最后才是灯光和喂食，它们不是“监控”对象，更多是“控制”对象。

这个优先级直接影响后续设计和开发顺序。我在这个项目里把监控通道分成了两层：第一层是安全层，包含水温、水位、设备运行状态，任何一项异常都立即触发告警；第二层是健康层，包含pH、光照周期、喂食日程，主要用于日常管理和趋势记录。先保证安全层可靠稳定，再谈健康层的数据分析。这样做的好处是，即使健康层传感器出现漂移，也不会影响系统最核心的保护功能。

1.2 技术方案选型：为什么不是树莓派也不是裸Arduino

确定了监控范围，接下来就是选型。这套系统需要一个能联网的主控、一组合适的传感器，以及对应的执行机构。很多初学朋友第一反应是用树莓派，觉得性能强、能跑Python，但实际做下来会发现，树莓派在鱼缸这种环境里杀鸡用牛刀，而且24小时通电的功耗高，断电恢复也不够可靠。另一头，传统的Arduino Uno虽然稳定，但没有网络能力，ESP8266又只有单核和较少的IO口，做多路传感器加本地控制比较吃力。

所以这个项目我选了ESP32作为主控。原因不复杂：双核处理器能同时跑传感器轮询和网络协议栈；自带WiFi和蓝牙，不用外接模块；ADC精度够用，可以直连pH传感器和TDS传感器的模拟输出；支持深度睡眠，后续做低功耗版本也方便。更重要的是它在电商平台上方案成熟、资料多，遇到问题几乎都能搜到别人踩坑的记录。从综合成本看，用ESP32比用树莓派加一堆外设便宜得多，可靠性和IO数量又比Arduino Uno合适。

2. 硬件选型与关键参数实测：哪些传感器值得买，哪些是花架子

选型决定下限。传感器选对了，后面写代码和调试都很顺；选错了，轻则数据漂移，重则直接烧毁主控。这一部分我直接把每个器件的实际使用体感写出来，包括哪些模块可以闭眼买、哪些必须加外围电路、哪些项目里干脆不用。

2.1 主控之外的硬件清单

“dz-1032”的完整硬件清单大概是这样的：ESP32开发板、DS18B20防水温度探头、超声波水位传感器、pH值检测模块、浊度传感器、继电器模块、可控硅调压模块、LED灯条、步进电机喂食器、直流气泵、12V适配器、降压模块、若干NPN三极管和电阻。

DS18B20水温测量是这条链路里最稳的一环。它的数字单总线协议抗干扰能力本来就比模拟温度传感器强，配合防水不锈钢探头可以直接泡在水里使用。接线只需一个4.7kΩ上拉电阻，读取精度在±0.5°C以内。需要特别提醒的是，买探头时认准“防水”款式，普通塑料封装版本只能在干燥环境工作，泡水里几小时就可能进水短路。

水位传感器是这个项目里纠结最久的部分。浮球开关虽然便宜，但无法获得连续水位数据，只能知道“到达了某个点”，不利于观察蒸发趋势。非接触式超声波模块能测连续距离，安装时从缸顶向下测量水面距离即可，但要注意鱼缸拉筋、灯架都会产生超声波反射干扰。最后我采用的是浮球开关做低水位硬保护，再用超声波模块做连续水位监测，两者冗余互补。实际下来，浮球开关是第一道防线，即使超声波数据漂移，浮球依然能触发断电保护。

2.2 水质传感器的适配问题

pH传感器建议购买带变送板的模块，配合玻璃电极探头使用，模拟输出经ADC采集后换算成pH值。这里有两个坑：一是玻璃电极需要定期校准，两周一次用校准液重新标定；二是电极不能干放，不用时要泡在保护液里。很多文件系统项目一开始pH读数漂到离谱，十有八九是电极保存方式不对。

浑浊度传感器很多新手看到会特别兴奋，觉得“能检测水体脏不脏，太好了”。但这东西在鱼缸里的实际表现挺尴尬的。它的原理是光穿透，容易受气泡、鱼排便、水草碎片干扰，读数毛刺多。持续监测浑浊度的绝对值意义不大，更靠谱的办法是检测浑浊度传感器输出的相对变化趋势。所以在这个项目中，我把浑浊度传感器定位成“换水提醒器”而不是精确仪表：设定一个基线值，读数持续上升超过20%就提示该换水了，而不是报告具体NTU数值。

3. 电路连接与程序实现：一份能跑起来的完整方案

硬件选好之后，真正让系统运转起来的是接线和代码。这一部分我给出引脚规划、接线要点和核心代码框架。代码直接用Arduino框架编写，便于在ESP32上编译和烧录。

3.1 引脚规划与接线要点

下面是我在“dz-1032”中使用的最终引脚分配表，直接照抄也可以跑通：

接线上有几个必须注意的细节。第一，继电器和可控硅这类开关型执行机构的电源，一定要和主控逻辑电源分开。我的做法是12V适配器供给泵和加热棒，经过降压模块输出5V供给主控和传感器，再经稳压至3.3V供给pH模块。这样即便泵启动瞬间拉低电压，主控也不会被复位。第二，继电器线圈两端必须并接续流二极管，否则断电瞬间的感应电动势很可能击穿主控GPIO口。第三，超声波模块Echo脚输出5V高电平，直接接到ESP32的3.3V GPIO上有烧毁风险，串联一个1kΩ电阻加3.3V钳位是标准做法。

3.2 主控程序框架：采集、控制、上报三件事

整个程序的核心是状态机轮询，结构分成三块：传感器数据采集、执行机构控制逻辑、数据上报与告警。程序启动后先初始化各类外设，接着在主循环里依次执行这三块逻辑。

采集部分的重点是滤波。水温这种变化缓慢的量，用简单的中值滤波就能消除毛刺：连续采集五次，取中间值作为结果。pH值读取则用滑动平均滤波，避免信号线受电磁干扰产生的跳变。

温度读取代码的基本框架如下：

#include <OneWire.h> #include <DallasTemperature.h> #define ONE_WIRE_BUS 4 OneWire oneWire(ONE_WIRE_BUS); DallasTemperature sensors(&oneWire); float readWaterTemperature() { sensors.requestTemperatures(); float raw = sensors.getTempCByIndex(0); if (raw <= -20 || raw > 60) { return -1; // 传感器异常，返回-1交给上层处理 } return raw; }

这里加了一个异常值判断。DS18B20在某些接触不良场景下会返回-127，如果没有边界过滤，这个错误值会导致后续加热逻辑误判。例如水温实际26°C，读数突然变成-127，控制系统会理解为“水温极低”，从而启动加热棒持续加热，直到把一缸鱼煮熟。所以任何传感器数据进入控制逻辑前，都必须经过合法范围校验。

3.3 控制逻辑：滞回与互锁

温度控制这里我不建议用“低于目标温度就开启加热棒”这种简单方式，因为继电器会在温度阈值附近频繁切换，加热棒触点寿命和电磁干扰都不好。正确做法是滞回控制：例如目标26°C，低于25.5°C时开启加热，高于26.5°C时关闭加热，中间的温度区间不动作。这样加热棒一天只通断几次，稳定性和寿命都大幅提升。

控制逻辑实现的核心片段：

#define TEMP_TARGET 26.0 #define TEMP_HYST_LOW 25.5 #define TEMP_HYST_HIGH 26.5 bool heaterOn = false; void updateHeater(float currentTemp) { if (!heaterOn && currentTemp < TEMP_HYST_LOW) { heaterOn = true; digitalWrite(HEATER_PIN, HIGH); } else if (heaterOn && currentTemp > TEMP_HYST_HIGH) { heaterOn = false; digitalWrite(HEATER_PIN, LOW); } }

互锁逻辑同样重要。加热棒通电时，如果水泵断电，热量无法随水流扩散，加热棒周围水温会局部过热。所以代码中水泵继电器在正常状态下必须常开，只有在换水维护、缸内水位过低时才允许断开水泵。我设定了水位硬保护逻辑：浮球开关给出低水位信号后，强制关闭加热棒和灯条，仅保留水泵短时运行，避免干烧。

3.4 数据上报与远程告警

数据上报我使用了MQTT协议，自建的本地MQTT服务作为中间层，同时接一个公网物联网平台的免费实例用于云端推送通知。这样做的好处是，局域网内操作延迟低，公网平台则负责在手机App上实时显示数据。代码结构如下：

#include <WiFi.h> #include <PubSubClient.h> WiFiClient espClient; PubSubClient mqttClient(espClient); void publishData() { StaticJsonDocument<256> doc; doc["temp"] = currentTemp; doc["ph"] = currentPh; doc["level"] = waterLevelPercent; char buffer[256]; serializeJson(doc, buffer); mqttClient.publish("home/fish_tank/status", buffer); }

告警逻辑在本地也可以直接执行，不依赖云服务。我在程序里维护了一张异常状态枚举表，任何一个参数越界时触发蜂鸣器，并在OLED屏幕上显示对应代码。远程通知则通过两套渠道同时推送：MQTT消息附带告警字段，云端规则引擎解析后推给手机；另外再接一个极简的局域网HTTP通知接口，方便内网调试时直接查看。

4. 部署与现场调试实录：从桌面测试到鱼缸落地

程序写完后，最耗时间的其实是部署和调参。这个环节直接决定系统在真实鱼缸环境下能不能长期稳定运行。我按“桌面裸板→水池测试→鱼缸落地”三个阶段推进，每个阶段都有完整的操作流程和记录。

4.1 桌面裸板测试：先别忙泡水

拿到元器件的第一天，我建议先不接任何传感器，单独给ESP32烧录一段空程序，确认开发板本身能启动、能连WiFi。然后逐个接入传感器：先接DS18B20，用手握住探头或者用冰块靠近，验证温度读数能朝正确方向变化；再接pH模块前，先短接模拟输入端，确认ADC读数稳定，排除了电源波动后，再接电极。

这一步最大的作用是建立“数据正确性预期”。如果你不知道常温下pH模块已经校准后读出的电压范围，那么后续把探头放进鱼缸后，根本判断不了读数是否正常。我在裸板测试时记录了一组关键参考值：DS18B20在室温25°C左右读数应为24.5±0.5°C，pH模块在清水中静态输出电压应在1.2V~1.6V之间，ADC读数对应500~800区间。这些参考值后续在校准和异常排查时非常有用。

4.2 传感器装缸位置与细节调整

正式装缸前，我先规划了传感器在鱼缸内的安装示意图。水温探头固定在远离加热棒的另一侧缸壁，高度在水面下方约三分之一处，理由是测量“平均水温”而不是加热棒附近的局部高温。水位传感器固定在缸顶，超声波探头向下发射，需要避开灯架和过滤出水口的水流扰动区域。pH探头则固定在过滤仓出水路径附近，那里的水是循环后的混合水体，比缸体角落更能代表实际水质。

固定传感器我用了两种方式：吸盘支架和扎带。吸盘适合水温探头和pH探头，取放方便；扎带适合超声波模块，固定得更牢靠。线材沿着鱼缸边框走，用理线夹固定，避免落入水中。一个重要的细节是，pH探头线缆不能和后端电源线并行走线，否则交流电产生的电磁干扰会让pH读数持续抖动。如果空间有限只能并行，那么至少隔开五厘米以上。

4.3 现场校准与数据基线记录

装缸通水后，第一件事不是直接调阈值，而是让系统空转24小时，期间每天记录三次读数，摸清水温、水位和pH的正常波动范围。以这次项目为例，白天光照强时水温会略微升高，晚上室温下降时水温跟着下降，整体可能在25.8°C上下浮动0.4°C。pH方面，刚换水后读数会短暂升高，两三天后随着微生物活动又缓慢回落。

pH传感器在这个环节需要做两点现场校准。第一步把探头放入标准缓冲液7.0中，调整模块电位器使读数稳定在pH 7.0；第二步放入标准缓冲液4.0，再调整斜率电位器使读数准确。如果只有一键校准的模块，那就在电解槽中按说明书操作。这里要特别注意，校准液是一次性的，取出探头后不要倒回瓶里，反复使用后缓冲液失效会导致校准误差越来越大。校准后，用一杯干净的纯净水冲洗电极，再放入鱼缸。

5. 常见故障排查与避坑记录

这部分内容是我在项目落地后强烈建议任何人先看一遍的。很多问题的症状相同，但根因完全不同，盲目更换硬件只会增加成本。我按照实际排查顺序整理了速查表，再挑几个典型故障详细解释。

5.1 故障速查表

5.2 几个值得展开的典型问题

第一个坑是继电器上电瞬间误动作。ESP32的GPIO在上电复位瞬间，会有一段进入有效电平的不确定状态。如果继电器接的是“高电平触发”，系统刚上电时可能继电器短暂吸合，水泵突然启动一下，吓鱼不说，还会产生浪涌电流。解决方法是给所有GPIO外设的供电加一个延迟，或者使用“低电平触发”继电器模块并在初始化时先强制写高电平。我最终改为低电平触发继电器，并增加了一个专门的使能引脚，只有初始化完成后才给执行机构供电。

第二个坑是长时间运行后pH读数漂移。探头玻璃膜表面会附着菌膜和藻类，导致响应变慢、读数偏低。这不是硬件损坏，我用软毛牙刷蘸中性清洁剂轻轻刷洗探头表面，再用蒸馏水冲洗，浸泡保护液两小时后即可恢复。建议每两周做一次这类维护，并且校准周期相应缩短。如果发现刷洗后读数仍然偏差很大，才考虑更换敏感头组件。

第三个值得注意的是传感器线缆长度和信号质量的关系。超声波水位模块和pH变送器都是模拟或脉冲信号，线缆超过五十厘米后容易受到电机启停产生的脉冲干扰。我在实际调试中遇到过一种诡异现象：气泵一启动，超声波水位读数马上跳高十厘米。排查后发现是气泵电机动作时在电源线上产生尖峰，传导到了超声波模块的供电。解决思路不是给传感器加滤波器，而是给气泵加一个独立的RC吸收电路，并在气泵两端并联一个104瓷片电容。这种问题靠软件滤波效果有限，必须从源头消除干扰。

5.3 数据记录与趋势判断的经验

持续记录数据不仅是给手机端曲线图用的，它本身就具备预警价值。我每日将数据落盘到本地SD卡，再每30分钟上传一次JSON到云端。用了一周后，我就能看出水位下降速度是否符合蒸发预期，pH在换水后什么时候回落到基线值。更有价值的是，这些历史数据能帮我发现传感器本身的失灵趋势。比如水温传感器在湿度较高的环境里线缆绝缘老化，读数会在固定时间点出现微小偏差，不对比长期趋势根本发现不了。

更实际的一个用法是设置“变化率告警”而不仅仅是“阈值告警”。水温下降太突然往往代表加热棒失效或缸内发生大量冷水交换，pH快速下跌则可能是硝化系统崩溃。这些事件发生时，即使当前数值还没跌破安全边界，也已经是极高风险的信号。我在系统中加入了简单的一阶差分计算，当读完历史值超过正常变化率五倍时，立即触发推送提醒。实测下来这个逻辑帮助我在一次水泵故障后及时介入，避免了水质持续恶化。

6. 按进度回顾与个人体会

再回到“dz-1032”这个编号项目本身。它不复杂，但足够完整，每一个环节都对应到物联网项目的核心技能点。如果按难度打分，硬件安装只占三成，程序逻辑占两成，剩下的时间几乎都消耗在校准、排干扰、和调整阈值这些看起来不起眼的事情上。这也正是这类项目最有价值的地方：它教会你的不是某一个函数的用法，而是如何在一个不确定的真实环境中做工程取舍。

有个小技巧对后续扩展很有帮助：不要把所有代码写在一个主文件里。虽然单片机项目的代码量不大，但把传感器读取、执行控制、网络上报分成三个独立模块文件，后面加功能时改动面会小很多。我当时用这个结构加了一个光照强度传感器，只花了二十分钟就完成对接。

这套系统的扩展方向其实还有很多可以玩。加入摄像头后可以用简单的帧差法识别鱼是否浮头，肌理状态检测和喂食量调整也能通过图像数据辅助判断；或者接入本地语音助手，播报“水质正常、水温二十六度”这种日常状态；再或者把云端数据对接日历系统，在出差前自动生成未来一周的预测告警建议。对于想深入学习物联网架构的开发者来说，把鱼缸监控改造成一套通用环境监测平台，也是一条清晰可走的技术路线。项目虽小，五脏俱全，跑过一遍之后再去看其他智能设备的产品逻辑，思路会通透很多。