企业官网建设流程全解析

智能家居网关这个东西，我从三年前就开始折腾了。最早是用一台旧笔记本跑Home Assistant，功耗高、噪音大，放在客厅里跟个小服务器似的，家里人意见很大。后来换过各种方案，路由器刷固件、旧手机改造、迷你主机装Linux，兜兜转转一圈，最后还是回到了树莓派上。原因很简单：功耗低、GPIO可扩展、社区资源丰富、价格也能接受。现在我用树莓派4B做核心网关，跑EMQ X Edge做本地MQTT Broker，再用EMQ X Kuiper做边缘流式数据处理，整套系统跑了快一年，稳定性相当不错，断电重启后自动恢复，基本不用管。

这套方案解决的核心问题是：让家里的智能设备在断网状态下依然能联动工作，同时把敏感数据留在本地，不上传到云端。适合有一定Linux基础、想自己动手搭建智能家居中枢的玩家，也适合做物联网相关毕设的同学参考。整套硬件成本控制在500元以内，软件全部开源，没有订阅费用。

1. 整体方案设计与选型思路

1.1 为什么选树莓派而不是其他硬件

市面上做智能家居网关的硬件方案很多，我大致列一下自己考虑过的几种：

我最终选树莓派4B（4GB内存版），核心原因是它能在低功耗和足够性能之间取得平衡。MQTT Broker加上规则引擎，日常内存占用在600MB左右，CPU负载长期低于15%，完全够用。树莓派5当然更好，PCIe接口可以接NVMe固态，但价格贵了一截，而且发热量明显更大，需要主动散热。如果你手头已经有树莓派4B，直接用它就行，没必要为了这个项目专门升级。

注意：如果你打算7x24小时运行，强烈建议用USB SSD替代SD卡。我第一年用SD卡，平均三个月左右就会出现文件系统损坏，换SSD之后跑了快一年没出过问题。

1.2 为什么选EMQ X Edge + Kuiper这套组合

智能家居网关的核心职责其实就三件事：设备接入、消息路由、本地自动化。围绕这三件事，我对比过几种主流方案：

• Home Assistant + Mosquitto：生态最完善，但HA本身比较重，插件多了之后启动慢，而且它的自动化引擎在复杂规则场景下不够灵活。
• Node-RED + Mosquitto：可视化编排很直观，但流程复杂之后性能下降明显，调试也麻烦。
• EMQ X Edge + Kuiper：Edge负责MQTT接入，Kuiper负责流式SQL规则处理，两者配合非常轻量，资源占用低，规则用SQL写，清晰好维护。

我选这套组合的关键理由是Kuiper的SQL规则引擎。举个例子，我想实现"如果温度传感器连续3次读数超过30度，且人体传感器检测到有人，就打开风扇"这种带时间窗口和条件的规则，用Kuiper写就是一条SQL的事，用HA的YAML写会非常啰嗦。而且Kuiper支持在边缘端做数据过滤和聚合，只有需要的数据才转发出去，减少了不必要的网络流量。

EMQ X Edge是EMQ X的轻量版，专门为边缘设备设计，支持MQTT 3.1.1和5.0协议，内置了Web管理界面，配置起来比Mosquitto方便很多。Kuiper则是同一个团队出的边缘流处理引擎，两者集成度很好，可以无缝对接。

1.3 网络拓扑与数据流向设计

整套系统的数据流向是这样的：

传感器/设备 → MQTT发布 → EMQ X Edge（Broker）→ Kuiper（规则处理）→ 执行器/转发

具体来说，Zigbee传感器通过zigbee2mqtt网关转成MQTT消息，WiFi设备直接连Broker，所有消息统一汇聚到EMQ X Edge。Kuiper订阅Broker上的主题，按照预设的SQL规则做过滤、聚合、判断，然后要么发布控制指令到执行器主题，要么把数据转发到外部（比如手机App、云端备份）。

这个设计的好处是解耦。设备只管发消息，规则只管处理消息，执行器只管收指令，任何一环出问题都不影响其他部分。我试过在Kuiper里加规则、改规则，完全不用动设备端配置，非常灵活。

2. 树莓派系统准备与基础环境搭建

2.1 系统烧录与基础配置

树莓派系统我推荐用Raspberry Pi OS Lite（64位），不带桌面环境，省资源。如果你习惯Ubuntu，用Ubuntu Server 22.04 for Raspberry Pi也可以，但要注意ARM64架构下部分软件的安装方式略有不同。

