helper 实体：开关、计数与下拉框

自动化的「内存变量」

写到第 2 章你会发现一个瓶颈：自动化之间没法直接共享信息。灯亮了这件事，只有那条自动化自己知道。想让另一条自动化也「知道」，就需要一个双方都能读写的中介——helper 实体就是 HA 官方提供的这套「全局变量」。

helper 在「设置 → 设备与服务 → 助手」分类下创建（旧版界面叫「助手」标签页），全程表单操作，不用写 YAML，创建后可在自动化、脚本、仪表盘中直接引用。它既是持久化的（重启不丢），又是可订阅的（状态变化可以触发其他自动化），这套双重特性是组织复杂逻辑的基石。

也可以用 YAML 声明，等效且利于版本管理：

input_boolean:
  guest_mode:
    name: 访客模式
    icon: mdi:account-group
input_number:
  target_temp:
    name: 目标温度
    min: 16
    max: 30
    step: 0.5
input_select:
  house_mode:
    name: 屋内模式
    options:
      - 在家
      - 离家
      - 睡眠
      - 观影

两种创建方式保存的都是同一种实体，按团队习惯选即可。表单适合随手加，YAML 适合一批次初始化。

这也意味着一条写配置的自动化可以直接改 helper 的值——下文所有「写」操作，都既可以来自自动化，也可以来自仪表盘按钮、语音指令或外部调用。helper 是 HA 里最普适的状态入口。

五种 helper 各管什么

挑类型的原则是「让界面约束输入」：能用下拉框就别用文本框，能用滑块就别让人手敲数字——表单本身就在帮你防错。选错类型的代价通常要几个月后才显现：一个本该是下拉框的模式被做成了文本框，家人输入了「做客」「客人」「访客」三种写法，自动化全部失效。

input_boolean：最常见的那个开关

input_boolean 只有两个状态：on 和 off。它最经典的用法是「模式开关」：访客模式、勿扰模式、度假模式、会议模式。这些开关平时由你手动打开，或由某条自动化自动打开，然后作为条件影响一整片自动化。

举个具体场景：

1. 来客人了，你（或语音助手）打开 input_boolean.guest_mode。
2. 所有「关灯」类自动化检测到它开着，自动放宽「人体传感器无人才关灯」的延时。
3. 空调自动化把它当作「优先制冷」的信号。
4. 客人走了，你关掉它，一切复原。

一个开关牵动多条自动化，但每条自动化只关心这一个开关——这就是解耦的力量。有了它，你再也不用为「客人来了」单独写一套自动化。

反过来想，如果没有 helper，你要么得复制三份几乎相同的自动化，要么得在条件里写一串又长又脆的模板判断谁在家。helper 的本质是把状态从代码里搬到界面上：状态有了可见的载体，读它、改它、分享它都变得自然。这也是为什么很多人说「会不会用 helper，是自动化玩家和新手之间的分水岭」。

input_number：可调的数值

input_number 提供一个带上下限和步长的滑块。常见用法有两个：作为目标值（比如「目标温度」由滑块设定，空调自动化读取它）和作为阈值（比如「亮度低于多少算暗」）。

它的杀手级场景是「可调闹钟」：一个 input_datetime 记时间，一个 input_number 记「提前几分钟启动咖啡机」，两者组合就是一个完全可调的早起流程，家人在界面上拖一拖就能改，完全不需要懂 YAML。

在自动化里读它也很直接：states('input_number.target_temp') | float 拿到数值，参与比较或计算。和传感器不同，helper 的值是「人定」的，不会自己变，所以它特别适合做基准线——传感器负责描述世界，helper 负责描述期望。

input_select：有限选项的下拉

input_select 给定一组选项，适合「模式」这类取值有限的状态。和 input_boolean 相比，它表达「多种模式之一」：在家、离家、睡眠、观影——一个下拉框管住整套场景逻辑，比四个布尔开关清晰得多。

一个实用模式是下拉框联动场景：选项变化时触发自动化，根据不同选项激活不同场景或脚本。家人只需在大屏或 App 上选一下「观影」，电视、投影、灯光、窗帘一整套动作就跑起来了，比逐一按开关体面太多。

触发写法非常干净：

trigger:
  - platform: state
    entity_id: input_select.house_mode

动作里再用 choose 按 trigger.to_state.state 分发。整套「模式中心」架构的核心就是这一个触发器：界面上一选，全屋联动。

input_datetime 与 input_text

input_datetime 分三种模式：时间（time）、日期（date）、日期时间（datetime）。最常用的是 time 模式做可调闹钟——时间触发器可以直接引用它，改时间即改触发，无需重载配置。

datetime 模式适合「从某个时刻开始倒计时」的需求：自动化写「距离 input_datetime 指定的时间还有多久」，实现「动态定时的浇水」「晒被子提醒」这类功能。date 模式用得少，典型场景是「生日提醒」「定期更换滤芯」的年度循环。

input_text 存自由文本，适合做「动态内容」：比如提醒消息模板、当前播放的歌单名、留给家人的便签。注意它有长度上限（默认 255 字符），别拿来存长篇内容；需要长文本或结构化数据时，应该考虑自定义传感器或文件。

在自动化里使用 helper

读取用 states('input_boolean.guest_mode')，写入用服务 input_boolean.turn_on / turn_off / toggle，input_select 用 select_option 并带 option 数据，input_number 用 set_value 带数值。写法汇总：

helper 也能被语音助手控制（「打开访客模式」），还能暴露给 Google Home、Alexa 等平台，进一步扩展使用面。这也意味着它成了家里「人人可操作」的入口：老人小孩不动自动化，但都会按屏幕上的开关。

使用 helper 的三条心法

1. 命名带语义：input_boolean.guest_mode 一眼读懂，input_boolean.switch_2 三个月后没人认识。
2. 单一职责：一个 helper 只表达一件事，别让「模式开关」兼任「场景触发」。
3. 仪表盘摆出来：放在首屏的卡片上，你和家人才会真正用起来，否则它只是个 YAML 里的名字。

第四条算赠品：给 helper 配图标（mdi 系列图标）。在实体列表和 App 里，带图标的开关更容易被家人识别，降低使用门槛。同时记得在界面上给 helper 加上友好的显示名称，别把实体 ID 直接暴露给不懂技术的家人——他们不需要知道 input_boolean.guest_mode 是什么，只需要看到「访客模式」。

延伸阅读

• helper 与场景、脚本的联用见本系列「场景与脚本的分工」一篇。
• 状态持久化机制见本系列下一章「状态持久化与开机还原」。
• 仪表盘卡片搭建可参考 《NAS 搭建指南》 中可视化章节的思路。
• 若 HA 部署在软路由上运行多个服务，《软路由指南》 的资源管理建议同样适用。