ESP32+WT3000TX离线语音通知盒子：从硬件接线到代码实战

大概两个月前，我在桌面上摆了一块ESP32开发板和一个小喇叭，折腾出了一套能自动播报“快递到门口”“电饭煲煮好了”“服务器挂了”的语音通知盒子。核心方案就是标题里写的：ESP32负责联网取数据，WT3000TX负责离线TTS播报。这套东西做起来不难，但踩坑点不少，尤其是WT3000TX的串口协议和编码转换，网上资料又碎又散。今天我把整个方案的选型思路、硬件接线、代码实现、场景化玩法，还有我踩过的坑一次性整理出来，给想自己动手做智能语音通知的朋友做参考。

这套方案适合三类人：第一类是正在玩ESP32、想给它加个“嘴巴”的嵌入式爱好者；第二类是想给家里的智能家居加语音提示、但又不想依赖云端的动手派；第三类是需要在工位或实验室搞一个低成本状态播报器的开发者。不需要很深的功底，会基本的Arduino编程就能跟着做出来。

1. 方案选型：为什么是ESP32搭配WT3000TX

1.1 WiFi主控的选择逻辑

一开始我考虑过好几条路线：用ESP8266省成本，用树莓派跑完整TTS服务，或者直接选一块带WiFi、蓝牙、双核的ESP32。最终定下来用ESP32，最关键的原因是它有余量。

ESP8266虽然便宜，但RAM只有160KB可用，跑TLS加密的HTTPS请求、解析JSON、再管理串口缓冲，内存经常捉襟见肘，指纹登录接口稍微复杂一点就崩。ESP32就从容很多，520KB SRAM，双核240MHz，后续想加传感器、加OLED屏、加BLE蓝牙控制都不会卡死。而且ESP32的WiFi稳定性比8266好不少，掉线重连机制写好了能几个月不用管。

树莓派那种跑完整Linux的方案我也考虑过，但直接否了。一个是成本，一张树莓派够买十几套ESP32；另一个是启动速度和可靠性，树莓派要等系统启动，断电还可能损坏SD卡，ESP32上电三秒就能跑完初始化开始干活。对于一个“播报通知”这种单一任务，杀鸡不用牛刀。

1.2 TTS方案的三个选择维度

TTS（Text To Speech，文本转语音）这部分，市面上可选方案主要分三类：纯在线API、ESP32本地软件TTS、专用TTS芯片。我在项目里抛开了前两者，直接锁定了WT3000TX，原因是三条硬指标：

第一是离线可用。在线API虽然音色自然，但依赖网络状况，还要注册账号、处理鉴权，家里宽带断一次语音通知就哑了，这违背了我做“可靠通知器”的初衷。WT3000TX是芯片级的离线TTS，语音合成在芯片内部完成，不占ESP32的资源，断网也能播报本地状态。

第二是零内存压力。如果让ESP32跑本地TTS算法，要么用极简的蜂鸣器“哔哔”方案，要么引入体积巨大的语音库，还要处理I2S音频输出、DMA缓冲区管理，代码复杂度直线上升。WT3000TX把文本通过串口发过去就完事了，芯片自己负责文字到语音的合成，输出音频信号直接驱动功放，ESP32只当个“传话筒”。

第三是中文支持与性价比。WT3000TX支持中英文混合播报，GB2312编码直接能读，不用做拼音到音频的映射。模块价格大概十几块钱到二十几块钱，比加一个云服务的一年订阅费便宜太多。

1.3 整体架构设计

这套系统的数据流很清晰：

信息源（天气API / MQTT服务器 / GPIO按钮 / 传感器） ↓ 网络请求或本地事件 ESP32（拉取文本 → 解析出播报语句 → 组帧） ↓ UART串口（9600波特率 + GB2312编码） WT3000TX（接收文本指令 → 离线语音合成） ↓ 音频输出（DAC输出 → 功放 → 喇叭） 用户耳朵（听到语音通知）

ESP32在这个架构里是“大脑”，负责所有逻辑判断和网络交互；WT3000TX是“嘴”，只管把文字变成声音。两者通过串口通信，协议异常简单。整台设备功耗不高，实测WiFi常开状态下整机电流大概80~120mA，USB口供电就够了。

2. 硬件准备与接线实战

2.1 元器件清单

先列一份我实际用到的物料清单，都是常见模块，电商平台随便买：

如果买的WT3000TX模块是带功放输出的完整版（有喇叭接线柱那种），PAM8403可以省掉。我买的是集成模块，直接接喇叭就行，省了功放电路。新手建议也买这种集成好的，别自己搭功放，调试起来麻烦。

2.2 接线表与关键注意点

接线特别简单，核心就三根线：TTS模块的RXD接ESP32的TXD，TTS的TXD接ESP32的RXD，再共地。注意一定是交叉接，否则两边都在发数据、都在收数据，串口对不上，收到的全是乱码。