烧录步骤不复杂，用Raspberry Pi Imager就行：

1. 下载并安装Raspberry Pi Imager（Windows/macOS/Linux都有）
2. 选择"Raspberry Pi OS Lite (64-bit)"
3. 选择存储设备（SD卡或USB SSD）
4. 点击齿轮图标，提前配置好WiFi、SSH、用户名密码、时区
5. 写入，等待完成

这里有个小技巧：在Imager的高级设置里直接开启SSH并配置WiFi，这样烧录完插电就能远程连接，不需要接显示器和键盘。我早期不知道这个功能，每次都接一堆线，后来发现直接在烧录时配置好，省事太多了。

烧录完成后，把存储设备插到树莓派上，通电，等一两分钟，然后用SSH连接：

ssh pi@192.168.1.xxx

第一次登录后，先做几件基础事情：

# 更新系统 sudo apt update && sudo apt upgrade -y # 设置时区（如果烧录时没设） sudo timedatectl set-timezone Asia/Shanghai # 安装常用工具 sudo apt install -y curl wget vim htop git unzip

2.2 系统优化与稳定性调优

树莓派长期运行，有几个优化必须做，不然迟早出问题。

第一，关闭不必要的服务。Lite版已经比较精简了，但蓝牙、avahi-daemon这些如果不用可以关掉：

sudo systemctl disable bluetooth sudo systemctl disable avahi-daemon

第二，配置日志限制。默认情况下systemd日志会无限增长，SD卡很快就被写满。限制一下：

sudo vim /etc/systemd/journald.conf # 修改以下两行 SystemMaxUse=100M RuntimeMaxUse=50M

然后重启日志服务：

sudo systemctl restart systemd-journald

第三，如果用的是SSD，开启TRIM。这个对SSD寿命很重要：

sudo systemctl enable fstrim.timer sudo systemctl start fstrim.timer

第四，设置swap。树莓派4B的4GB内存跑这套系统够用，但为了保险起见，保留1GB的swap。默认的dphys-swapfile配置就行，不用改。如果你用的是2GB内存版，建议把swap调到2GB。

实操心得：我踩过最大的坑就是SD卡寿命。第一套系统跑了三个月，某天突然SSH连不上，接显示器一看，文件系统只读挂载了。后来查日志发现是SD卡坏块。换SSD之后，同样的负载跑了快一年，一点问题没有。所以如果你打算长期运行，SSD是必须的，别省这个钱。

2.3 Docker环境安装

我强烈建议用Docker来部署EMQ X Edge和Kuiper，原因有三：隔离性好、升级方便、配置清晰。直接在宿主机上装也不是不行，但版本管理和依赖冲突会很头疼。

安装Docker：

# 官方一键脚本 curl -fsSL https://get.docker.com | sh # 把当前用户加入docker组，免sudo sudo usermod -aG docker $USER # 重新登录使组生效 exit

重新SSH登录后，验证一下：

docker version docker compose version

如果docker compose提示找不到命令，可能需要单独安装compose插件：

sudo apt install -y docker-compose-plugin

Docker装好后，建议配置一下日志驱动，避免容器日志把磁盘写满：

sudo vim /etc/docker/daemon.json

写入：

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

然后重启Docker：

sudo systemctl restart docker

3. EMQ X Edge部署与MQTT接入配置

3.1 用Docker部署EMQ X Edge

EMQ X Edge的Docker镜像官方有提供，直接拉取就行。我习惯用docker compose来管理，配置文件清晰，重启也方便。

先创建工作目录：

mkdir -p ~/smart-home/emqx-edge/{data,log,etc} cd ~/smart-home/emqx-edge

创建docker-compose.yml：

version: '3.8' services: emqx-edge: image: emqx/emqx-edge:latest container_name: emqx-edge restart: unless-stopped ports: - "1883:1883" # MQTT - "8883:8883" # MQTT over TLS - "8083:8083" # WebSocket - "8084:8084" # WebSocket over TLS - "18083:18083" # Dashboard volumes: - ./data:/opt/emqx/data - ./log:/opt/emqx/log - ./etc:/opt/emqx/etc environment: - EMQX_NAME=emqx-edge - EMQX_HOST=127.0.0.1 healthcheck: test: ["CMD", "/opt/emqx/bin/emqx", "ctl", "status"] interval: 30s timeout: 10s retries: 3

