企业官网建设流程全解析

如果你已经看完了这个系列的第一篇，把手上的影音硬件都定了下来，那现在的处境大概是：电视、功放、投影、播放器、智能灯全都堆在客厅，但各跑各的——电视用品牌的专用App，功放又得切换到另一个App，投影只配了一个半残废的遥控器，智能灯还得多开一个App。这时候你缺的不是又一台设备，而是一个能把它们全部串起来的中枢。Home Assistant（以下简称HA）就是干这个的。

这篇我完整走一遍HA在家庭影音系统里的落地过程：怎么选硬件、怎么用Docker Compose部署、初始化要做哪些设置、影音设备怎么接入、自动化怎么设计，最后把最容易翻车的坑单独拉出来讲。适合刚把硬件买齐、正打算搞软件中枢的朋友，也适合已经装好HA但不知道怎么把影音链路串起来的人。

1. 部署前先想清楚：HA 在影音系统里到底扮演什么角色

1.1 为什么影音系统需要中枢

很多人对“智能家庭影音”的第一反应是给电视配一个遥控器App，或者给功放买一个语音助手音箱。但实际体验过就知道，问题不在单个设备难控制，而在设备之间完全没有联动。

举个例子，你的播放源是蓝光播放器，功放是Denon AVR，显示设备是投影仪。手动操作的话，你要先按投影遥控器开机，等它预热；再切功放的输入源到Blu-ray；再去开电影灯、关展示灯；最后把手机上的Plex推流到播放器。这一套下来小两分钟，而且每一步都要切换不同的App或遥控器。

HA解决的是这件事：它把所有设备抽象成统一的实体，然后根据事件自动执行一套动作。你能定义一个“影院模式”：功放输入切到Blu-ray这个动作发生时，自动触发关灯、调暗壁灯、把投影仪电源打开、确认音量在合理范围。所有状态都集中在同一个面板，手机、平板、电脑都能访问。

影音系统比其他智能家居场景更依赖状态同步。灯光可以纯本地控制，但影音链路需要知道“现在在放什么”，才能决定要不要启动氛围、要不要把音量压下来、退出时要不要恢复。这个需求不是某个品牌App能解决的，只有统一的平台才做得到。这也是我建议所有影音玩家认真学一下HA的根本原因。

1.2 硬件选择：树莓派、迷你主机、旧电脑还是 NAS

部署HA的硬件方案其实不少，我直接给出结论性的对比：

如果你只跑HA，树莓派4完全够用。但“智能家庭影音系统”大概率还会加上媒体库、下载器、语音识别这类服务，这时候我更推荐N100迷你主机。理由很简单：HA本身对资源占用不大，真正吃资源的是转码、缩略图、日志这些周边服务；迷你主机功耗低、无风扇设计安静、CPU性能应付这些绰绰有余，内存可以上16G。我自己的部署机就是从树莓派4迁移到N100上的，迁移过程几乎无感。

如果你已经有NAS，直接在NAS上跑HA也完全可行，但要注意两点：一是NAS的Docker如果默认使用bridge网络，HA的设备发现会非常不稳定，必须能支持host网络模式；二是后续如果要接USB的Zigbee适配器或者蓝牙设备，NAS对USB设备的映射支持参差不齐，提前确认型号能不能挂载/dev/ttyUSB0。

1.3 环境准备：操作系统、Docker、目录规划

不管用哪种硬件，我都建议底层装64位的Debian或Ubuntu LTS系统。原因不复杂：这两个系统的Docker支持最好，内核较新，社区资料也最多。系统装好后，先更新再装Docker。

sudo apt update && sudo apt upgrade -y curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER newgrp docker docker --version

Docker装好后，建议把HA的配置目录和媒体目录先规划好，不要随便散落。我常用的一套结构是这样的：

sudo mkdir -p /opt/ha/config sudo mkdir -p /media/music /media/movies /media/backups sudo chown -R $USER:$USER /opt/ha /media

