2025 年 5 月 22 日,Home Assistant 官方宣布对两个安装方法和三种老旧 CPU 架构进行弃用。受影响的安装方法是 Home Assistant Core(在 Python 环境中直接运行)和 Supervised(在自有操作系统上安装 Supervisor 与相关组件)。被弃用的架构包括 i386、armhf 和 armv7 三种 32 位平台。官方将在 2025.6 版本中对受影响系统发出通知,六个月后即 2025.12 起终止官方支持与面向这些平台的构建与更新。对于正在运营中的系统,理解变更的范围、风险与可选路径,是确保智能家居稳定运行的关键。下面将分层解析背景、影响、如何确认自身系统、实用迁移方案与常见顾虑,帮助用户平稳过渡到受支持的安装方法与架构。
官方为何做出这项决定 Home Assistant 给出的理由可以归结为三点:使用与支持人数的变化、维护成本与产业生态的演变。官方数据表明 Core 与 Supervised 安装方式的占比逐步下滑,当前分别约为 2.5% 与 3.3%。这些安装方式对用户和维护者都更为复杂,社区支持成本高且经常产生难以复现的问题。与此同时,大多数用户已经转向 Home Assistant OS 或 Container(例如 Docker)这些更易于安装、维护、并由官方重点支持的方式。关于 32 位架构,i386、armhf 与 armv7 的占比极低,分别低于 0.5%(i386 与 armhf)与约 0.95%(armv7)。硬件行业与依赖项目也逐渐放弃 32 位支持,新功能开发有时会因兼容这些老旧平台而受阻。
综合这些因素,官方选择把精力集中在 aarch64 与 amd64 两种 64 位架构上,以及 Home Assistant OS 与 Container 两种安装方式上。 官方给出的时间线与后果 从 2025.6 起,凡是运行被弃用安装方法或在被弃用架构上的系统都会收到一条通知,提示六个月后支持终止。从 2025.12 开始,官方将不再为这些安装方法或架构发布构建、更新或受理问题报告。重要的是,弃用并不意味着立刻中断你当前的运行;你仍然可以继续用现有方式运行并自行更新,但失去的是官方的技术支持、文档推荐以及后续平台更新。这意味着在六个月窗口内用户需要决定是否迁移以及选择合适的新平台,以免日后遇到安全或兼容性问题时无法获得官方修复。 如何判断你的系统是否受影响 你可以通过 Home Assistant 的系统信息快速确认安装类型与 CPU 架构。
进入 Settings > System > Repairs,然后打开右上角的菜单并选择 System information,检查 Installation type 与 CPU architecture 字段。如果显示 Home Assistant OS 或 Container,安装方法无须担忧。如果 CPU 架构显示为 aarch64 或 x86_64(也称 amd64),则架构无须担忧。如果显示的是 i386、armhf 或 armv7,则你的设备受弃用影响。对部分用户而言,硬件本身支持 64 位但当前运行的是 32 位系统,仍然可以通过安装 64 位操作系统并恢复备份来实现迁移。 迁移的总体思路与核心工具 官方强调备份与恢复是迁移的核心。
Home Assistant 的备份功能在各安装方法间已经互通,备份文件可从任一安装方式恢复到另一种方式。Home Assistant Cloud 的离线备份功能更简化了操作,订阅用户仅需凭密码即可恢复到新系统。迁移的基本步骤是先在现有系统生成并下载备份,准备目标设备并安装受支持的 Home Assistant OS 或 Container 环境,然后在初始化过程中选择从备份恢复。由于配置、集成与数据大部分都包括在备份中,迁移后所需人工干预通常较少。 对不同用户的推荐迁移路径 对于 Supervised 用户,官方推荐迁移至 Home Assistant OS,因为它包含 Supervisor 与丰富的 add-on 支持。如果用户又想保留对宿主机的控制,可以选择在虚拟机(例如 Proxmox)中运行 Home Assistant OS,从而在保障兼容性的同时不放弃对宿主系统的掌控。
对于 Core 用户,最接近的替代是 Home Assistant Container,通常结合 Docker 使用,适合希望保持系统轻量且可控的场景。如果硬件不支持 Home Assistant OS 或你希望将部分功能以容器方式并行运行,Container 路径是合理选择。对于无法在现有硬件上升级到 64 位的设备,最实际的做法是采购兼容 aarch64 或 amd64 的新设备,或考虑二手板卡、小型办公机等替代硬件以节省成本并符合可持续原则。 具体迁移注意事项与实践建议 在实际迁移前,务必先完整备份并验证备份文件是否可下载与完整。对于大型用户,建议先在一台测试设备上恢复备份以验证核心集成与自动化逻辑是否能正常运行。迁移到 Container 时需关注外部依赖的容器化,例如一些 add-on 可以直接以容器形式部署,但某些原生 Supervised add-on 可能需要额外配置。
运行 Home Assistant OS 的用户享有最接近"开箱即用"的体验,但在特定高定制场景下,运行 OS 于虚拟机内可以兼顾弹性与控制权。 对于硬件迁移,Raspberry Pi 系列是常见选择,但需注意选择支持 64 位的型号并安装对应的 64 位 OS。Raspberry Pi 3 与 4 在很多情况下都能运行 64 位系统,即便之前运行的是 32 位系统,也可重新安装 64 位 Home Assistant OS 并恢复备份。对于 Intel 或 AMD 平台,选择面向 amd64 的小型主机或二手迷你电脑能提供更强的处理能力与长期兼容性。厂商生态的演变使得购买新硬件并长期运行比维持老旧 32 位设备在成本与可维护性上更具优势。 安全性与长期维护的影响 终止官方构建意味着不会再有安全更新或新功能补丁面向这些平台发布。
即便社群可能继续自行维护相关 tooling 或镜像,官方不再接手支持会增加长远运行的风险。安全方面尤其重要,Home Assistant 常连接家庭网络与多个 IoT 设备,缺乏后续补丁可能使系统暴露在已知漏洞之下。此外,未来对第三方依赖的更新也可能直接影响到旧平台的兼容性。因此对于注重安全与稳定的用户,尽早迁移到受支持的平台是合理且必要的选择。 常见问题解答与误区澄清 关于能否继续使用 Core 或 Supervised,官方回答是可以继续使用,但在 2025.12 后不再受理问题与发布更新。开发者文档中仍会保留用于开发用途的 Core 相关说明,变化是针对终端用户文档与支持策略的调整。
有用户担心社区是否会失去维护意愿,官方指出社区仍可自行维护相关文档或第三方项目,公开构建管线也允许任何人复刻或继续发布针对旧平台的版本。还有人误解为 Home Assistant 可能转向闭源或商业化,官方重申项目属于 Open Home Foundation 的非营利框架,必须遵守开源原则与底层治理。 如果你无法在六个月内迁移 有些用户因时间或资源限制无法在 2025.12 前完成迁移。现实做法是继续保持现有系统运行并在可行时定期手动备份数据与配置,尽量减少对新依赖或不兼容集成的添加,以降低将来迁移时的工作量。对安全较为敏感的用户,可以采取网络隔离、规则限制与仅在内网使用等临时性防护措施,以减少外部暴露风险。同时关注社区是否有第三方维护者发布兼容包或镜像,权衡短期利益与长期可维护性后再做抉择。
社区与维护者的角色转变 官方此举目的在于聚焦资源以提升对大多数用户的支持质量,但并不意味着排斥高级用户或开发者的实验。社区仍然可以继续运营相关项目与文档,或为 Core 与 Supervised 发布独立维护的指南。对于那些愿意承担维护成本的个人或团队,开放的构建管线为继续发布旧平台支持提供了技术可行性。官方的改变也提醒了使用者在选择安装方式时要考虑长期维护与支持链条,而非仅凭短期便利。 结语与行动建议 面对 Home Assistant 的这次弃用决策,建议用户首先在系统中检查安装类型与架构,确认是否受到影响。若受影响,应在六个月窗口内制定迁移计划,优先进行完整备份并在测试环境中验证恢复过程。
根据使用习惯与对宿主机控制的需要,在 Home Assistant OS、Container 与虚拟化部署之间做出选择。对硬件有限制的用户,可优先考虑替换为支持 aarch64 或 amd64 的设备,或采用虚拟机方案以延长兼容性。对于不愿迁移、愿意自主管理的高级用户,社区仍然可成为继续运行与维护的资源来源。总体而言,尽早评估风险并着手迁移准备,能最大程度降低后续的运维与安全隐患,确保智能家居系统长期稳定可靠地运行。 。