启动：

docker compose up -d

等十几秒，查看状态：

docker compose ps docker compose logs -f emqx-edge

看到EMQX is started!就说明启动成功了。

3.2 Dashboard初始配置与安全加固

EMQ X Edge自带Web管理界面，默认端口18083。浏览器打开http://树莓派IP:18083，默认账号admin，密码public。

第一件事就是改密码。默认密码是公开的，不改等于把家门钥匙挂在门口。在Dashboard的"Users"页面修改admin密码，或者用命令行：

docker exec -it emqx-edge /opt/emqx/bin/emqx ctl admins passwd admin 你的新密码

第二件事是创建独立的MQTT用户。不要让设备用admin账号连MQTT，权限太大。在Dashboard的"Access Control" → "Authentication"里，添加一个Password-Based认证：

• 认证方式：Password-Based
• 数据源：Built-in Database
• 添加用户：比如home-device，密码设一个强密码

然后在"Authorization"里配置ACL规则，限制这个用户只能发布和订阅特定主题：

允许 home-device 发布 home/sensor/# 允许 home-device 订阅 home/control/# 拒绝 其他所有

这样即使某个设备被攻破，影响范围也有限。

第三件事是关闭匿名访问。在"Management" → "MQTT"里，把Allow Anonymous关掉。默认是开启的，任何人不认证就能连，非常危险。

注意：改完认证配置后，记得在Dashboard里点"Save"并"Reload"，不然不生效。我第一次改完忘了重载，排查了半天为什么匿名还能连。

3.3 设备接入与主题规划

主题规划是MQTT网关的核心设计。我踩过的坑是：一开始随便起主题名，设备多了之后完全乱套，改起来要动所有设备配置。后来重新规划了一套命名规范，分享给你：

home/{房间}/{设备类型}/{设备ID}/{属性}

举例：

• home/livingroom/temperature/sensor01/state— 客厅温度传感器状态
• home/bedroom/light/light01/set— 卧室灯控制指令
• home/kitchen/smoke/smoke01/state— 厨房烟雾报警器状态

规则是：传感器用state后缀发布状态，执行器用set后缀接收指令。这样Kuiper写规则时，订阅home/+/+/+/state就能拿到所有传感器数据，订阅home/+/+/+/set就能控制所有执行器。

设备接入测试，用mosquitto客户端工具：

# 安装客户端 sudo apt install -y mosquitto-clients # 订阅测试 mosquitto_sub -h localhost -p 1883 -u home-device -P 你的密码 -t 'home/#' -v # 另开一个终端，发布测试 mosquitto_pub -h localhost -p 1883 -u home-device -P 你的密码 -t 'home/livingroom/temperature/sensor01/state' -m '{"value": 25.6, "unit": "C"}'

如果订阅端能收到消息，说明Broker工作正常。

3.4 持久化与会话配置

MQTT有个很重要的概念叫持久会话（Persistent Session）。如果设备断线重连，持久会话能让Broker保留它订阅的主题和未接收的消息。对于传感器设备，这个功能很关键，不然断线期间的数据就丢了。

在EMQ X Edge的配置里，找到mqtt相关配置，确保：

# 在Dashboard的Management → MQTT里 Session Expiry Interval: 3600 # 会话过期时间，秒 Maximum QoS: 2 Retain Available: true

对于重要的传感器数据，发布时用QoS 1，确保至少送达一次。控制指令用QoS 1或2，看你对可靠性的要求。

Retain标志也很有用。比如灯的状态，发布时带上retain，新订阅的客户端立刻就能收到当前状态，不用等下一次状态更新。我在Kuiper规则里处理灯状态时，就依赖retain消息来做初始状态同步。

4. EMQ X Kuiper规则引擎实战

4.1 Kuiper部署与Broker对接

Kuiper的Docker部署同样简单。先创建工作目录：

mkdir -p ~/smart-home/kuiper/{data,log,etc} cd ~/smart-home/kuiper

创建docker-compose.yml：

version: '3.8' services: kuiper: image: lfedge/ekuiper:latest container_name: kuiper restart: unless-stopped ports: - "9081:9081" # REST API - "20498:20498" # 内部通信 volumes: - ./data:/kuiper/data - ./log:/kuiper/log - ./etc:/kuiper/etc environment: - KUIPER__BASIC__CONSOLELOG=true - KUIPER__BASIC__RESTPORT=9081 depends_on: - emqx-edge