/opt/ha/config是HA的全部配置所在地，后续备份只需要打包这个目录；/media下面挂音乐、电影、备份，HA容器只读挂载进去，影音自动化里可以直接引用本地媒体文件（比如定时播放电台、播放片头音效）。目录规划这一步千万别偷懒，很多人的HA跑了一年后配置目录长成一团乱麻，就是因为当初没定规矩。

2. 用 Docker Compose 把 HA 跑起来：配置与细节

2.1 为什么不直接用 HAOS，而是选 Docker

Home Assistant的官方安装方式里，HAOS（烧录到整张SD卡或硬盘）是最省心的，自带加载项商店和备份功能。但在我这套影音系统里，我最终还是选了Docker Compose，核心原因有三个：

第一，影音系统里的附加服务不是一个HA插件能解决的。我需要同时跑MQTT broker、Node-RED、Plex或Jellyfin、下载工具，这些用Docker Compose统一管理比在HAOS里折腾加载项方便太多，容器间的网络、日志、升级都是同一套约定。

第二，迁移和回滚非常舒服。HA的配置就是/opt/ha/config目录，Docker Compose文件也是纯文本。换机器时把这俩目录拿过去，docker compose up -d就完事，不存在烧镜像、备份恢复的仪式感。

第三，升级路径清晰。想升级HA就是改镜像tag或执行docker compose pull，想回滚就改回旧tag。这对影音系统这种“平时不想折腾、但必须稳定”的场景特别友好。

当然代价也有：Docker部署没有HAOS的加载项商店，某些一键备份功能要自己手动配置。但对应的解决方式也不难，后面我会说到。

2.2 完整的 docker-compose 配置

我用的compose文件长这样，可以直接复制：

services: homeassistant: image: ghcr.io/home-assistant/home-assistant:stable container_name: homeassistant restart: unless-stopped network_mode: host privileged: true volumes: - /opt/ha/config:/config - /etc/localtime:/etc/localtime:ro - /media:/media:ro - /run/dbus:/run/dbus:ro environment: - TZ=Asia/Shanghai logging: driver: "json-file" options: max-size: "10m" max-file: "3"

这里有两个参数容易被忽略，但恰恰特别关键。

第一个是network_mode: host。HA需要向局域网广播mDNS（也叫Bonjour）来发现Chromecast、Sonos这类设备，还需要通过SSDP发现大部分电视和播放器。如果Docker默认使用bridge网络，容器相当于躲在NAT后面，广播和组播基本出不去，你会发现设备明明在同一个网络里但HA死活搜不到。用host模式后容器直接共享宿主机网络栈，这类网络发现全部恢复。代价是容器不再有独立端口映射，但这本身也是HA的推荐用法。

第二个是privileged: true。这个参数给了容器访问宿主机的所有硬件设备的权限。我在影音场景里需要它是因为要访问USB蓝牙适配器、USB声卡、可能的Zigbee遥控器接收器。如果你完全不需要这些设备，可以改成更精确的方式：

devices: - "/dev/ttyUSB0:/dev/ttyUSB0"

很多教程喜欢直接让你privileged，图省事，但真要接多个USB设备时建议按实际需要精确映射，避免容器有过度权限。我这里保留privileged是默认方案，你可以按自己的情况决定。

2.3 启动、看日志、首次访问

进入compose文件所在目录，执行：

cd /opt/ha docker compose up -d docker compose logs -f homeassistant

首次启动需要拉取镜像和初始化，日志会滚动一段时间。看到类似Home Assistant initialized in ...的输出，说明核心已就绪。这时候浏览器打开http://<服务器IP>:8123，就能看到创建账户的页面了。

如果打开页面发现空白或者提示无法连接，先别急着重启容器，等两三分钟再看。首次启动时HA会在后台建数据库、装依赖，慢一点的机器可能要几分钟。真有问题就用docker compose logs看具体报错，而不是凭感觉反复重启。

