企业官网建设流程全解析

告警机这个东西，说白了就是在特定事件发生时，能主动发出声音、灯光或者消息提醒的小终端。工厂产线用它报故障，机房用它报温度异常，家里用它提醒老人吃药、提醒自己别忘关火。市面上的成品终端从几十块到几千块都有，功能参差不齐。而树莓派这类单板计算机的出现，让不少人动了"自己攒一台"的念头——毕竟硬件开放、软件自由、想怎么改就怎么改。但真动手之前，有几个问题必须先想清楚：树莓派做告警机到底靠不靠谱？TTS语音播报怎么落地？USB声卡是不是必须的？和成品终端比，DIY方案的优势和短板分别在哪里？这篇内容就把这些问题一次讲透，从选型逻辑到实操步骤，再到实测中踩过的坑，全部摊开来说。

1. 先搞清楚告警机到底在告什么警

很多人一上来就买板子、买传感器，结果做到一半发现根本不知道自己要做的是什么。告警机不是一个单一设备，它是一类需求的总称。动手之前，先把"告警"这件事拆开看。

1.1 告警的三种典型触发源

从实际项目经验来看，告警机的触发源基本逃不出这三类：

• 物理量越限：温度超过阈值、湿度低于下限、烟雾浓度异常、电流过载。这类场景最常见，传感器采集数据，程序判断是否越界，越界就触发告警。
• 事件驱动：某个开关被按下、某个人经过红外感应区、某个设备发出了特定信号。这类场景强调的是"事件发生"而不是"数值变化"。
• 外部消息推送：收到一条特定内容的网络消息、某个服务挂了、某个定时任务失败了。这类场景下，告警机本身不采集数据，而是作为消息的"出口"。

这三类触发源对应的硬件配置和软件逻辑完全不同。物理量越限需要传感器和ADC（模数转换），事件驱动需要GPIO输入和中断处理，外部消息推送则更依赖网络通信和消息队列。你在动手之前，先把自己要做的告警机归到哪一类想清楚，能省掉大量返工。

1.2 告警的输出方式决定了硬件选型

触发源想清楚了，接下来看输出。告警的输出方式直接决定了你需要什么硬件：

如果你只是要"响一声"，蜂鸣器就够了，树莓派GPIO直接驱动，代码三行搞定。但如果你要"说出具体哪里出了问题"，那就必须上TTS，而TTS对音频输出的要求就高了一个档次——树莓派自带的3.5mm音频口底噪大、音质差，这时候USB声卡就成了刚需。

1.3 成品终端和DIY方案的分水岭在哪里

成品告警终端（比如机房用的声光报警器、工业用的报警灯柱）的核心优势是：即插即用、稳定可靠、有外壳有认证。你买回来接上线就能用，不需要写代码，不需要调试，坏了直接换。

DIY方案的核心优势则是：灵活、可编程、可扩展。你想让它报什么它就报什么，你想让它怎么报它就怎么报。今天用来报温度，明天改几行代码就能用来报消息。

但这里有一个很多人忽略的分水岭：当你的告警需求是固定不变的，成品终端几乎总是更优解；当你的告警需求会变化、需要和其他系统联动、或者需要传达动态内容时，DIY方案才有意义。我见过太多人花了几百块攒了一台树莓派告警机，结果只是用来做"温度高了响一声"这件事——一个三十块的温控开关就能干的事，硬是上了一整套Linux系统。

2. 树莓派做告警机的硬件账怎么算

决定走DIY路线之后，硬件选型就是第一道坎。树莓派型号那么多，配件那么杂，钱要花在刀刃上。

2.1 树莓派型号选择：别为用不上的性能买单

目前市面上能买到的树莓派主要有这几档：

