Home Assistant 2026.10 将安全警报带到主仪表盘：建立真正有人会使用的响应系统

Home Assistant 2026.10 做了一项看似细小、实际影响很大的界面调整：在 Security 仪表盘中配置的警报，现在可以出现在主 Home 仪表盘上。它之所以重要，是因为警告只有在看到它的人知道下一步该做什么时才有用。门没关、烟雾探测器触发、检测到漏水，或关键传感器失联，都不应该被埋在几乎没人打开的专业页面里。

这次发布并没有把 Home Assistant 变成经过认证的报警系统，也没有解决传感器不可靠、手机静音或网络设计不佳的问题。它只是给家庭警报提供了一个更显眼的位置。合理的做法不是把所有设备都塞到首页，而是先判断哪些条件值得打断日常，哪些只适合放进安静的维护清单，以及哪些情况必须依靠独立于智能家居控制器的实体备用设备。

2026.10 真正值得借鉴的地方在于：把仪表盘看成响应计划的起点，而不是堆满状态卡片的一面墙。

2026.10 改变了什么

Home Assistant 10 月 7 日的发布说明提到，配置在 Security 仪表盘中的警报，例如门长时间未关或烟雾探测器触发，现在可以出现在 Home 仪表盘上。这项变化填补了配置与日常使用之间一个常见的空档。用户可能认真搭建了一个安全页面，但家里平时打开的通常仍是默认 Home 页面。

这里有一个重要区别：新的展示方式并不会把每个二进制传感器都变成警报。它只会显示你已经配置好的警报。底层条件、传感器质量、通知路径和自动化逻辑，仍然决定警告是否准确、是否真正有用。

这次发布还包括一些无关的改动，例如 Energy 仪表盘中的独立电池放电信息，以及更多仪表盘控制项。这些功能也许有用，但不能和安全警报变化混为一谈。看到一条警报，并不代表设备健康、通知已经送达，或有人已经确认处理。

升级后可以先打开 Home 仪表盘，查看当前是否有活动警报。如果有，逐条问自己四个问题：

• 到底是什么条件触发了它？
• 谁负责响应？
• 最安全的立即行动是什么？
• 家庭如何知道问题已经解决？

如果其中任何一个问题没有清楚答案，就应该先重新设计警报，再继续添加设备。

警报是一种状态，不是一条通知

Home Assistant 的 Alert 集成适合处理那些在修复或确认之前仍然重要的条件。它的文档区分了空闲警报、活动警报，以及仍处于活动状态但已经被确认的警报。它可以按照设定的间隔重复发送通知，也可以在条件恢复后发送完成消息。

这种模型适合仍然敞开的车库门，却不适合短暂的移动事件。移动传感器可能产生一个值得记录或用于自动化的事件，但通常不应像持续存在的安全问题一样不断提醒。把事件和状态混淆，是制造通知疲劳最快的方式之一。

可以遵循一条简单规则：

需要有人做出决定或恢复安全状态的持续条件，适合使用警报。只是提供信息、具有时效性，或已经由另一条自动化处理的事件，则更适合使用通知。

通常值得设置为持续警报的条件包括：漏水传感器检测到水；冷冻柜温度持续高于某个已经足以造成损失的阈值；车库门在夜间仍然打开；烟雾报警器出现关键故障；或者房屋处于离家模式时安全门仍然敞开。

通常需要不同处理方式的情况包括：灯被打开、有人回家、繁忙走廊里的移动事件，或电池短暂报告了一个明显不合理的数值。这些信息仍可用于自动化、日志或低优先级维护页面。

这样的区分还能避免一种令人尴尬的失败：如果所有事情都被标为紧急，家里的人最终会认为红色横幅意味着“可能又没什么”。安静但会重复出现的警报，应当留给那些拖得越久，代价就越高的未解决条件。

先建立一份小型警报清单

在修改 YAML 或购买新传感器之前，先列出可能造成真实伤害、财产损失或时间敏感问题的家庭条件。清单要具体，而且要描述物理情况。“安全”太宽泛；“无人居住时后门仍然打开”才是可以采取行动的描述。

可以从下面这些条件开始：

最后一行很容易被遗漏。一个只有在中枢、无线协调器、网络、电源和通知路径全部正常时才能告诉你漏水的系统，当然有用，但它并不是完整的安全层。Home Assistant 自己的安全指南建议保护安装，尤其是当系统可以从家庭网络外部访问时。那属于另一类问题，与仪表盘是否方便查看并不是一回事。