2.4 数据目录和备份习惯

HA的所有配置、设备状态、历史数据都落在/opt/ha/config里，备份的核心就是打包这个目录。我建议从第一天就养成每日备份的习惯，最简单粗暴的方式是cron加一行：

0 3 * * * tar -czf /media/backups/ha-$(date +\%F).tar.gz -C /opt/ha config && find /media/backups -name "ha-*.tar.gz" -mtime +7 -delete

这段会在每天凌晨3点打包整个config目录，并自动删除7天前的备份。恢复时把备份解压覆盖回/opt/ha/config，然后重启HA容器即可。

注意一点：恢复时尽量保持HA版本和备份时一致或向后兼容。虽然HA的配置迁移整体很顺，但跨大版本后某些设备实体ID可能发生变化，保险起见升级前一定做一次完整备份。

3. 初始化配置：账号、时区、系统选项和 HACS

3.1 第一次登录：账号、家庭位置、时区

浏览器打开8123端口，首屏会引导你创建管理员账户。这里有一个细节：用户名和密码不要跟路由器管理密码重复，后面会挂一大堆家庭设备，这台服务器实际上已经是整个影音系统的控制核心了，安全底线要有。

创建账户后，会要求设置家庭名称（比如“我的家”或“影音室”）、家庭位置、时区。时区一定选择Asia/Shanghai，不只是让时钟显示正确，更重要的是之后所有自动化、日出日落、日志时间都依赖它。如果你在区域里设置了准确的经纬度，HA还能计算日出日落时间，影音系统的灯光联动会用到这些数据。

然后进入“设置-系统”，把右上角的“高级模式”开关打开。这个开关不会增加什么神奇功能，但会显示更多实体细节和调试信息，排查问题时特别有用。

3.2 配置日志级别，给排查问题留后路

很多人装好HA直接用，等到设备发现不了、自动化不触发才想起看日志，结果日志里全是info级别的流水账，找不到关键信息。我建议在/opt/ha/config/configuration.yaml里主动加一段日志配置：

logger: default: info logs: homeassistant.components.discovery: debug homeassistant.components.ssdp: debug homeassistant.components.mqtt: debug

保存后重启HA。日常使用时保持info级别就够了，但discovery和ssdp这类网络发现的日志会单独以debug级别输出。以后遇到设备搜不到的情况，直接看日志就能精确定位是组播问题、防火墙问题还是集成本身的问题。

3.3 HACS：装不装，什么时候装

HACS（Home Assistant Community Store）是第三方集成和前端卡片的下载渠道，影音系统里很多好用的东西（比如更专业的媒体播放器前端卡片mini-media-player、某些国内流媒体平台集成）都通过它安装。但我的建议是：先用官方集成把设备接起来、自动化跑通，再装HACS补增强体验，不要一上来就装一堆第三方组件，出问题很难排查。

如果你决定装，流程很简单。先进入/opt/ha/config目录，创建custom_components目录，把HACS下载进去：

cd /opt/ha/config mkdir -p custom_components cd custom_components wget https://github.com/hacs/integration/releases/latest/download/hacs.zip unzip hacs.zip -d hacs rm hacs.zip

然后重启HA容器，在“设置-设备与服务”里添加HACS集成，它会引导你绑定GitHub账号。绑定成功后就可以在HACS商店里搜索安装第三方集成了。需要注意，HACS下载的组件需要重启HA或重新加载相关集成才能生效，安装后别急着问为什么没反应。

3.4 备份这件事：先测试恢复，再谈日常备份

上面我已经给了cron定时备份的写法，但这里必须强调一句：备份不可怕，可怕的是备份了却不会恢复。第一次部署完HA后，建议立刻手动做一次完整备份，然后在另一台机器（或者临时改个目录）里解压一份，按照上面的恢复方法跑一次，确认数据、实体、自动化都能正常加载。这个过程花不了半小时，但关键时刻能救命。

