“buzz”这个名字，你一听大概就能联想到那种持续的嗡嗡声、蜜蜂振翅的声音，或者是手机揣在兜里突然震动时的那种酥麻感。我手头这个代号为“buzz”的小项目，做的就是和声音、提醒有关的事：它是一套基于ESP32的声音检测与多端提醒系统，可以看作一个“长耳朵的小盒子”，放在房间里替你监听环境动静，一旦捕捉到异常声响，比如婴儿哭闹、门铃响、水壶啸叫、设备报警，它就会立刻本地蜂鸣提醒你，同时通过MQTT把消息推送到手机。

最初想做这个玩意，是因为有一次戴着降噪耳机在客厅剪视频，孩子在儿童房午睡，我完全听不见动静，等我想起来去瞄一眼，他已经哭了好一阵了。那之后我就琢磨，是不是能做个东西，专门盯着“我需要听到但人不在场”的声音，把耳朵延伸到另一个房间。这个项目就这么开始的，整体做下来难度不算高，适合玩单片机、物联网或者家庭自动化的人复刻，也适合完全不懂硬件、只想照抄代码给家里添个看护小助手的新手。下面我把整个拆解和实操过程完整记录下来。

1. 项目定位与整体方案设计

1.1 “buzz”到底要解决什么问题

先摆结论：buzz不是一个语音识别设备，它不关心“谁在说话”，只关心“现在环境里的声音能量是不是明显超出了正常水平”。从原理上讲，它就是一块麦克风+一块主控板+一个网络模块的组合，做的是声音强度检测和事件上报，而不是语义理解。

我说的“声音提醒”，指的是一整个事件链路：环境声音出现异常 -> 本地发出蜂鸣声 -> 远程推送消息到手机 -> 恢复安静后设备自动回到监听状态。这个链路里，本地蜂鸣处理的是“你就在房间附近但没注意”的情况，远程推送解决的是“你人在客厅、楼下甚至公司”的场合。两个输出同时生效，覆盖面才是完整的。

它的目标用户很明确，我把它分成四类场景来理解：

• 宝爸宝妈：宝宝在房间里睡觉，大人需要离开几分钟。buzz放在床头柜或婴儿床边，检测到持续哭闹就通知手机。
• 独居人士：外卖、快递按门铃，但自己在卧室戴耳机打游戏听不见。buzz放在玄关，捕捉门铃响铃频率特征。
• 工作室/机房维护者：设备发出异常报警音、烟雾报警器鸣叫，人不在现场也能第一时间知道。
• 养宠人群：猫咪半夜跑酷把东西打翻、狗狗长时间吠叫，做一个不侵入的“动静监视器”。

这些场景对灵敏度、延迟和准确度的要求各不相同，但底层逻辑是一致的：用一个模拟麦克风模块采集声音信号，用算法计算声音能量，用阈值判断是否触发。理解了这个，方案设计就有了方向。

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

主控我选了ESP32系列，具体到硬件是ESP32 DevKitC（或者ESP32-WROOM-32模组的开发板）。选它的理由很现实：

• WiFi集成度高：不需要再单独买一块ESP8266做网络透传，一个芯片全包了。STM32F103性能不差，但没有原生WiFi，要走SPI挂ESP8266，连接稳定性会差一个量级。
• 双核处理器：主核干音频采样和算法，辅核跑网络协议栈，互不干扰。对于需要实时计算RMS值的场景，这是明显优势。
• 烧录调试简单：Arduino内核成熟，PlatformIO一键编译上传，不用像STM32那样折腾Keil配置和下载器。
• 性价比高：一块兼容开发板二十来块钱，比树莓派Zero W还便宜一半以上，而且没有操作系统拖后腿，上电2秒就能开始采样。

当然，如果只做“本地蜂鸣提醒”不做网络推送，用ATtiny85这种微小型号也够，但如果要推送、远程配置、后续扩展，就绕不开带WiFi的主控。这里还有一个关键约束：ESP32的ADC2虽然也有模拟输入通道，但是和WiFi调度有冲突，WiFi开启状态下ADC2的结果会不稳定。所以我专门把麦克风输出接到了ADC1通道，具体是GPIO34。这个坑后面再展开。

1.3 系统架构与数据流转

整个系统是典型的“端-管-云”三层结构，但为了降低复刻门槛，云这一层我选的是完全免费的MQTT Broker（公共测试broker或用家里NAS上搭建的EMQX），消息推送则借用Server酱或Bark这样的免费通道。