ESP32 DevKitC的默认串口引脚是：

• TX0 = GPIO1，接WT3000TX的RXD
• RX0 = GPIO3，接WT3000TX的TXD
• 两者GND共地

WT3000TX的VCC接3.3V或5V，具体看模块说明书，我这块是5V供电。如果是3.3V逻辑的模块，可以直接和ESP32的3.3V通信；模块标注5V的话，串口电平多数兼容3.3V，但我建议用万用表确认一下，防止烧TTS模块的串口引脚。

喇叭接模块的SPK+和SPK-，没有正负之分，但注意别短路。模块音量调节一般有个电位器，先转到中间位置，再上电测试。

2.3 供电设计的一个隐蔽坑

这是我第一次点亮时踩的坑：用电脑USB口供电，一切正常；换成充电头供电，播报声音就变调或者中途卡住。查了半天才发现，劣质充电头输出纹波太大，TTS芯片在做语音合成时对电源比较敏感，电压一抖声音就失真。

解决方法是加一个1000μF电解电容并在电源入口处，或者在ESP32的5V和GND之间并几个100nF陶瓷电容。另外一个更稳妥的办法是直接买个明纬或者普通的5V/2A开关电源，别省这点钱，电源是整个系统稳定性的底层基础。

3. 核心代码实现与串口协议解析

3.1 环境准备

代码用的Arduino框架，先在Arduino IDE里装好ESP32开发板支持包（开发板管理器地址用官方espressif的JSON，网上搜一下大把教程）。板卡选择ESP32 Dev Module，上传速度建议115200。串口监视器波特率设成115200，方便看调试日志。

需要用到的库就两个：

• WiFi.h：ESP32自带，不需要额外装
• WiFiManager.h：开源库，用于配网（也可以不用，我后面会讲两种方式）
• ArduinoJson.h：解析接口返回的JSON数据，我用的是版本6，注意和相关代码的兼容性

3.2 Wi-Fi连接的两种配网方式

在讲正式的语音播报前，先解决联网这个基础问题。

方式一：硬编码账号密码（快速验证用）

适合在家调试，直接把WiFi名称和密码写死在代码里：

#include <WiFi.h> const char* ssid = "YourWiFiSSID"; const char* password = "YourWiFiPassword"; void setup() { Serial.begin(115200); // 调试串口 Serial2.begin(9600); // 串口2，用于和WT3000TX通信，稍后会用到 WiFi.mode(WIFI_STA); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println("\nWiFi connected, IP address: "); Serial.println(WiFi.localIP()); } void loop() { // 业务逻辑放这里 }

方式二：SmartConfig一键配网（体验更好，推荐）

手机下载“ESP8266 SmartConfig”类App，或者用微信小程序（搜索“ESP Touch”），长按按键让ESP32进入配网模式，手机App把WiFi账号密码广播过去。代码用SmartConfig库实现：

#include <WiFi.h> void smartConfigSetup() { WiFi.mode(WIFI_STA); WiFi.beginSmartConfig(); Serial.println("Waiting for SmartConfig..."); while (!WiFi.smartConfigDone()) { delay(500); Serial.print("."); } Serial.println("SmartConfig received, connecting..."); while (WiFi.status() != WL_CONNECTED) { delay(500); } Serial.println("Connected, IP: " + WiFi.localIP().toString()); }

第一次配网之后，ESP32会自动保存WiFi信息到Flash里，断电重启也会自动重连，不用每次重新配。这个改动极大提升了使用体验，做产品原型或者送给朋友用都更体面。

3.3 向WT3000TX发送TTS指令：协议细节与代码封装

WT3000TX的通信协议是典型的串口帧格式：帧头 + 数据长度 + 命令字 + 数据内容 + 校验，具体每一字节的取值以你手里芯片的《数据手册》为准。下面是一个通用模板（我以常见的WT3000系列帧结构为例，实际参数请对照芯片手册）：

// 发送文本到WT3000TX播报 // text为要播报的中文文本，需为GB2312编码 void sendTTS(const char* text, uint8_t textLen) { // 组帧：帧头 + 长度 + 命令(0x01表示文本播报) + 文本数据 // 长度为数据域长度 + 2（命令字 + 校验位） // 这里仅示意，具体对应关系以芯片手册为准 uint8_t frame[128]; // 根据文本长度调整 frame[0] = 0xFD; // 帧头 frame[1] = (uint16_t)(textLen + 3) >> 8; // 长度高字节 frame[2] = (uint16_t)(textLen + 3) & 0xFF; // 长度低字节 frame[3] = 0x01; // 命令字，0x01=文本播报 memcpy(&frame[4], text, textLen); // 文本数据 // 异或校验（部分芯片是累加和，以手册为准） uint8_t checksum = 0; for (uint8_t i = 0; i < textLen + 4; i++) { checksum ^= frame[i]; } frame[textLen + 4] = checksum; Serial2.write(frame, textLen + 5); }