Docker部署下没有HAOS那种一键恢复的图形界面，但恢复逻辑非常简单：停掉HA容器，把config目录替换成备份里的内容，重新启动容器。只要备份是完整的，基本能恢复原状。

4. 影音设备接入实战：播放器、功放、电视逐个击破

4.1 媒体播放器：Google Cast、DLNA、Plex、Jellyfin

媒体播放器是整个影音系统里实体最多的一类。先明确一点：HA官方集成已经覆盖了绝大多数主流播放器，不要一上来就找第三方。

Google Cast（Chromecast内置的Google TV、电视内置Chromecast）是最丝滑的接入方式。HA在host网络模式下通常能自动发现局域网内的Cast设备，在“设置-设备与服务”里点“添加集成”，搜索Google Cast，会自动列出可发现设备。确认后，播放器实体就会出现在设备列表里，支持播放、暂停、音量、推流URL。我在客厅电视、书房音箱上都用的Cast接入，体验最稳。

DLNA/DMR是另一个通用协议，适合那些不支持Cast但支持DLNA的电视和音箱。官方集成会自动发现局域网里的DLNA渲染器。DLNA的缺点是状态同步有延迟，快进快退的响应不及时，所以我只把DLNA当兜底方案，能用IP控制或专属集成的设备优先用专属集成。

Plex、Jellyfin这类媒体库服务器也有官方或社区集成。Plex集成在“添加集成”里直接搜索Plex，用Plex账户授权后会自动同步服务器上的媒体库。Jellyfin需要在Jellyfin后台创建API Key，然后填地址和Key。接好之后，媒体播放器实体可以直接控制挂载在Plex/Jellyfin下的播放，配合之前规划的/media目录，本地文件也能被直接引用。

接入播放器时有个小建议：统一命名。HA自动生成的实体名字可能是一长串型号，比如media_player.chromecast_ultra_95f0a1。在“设置-设备与服务”里把每个设备的friendly_name改成“客厅电视”“书房音箱”这样有语义的名字。命名规范不只是好看，后面写自动化时引用实体名称会舒服很多。

4.2 功放和音响：Denon、Yamaha、Sonos

功放是影音系统中的“汇流排”，它的输入源切换直接决定了整套系统在看什么。Denon/Marantz功放有官方HEOS集成，添加集成时搜索Denon或HEOS，可以通过IP地址直连，也可以绑定HEOS账户。接入后，功放会出现在媒体播放器类别下，有一个source属性表示当前输入源，你可以通过动作media_player.select_source切换输入，比如从“Media Player”切到“Blu-ray”。

这里要记住一个坑：功放的IP地址必须固定。家用路由器的DHCP默认租约可能是一天或几天，IP变动后HA设备和实体全会失效。到路由器管理界面给功放、电视、投影这些固定设备绑定静态DHCP租约，这一步提前做了能避免很多莫名其妙的失联问题。

Sonos和Yamaha MusicCast各有官方集成。Sonos接入后，扬声器组件里的多个实体可以组成播放组，适合餐厅、客厅、阳台多音箱同时播放的场景。Yamaha MusicCast的使用方式类似。如果你用的是AirPlay音箱，也可以尝试AirPlay集成，但延迟和稳定性不如原生协议，实测下来响应速度和状态同步都一般。

4.3 电视和投影：webOS、SmartThings、IP控制兜底

电视接入优先走官方集成。LG电视用webOS集成，在“添加集成”里搜索webOS，它会通过局域网发现设备并在电视上弹确认框，确认后就能控制开关机、切换输入、启动应用。三星电视可以走官方SmartThings集成，需要先在SmartThings账户里绑定设备，再把令牌给HA；也可以用社区维护的Samsung Tizen集成直接局域网控制。