一句话描述数据流：麦克风模块把声压波转换为模拟电压信号，ESP32内置ADC以一定采样率连续采集并计算声音能量值，当能量值超过动态阈值并且连续满足触发条件时，设备执行两条动作：一是拉高蜂鸣器引脚让本地发出“哔哔”声，二是把一条JSON消息通过MQTT发布到指定主题。订阅这条主题的可以是手机上的MQTT客户端，也可以是Node-RED、Home Assistant这类自动化平台，再由它们调用手机推送接口完成通知。

这个架构的好处是灵活。如果你不想用MQTT，直接把发布消息那一步改成请求一个Webhook，一样能跑。如果你想接入智能家居，MQTT主题稍加改造，Home Assistant就能自动发现设备。后面我会给出一个实际可用的改动方向。

2. 硬件选型与接线实操

2.1 硬件清单与每一样东西的作用

下面是实测过的完整物料清单，按“缺一样就起不来”的顺序排列：

MAX4466和MAX9814都是驻极体麦克风放大模块，MAX4466默认增益比较高，适合监听安静的室内环境；MAX9814带AGC（自动增益控制），更适合现场声音大小变化剧烈的场景。我第一次用的是MAX4466，在卧室这种安静环境里非常灵敏，半米外正常说话都能捡到明显波形。如果你计划放在厨房这种本身有底噪的地方，我更推荐MAX9814，AGC会让输出幅度稳定在一个范围内，不至于被突然的炒菜声灌满。

2.2 接线图与其背后的原理

接线非常直白，关键是把每个引脚的作用搞清楚：

• 麦克风模块 VCC -> ESP32 3.3V，GND -> GND，OUT -> GPIO34。
• 有源蜂鸣器正极 -> GPIO21，负极 -> GND。有源蜂鸣器内部自带振荡源，只要给高电平就响，不需要用PWM控制频率，对新手最友好。
• 按键一端 -> GPIO22，另一端 -> GND。上拉模式开启后，按下时读到低电平，触发校准逻辑。
• LED正极 -> GPIO23，负极串联一个220Ω电阻到GND。

需要特别注意的是麦克风模块的供电。MAX4466模块虽然标注5V供电兼容，但它的输出是轨到轨的，5V供电时输出偏置也接近2.5V，超出ESP32 ADC的线性测量范围。实测下来，用3.3V给模块供电，输出偏置大概在1.6V左右，留出了上下动态范围，ADC读数更安全。还有一个容易中招的细节：蜂鸣器和麦克风不要共用一条细的杜邦线供电。蜂鸣器动作瞬间电流会拉低电压，导致ADC读数跳变，产生误触发。至少用两根电源线分别从开发板的3.3V引脚引出，或者干脆用一个小三极管隔离蜂鸣器供电。

2.3 为什么要重视“声音信号的数字化质量”

很多朋友拿到模块直接读ADC值，然后发现数值一直在几千到几千跳来跳去，阈值根本没法设。这是正常的，因为麦克风模块输出的是交流小信号叠加直流偏置，不是稳定的直流电压。你在串口监视器里看到的原始ADC是一串在偏置值附近上下波动的数据，这个数值本身没有意义，有意义的是波动幅度。

所以第一步必须做“去直流”处理：采样N次求平均值，把平均值当作静音基线，然后每次读数减去这个基线，得到当前的瞬时偏差。第二步是计算RMS（均方根值），大致做法是：对一组采样值先减去基线、再平方、再求平均、最后开平方。RMS与声音能量成正比，比拿峰值判断要稳得多。峰值对毛刺噪声太敏感，空调压缩机启动瞬间就能输出一个尖峰，而RMS能更合理地反映“一段时间内声音到底有多大”。后面代码部分我会给出完整的函数实现。

3. 核心代码与完整实现过程

3.1 开发环境准备与工程框架

我先用Arduino IDE做了一版原型，后来为了依赖管理方便，迁移到了PlatformIO。Arduino IDE对ESP32支持的库、编译下载流程非常简单，但项目里只要涉及到多个库文件、自定义配置文件，它那套目录结构就开始难受了。PlatformIO用platformio.ini声明板型和依赖，代码可以干净地分成nv、main.cpp和config.h，这对后续维护是很大的加分项。我的platformio.ini大概长这样：