启动：

docker compose up -d

Kuiper启动后，需要配置它连接EMQ X Edge。有两种方式：通过REST API配置，或者通过配置文件。我推荐用REST API，因为可以脚本化，重装系统后一键恢复。

先测试Kuiper的REST API是否可用：

curl http://localhost:9081/

应该返回Kuiper的版本信息。

然后配置MQTT源，让Kuiper能连上EMQ X Edge：

curl -X POST http://localhost:9081/metadata/sources/mqtt/confKeys \ -H "Content-Type: application/json" \ -d '{ "emqx-edge": { "server": "tcp://emqx-edge:1883", "username": "home-device", "password": "你的密码", "qos": 1, "keepAlive": 60 } }'

注意：这里的emqx-edge是Docker容器名，因为Kuiper和EMQ X Edge在同一个Docker网络里，可以直接用容器名通信。如果你把Kuiper装在宿主机上，就要用tcp://localhost:1883。

4.2 用SQL写第一条自动化规则

Kuiper的规则用SQL描述，非常直观。我拿一个实际场景来演示：客厅温度超过28度时，自动打开风扇。

首先，在Kuiper里创建一个流（Stream），定义数据来源：

CREATE STREAM livingroom_temp ( value FLOAT, unit STRING ) WITH ( DATASOURCE = 'home/livingroom/temperature/sensor01/state', FORMAT = 'json', CONF_KEY = 'emqx-edge' );

这条SQL的意思是：从home/livingroom/temperature/sensor01/state主题接收JSON格式的消息，解析出value和unit两个字段。

然后创建规则：

SELECT value, 'fan01' AS device_id, 'on' AS action FROM livingroom_temp WHERE value > 28

这条规则的意思是：当温度值大于28时，输出一个包含设备ID和动作的消息。

最后配置规则的动作（Action），把输出发布到MQTT主题：

curl -X POST http://localhost:9081/rules \ -H "Content-Type: application/json" \ -d '{ "id": "rule_fan_on", "sql": "SELECT value, \"fan01\" AS device_id, \"on\" AS action FROM livingroom_temp WHERE value > 28", "actions": [ { "mqtt": { "server": "tcp://emqx-edge:1883", "topic": "home/livingroom/fan/fan01/set", "username": "home-device", "password": "你的密码", "qos": 1, "sendSingle": true } } ] }'

这样，当温度超过28度时，Kuiper会自动往home/livingroom/fan/fan01/set主题发一条{"device_id": "fan01", "action": "on"}的消息，风扇接收到就打开了。

4.3 带时间窗口的复杂规则

简单阈值规则只是开胃菜，Kuiper真正强大的地方是时间窗口和状态聚合。我举一个更贴近实际的例子：如果温度连续3次读数超过30度，才触发报警，避免传感器抖动导致误报。

SELECT AVG(value) AS avg_temp, COUNT(*) AS sample_count FROM livingroom_temp GROUP BY TUMBLINGWINDOW(ss, 30) HAVING AVG(value) > 30 AND COUNT(*) >= 3

这里用了TUMBLINGWINDOW(ss, 30)，意思是30秒的滚动窗口。每30秒统计一次，如果窗口内平均温度超过30度且样本数不少于3，就触发。

再复杂一点，结合多个数据源。比如只有人在家且温度高时才开空调：

SELECT t.value AS temperature, p.present AS someone_home FROM livingroom_temp t INNER JOIN presence_stream p ON t.value > 28 AND p.present = true

Kuiper支持流之间的JOIN，不过要注意JOIN的窗口对齐问题。实际用的时候，我建议把多个传感器的数据先汇聚到一个流里，再做判断，这样逻辑更清晰。

4.4 规则调试与性能观察

Kuiper的规则写完之后，怎么确认它真的在工作？我常用的几个方法：

第一，看规则状态。通过REST API查询：

curl http://localhost:9081/rules/rule_fan_on/status

返回里会有running状态和消息处理计数。

第二，用MQTT客户端订阅输出主题。比如订阅home/livingroom/fan/fan01/set，然后手动发布一条高温数据，看是否收到控制指令：

# 订阅输出 mosquitto_sub -h localhost -u home-device -P 你的密码 -t 'home/livingroom/fan/fan01/set' -v # 另开终端，发布高温数据 mosquitto_pub -h localhost -u home-device -P 你的密码 -t 'home/livingroom/temperature/sensor01/state' -m '{"value": 31.5, "unit": "C"}'