投影仪是最尴尬的设备。消费级投影大多没有完善的局域网控制协议，只有少数型号支持IP命令或RS232转网络。我的处理方式是：能网络控制的优先用集成，不能的用command_line集成来发送命令。比如某台投影支持通过TCP端口发指令开关机，就可以写成：

command_line: - switch: name: 投影仪电源 command_on: "python3 /config/scripts/projector_on.py" command_off: "python3 /config/scripts/projector_off.py"

如果你的投影连IP控制都不支持，那就只能在灯光、幕布联动上做文章了，投影本身的电源状态无法反馈到HA，自动化里只能用延时估算。

另外再说一下HDMI CEC。很多教程会把CEC作为万能方案，但实际上HA并没有成型的官方CEC集成，要走USB CEC适配器加自定义组件的路线，调试成本很高。我的建议是：在条件允许的情况下优先用各品牌的原生IP集成，CEC只作为备用方案。毕竟HA的价值在于把IP控制集中起来，而不是把每一根HDMI线都变成核心调试对象。

4.4 统一实体命名与区域划分

设备接入都完成之后，别急着写自动化，先把区域和命名整理清楚。在“设置-区域”里创建“影音室”“客厅”“书房”等区域，然后把相关设备拖进去。这一步对后面的自动化和语音控制非常有帮助。

实体命名方面，尽量保持“区域+功能+序号”的格式，比如“影音室墙灯”“影音室展示灯”“客厅主音箱”。HA允许你在界面里直接修改friendly_name，而不影响底层entity_id，所以可以大胆改名。改好名之后，你写自动化时引用的自然语言语义会清晰很多，也更方便家里人通过语音助手下指令时能准确对应到设备。

5. 自动化：把看电影变成“一件事”

5.1 触发方式怎么选：状态、语音、场景按钮

自动化设计的第一步是选触发源。在影音场景里，我总结的优先级是这样的：

• 功放source变化是最可靠的状态变化信号。一旦功放输入切到某个源，就意味着用户有明确意图，这时候联动灯光、投影、音量最自然。
• 电视开关机状态是另一个好信号。LG、三星这类电视通过IP控制后，power状态能实时同步到HA。
• 物理场景按钮是给“非折腾型”用户用的，放在沙发旁按一下比让家人学习App更友好。
• 语音控制适合低频操作，比如“打开蓝光播放器”“调暗灯光”，但高频的影院模式更适合状态触发。

我个人的习惯是：把状态变化作为主触发，把物理按钮和语音作为补充触发，尽量不要只依赖一种触发。因为状态触发偶尔会有几秒延迟，而按钮触发的确定性最高。

5.2 一个影院模式的完整自动化示例

下面是一个我在影音室里实际使用的影院模式自动化的核心逻辑，用HA的新版自动化YAML格式写：

alias: 影院模式开启 description: 功放输入源切到Blu-ray时进入影院模式 triggers: - trigger: state entity_id: media_player.denon_avr attribute: source to: "Blu-ray" for: "00:00:05" conditions: - condition: state entity_id: binary_sensor.ha_ready state: "on" actions: - action: light.turn_off entity_id: light.yingshiroom_display_light - action: light.turn_on target: entity_id: light.yingshiroom_wall_light data: brightness_pct: 30 - action: switch.turn_on entity_id: switch.projector_power - action: media_player.volume_set target: entity_id: media_player.denon_avr data: volume_level: 0.28 - action: notify.mobile_app_iphone data: title: 影院模式 message: 功放已切换，灯光已调暗 mode: single

简单拆解一下：

• trigger里的for: "00:00:05"是防抖，避免功放在短时间内来回切信号导致自动化反复触发。
• 关展示灯、开壁灯到30%亮度，是影音环境里比较舒服的灯光状态。
• 投影仪的开关用switch实体控制，如果投影不支持状态反馈，自动化结束后会有短暂的时间差，可以接受。
• volume_set直接设到0.28，避免上次看大片音量太响，一开机炸耳。你也可以改成“只调低不调高”，这个看个人习惯。
• notify推送不是必须，但我习惯开一个，方便确认自动化确实触发了，不用专门去看仪表盘。