不要仅仅因为软件能够控制某个设备，就把智能家居警报连接到危险的物理动作上。关闭阀门、解锁门、切换加热器或停用设备，都可能产生传感器无法完全理解的后果。先从通知和人工确认开始。只有当设备本来就为这种用途设计，而且故障模式已经被理解和测试后，才考虑自动控制。

让主仪表盘成为分诊界面

主 Home 仪表盘应该回答“现在有什么需要处理？”而不是重现家里的每一个实体。

一个克制的布局可以分成三个区域：

1. 当前活动的安全和家庭警报。
2. 做出快速决定所需的当前状态。
3. 通往深入诊断和历史记录的链接。

第一个区域可以显示外门打开、检测到漏水、烟雾报警器状态，或冷冻柜在延迟时间后仍然过热。第二个区域可以显示房屋是否有人、主机是否在线，以及关键传感器最近一次更新时间。第三个区域则可以链接到 Security 仪表盘、设备页面、日志和自动化跟踪记录。

这样的安排能减少为每块电池、每个门磁和每条集成警告添加卡片的冲动。那些信息并非不重要，但更适合维护工作。主仪表盘是决策界面，不是实体清单的导出文件。

新的 2026.10 行为让这一区别变得更明显，因为活动的 Security 仪表盘警报现在可以出现在人们已经习惯使用的位置。当警报列表经过筛选时，这很有帮助；当列表变成低电量和短暂连接故障的倾倒场时，它只会制造干扰。

名称应该使用家庭成员能理解的语言。“离家时后门打开”好过“binary_sensor.contact_07”。必要时写明位置和持续时间。人在决定是否叫醒或提醒另一位家庭成员时，不应该还要回忆某个传感器名称对应哪一个房间。

延迟也是安全设计的一部分

很多家庭条件在变成警报前都需要等待一段时间。装 groceries 时冷冻柜门可能暂时打开；有人在车库工作时车库门可能一直开着；宠物经过房间也会让移动传感器持续活动。对所有情况都立即发出警告，只会制造噪音。

延迟应当根据后果设定，而不是根据一个统一的个人偏好。专门用于检测漏水的水传感器可能值得立即通知。车库门可以留出一个短暂宽限期。冷冻柜温度警报则可能要求温度持续偏高一段时间，以便区分开门取物和设备故障。

Home Assistant 的 Alert 集成支持重复间隔，也可以使用一组逐步变化的延迟，而不是始终使用同一个间隔。文档还描述了确认状态：人在条件仍然存在时可以暂时停止重复提醒。这个功能有用，但确认绝不能当成解决。确认“车库门打开”只说明有人看到了，并不代表车库已经安全。

一种合理的节奏可以是：

• 对可能的漏水或人身安全事件立即发送第一条消息。
• 对可能只是正常活动的门或车库条件设置短暂延迟。
• 条件持续存在时重复提醒。
• 传感器恢复正常后发送清楚的“已解决”消息。
• 如果警报反复被确认却没有修复底层问题，就安排维护检查。

不要用很长的延迟来掩盖不可靠的传感器。如果传感器抖动、掉线或报告不可能的数值，就单独修复这些问题。一个延迟发送的坏信号仍然是坏信号。

通知需要一条送达计划

仪表盘警报只有在有人打开仪表盘时才会发挥作用。时间敏感的条件通常还需要通知路径。Home Assistant 支持通知集成，其 Companion 文档也支持带按钮的可操作通知，这些按钮可以向 Home Assistant 发回事件。

这样就能围绕响应设计消息，而不是只发一条含糊的警报。例如，车库通知可以提供“打开仪表盘”和“标记为已查看”两个操作；门警报可以直接链接到相关摄像头画面。操作按钮不应仅因为方便，就默默执行危险动作。解锁门或关闭报警器的按钮，需要身份验证和谨慎处理。

送达链路中有许多彼此独立的故障点：

• 传感器可能掉线，或电池已经耗尽。
• 主机可能不可用。
• 家庭网络可能中断。
• 手机可能关闭通知，或处于专注模式。
• 通知服务可能延迟。
• 当前负责的人可能不是预设接收者。
• 消息可能含糊到无法据此行动。