• 树莓派Zero 2 W：四核1GHz，512MB内存，体积最小，功耗最低。适合纯GPIO控制、简单网络推送类的告警机。价格约100-150元。
• 树莓派4B：四核1.5GHz，2GB/4GB/8GB内存可选。性能足够跑TTS、跑轻量级视觉识别。价格约300-500元。
• 树莓派5：四核2.4GHz，4GB/8GB内存。性能最强，但功耗和发热也最大。价格约500-700元。

做告警机，我的建议是：如果你只需要GPIO控制和网络推送，Zero 2 W完全够用，而且功耗低到可以用充电宝供电。如果你需要跑TTS或者轻量级AI推理，4B是性价比最高的选择。树莓派5对于告警机来说性能过剩，除非你同时还要跑YOLO之类的视觉模型。

这里有一个容易被忽略的点：树莓派的供货和价格波动很大。有时候4B的价格会被炒得很高，这时候不妨看看二手的3B+，做告警机性能绰绰有余。

2.2 USB声卡：TTS方案里最容易被低估的一环

树莓派自带的3.5mm音频接口，用过的人都知道——底噪大、音量小、音质差。如果你只是让告警机"滴滴"响，那无所谓。但如果你要用TTS播报"三楼机房温度过高，请立即检查"，那音质就直接影响信息传达效果。

USB声卡的作用就是把数字音频信号从USB接口输出，绕过树莓派自带的PWM音频电路。市面上几十块钱的USB声卡（比如CM108芯片的方案）就能带来明显的音质提升。选USB声卡的时候注意两点：

• 免驱：树莓派系统（Raspberry Pi OS）内核已经包含了主流USB声卡芯片的驱动，插上就能识别。买之前确认一下芯片型号，CM108、CM119、SA9023这些都没问题。
• 带独立音量调节：有些USB声卡带物理旋钮，调试的时候方便很多，不用每次都进系统调音量。

注意：树莓派的USB接口和以太网口在某些型号上是共享带宽的。如果你同时插了USB声卡、USB摄像头、USB网卡，可能会出现音频卡顿。做告警机的话，尽量用WiFi联网，把USB带宽留给声卡。

2.3 音箱和功放：别让最后一步拖后腿

USB声卡输出的是线路电平信号，直接接无源音箱声音很小。你需要一个有源音箱（自带功放），或者一个功放模块加无源喇叭。

• 有源音箱：最简单，USB声卡输出直接插音箱的3.5mm输入口。推荐用那种USB供电的小音箱，可以和树莓派共用电源。
• 功放模块 + 无源喇叭：适合需要大音量的场景。PAM8403功放模块几块钱，配上4欧3瓦的小喇叭，声音足够覆盖一个房间。

实测下来，告警机场景下最稳妥的方案是：USB声卡 + 有源小音箱。整套成本控制在80元以内，音质和音量都能满足室内播报需求。

2.4 完整硬件清单和成本核算

以"树莓派4B + TTS语音播报 + 网络推送"这个配置为例，列一份完整的清单：

对比一下成品：一个带语音播报功能的工业告警终端，价格通常在800-2000元。DIY方案在成本上确实有优势，但前提是你把自己的时间成本算作零。

3. TTS语音播报的落地路线

TTS是告警机DIY方案里技术含量最高的部分，也是最多人卡住的地方。树莓派上跑TTS，有几条路线可以走，各有各的适用场景。

3.1 在线TTS和离线TTS的取舍

在线TTS（比如各种云服务商的语音合成API）的优点是音质好、发音自然、支持多种音色。缺点是依赖网络、有调用次数限制、长期使用有成本。

离线TTS（在树莓派本地运行合成引擎）的优点是断网可用、无调用限制、隐私性好。缺点是音质参差不齐、资源占用高、中文支持需要额外配置。

做告警机，我的建议是：如果告警机部署在有稳定网络的环境，优先用在线TTS，省心省力。如果部署在断网或网络不稳定的环境，或者对隐私有要求，那就必须走离线路线。

3.2 离线TTS方案对比：eSpeak、Piper和神经网络TTS

树莓派上能跑的离线TTS方案主要有这几个：