5.3 退出影院模式：恢复灯光和处理无状态设备

有开就有关。影院模式的退出自动化一般这样写：功放关闭，或者功放source切到其他输入时触发。

alias: 影院模式退出 triggers: - trigger: state entity_id: media_player.denon_avr to: "off" conditions: [] actions: - action: light.turn_on entity_id: light.yingshiroom_display_light - action: light.turn_on target: entity_id: light.yingshiroom_wall_light data: brightness_pct: 100 - action: switch.turn_off entity_id: switch.projector_power - action: input_boolean.turn_off entity_id: input_boolean.movie_mode mode: single

注意投影仪的关闭：如果投影不支持状态反馈，直接switch.turn_off可能只是断电，但很多投影机直接断电会缩短灯泡寿命或导致关机不完整。所以如果投影没有可靠关机电信号，我建议要么用delay延时几秒后再断电，要么干脆保持通电只在自动化里关闭灯光，把投影关机留给用户手动或改用可反馈的电源插头。设计自动化之前，一定先确认每个设备的物理关机行为。

5.4 场景变量和状态标记

当自动化越来越多以后，很容易出现“两个自动化互相触发”的情况。建议引入input_boolean或input_select作为场景标记。比如input_boolean.movie_mode表示正在观影，input_boolean.music_mode表示正在听音乐。每个自动化开始前先判断场景标记状态，避免冲突。

例如，如果灯上有“调暗”指令来自影院模式，而另一个音乐模式也想调暗，那这两个自动化就会打架。实际做法是影院模式开启时置位input_boolean.movie_mode，退出时清除；音乐模式的自动化里先判断movie_mode是off才执行。这套做法在设备数量多以后非常值得坚持。

6. 外网访问和安全基线

6.1 局域网就是最常使用的入口

很多人在部署HA后的第一个念头就是“我要在外面也能访问”。但以我的经验，影音系统百分之九十的控制都发生在家里，局域网体验才是核心。HA官方App支持局域网自动发现，手机装上后不用填IP不用配端口，会自动连上实例。电脑上则直接把主页添加到书签栏，用起来非常顺手。

同时我建议开启App的“PWA添加到主屏幕”功能，从主屏幕打开HA就跟打开原生App一样，全屏无地址栏，使用体验好很多。这个阶段先把局域网内的操作做到顺手，再考虑外网。

6.2 外网访问：Nabu Casa 是低门槛的官方方案

如果确实需要在外面查看状态或控制设备，Nabu Casa是官方提供的云服务。在HA“设置-系统-远程访问”里，登录或创建Nabu Casa账户，点击启用就能得到一个固定的远程访问域名，不需要拥有公网IP，不需要自己配置端口转发，TLS证书也是自动管理的。

Nabu Casa是订阅制服务，价格在HA官网上写得很清楚。好处是全链路加密，不依赖你的网络环境，而且顺带打通了Alexa和Google Home的官方集成。这是最省心的方案，也是我最推荐的方案。

如果不想订阅，也有一些自建组网工具可以实现类似效果，但我不建议把它们复杂化，更不建议把HA的8123端口直接映射到公网。直接暴露管理端口到公网的后果是灾难性的，扫描器会在几分钟内找到你的实例，然后开始爆破。HA端到端的风险不只影响HA本身，还可能影响同一网络里的其他设备。

6.3 两步验证与长期访问令牌

安全基线有几条务必要做：