如果订阅端收到{"device_id": "fan01", "action": "on"}，说明规则生效了。

第三，看Kuiper日志。如果规则没触发，日志里会有线索：

docker logs -f kuiper

常见的问题是SQL语法错误、主题名写错、或者认证失败。日志里都会明确提示。

实操心得：Kuiper的SQL调试有个小技巧——先用SELECT * FROM stream把原始数据打出来，确认数据格式和字段名都对，再写复杂的WHERE和JOIN。我一开始直接写复杂规则，结果字段名大小写不对，排查了好久才发现。

5. 常见问题排查与稳定性维护

5.1 设备频繁掉线怎么排查

设备掉线是智能家居网关最常见的问题。我遇到过好几次，总结下来原因主要有三类：

第一类，WiFi信号弱。特别是Zigbee网关和WiFi设备混用的时候，2.4GHz频段拥挤，设备容易掉。解决办法是把Zigbee网关远离路由器，或者把WiFi的2.4GHz信道固定到1、6、11中的一个，减少干扰。

第二类，MQTT KeepAlive设置不合理。默认60秒，如果设备网络不稳定，60秒内没发心跳就被Broker踢了。可以在设备端把KeepAlive调大，比如120秒，同时Broker端把keepalive_backoff调大。

第三类，客户端ID冲突。两个设备用了同一个Client ID，互相踢下线。这个在批量刷固件时特别容易发生。解决办法是确保每个设备的Client ID唯一，我习惯用设备类型_设备ID的格式。

排查方法：在EMQ X Edge的Dashboard里，看"Clients"页面，掉线的设备会显示为断开状态。点进去看连接日志，能看到断开原因。

5.2 Kuiper规则不触发的排查思路

规则不触发，按这个顺序排查：

我遇到最多的是字段名大小写问题。Kuiper的SQL对字段名大小写敏感，value和Value是两个不同的字段。设备端发的是小写，SQL里写了大写，就匹配不上。

5.3 系统资源监控与告警

树莓派长期运行，资源监控不能少。我装了一个轻量的监控方案：node_exporter + Prometheus + Grafana，但如果你不想搞这么复杂，用简单的脚本也行。

我自己的做法是写一个cron脚本，每5分钟检查一次关键指标，超过阈值就通过MQTT发告警：

#!/bin/bash # /home/pi/check_system.sh CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1) MEM_USAGE=$(free | grep Mem | awk '{print $3/$2 * 100.0}') DISK_USAGE=$(df / | tail -1 | awk '{print $5}' | cut -d'%' -f1) if (( $(echo "$CPU_USAGE > 80" | bc -l) )); then mosquitto_pub -h localhost -u home-device -P 你的密码 \ -t 'home/system/alert' -m "{\"type\":\"cpu\",\"value\":$CPU_USAGE}" fi if (( $(echo "$MEM_USAGE > 85" | bc -l) )); then mosquitto_pub -h localhost -u home-device -P 你的密码 \ -t 'home/system/alert' -m "{\"type\":\"memory\",\"value\":$MEM_USAGE}" fi if [ "$DISK_USAGE" -gt 85 ]; then mosquitto_pub -h localhost -u home-device -P 你的密码 \ -t 'home/system/alert' -m "{\"type\":\"disk\",\"value\":$DISK_USAGE}" fi

加到crontab：

crontab -e # 添加 */5 * * * * /home/pi/check_system.sh

然后在Kuiper里加一条规则，订阅home/system/alert，转发到手机通知。

5.4 数据备份与快速恢复

网关跑久了，配置和数据越来越多，备份很重要。我每周自动备份一次，备份内容包括：

• EMQ X Edge的data目录（包含认证用户、ACL规则）
• Kuiper的data目录（包含流、规则定义）
• Docker compose文件

备份脚本：