eSpeak NG：最轻量，安装最简单，资源占用极低。但音质是典型的"机器人声"，中文发音生硬，适合对音质要求不高的场景。

sudo apt install espeak-ng espeak-ng -v zh "温度过高，请检查"

Piper TTS：基于神经网络的轻量级TTS，音质比eSpeak好很多，资源占用适中。树莓派4B上可以流畅运行。但中文模型的选择有限，部分模型的中文发音不够标准，需要自己试听筛选。

# 安装piper pip install piper-tts # 下载中文模型后使用 echo "温度过高，请检查" | piper --model zh_CN-model.onnx --output_file output.wav

其他神经网络TTS：比如VITS系列的模型，音质最好，但对树莓派的算力要求较高。树莓派4B上推理一句话可能需要几秒钟，树莓派5会快一些。如果你的告警机对实时性要求不高（比如温度告警不需要毫秒级响应），这个延迟是可以接受的。

实操心得：Piper TTS的中文模型在不同版本之间发音差异很大。我试过好几个模型，有的会把"温度"读成奇怪的声调。建议在正式部署前，把你要播报的常用语句全部用模型合成一遍，人工听一遍，确认没有发音问题再上线。

3.3 在线TTS的接入方式和注意事项

如果你选择在线TTS，接入方式通常很简单：注册账号、获取API Key、调用HTTP接口、把返回的音频数据保存成文件、用播放器播放。

以百度TTS为例，基本流程是：

import requests import base64 # 获取access_token（需要先在平台创建应用） def get_token(api_key, secret_key): url = "https://aip.baidubce.com/oauth/2.0/token" params = { "grant_type": "client_credentials", "client_id": api_key, "client_secret": secret_key } return requests.post(url, params=params).json()["access_token"] # 合成语音 def tts(text, token): url = "https://tsn.baidu.com/text2audio" params = { "tex": text, "tok": token, "cuid": "raspberrypi", "ctp": 1, "lan": "zh", "spd": 5, # 语速 "pit": 5, # 音调 "vol": 9 # 音量 } resp = requests.post(url, data=params) with open("/tmp/alert.mp3", "wb") as f: f.write(resp.content)

然后调用系统播放器播放：

mpg123 /tmp/alert.mp3 # 或者 ffplay -nodisp -autoexit /tmp/alert.mp3

在线TTS的注意事项：

• 网络延迟：从发送请求到拿到音频，通常需要几百毫秒到一两秒。告警机对实时性要求高的话，这个延迟要纳入考虑。
• API限额：免费额度通常有限，告警频繁的话很快会用完。要么控制告警频率，要么上付费套餐。
• 音频格式：不同平台返回的格式不同（MP3、WAV、PCM），确保你的播放器支持对应格式。
• 错误处理：网络请求可能失败，代码里必须加异常处理和重试逻辑，否则告警机在关键时刻掉链子。

3.4 让TTS播报更"像人话"的工程技巧

TTS合成出来的语音，如果直接把原始文本丢进去，往往听起来很生硬。几个实用的优化技巧：

• 文本预处理：把数字转成中文读法（"25"读成"二十五"而不是"二五"），把符号转成文字（"℃"读成"摄氏度"），把缩写展开（"CPU"读成"C-P-U"或"处理器"）。
• 插入停顿：在句子之间加逗号或句号，让TTS引擎自然断句。有些引擎支持SSML标记，可以精确控制停顿。
• 控制语速：告警语音的语速不宜过快，比正常语速稍慢一点，确保听清楚。但也不能太慢，否则紧急情况下让人着急。
• 重复关键信息：重要的告警内容可以播报两遍，或者在开头和结尾各强调一次关键信息。

def preprocess_text(text): # 数字转中文 text = text.replace("25", "二十五") # 符号转文字 text = text.replace("℃", "摄氏度") text = text.replace("%", "百分之") # 插入停顿 text = text.replace("，", "，") return text