要有意识地测试整条链路。触发一个无害的测试条件，检查仪表盘，确认手机收到消息，验证操作按钮有效，然后恢复测试状态。每一部应该接收关键通知的手机都要测试。几个月前配置过一条通知，并不能证明它今天仍然有效。

尽可能使用命名明确的 notify 目标。Home Assistant 的通知文档提醒，通用的 notify.notify 目标只是第一个可找到的通知动作的简写。随着设置规模扩大，这会让实际送达对象变得不明显。显式指定目标，更容易审计，也能减少新增设备或集成后的意外。

对于关键警报，不要只依赖一个人的手机。根据具体条件和家庭情况，决定是否需要第二部家庭设备、共享通知服务、本地警笛或人工检查。手机通知不能替代经过认证的烟雾或一氧化碳报警器。

可操作通知必须有护栏

按钮很有用，因为它缩短了从看到问题到采取行动的路径。但它也可能导致误操作。

Home Assistant Companion 文档指出，通知操作会以事件形式送达，自动化可能运行不止一次。它建议谨慎设计操作标识符，避免一条通知意外触发原本属于另一条通知的逻辑。文档还提醒，需要考虑通知被清除，或应用不可用时会发生什么。

这带来一个实际原则：“确认”和“修复”应该是两个不同的操作。确认表示“有人看到了”。修复表示“物理条件已经被纠正”。如果通过按钮静音警报，就继续在仪表盘上显示底层状态，并保留通往设备历史记录的路径。

涉及门禁的警报需要更高的操作门槛。打开摄像头画面的通知通常比解锁入口风险低。如果一个操作能够改变谁可以进入房屋，那么身份验证、短时有效窗口和醒目的确认提示都是合理的保护措施。不要让手机通知成为防止危险物理状态的唯一屏障。

当一条自动化可能发送多条相关通知时，使用唯一的操作标识符。操作处理器要保持范围狭窄：确认预期上下文，检查条件是否仍然存在，并在相关传感器不可用时拒绝执行。过时的通知不应在几分钟后变成含义不同的命令。

为传感器不可用设计方案

智能家居仪表盘可能让一个健康的系统看起来很安心，却把盲区藏起来。每一个关键警报都应该对应一个问题：传感器停止报告时会怎样？

答案不一定是为每台设备再增加一个警报，但必须有维护信号。几天没有回报的门传感器，不能等同于“门已关闭”。电池耗尽的漏水传感器，不能被当成地面干燥的证明。烟雾报警器集成失去连接后，应显示为不可用，而不是悄悄保持正常。

这正是主仪表盘和维护页面需要配合的地方。把正在发生的危险放在主仪表盘，把过期数据和电池状态放在标注明确的健康区域，并让它们有足够的可见度，避免被遗忘。小型住宅每周检查一次也许足够；大型安装则应按后果对设备分组，并设立维修流程。

避免使用模板把未知值转换成“关闭”。这种做法可能让自动化看起来更干净，却抹掉安全、错误和未知之间的区别。在保护财产或人员的警报中，未知必须仍然明显不同于正常。

无线和网络设计同样重要。Thread、Zigbee、Wi-Fi 或 Z-Wave 传感器，可能因为距离、干扰、电池行为、协调器故障或路由器变化而失效。增加第二个仪表盘卡片不会改善连接。关键传感器必须在实际安装位置测试，而不能只在主机旁边的工作台上测试。

让人身安全设备保持独立

Home Assistant 可以接入烟雾探测器和其他安全设备，但控制器应当是额外的信息层，而不是唯一防线。使用适合当地法规和建筑条件、经过批准并得到维护的报警器。遵循制造商关于安装位置、测试、电池和更换周期的建议。

智能家居自动化可以告诉你哪个房间报告了事件，可以向手机重复发送消息，也可以打开照明帮助人找到出口。但它不应该让人在排查应用时延误撤离。如果经过认证的报警器响起，应先遵循紧急流程。

同样的原则适用于电气和加热设备。不要把仪表盘警报变成市电布线项目。固定电气设备周围的安装、修改或绕过保护，应交给合格专业人员。智能插座的标签上即使写着某个瓦数，也不代表它自动适合加热器、锅炉、家电或大负载电机。负载类型、工作周期、外壳、当地规范和故障模式都很重要。