#!/bin/bash # /home/pi/backup.sh BACKUP_DIR="/home/pi/backups" DATE=$(date +%Y%m%d) mkdir -p $BACKUP_DIR # 备份EMQ X Edge数据 tar -czf $BACKUP_DIR/emqx-edge-$DATE.tar.gz -C /home/pi/smart-home/emqx-edge data # 备份Kuiper数据 tar -czf $BACKUP_DIR/kuiper-$DATE.tar.gz -C /home/pi/smart-home/kuiper data # 备份compose文件 cp /home/pi/smart-home/emqx-edge/docker-compose.yml $BACKUP_DIR/emqx-edge-compose-$DATE.yml cp /home/pi/smart-home/kuiper/docker-compose.yml $BACKUP_DIR/kuiper-compose-$DATE.yml # 删除30天前的备份 find $BACKUP_DIR -name "*.tar.gz" -mtime +30 -delete find $BACKUP_DIR -name "*.yml" -mtime +30 -delete

恢复的时候，把备份文件解压回对应目录，重新docker compose up -d就行。我实测过，从零恢复到完整运行，15分钟内搞定。

注意：备份文件最好同步一份到NAS或另一台机器上。我有一次树莓派SSD坏了，备份文件也在同一块盘上，结果全丢了。后来改成备份到NAS，才安心。

6. 扩展玩法与进阶方向

6.1 接入Zigbee设备

树莓派本身没有Zigbee模块，需要外接一个Zigbee协调器，比如CC2652P或ConBee II。然后跑zigbee2mqtt，把Zigbee设备转成MQTT消息。

zigbee2mqtt的Docker部署：

services: zigbee2mqtt: image: koenkk/zigbee2mqtt:latest container_name: zigbee2mqtt restart: unless-stopped volumes: - ./data:/app/data - /run/udev:/run/udev:ro devices: - /dev/ttyUSB0:/dev/ttyUSB0 environment: - TZ=Asia/Shanghai ports: - "8080:8080"

配置data/configuration.yaml：

mqtt: server: mqtt://emqx-edge:1883 user: home-device password: 你的密码 base_topic: zigbee2mqtt serial: port: /dev/ttyUSB0 adapter: zstack advanced: network_key: GENERATE

启动后，Zigbee设备的消息会发布到zigbee2mqtt/{设备名}主题。你可以在Kuiper里订阅这些主题，和WiFi设备的数据统一处理。

6.2 本地语音控制

树莓派4B的性能跑本地语音识别有点吃力，但跑简单的关键词唤醒是够的。我试过用Porcupine做唤醒词检测，配合Vosk做离线语音识别，识别"打开客厅灯"这类简单指令，准确率还行。

流程是：麦克风采集 → Porcupine检测唤醒词 → Vosk识别指令 → 解析成MQTT消息 → 发布到控制主题。

这个方案的好处是完全离线，不依赖任何云服务，隐私性好。缺点是识别准确率不如云端，复杂指令识别不了。适合做简单的开关控制。

6.3 数据持久化与可视化

MQTT消息默认不存储，历史数据查不了。我加了一个Telegraf + InfluxDB + Grafana的组合，把传感器数据存下来，做趋势图。

Telegraf订阅MQTT主题，写入InfluxDB：

[[inputs.mqtt_consumer]] servers = ["tcp://localhost:1883"] topics = ["home/+/+/+/state"] username = "home-device" password = "你的密码" data_format = "json" tag_keys = ["device_id"] [[outputs.influxdb_v2]] urls = ["http://localhost:8086"] token = "你的token" organization = "home" bucket = "sensors"

Grafana连InfluxDB，就能画出温度、湿度、功耗的曲线图。我用了半年，发现了一些有意思的规律，比如客厅温度在下午3点左右达到峰值，空调提前半小时开效果最好。

6.4 边缘AI推理

树莓派5的NPU和更强的CPU，让它能跑一些轻量AI模型。我试过在树莓派5上部署YOLOv5的量化版本，做简单的人形检测，配合摄像头实现"有人才开灯"。

流程是：摄像头采集 → YOLOv5推理 → 检测到人 → 发布MQTT消息 → Kuiper规则触发开灯。

这个方案比PIR传感器更精准，能区分人和宠物。但树莓派5跑YOLOv5帧率只有5-10fps，做实时检测勉强够用。如果要做更复杂的识别，建议用专门的AI加速棒。

整套系统跑下来，我最深的体会是：智能家居网关的核心不是功能多，而是稳定。功能再多，三天两头掉线，家里人很快就会失去耐心。所以我的建议是先把基础架构搭稳，MQTT Broker和规则引擎跑顺了，再慢慢加设备、加规则。每加一个功能，观察一周，确认稳定了再加下一个。这样虽然慢，但系统会越来越可靠，最终变成一个真正能用的家庭基础设施。