4. 从零搭建一台TTS告警机的完整流程

前面把硬件和TTS方案都理清楚了，这一章把整个搭建流程串起来。假设你要做一台"温度越限就语音播报"的告警机，以下是完整的实操步骤。

4.1 系统烧录和基础环境配置

第一步是给树莓派装系统。推荐用Raspberry Pi OS Lite版本（无桌面），资源占用低，适合告警机这种不需要图形界面的场景。

烧录工具用官方的Raspberry Pi Imager，操作很直观：选系统、选TF卡、点写入。烧录之前在Imager的高级设置里把WiFi、SSH、用户名密码都配好，这样烧录完插卡就能直接SSH连接，不用接显示器和键盘。

系统起来之后，先做几件事：

# 更新软件源和系统 sudo apt update && sudo apt upgrade -y # 安装常用工具 sudo apt install -y python3-pip python3-venv git mpg123 ffmpeg # 确认USB声卡被识别 aplay -l

aplay -l的输出里应该能看到USB声卡对应的card编号。记下这个编号，后面配置音频输出要用。

4.2 音频输出配置和测试

树莓派默认可能把音频输出到HDMI或者自带的3.5mm接口。要让声音从USB声卡出来，需要配置ALSA。

创建或编辑/etc/asound.conf：

defaults.pcm.card 1 defaults.ctl.card 1

这里的1是USB声卡的card编号，根据aplay -l的输出调整。

然后测试播放：

# 生成一个测试音频 espeak-ng -v zh "测试音频输出" -w /tmp/test.wav # 播放 aplay -D plughw:1,0 /tmp/test.wav

如果声音从USB声卡连接的音箱里出来了，说明配置正确。如果没有，检查card编号和音箱连接。

注意：树莓派上音频配置有时候会被系统更新覆盖。建议把配置写进脚本，每次开机自动检查并设置。

4.3 传感器数据采集和阈值判断

以DHT22温湿度传感器为例，接线方式是：VCC接3.3V，GND接GND，DATA接GPIO4（可改）。

安装依赖库：

pip install Adafruit_DHT

采集和判断逻辑：

import Adafruit_DHT import time SENSOR = Adafruit_DHT.DHT22 PIN = 4 TEMP_THRESHOLD = 30.0 # 温度阈值，摄氏度 def check_temperature(): humidity, temperature = Adafruit_DHT.read_retry(SENSOR, PIN) if temperature is None: return None return temperature while True: temp = check_temperature() if temp and temp > TEMP_THRESHOLD: trigger_alert(temp) time.sleep(10) # 每10秒采集一次

这里有几个实操细节：

• read_retry：DHT22的读取成功率不是100%，用retry版本可以自动重试，减少读取失败。
• 采集间隔：DHT22的采样率有限制，不能太快，建议至少2秒一次。告警机场景下10秒一次完全够用。
• 异常处理：传感器可能断线、可能返回None，代码里必须处理这些情况，否则程序会崩。

4.4 告警触发和TTS播报的联动

把传感器判断和TTS播报串起来：

import subprocess import os def trigger_alert(temperature): # 防止重复告警，加一个冷却时间 if not should_alert(): return text = f"警告，当前温度{temperature:.1f}摄氏度，超过阈值，请检查" text = preprocess_text(text) # 合成语音 subprocess.run([ "espeak-ng", "-v", "zh", "-s", "150", "-w", "/tmp/alert.wav", text ]) # 播放 subprocess.run(["aplay", "-D", "plughw:1,0", "/tmp/alert.wav"]) # 记录告警时间 record_alert_time() # 冷却时间：5分钟内不重复告警 last_alert_time = 0 COOLDOWN = 300 def should_alert(): global last_alert_time now = time.time() if now - last_alert_time > COOLDOWN: last_alert_time = now return True return False

冷却时间这个设计非常重要。没有它的话，温度持续超标时告警机会一直播报，吵得人受不了。5分钟是一个比较合理的值，可以根据实际场景调整。