家庭自动化非常擅长提供上下文，但它不能替代烟雾报警器、一氧化碳报警器、正确安装的切断装置、机械安全联锁，或了解家庭紧急计划的人。

2026.10 的实际设置顺序

如果已经在运行 Home Assistant，可以把这当成一个简短的维护项目。

首先，按照正常的受支持流程升级，并阅读 2026.10 发布说明中可能影响当前安装的破坏性变更。除非能够分别测试每项改动，否则不要把安全警报重设计和多个无关迁移安排在一起。

接着打开 Security 仪表盘，写下真正可采取行动的警报。删除或重新设计那些没有明确负责人、没有有用响应，或没有可靠来源的条目。然后打开主 Home 仪表盘，检查活动警报在那里如何呈现。为每一条警报设置家庭成员能理解的名称，并确认位置准确。

针对每一个关键条件，在实际安装位置测试真实传感器。确认警报能够启动、出现在主仪表盘、发送预期通知、按照计划的节奏重复，并在物理条件恢复后清除。如果使用确认功能，还要确认确认操作不会抹掉底层状态。

然后测试故障路径。只有在测试安全且可逆的前提下，暂时断开传感器或以其他方式模拟不可用状态。检查仪表盘能否区分不可用与正常。确认家庭对于火灾、一氧化碳和其他人身安全风险，仍然拥有独立的安全机制。

最后记录责任归属。“收到这条通知的人检查后门”比默认大家都会处理更好。如果多人共同居住，要事先约定“已查看”“已确认”和“已解决”分别意味着什么。如果没有人能响应某条警报，就应该改变设计，而不是继续发送更多消息。

下面这个简短例子足以说明底层模式：

alert:
  garage_open:
    name: "车库门仍然打开"
    entity_id: binary_sensor.garage_door
    state: "on"
    repeat:
      - 15
      - 30
      - 60
    can_acknowledge: true
    skip_first: true
    notifiers:
      - household_phone

具体实体、通知器、时间安排和条件必须与实际安装相匹配。不要把这个例子原样粘贴到正在运行的系统中。真正重要的设计选择是：条件必须具有持续性；第一次提醒要延迟，以便给正常活动留出时间；重复间隔逐渐变长；通知目标必须明确。

一周后应该检查什么

警报系统应当根据实际行为评估，而不是根据配置文件看起来是否整齐。运行几天后，检查哪些警报触发过、重复了多少次、是否有人采取行动，以及哪些警报在没有修复的情况下被确认过。

通常会得到三类结果：

• 警报很少出现、内容准确，并且促成了明确响应。
• 警报在技术上正确，但时间点不合适或描述太含糊。
• 警报过于嘈杂、重复了另一条警告，或依赖无人维护的传感器。

保留第一类，改进第二类，删除或重新设计第三类。一组规模较小但值得信任的警报，远比覆盖面很全却训练所有人忽略仪表盘的系统有价值。

还要观察主仪表盘新增的可见性是否真的改变了行为。家里的人是否确实看到了警告？警告是否出现在经常处于休眠状态的墙面平板上？大家实际使用的是手机还是仪表盘？通知是否提供了足够上下文，让人能够做出决定？如果答案是否定的，那么界面变化暴露的是工作流程问题，增加另一个传感器并不能解决它。

Home Assistant 2026.10 让活动安全警报更容易被注意到。持久的改进来自更准确的匹配：每条警报对应真实条件、明确负责人、经过测试的送达路径，以及在风险较高时独立存在的备用机制。这样，仪表盘才会在普通而忙碌的一天里真正有用，而不是变成又一块堆满警告的屏幕。

来源与延伸阅读

• Home Assistant 2026.10 发布说明 —— 介绍 10 月版本的变化，包括活动 Security 仪表盘警报出现在 Home 仪表盘上。
• Home Assistant Alert 集成 —— 介绍持续警报状态、确认、重复间隔和完成消息。
• Home Assistant 可操作通知 —— 介绍按钮、事件处理、操作标识符和平台注意事项。
• Home Assistant 自动化触发器 —— 说明触发事件与持续为真的条件之间的区别。
• Home Assistant 通知动作 —— 介绍显式通知目标以及通用通知动作的行为。
• 保护你的 Home Assistant —— 提供账户和远程访问安全方面的指导。
• Home Assistant 2026.10 社区讨论 —— 社区对该版本的反应，以及围绕发布内容的实现讨论。