这里有一个最大的坑：编码转换。

WT3000TX需要的是GB2312编码的中文字节流，而我们编写的Arduino代码源文件默认是UTF-8。如果直接把字符串“你好”发过去，芯片会认为这是两个乱码字符。解决方案有两个：

方案一（最简单）：在写代码时用VSCode的“更改文件编码”功能，把.ino文件编码改为GB2312，但这种方式会导致WiFi名称、日志等中文字符串也变成GB2312，混合编码很容易乱套，我不推荐。

方案二（推荐）：用文本编码转换库。Arduino有个开源库GBK_Encoding，支持UTF-8到GBK的转换，用法如下：

#include <GBK_Encoding.h> String utf8Text = "快递已到门口"; String gbkText = Utf8ToGbk(utf8Text); sendTTS(gbkText.c_str(), gbkText.length());

没有现成库也可以用查表法实现，但代码量比较大。我建议直接在GitHub搜“ESP32 GBK UTF8”，下载转换库塞进libraries文件夹就行，这一行转换能省你三小时排查乱码的青春。

3.4 一个完整的播报函数封装

把上面的内容整合一下，我的播报函数长这样：

#include <WiFi.h> #include <GBK_Encoding.h> HardwareSerial TTS(2); // 用串口2接TTS模块 void ttsInit() { TTS.begin(9600, SERIAL_8N1, 16, 17); // RX=GPIO16, TX=GPIO17 } void ttsSpeak(String utf8Text) { String gbkText = Utf8ToGbk(utf8Text); sendTTS(gbkText.c_str(), gbkText.length()); Serial.println("[TTS] " + utf8Text); }

这里我选择用UART2（GPIO16/17）而不是默认的UART0，原因是UART0同时也是USB调试串口，如果给TTS用了，Serial.print()打印日志就会和语音数据混在一起，排查问题非常痛苦。分离之后，调试信息走UART0，语音数据走UART2，互不干扰。

4. 场景化应用：把语音通知变得真正有用

代码框架打好了，接下来就是往里面装“灵魂”——让WiFi拿到的数据变成嘴里说出来的话。这里分享四个我实际做过的场景，代码思路都可以复用。

4.1 场景一：天气预警定时播报

每天早上一睁眼，先让系统从天气API拉取温度、天气状况和降水概率，然后合成一句话播报：“早上好，今天多云，气温22到28度，降水概率百分之三十，记得带伞。”

用免费的OpenWeatherMap或者心知天气API，ESP32发起HTTP请求，拿到JSON后解析：

#include <HTTPClient.h> #include <ArduinoJson.h> String fetchWeather() { HTTPClient http; http.begin("https://api.seniverse.com/v3/weather/now?key=YOUR_KEY&location=jiangsu&language=zh-Hans"); int httpCode = http.GET(); if (httpCode > 0) { String payload = http.getString(); DynamicJsonDocument doc(1024); deserializeJson(doc, payload); const char* temperature = doc["results"][0]["now"]["temperature"]; const char* weather = doc["results"][0]["now"]["text"]; String report = "早上好，当前温度" + String(temperature) + "度，" + String(weather) + "。"; http.end(); return report; } http.end(); return "天气服务暂时不可用"; }

用HTTPS连接需要初始化TLS指纹和证书，HTTPClient库默认能处理大部分场景，但遇到握手失败就多试几个版本的内置证书更新包。这种习惯性问题网络上有很多现成方案，这里不展开细说。

4.2 场景二：GPIO触发即时播报

这个场景最简单也最实用：门口放一个微波雷达模块（或人体红外传感器），检测到有人靠近就播报“欢迎光临”；门上放一个门磁传感器，门打开就播报“大门已开启”。

代码核心就是中断或轮询GPIO状态：

#define BUTTON_PIN 0 // 按键或者传感器信号引脚 void setup() { pinMode(BUTTON_PIN, INPUT_PULLUP); ttsInit(); // WiFi连接等等 } void loop() { if (digitalRead(BUTTON_PIN) == LOW) { ttsSpeak("门口有人按门铃，请查收。"); delay(3000); // 防止连续触发 } }

注意点：传感器输出如果是高电平脉冲，需要用digitalRead延时消抖；如果追求可靠性，可以在GPIO口加一个上拉电阻和100nF滤波电容，防止干扰信号误触发。我实测裸奔状态在阳台门附近偶尔会被风刮一下误报，加了消抖之后就稳了。

4.3 场景三：MQTT消息订阅播报

这是整套方案最有生产力的一种玩法：家里NAS、跑批服务器、甚至树莓派上的脚本，执行完关键任务后通过MQTT发一条消息，ESP32收到后播报“任务已完成”或“构建失败”。