4.5 开机自启和长期运行稳定性

告警机是要7x24小时运行的，不能每次断电重启后还要手动启动程序。用systemd配置开机自启：

创建/etc/systemd/system/alert.service：

[Unit] Description=Alert Machine Service After=network.target sound.target [Service] Type=simple User=pi WorkingDirectory=/home/pi/alert ExecStart=/usr/bin/python3 /home/pi/alert/main.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload sudo systemctl enable alert.service sudo systemctl start alert.service

Restart=always和RestartSec=10保证程序崩溃后10秒自动重启，这是长期运行稳定性的关键。

5. DIY方案和成品终端的真实差距

聊完了怎么攒，现在回到标题里的核心问题：DIY方案和成品终端到底怎么选？我把实际使用中感受到的差距列出来。

5.1 稳定性：成品终端的护城河

成品告警终端的设计寿命通常是5-10年，硬件经过老化测试，固件经过大量现场验证。你把它装在墙上，可能几年都不用管它。

DIY方案的稳定性取决于你的软件质量和硬件连接可靠性。TF卡会磨损、电源会老化、系统更新可能引入bug、Python脚本可能因为内存泄漏跑几天就崩。我自己的树莓派告警机，平均每两三个月就要维护一次——要么是TF卡出问题，要么是某个依赖库更新后不兼容。

如果你要部署在无人值守的关键场景，成品终端的稳定性优势是DIY方案很难追上的。

5.2 灵活性：DIY方案的绝对主场

成品终端的逻辑是固定的：温度超过多少度就报警，报警方式是声光。你想改逻辑？对不起，改不了。你想让它把告警信息推送到某个系统？对不起，没有这个接口。

DIY方案在这方面的优势是碾压性的。你想加一个"只在工作时间告警"的逻辑，加几行代码就行。你想让它把告警信息同时推送到多个渠道，加几个函数调用就行。你想让它根据不同的告警级别播报不同的语音，改一下判断逻辑就行。

5.3 成本：短期看DIY便宜，长期看未必

前面算过，DIY一台TTS告警机的硬件成本大约400-600元。成品终端的价格区间很大，简单的声光报警器几十块，带语音播报和网络功能的工业终端800-2000元。

但DIY方案有一个隐性成本：你的时间。从选型、采购、组装、写代码、调试到后期维护，一台功能完整的TTS告警机，新手可能需要20-40小时，熟手也要5-10小时。如果你的时间值钱，这个成本要算进去。

另外，DIY方案的故障率更高，每次故障都要你自己排查修复。成品终端坏了直接换新或者走保修，省心得多。

5.4 什么情况下DIY方案明显更优

根据我的经验，以下几种情况DIY方案是更好的选择：

• 需求会变化：今天报温度，明天可能要报湿度，后天可能要接入新的传感器。成品终端很难适应这种变化。
• 需要和其他系统联动：告警机需要把数据推送到自己的服务器、需要根据其他系统的状态决定是否告警。成品终端通常没有这种开放接口。
• 需要传达动态内容：告警信息里包含实时数据（比如具体温度值、具体设备编号），成品终端的固定语音无法满足。
• 预算极度有限且时间充裕：愿意花时间折腾，用最低的硬件成本实现功能。
• 学习和实验目的：做告警机本身就是为了学树莓派、学Python、学硬件控制，那DIY就是目的本身。

反过来，如果你的需求是固定的、部署环境是无人值守的、对稳定性要求极高、不想花时间维护，那就老老实实买成品终端。

6. 实测中踩过的坑和对应的解法

这一章记录我在实际搭建和使用过程中遇到的问题，以及最终的解决方式。这些经验在常规教程里很少提到，但实际做的时候大概率会遇到。

6.1 TF卡磨损导致系统崩溃