• 开启两步验证。在“设置-用户-你的用户”里可以启用TOTP（Google Authenticator这类），启动后每次登录都要输验证码。
• 使用长期访问令牌而不是明文密码。第三方App或脚本接入HA时，应该在“个人资料-安全”界面生成长期访问令牌，这个令牌可以单独撤销，不会影响主密码。
• 给家庭成员创建独立账户，权限不要全都给管理员。影音设备的状态查看和开关控制，普通用户可以完全胜任，管理员权限留着给真正会折腾的人。
• 保持更新。HA官方Docker镜像会频繁发布安全更新，建议至少每月docker compose pull && docker compose up -d一次，升级前把config目录备份一份。

7. 最容易翻车的几个坑：现象、排查、修复

7.1 容器起不来，日志里全是奇奇怪怪的报错

现象：docker compose up -d后容器反复重启，docker compose logs里看到模块加载失败或数据库初始化失败。

排查链路：先看是不是镜像架构不匹配。在树莓派上拉取了amd64镜像、或者在x86主机上拉取了aarch64镜像，都会导致启动失败。确认方式很简单：

docker inspect homeassistant --format '{{.Architecture}}' uname -m

如果架构没问题，再看是不是homeassistant版本问题和配置目录里的.storage老数据冲突。把config目录临时改名为config.bak，起一个全新容器，如果能起来，说明是历史数据问题，慢慢排查具体是哪个配置文件；如果全新也起不来，那就要检查Docker版本是否过旧，升级Docker再试。

7.2 Zigbee或蓝牙适配器在容器里用不了

现象：宿主机的/dev/ttyUSB0能识别，但HA里看不到设备。

这里其实不是HA的问题，是Docker没把USB设备传进去。你可以检查容器视角下的设备节点：

docker exec -it homeassistant ls -l /dev/ttyUSB0

如果提示不存在，说明compose文件里的privileged或devices映射没生效。使用privileged: true后重启容器一般能解决，但这也会把宿主机的所有设备暴露给容器。如果不想给全部权限，就在compose中显式加上：

devices: - "/dev/ttyUSB0:/dev/ttyUSB0"

另外一个隐藏坑是权限冲突：宿主机上如果有其他进程占用了这个USB串口，HA容器也会拿不到。用lsof /dev/ttyUSB0查一下占用进程，把冲突服务停掉。

7.3 设备发现不到：mDNS、host模式和防火墙的三角关系

现象：Chromecast、Sonos、部分电视在HA里搜不到，但在手机App里能看到。

这是Docker部署最典型的网络问题。排查链路是这样的：先确认compose里用的是不是network_mode: host，如果不是，改成host重启；再检查宿主机防火墙是否放行UDP 5353（mDNS）和SSDP需要的UDP 1900。企业级网络环境里，还要看路由器是否开启了AP隔离或组播隔离，这一项会直接阻断整个局域网的设备发现。

如果你用的是NAS上的Docker，这一步更要注意NAS的Docker Manager默认可能开了bridge模式，一定要找到“使用与宿主机相同的网络”对应选项并开启。

7.4 自动化提前八小时触发：时区错乱

现象：自动化的时间触发总是比预期早8小时，比如定了晚上8点开氛围灯，结果中午12点就触发了。

原因很直白：容器或系统时区没设为Asia/Shanghai，HA内部使用UTC时间。compose里没有设置TZ=Asia/Shanghai，或者宿主机的/etc/localtime没挂进容器，就会这样。

修复就是回到前面compose配置，加上环境变量和localtime挂载，然后重启容器。这属于基础的配置问题，但因为一次部署大概率只遇到一次，很多人过了很久才反应过来。

最后再说一个我自己的实操习惯：把所有部署相关的文件，也就是docker-compose.yml、configuration.yaml、automations.yaml这些，放进一个Git仓库里管理，每次改动都提交一次。换机器、回滚、对比改动，全都凭Git记录说话，比“我记得我改过”可靠得多。这个系列讲的是影音系统，但这个习惯延伸到整个智能家居运维都通用。下一篇我会继续讲语音控制、媒体库和音箱组的联动，到时候见。