MQTT客户端用PubSubClient库：

#include <PubSubClient.h> WiFiClient espClient; PubSubClient mqtt(espClient); void mqttCallback(char* topic, byte* payload, unsigned int length) { String msg = ""; for (int i = 0; i < length; i++) { msg += (char)payload[i]; } ttsSpeak("收到新消息：" + msg); } void setup() { mqtt.setServer("192.168.1.100", 1883); mqtt.setCallback(mqttCallback); } void loop() { if (!mqtt.connected()) { mqtt.connect("esp32_tts"); mqtt.subscribe("home/notification"); } mqtt.loop(); }

设置好重连逻辑后，这台设备就可以像“语音小助理”一样，接收来自任何设备的通知消息。我把电脑上的rsync备份脚本、家里的门铃、甚至路由器断线告警都接进了这个Topic。体验非常奇妙——你坐在沙发上，系统在你身后报一句“备份同步完成”，然后你甚至不用回头。

4.4 音量调节与多音色切换

WT3000TX本身支持音量调节，一般通过指令字控制，比如带音量参数的播报指令。我封装了这样一个函数：

void ttsSetVolume(uint8_t volume) { // 组帧：设置音量指令，具体帧内容参考芯片手册 uint8_t cmd[] = {0xFD, 0x00, 0x02, 0x22, volume}; TTS.write(cmd, sizeof(cmd)); }

灵感：可以把音量拉大到最大值，在客厅播报；晚上用手机通过MQTT发一条“音量低”，把音量调小，不影响家人睡觉。多音色切换同理，男声、女声、童声在芯片内部有不同音色ID，指令换一字节就行。具体音频参数表在数据手册最后几页，照抄即可。

5. 常见问题排查与避坑实录

5.1 问题速查表

5.2 深坑：帧长度字节的“大端陷阱”

WT3000TX这类芯片的帧长度字段普遍是大端序（高位在前），我第一次写组帧代码习惯性地用了小端序，结果芯片一个字都不说，也不回ACK。卡了一晚上，最后拿逻辑分析仪抓波形才发现问题。

写框架的时候千万别想当然，一定要对着手册扒每一字节。如果发现芯片完全没反应，先循环发送一个固定文本，用示波器/逻辑分析仪看串口波形是否正常发出。90%的“芯片不响应”问题都能在这种排查里找到答案。

5.3 深坑：串口二选一，别占用了系统调试口

有朋友写的代码死活不播报，日志也看不见。后来发现他把TTS接在GPIO1（UART0的TX）上，导致USB转串口芯片也被占用，整个串口链路就乱了。ESP32 DevKitC的USB串口芯片只接到UART0，所以只要把TTS换到UART2就能解决。

我的固定接法：GPIO16 = TTS_RX，GPIO17 = TTS_TX，与UART0完全隔离，调试体验直线上升。

5.4 深坑：中文文本长度别超出限制

WT3000TX这种入门级TTS芯片，单次播报的文本长度通常限制在几百字节以内（具体看手册），如果发长句子，芯片可能截断或者不播报。我的做法是把长文案拆成多个短句，每条单独发送，中间隔200ms延时，避免芯片内部缓冲区溢出：

void ttsSpeakLong(String text) { // 粗略按30个字拆一次，具体长度参考芯片限制 while (text.length() > 60) { String sub = text.substring(0, 60); ttsSpeak(sub); text = text.substring(60); delay(200); } if (text.length() > 0) { ttsSpeak(text); } }

这个“拆句播报”的心得让我原先一个很长的日报播报顺利实现，不然你辛苦拼接完的整段话，芯片只念一半，挺尴尬的。

5.5 合规与安全提醒

最后多啰嗦一句：这套方案里ESP32是连接你自己家或你自己管理的网络设备。配网时密码要对，但不要试图去连接或破解不属于你的网络和设备，这既是法律红线和基本道德，也是网络安全管理的基本常识。做智能家居产品的时候，保障自己网络密码的强度，开启路由器的访客隔离（IoT设备网段隔离），都是非常必要的安全习惯。咱们玩开源硬件是为了提升生活质量，不是给自己惹麻烦。

附：我的一点调试心法

这套系统跑通之后，我的生活确实变化不小：门铃响了人在书房，语音报一句“有人来了”，不用跑过去看；服务器半夜报警，它在客厅喊“生产环境异常”，比手机推送靠谱得多，因为语音具有天然的强存在感。

最后再分享一个小技巧：在loop()里加一个简单的优先级队列，门铃通知的优先级永远高于天气播报，这样当两个事件同时出现时，语音不会被低优先级的内容打断。我就是这样一点点把它变成一台真正“懂事”的语音通知设备。DIY的魅力就在于此——你不只是在做一个喇叭，而是在给自己的生活安排一个可靠的信使。