树莓派用TF卡作为系统盘，告警机7x24小时运行，日志不断写入，TF卡很快就会出现坏块。我遇到过好几次系统突然无法启动，或者运行中突然报I/O错误。

解法：

• 把日志写入内存盘（tmpfs），减少TF卡写入。编辑/etc/fstab，添加：

tmpfs /var/log tmpfs defaults,noatime,nosuid,size=50m 0 0 tmpfs /tmp tmpfs defaults,noatime,nosuid,size=100m 0 0

• 使用高质量的TF卡，比如三星EVO系列或者闪迪Extreme系列，不要用杂牌卡。
• 定期备份系统镜像，出问题时直接恢复。
• 有条件的话，用USB SSD启动，彻底摆脱TF卡磨损问题。

6.2 USB声卡被系统识别为默认设备但没声音

这个问题很常见：aplay -l能看到USB声卡，但播放时声音还是从HDMI或者3.5mm口出来。

排查链路：

1. 确认/etc/asound.conf里的card编号和aplay -l输出一致。
2. 检查alsamixer里的音量是否被静音。运行alsamixer，按F6选择USB声卡，确认音量不为0且没有静音。
3. 检查树莓派的音频输出配置。运行sudo raspi-config，在System Options → Audio里选择USB声卡。
4. 如果还是不行，尝试在播放命令里显式指定设备：aplay -D plughw:1,0 file.wav。

6.3 TTS合成速度慢导致告警延迟

用神经网络TTS（比如Piper）在树莓派4B上合成一句话，可能需要1-3秒。如果告警逻辑是"检测到异常→合成语音→播放"，那从异常发生到声音出来，可能有3-5秒的延迟。

解法：

• 预合成常用语句：把常用的告警语句提前合成好，存成音频文件。告警时直接播放文件，不需要实时合成。只有包含动态数据的语句才需要实时合成。
• 用更轻量的TTS引擎：如果对音质要求不高，eSpeak NG的合成速度是毫秒级的，几乎没有延迟。
• 异步处理：告警触发和语音合成放在不同线程里，不阻塞主循环。

import threading def async_alert(text): thread = threading.Thread(target=trigger_alert, args=(text,)) thread.start()

6.4 网络TTS服务不可用时的降级方案

用在线TTS的话，网络断了或者服务挂了，告警机就哑了。必须有降级方案。

解法：本地保留一个轻量级TTS引擎作为备份。代码里先尝试在线TTS，失败后自动切换到本地eSpeak。

def speak(text): try: # 尝试在线TTS online_tts(text) except Exception as e: # 降级到本地TTS print(f"在线TTS失败: {e}，降级到本地TTS") local_tts(text)

这个降级逻辑看起来简单，但在关键时刻能保证告警机不会完全失效。

6.5 告警风暴和冷却机制的设计

如果传感器数据抖动，或者阈值设置得太接近正常值，告警机可能会在短时间内反复触发。我遇到过温度在阈值附近波动，告警机每隔几秒就播报一次的情况，非常吵。

解法：除了前面提到的冷却时间，还可以加"迟滞"逻辑——触发告警的阈值和解除告警的阈值不同。比如温度超过30度触发告警，但要降到28度以下才解除告警状态。这样避免了在阈值附近反复触发。

ALERT_THRESHOLD = 30.0 CLEAR_THRESHOLD = 28.0 alert_active = False def check(temp): global alert_active if not alert_active and temp > ALERT_THRESHOLD: alert_active = True trigger_alert(temp) elif alert_active and temp < CLEAR_THRESHOLD: alert_active = False

这个迟滞窗口的设置需要根据实际场景调整。温度变化慢的场景，窗口可以设大一点；变化快的场景，窗口要小一点。

6.6 外壳和散热：别让硬件死在最后一步

树莓派4B和5的发热都不小，长时间运行温度能到60-70度。如果装在密闭外壳里，温度会更高，可能导致降频甚至死机。

解法：