[env:esp32dev] platform = espressif32 board = esp32dev framework = arduino monitor_speed = 115200 lib_deps = knolleary/PubSubClient@^2.8

配置里只有一个第三方依赖，PubSubClient，用于MQTT通信。WiFi连接直接用Arduino内置的WiFi库，不需要额外安装。

3.2 环境底噪校准与阈值计算

声音检测最核心也最容易翻车的点是阈值怎么定。如果写死一个固定阈值，那么这设备在白天采光和夜晚采光下表现完全不同：白天窗外车流不断，RMS轻松就能到几百；深夜一切安静，又可能重新校准后只有三四十。固定阈值的结果就是白天狂误报、晚上漏报。

所以我的方案是上电自动校准+按键手动校准两种方式。校准动作做的是同一件事：持续采集两秒环境声音，计算RMS的平均值和标准差，然后把触发阈值设为“平均值 + 3倍标准差 + 一个最小偏移量”。用统计学的角度理解，正常环境波动基本都落在均值上下三个标准差范围内，超过这个范围的信号才有资格被称为“异常事件”。

代码实现是这样：

#define MIC_PIN 34 #define SAMPLE_WINDOW_MS 50 #define CALIBRATION_MS 2000 float baseline = 0.0f; float threshold = 0.0f; float computeRms(int pin, int windowMs) { unsigned long start = millis(); float sumSq = 0; int count = 0; float localBaseline = analogRead(pin); while (millis() - start < windowMs) { int raw = analogRead(pin); float diff = raw - localBaseline; sumSq += diff * diff; count++; delay(1); } return sqrt(sumSq / count); } void calibrate() { Serial.println("Calibrating..."); float sum = 0, sumSq = 0; const int samples = 30; float rmsValues[samples]; for (int i = 0; i < samples; i++) { rmsValues[i] = computeRms(MIC_PIN, SAMPLE_WINDOW_MS); sum += rmsValues[i]; sumSq += rmsValues[i] * rmsValues[i]; } float mean = sum / samples; float variance = sumSq / samples - mean * mean; float stddev = sqrt(variance); baseline = mean; threshold = mean + 3 * stddev + 15.0f; Serial.print("Threshold: "); Serial.println(threshold); }

这里的localBaseline在每次computeRms内部动态刷新为第一个采样值，本身就有一定的自适应能力。如果环境底噪稳定，localBaseline基本保持在静音偏置附近；如果底噪本身就有起伏，RMS会把波动纳入计算，阈值也会相应抬高。3倍标准差在实际体验中是一个比较合理的档位，白天窗户开着不太会误报，婴儿尖声哭闹一秒钟内能触发。噪声比较自闭的环境里，可以把这个系数调到2.2，让灵敏度更高。

3.3 声音事件判定：防止单次尖峰误触发

算法层还有一个关键思路：触发必须“持续确认”。很多场景下环境里会有一次性的瞬时响声，比如门砰地关一下、楼上扔东西、打雷，它们虽然也超过阈值，但没有持续意义。为了过滤这类干扰，我在进入Alert状态前设置了连续帧确认机制：连续3个50ms窗口（一共150ms）RMS都超过阈值，才算有效事件。

这个逻辑写起来很简单，但实际效果天差地别。最初我只判断单次RMS超过阈值就触发，结果楼道里有人跺一脚，蜂鸣器就响一下，一个下午能收到十几次推送。改掉之后，家里只剩下两种推送：真正持续的声音异常和明确到无法忽视的瞬时巨响。实现代码：

const int CONFIRM_FRAMES = 3; int confirmCount = 0; bool alertActive = false; void loop() { float rms = computeRms(MIC_PIN, SAMPLE_WINDOW_MS); if (rms > threshold) { confirmCount++; if (confirmCount >= CONFIRM_FRAMES && !alertActive) { alertActive = true; handleAlert(); } } else { confirmCount = 0; } if (alertActive && rms < threshold * 0.7f) { alertActive = false; } delay(10); }

注意我用threshold * 0.7作为退出条件而不是threshold，这是为了滞回。事件发生后必须等声音明显降低到阈值以下30%才算结束，避免声音在阈值附近轻微震荡导致状态反复横跳。这种滞回设计在工业继电器里都是常规操作，在这里同样有效。

3.4 本地提醒与远程推送实现

