Home Assistant 2026.11 上手：容器部署、内置市场与命名改动

Home Assistant 是一个跑在自己硬件上的开源智能家居中枢。设备接入、自动化、面板都在本地完成，外网断了也能用。2026.11 版本在 11 月 4 日发布，仓库采用 Apache-2.0 许可，2026 年 11 月 7 日查看时约 9.2 万 Star。

它用 Python 写，主仓库从 2013 年维护至今。月度发布的节奏让它跟得上新设备，也意味着每次升级都可能带来破坏性改动。

它是什么：把不同协议的设备收进一个界面

接进来的设备会拆成若干实体。一盏灯通常是开关实体加亮度实体，传感器就是读数实体。自动化按触发、条件、动作三段组织，面板把这些实体排成卡片。

仓库描述写得很直白：本地控制与隐私优先。数据不经过厂商云，规则也在本地跑。这是它与各家厂商 App 的根本差别，代价是维护责任落在自己身上。

安装文档现在只列两种安装类型。Home Assistant OS 是打包好的系统镜像，带 Supervisor 与应用商店；Container 是单独的容器，系统与更新都由自己管。

能力	Home Assistant OS	Home Assistant Container
自动化、面板、集成	有	有
应用（原加载项）	有	无
一键更新	有	无，需手动重建容器
内置备份	有	有

分界线就在应用这一行。Thread 与 Z-Wave 这类集成由应用托管，所以在容器版里没有开箱支持。

部署：容器版一条命令，装之前先想清楚

前提是 Docker Engine 23.0.0 或更新，Docker Desktop 不行。官方也写明，想要应用就别选容器。

命令本身不复杂。镜像用 ghcr.io/home-assistant/home-assistant:stable，配置目录挂到 /config，网络走 host 模式，访问端口 8123。完整参数在容器安装文档里。

docker run -d --name homeassistant --privileged --restart=unless-stopped -e TZ=Asia/Shanghai -v /PATH_TO_YOUR_CONFIG:/config -v /run/dbus:/run/dbus:ro --network=host ghcr.io/home-assistant/home-assistant:stable

host 网络不只是图省事。设备发现依赖局域网广播，桥接网络会让不少设备搜不到。

用蓝牙要挂 /run/dbus。接 Zigbee 或 Z-Wave 的 USB 棒，再加 --device /dev/ttyUSB0:/dev/ttyUSB0，并确认运行容器的用户对 /dev/tty* 有权限。

容器版的更新要手动走一遍：pull 新镜像，stop，rm，再用同样参数 run。配置都在 /config 里，重建不会丢，但这一步容易被忘成“拉完镜像就完事”。

还有一个容易忽略的参数。Docker 默认只给 10 秒让进程退出，数据库可能来不及关，日志里会出现 sqlite 未正常关闭的警告。加 --stop-timeout 60 更稳妥。

ARM64 且页大小大于 4K 的机器，可能撞上 jemalloc 报错，加 -e DISABLE_JEMALLOC=true 可以绕过。容器部署的这类细节，和Actual 的单容器实测遇到的问题很像。

2026.11 的改动：HACS 变成内置市场

这一版把 HACS 并进核心，改名 Marketplace，入口在设置里。所有安装类型都能用，包括容器版，不必再手动下载解压。

已有的 HACS 会在升级后首次启动时自动迁移。已装内容保留，更新继续。HACS 安装器在这一版停止，之后无法再单独安装。

体验上的变化是少一次重启。在市场里点安装，会直接进入该集成的配置流程；更新仍需重启。市场内容免费，但首次使用要接受风险提示，社区项目不经官方测试。

其余几项值得一并知道。新增 38 个集成。Matter 1.5 的摄像头能出实时画面与快照，双向对讲还是 Labs 预览，且浏览器要求 HTTPS。

LoRaWAN 接入 ChirpStack 与 The Things Network。备份可以写到内置盘或 U 盘，ZHA 也支持了不用电池的 Green Power 设备。

发布说明里单独有一节向后不兼容清单，升级前值得逐条对照。

命名改动：哪些会变，哪些不受影响

以前是给实体起一个完整名字。现在只起基础名，系统按设备、区域自动补上下文。举例：电表设备下名为“低谷用电”的实体，会显示成“电表低谷用电”。

官方明确这是向后不兼容的改动。面板上没自定义名称的卡片与徽章会变样，需要手动收拾一轮。

不受影响的部分同样明确。实体 ID 不变，自动化和脚本照常跑。自己设过的名称会保留，旧名字还留作语音助手的别名。

friendly_name 属性计划弃用，模板要改用 entity_name()、device_name()、area_name()。写模板的人现在就该换。

同一版还有别的坑。Hue 的 None 灯光效果被移除。涂鸦多路设备拆成子设备，名字跟着变。

没有 unique_id 的 MQTT 实体不再套用设备配置。反向代理登录则要求协议、主机、端口三者匹配。部分自定义卡片依赖的前端组件也被删掉了。

第三方的升级清单给的建议是：先备份，等 2026.11.1 再看。写这篇时补丁版还没发布。

和 openHAB 比，差在哪

openHAB 是另一条路线。它用 Java 写，5.x 要求 Java 21，当前稳定版是 5.2.1，默认端口 8080。稳定版按半年节奏发布。

两边的配置哲学不同。openHAB 把设备、通道、条目、规则都放进文本文件，适合纳入 Git 做版本管理。Home Assistant 以界面配置为主，复杂逻辑再退回 YAML。

规则引擎是 openHAB 的长处。DSL、Blockly 与脚本更接近编程，写状态复杂的逻辑更自然。代价是简单自动化也要多几步。

Home Assistant 的长处是集成数量与新设备跟进速度，还有原生手机 App、内置语音助手与能源面板。月度发布既是优势也是负担，破坏性改动来得更勤。

换平台的成本要有预期。两边设备模型不同，自动化得重建；不过 MQTT、Zigbee2MQTT 这类中间层可以复用，能新旧并行一段时间。openHAB 下载页列了各平台的安装包与版本。

局限与适用人群

先说不适合的。只想用手机点两下控制几盏灯，厂商 App 或 Matter 生态更省心；不愿意维护一台常开机器，也不适合自建。

容器版的取舍要提前算清。没有应用商店，Zigbee2MQTT、ESPHome、Mosquitto 都得自己起容器并自己更新，Z-Wave 与 Thread 没有开箱支持。想要这一层，只能走 OS 或虚拟机路线。

硬件上，官方在每种整机方案的必需项里都写了有线网络。Raspberry Pi 4 或 5 起步，内存至少 2GB。

先列设备清单，逐个确认有没有对应集成，再决定装哪种。
能用 OS 就用 OS，容器留给已经有 Docker 环境的人。
升级前导出备份，再对照发布说明的不兼容清单。
配置目录单独纳入备份策略，别只依赖容器卷本身。
同一台机器还可以放Beszel 这类轻量监控，或Immich 这样的相册服务，但要先算内存。

把它当成一台需要照看的家用服务器，预期就对了。它给的是本地控制与可编排性，换来的是每月一次的维护动作。

相关地址

以下为文中项目的官方入口，版本号、文档与下载以这些页面为准。

Home Assistant（GitHub 仓库）：https://github.com/home-assistant/core
Home Assistant（官网）：https://www.home-assistant.io/
Home Assistant（安装文档）：https://www.home-assistant.io/installation/
Home Assistant（Linux 与容器安装）：https://www.home-assistant.io/installation/linux
Home Assistant（2026.11 发布说明）：https://www.home-assistant.io/blog/2026/11/04/release-202611
openHAB（官网下载页）：https://www.openhab.org/download/