影院模式与 NAS 联动

一个「开关」拉满整个客厅

影院模式是展示联动能力最好的场景：一个动作下去，灯光、窗帘、电视、音响、空调同时变化——而这一切的起点只是一个 helper 开关。它把第 2 章的工具全用上了：helper 触发、scene 存氛围、script 编排过程、event 做跨设备通信。

本篇用一个完整案例把前面学到的零件串成一台「戏」。

拆解「看一部电影」这件事

先别写配置，把人实际看电影的步骤拆开：

  1. 找到遥控器，打开电视，切到 HDMI；
  2. 关顶灯，留一盏氛围灯；
  3. 拉上窗帘（白天）；
  4. 空调调到舒适温度；
  5. 音响切到观影模式。

五件事里没有一件难，但每天凑在一起就烦。影院模式的目标是：按一下，五件事自己发生。这五件事就是自动化要捕捉的「剧本」，写代码之前先把它列清楚，是做好任何场景自动化的第一步。

拆解之所以重要，是因为它决定了你该用什么工具：五件事有明确先后（窗帘没关好灯就暗了会扑街），所以要 script 而不能只靠 scene；氛围是纯状态（灯光组合），所以交给 scene 而不是逐条写 service。流程像剧本，状态像照片，这个判断贯穿全篇。

用 helper 当总闸

创建一个 input_boolean.theater_mode，它是整个场景的「总闸」。触发它的可以是：

  • 仪表盘按钮（家人最爱）
  • 无线按钮的某一档按键（物理快捷键）
  • 语音指令（「打开电视，看电影模式」）
  • 手机 App 快捷方式

总闸的设计意图是把「入口」和「执行」解耦：入口想加几个加几个，执行逻辑只认这一个开关。

所有入口统一修改同一个布尔开关，剩下的交给状态触发：当 input_boolean.theater_mode 变为 on 时，自动调用 script.theater_on；变为 off 时调 script.theater_off。这样部署在家人手机里的 App、墙上的按钮、语音助手全都是等价的入口，没有任何一个入口需要复制整套逻辑。

用 script 编排过程

核心是一个 script：

script:
  theater_on:
    alias: 开启影院模式
    mode: restart
    sequence:
      - service: cover.close_cover
        target:
          entity_id: cover.living
      - wait_template: >-
          {{ is_state('cover.living', 'closed') }}
        timeout: "00:00:20"
      - service: scene.turn_on
        target:
          entity_id: scene.theater_lights
      - service: media_player.turn_on
        target:
          entity_id: media_player.tv
      - service: climate.set_temperature
        target:
          entity_id: climate.ac
        data:
          temperature: 24

注意两个细节：script 用 restart 模式（重复触发会重来而不是被忽略）；wait_template 让窗帘先就位再进入下一步（设备顺序执行，避免一窝蜂）。这两处是剧本和清单的分水岭。

另外注意 sequence 的顺序刻意做了安排：窗帘先动，然后才是灯和播放设备。原因是窗帘电机声音大，先把它干完，等灯变暗、音响响起的时候，环境里就只剩电影的声画了。script 的顺序本身就是体验设计，随手排的顺序和精心排的顺序，家人感受得到差别。

用 scene 存氛围

灯光部分交给 scene：顶灯 10%、落地灯暖光、灯带 30%，存成一个「影院灯光」场景。改氛围时只改场景，不动 script——每个工具只做它擅长的事。

影院模式链路

和 NAS 联动

家里有 NAS 的话能再进一步。联动通常分两类：

联动类型 例子
状态读取 下载完成、转码完成、硬盘休眠
设备控制 唤醒 NAS、启动容器、关机

最常见的两种玩法：

  1. 观影时保安静：影院模式触发后，让转码任务暂缓或容器暂停（通过 webhook 调 NAS 接口）。
  2. 下载完成推送：NAS 下载完一部新片，推一条通知到 HA，家人点了直接播放。NAS 侧的 Webhook 回调 HA 的 webhook 触发器即可，相关部署方式可参考 《群晖 DSM 指南》。

第二类玩法更有生活感：孩子心心念念的新一季下好了，手机弹出提醒，一键就能在客厅电视上播。这种小细节是「智能家庭」真正打动人的地方。

这类联动的技术底座值得多说一句：NAS 侧通常没有 HA 的原生集成，但几乎都支持 webhook 或脚本。NAS 完成任务时向 HA 的 webhook URL 发个请求，HA 收到后触发「下载完成」事件或直接发通知。反过来，HA 调用 NAS 的 API 也能唤醒休眠的机器。接口不复杂，难的是把两个系统的「词表」对齐，而这正是事件总线和 webhook 的用武之地。

投影仪的特殊处理

投影仪比电视麻烦：开要预热、关要散热。直接断电会损寿命，所以自动化的「关影院模式」必须是：

  1. 发送软关机指令；
  2. 等待风扇停转（通过功率传感器或固定时长）；
  3. 才允许断电。
- service: media_player.turn_off
  target:
    entity_id: media_player.projector
- delay: "00:01:30"
- service: switch.turn_off
  target:
    entity_id: switch.projector_outlet

固定 90 秒是简化做法；有功率插座时换成 wait_template 判断「功率低于 5W 才断电」更优雅。设备自动化里，等待是最体现对硬件尊重的地方。

投影幕布同理：升降都需要时间，上下指令之间留足延时，否则幕布卡在半空既难看又伤电机。用 wait_template 监听幕布到位的状态再做下一步，是最稳妥的做法。这类等待写起来啰嗦，却是「自动化替你守着设备」的实质内容。

退出模式与异常处理

退出（script 叫 theater_off）基本是镜像过程：关播放设备、等投影散热、开窗帘、恢复日常灯光场景。但还要处理边界情况：

  • 有人按了总闸但播放器正播到一半：先保存当前播放位置（播放器集成支持则调用）。
  • 影院模式做到一半家人要看电视新闻：给 script 加取消手段，比如总闸再按一次就是退出。
  • 夜里退出自动变暗：退出前判断时间，深夜的「恢复日常灯光」只亮到 30%。

异常处理的核心思路：把退出场景当作和进入场景同等重要的剧本，而不是简单的反向操作。

再补一个容易被忽略的点：被动打断也要能恢复。比如看到一半有快递敲门，全部关掉后过两分钟想继续看，总闸还亮着、位置却丢了。给 script 加一条「恢复上次播放位置」的入口（多数播放器集成支持 media_seek 之类的补充服务），整个体验才完整。自动化做到最后，拼的都是这些边角。

影院模式全流程

为什么不用一条大自动化

所有这些其实都能塞进一条 automate，但拆成「helper 总闸 script 编排 scene 氛围」的组合有三点好处：

  1. 可复用：script 可以被语音、按钮、时间触发器分别调用。
  2. 可调试：script 能单独跑，场景能单独激活，出问题易定位。
  3. 可演进：想给影院模式加「顺手泡咖啡」，只需往 script 里加动作。

这就是前几章一直强调的分工在真实场景里的样子：结构对了，加功能是加法；结构错了，改功能是重写。

顺带分享一个反馈循环的做法：影院模式上线之后，把家人的吐槽都记下来——「字幕没开」「声音太大」「空调太冷」，每一条都对应 script 里一行微调。两周之后这套模式就长成你家自己的形状，再也不是照抄的配置。

延伸阅读

  • helper 与场景分工见本系列「helper 实体」与「场景与脚本的分工」。
  • webhook 触发器见「触发器全家桶」。
  • NAS 侧部署参考 《NAS 搭建指南》，网络层优化见 《软路由指南》。