事件触发后，handleAlert要做三件事：本地蜂鸣、发送MQTT消息、冷却计时。这里有一个必须提前想好的问题：推送通知不能每次触发都发。如果宝宝哭闹持续5分钟，算法可能会触发几十次事件，手机弹窗刷屏体验极差。我的处理方式是引入冷却时间，默认180秒，冷却时间内重复触发只更新状态、不重复推送，但蜂鸣还是会响应，保证人在现场时永远有反馈。

MQTT部分直接用PubSubClient发布JSON消息：

#include <WiFi.h> #include <PubSubClient.h> WiFiClient netClient; PubSubClient mqtt(netClient); const char* mqttServer = "你的broker地址"; const int mqttPort = 1883; void connectMqtt() { while (!mqtt.connected()) { if (mqtt.connect("buzz-device-" + String((uint32_t)ESP.getEfuseMac()))) { Serial.println("MQTT connected"); } else { delay(2000); } } } void handleAlert() { digitalWrite(BUZZER_PIN, HIGH); delay(300); digitalWrite(BUZZER_PIN, LOW); static unsigned long lastNotify = 0; if (millis() - lastNotify > 180000UL) { lastNotify = millis(); char payload[128]; snprintf(payload, sizeof(payload), "{\"device\":\"bedroom\",\"event\":\"sound_detect\",\"rms\":%.1f,\"threshold\":%.1f}", rmsValue, threshold); if (!mqtt.connected()) connectMqtt(); mqtt.publish("home/buzz/alert", payload); } }

broker我推荐两个选型：如果只是自己折腾，用公共的broker.emqx.io最容易起步，但延时和稳定性不保险；如果想长期用，在家里NAS或树莓派上跑一个EMQX容器，局域网内推送延迟几乎为零，手动技能。Node-RED订阅home/buzz/alert这个主题后，只要加一个HTTP Request节点就能把消息转发到Server酱或Bark的开放接口上，手机通知秒到。

3.5 部署前的串口调试与关键输出

写代码不是最难的，最难的是确定阈值调多少合适。我强烈建议在正式部署前保留串口输出，实时打印每个窗口的RMS和当前阈值。具体做法是在loop()里加一行：

if (Serial) { Serial.printf("RMS: %.1f / TH: %.1f / Alert: %s\r\n", rms, threshold, alertActive ? "YES" : "NO"); delay(100); }

打开串口监视器后，你在房间里正常走动、说话、关门，观察RMS的变化轨迹。比如平时背景RMS在20左右，你走路大概到40，关门能冲到120；那阈值定在60时，关门会触发而走路不会。这套“观察-调整-复测”的流程比任何理论计算都靠谱。我自己调婴儿房的那台设备时就是这么反复测了十几分钟，最后把系数定在了2.8，既不太敏感又不至于漏掉哭声。

4. 常见问题与排查技巧实录

4.1 误报和漏报到底怎么治

误报漏报问题是最多人问的，也是最难一言蔽之的，但有一张表可以帮大家快速定位。

还有一个非常隐蔽的坑：模块的自动增益调整会让输出偏置缓慢漂移。MAX4466没有AGC，漂移不明显。但MAX9814的AGC会导致信号曲线整体下压或抬升，间接改变基线水平。如果你用MAX9814，建议在computeRms里每50个窗口就重新更新一次localBaseline，否则时间久了阈值会失真。这一点我会在后续版本里直接用高通滤波算法替代简单的基线减法，但从工程角度讲，低阶方案已经够用，不必为了炫技让项目变复杂。

4.2 WiFi掉线、MQTT卡死与看门狗

ESP32的WiFi稳定性整体不错，但公共路由器环境下仍然会遇到DHCP租期到期、路由器重启、信号弱等导致断连的情况。最直接的解决思路是给设备配置静态IP，减少对DHCP的依赖，同时在MQTT连接断开时立即重连，而不是等下一次事件。

还需要一个完整方案里的“保命”手段：硬件看门狗。如果WiFi长时间无法连接，主循环可能会卡在connectMqtt的while里，导致设备僵死。ESP32的看门狗定时器能强制重启设备，但要避免无限等待，我在connectMqtt里加了一个超时计数，连续15秒连不上就esp_restart()，让整个设备重新上电校准。这个方法很粗暴，但在无人值守的环境里，一个能自愈的设备好过一个永远卡死的残废设备。