• 用带散热孔的亚克力外壳，或者3D打印一个带风扇位的外壳。
• 加装小风扇，5V的静音风扇几块钱，接在树莓派的5V和GND引脚上就能转。
• 如果外壳是金属的，注意绝缘，避免电路板短路。
• 告警机通常放在角落或天花板附近，灰尘积累快，定期清理散热孔。

7. 这套方案还能怎么扩展

告警机做出来之后，你会发现它的潜力远不止"温度高了响一声"。基于树莓派的开放性，可以往好几个方向扩展。

7.1 接入更多类型的传感器

树莓派的GPIO和USB接口可以接入大量传感器：烟雾传感器、水浸传感器、门磁开关、人体红外感应、电流互感器、空气质量传感器。每加一种传感器，告警机的覆盖范围就扩大一圈。

接入方式通常有两种：数字传感器直接接GPIO，模拟传感器需要通过ADC芯片（比如MCP3008）转成数字信号。代码层面，每种传感器写一个采集函数，统一交给告警判断逻辑处理。

7.2 增加网络推送渠道

除了本地语音播报，还可以把告警信息推送到各种渠道：邮件、即时通讯工具、自定义的Webhook。这样即使人不在现场，也能第一时间知道异常。

以Webhook为例，很多即时通讯工具都支持自定义机器人，你只需要向特定的URL发送一个HTTP POST请求，就能把消息推到群里。

import requests def push_to_webhook(message): webhook_url = "你的webhook地址" data = { "msgtype": "text", "text": {"content": message} } requests.post(webhook_url, json=data)

7.3 加一块屏幕做状态显示

语音播报是"被动接收"，加一块小屏幕可以让人主动查看当前状态。SPI接口的TFT屏或者I2C接口的OLED屏都很适合树莓派，成本几十块钱。

屏幕上可以显示：当前温度湿度、告警阈值、最近一次告警时间、系统运行状态。用Python的PIL库或者专门的屏幕驱动库都能实现。

7.4 用树莓派Pico做分布式告警节点

如果告警点分布在不同房间，每个点都放一台树莓派4B成本太高。可以用树莓派Pico（几块钱一片）做分布式采集节点，通过无线模块把数据汇总到一台树莓派4B上统一处理。

Pico负责采集传感器数据和本地声光告警，树莓派4B负责TTS播报和网络推送。这样既降低了成本，又保证了核心功能的集中管理。

7.5 接入轻量级视觉识别

树莓派4B和5的算力已经可以跑一些轻量级的视觉模型。接上摄像头模块（比如OV5647），可以实现"检测到特定物体就告警"的功能。比如在仓库里检测到有人进入禁区，或者在产线上检测到产品摆放异常。

用YOLOv5的nano版本或者MobileNet SSD，在树莓派4B上可以达到几帧到十几帧的推理速度。对于告警机这种不需要实时视频分析、只需要定期检测的场景，这个性能完全够用。

不过视觉识别对算力和内存的占用比较大，如果告警机同时还要跑TTS和其他逻辑，建议用树莓派5或者把视觉识别放到单独的节点上。

8. 我的最终建议

如果你看到这里还在纠结"到底DIY还是买成品"，我给你一个简单的判断标准：

先问自己三个问题：第一，我的告警需求在未来一年内会不会变化？第二，我有没有至少一个周末的时间来折腾？第三，我能不能接受每隔几个月维护一次？

三个问题的答案都是"是"，那就走DIY路线，树莓派4B加USB声卡加TTS的方案足够你玩出花来。任何一个答案是"否"，那就买成品终端，省下来的时间和精力用在别的地方更划算。

我自己两台告警机，一台是DIY的树莓派4B方案，用来做实验室的环境监测和语音播报，因为需求经常变，DIY很合适。另一台是成品的水浸报警器，放在机房地板下面，就一个功能——检测到水就响，买了三年没管过，非常省心。

工具没有好坏，只有合不合适。想清楚自己要什么，答案自然就出来了。