void connectMqtt() { int retries = 0; while (!mqtt.connected()) { if (mqtt.connect("buzz-device")) { break; } retries++; if (retries > 5) { ESP.restart(); } delay(3000); } }

另外，ESP32和路由器之间有距离限制。实测在隔一堵承重墙、距离约6米的地方，设备偶尔会出现几十秒的断流，表现为消息延迟严重。给设备外接一个2.4G天线可以改善，但更简单的办法是把设备部署在离路由器近的位置，麦克风拾音是本地能力，网络模块可以稍微妥协方向。

4.3 供电越纯净，声音数据越干净

这是我在调应急报警器时踩过最大的坑。一开始用USB充电宝给ESP32供电，整机跑起来后蜂鸣器每次动作，串口输出的RMS就从平稳变成锯齿状，甚至不曾触发的情况下都会报假事件。用示波器一看，供电纹波大得吓人，蜂鸣器一拉高电平，总线电压跌了差不多0.3V，直接影响ADC的参考电位。

解决的土办法是给开发板的3.3V和GND之间并一个100μF电解电容和0.1μF陶瓷电容，目的就是给电源去耦，吸收蜂鸣器动作带来的瞬态电流。有条件的话，把蜂鸣器的供电独立到开发板的5V引脚，通过一个S8050三极管来开关，避免它共享3.3V稳压输出的负载。这样处理后，RMS曲线明显干净了，误报率下降了不止一个数量级。

4.4 延迟到底能不能接受

本地蜂鸣从检测到发声，实测延迟稳定在180ms以内，因为检测窗口本身就占了150ms，加上蜂鸣响应的数字化判断，这个数字属于正常范围。远程推送的延迟比较感性：同一局域网下用Node-RED转推Bark，基本1秒内能到；走公共MQTT broker+手机DNS解析，2到4秒属于正常，偶尔会有5秒以上的波动。

所以如果你的核心场景是“必须秒级感知”，比如老人倒在房间需要立刻通知，单纯靠声音能量检测推APP是根本不够的，这种场景该上语音识别或者人体传感器。buzz这类声音检测设备的定位是“辅助提醒”，不是安防级报警器，这一点在设计预期时就要搞清楚。我后面扩展视频监控联动时，也是把buzz作为事件触发源，而不是替代传感器。

5. 扩展方向与最终心得体会

5.1 从“声音强度”升级到“声音类型”

单纯的能量检测区分不了哭声、门铃声和装修电钻声。想进一步提升实用性，可以换用支持离线语音识别的硬件，比如ESP32-S3 + 离线唤醒词引擎，或者直接外挂一个SU-03T语音识别模块。这种方案能识别特定词条，比如“宝宝哭了”“有人按门铃”，识别的可靠性比阈值高很多，功耗也基本不变。

不过我不建议一上来就直接上这套。能量检测是这套系统的地基，先把阈值校准、消息推送、供电稳定性跑顺了，再考虑换识别方案。换了识别方案后，数据流从“RMS超过阈值”变成“关键词置信度超过阈值”，逻辑完全一样，代码改起来也快。

5.2 接入Home Assistant实现回家联动

buzz的MQTT消息可以被Home Assistant通过MQTT Discovery方式自动发现，对应的binary_sensor实体出现后，就能做类似“检测到异响，同时家中没人，自动把摄像头转向儿童房并把推送发到所有手机”的自动化。这一步不用改设备端代码，只要在Home Assistant的configuration.yaml里配置好MQTT broker，buzz发布的主题就会自动被感知到。这也是我选择MQTT而不是HTTP告警的一个原因——生态兼容性实在太好了。

5.3 这个小项目真正训练了什么

最后说一点自己的体会：做buzz的过程，表面上是玩了个蜂鸣器报警器，实际上完整走通了一条“传感器采集-信号处理-阈值判断-网络上报-消息推送-端侧自愈”的物联网链路。这里面的每一个环节都足够独立成项目，但组合在一起时才会真正考验人的系统思维。特别是阈值校准那部分，从“拍脑袋定一个数字”到“用统计学方法算出一个可复现的阈值”，这一层理解上的跃迁，比我买十块开发板泡在教程里还有用。

如果你也想复刻，我的建议是先别急着加各种花哨功能，把“麦克风采到声音 -> 本地蜂鸣器响起来”这一个最小闭环跑通，再往上堆网络推送和自动校准。基础链路稳定了，后面一切扩展都是水到渠成的事。