Home Assistant 2026.10.3 的补丁清单：集成修复占八成，剩下的在追基础设施

Home Assistant 2026.10.3 是 10 月 23 日的补丁版。这类版本的清单看起来很长，其实结构很简单：八成是具体集成的 bug，两成是底座升级。挑几条有教学价值的看。

一、集成修复：三类典型错误

共享状态被就地改写

Fix Sensibo full_state action modifying the coordinator data (#187014)

Home Assistant 的集成普遍用 coordinator 模式：一个对象定期拉取设备状态，所有实体都从它读。问题在于，如果一个 action（比如「设置完整状态」）直接在 coordinator 的数据结构上改字段，那么：

• 所有实体立刻看到「假状态」；
• 下一次轮询拿回真实状态，界面又跳回去；
• 中间这段时间的自动化可能基于假状态执行。

正确做法是「构造新状态 → 提交给设备 → 等轮询确认」，而不是就地改。这类 bug 在自研集成里非常常见，因为它只在「设备拒绝了这个设置」时才暴露。

共享 SSL context

Create new SSL context instead of sharing context in SMTP integration (#186812)

SMTP 集成为所有通知共用同一个 SSL context。共用本身不算错，但 context 是可变对象 —— 一旦某处改了验证模式或加了证书，影响面是全局的。改成每次新建，代价是一点内存，换来的是「一个集成出问题不会污染其他连接」。

依赖版本冲突

Constrain bitstring<5 to fix edl21 (pysml incompatibility) (#186985)

这条是纯工程债的典型：edl21 集成依赖 pysml，而 pysml 与 bitstring 5.x 不兼容。解法不是改代码，而是在依赖里钉住上界。Python 生态里这类「钉上界」的补丁会一直存在，因为没人能单方面要求上游兼容。

二、启动时序：KNX 那条值得看

Hold off the bootstrap timeout while the KNX telegram store initializes (#186980)

KNX 是楼宇总线协议，集成启动时要先载入「电报存储」（telegram store）—— 可能很大。而 Home Assistant 的启动有超时保护：某个集成启动太久会被判为失败。

于是出现一个矛盾：超时保护本来是为了防止卡死，结果把「正在正常加载大文件」的集成杀掉了。修法是让集成显式告诉框架「我还在干活」，别超时。

这是启动流程设计里的通用问题：超时是必要的，但它需要一个「进度信号」的出口，否则慢就等同于死。

三、底座：Python、uv、runner、前端

补丁版的后半段是基础设施，信息量也不小：

项目	变化
Python	3.14.8
uv	0.12.24 → 0.13.0 → 0.13.4 → 0.13.5（同一周期内连升四次）
构建 runner	Ubuntu 26.04
wheels / base image	2026.10.0 → 2026.10.1
前端	20260930.5

uv 那条最有意思：一个补丁周期里追了四个 uv 版本。这说明 HA 把 uv 当作构建与依赖解析的基础设施，跟着上游的安全与证书修复走 —— 和我上周写的「自带证书库的工具必须能高频发版」是同一件事。

四、从补丁清单能读出什么

我读这类清单有三个关注点：

1. 有没有「数据被就地改写」类修复。这类 bug 的破坏力最大 —— 它不报错，只让界面和自动化短暂地说谎。Sensibo 那条就是。
2. 有没有依赖上界钉住的补丁。它意味着生态里有个长期矛盾没解，你的升级路径上会有个坑。
3. 底座升级的节奏。Python 与 uv 的版本号变化，能看出这个项目对「上游安全修复」的响应速度。

按这三条看，2026.10.3 是个健康的补丁版：没有惊天动地的安全修复，但把一批「会在特定条件下骗人」的 bug 清掉了。

五、要不要升

升。Home Assistant 的补丁版之间几乎不引入行为变化，而这类集成 bug 往往在你最不希望的时候出现 —— 比如自动化在半夜按「假状态」执行。

升级前唯一要做的是看一条：如果你用了被修的集成（Proxmox、UniFi Access、Sensibo、KNX、FRITZ!SmartHome、Home Connect、Synology DSM），升级后检查这些实体的历史记录有没有异常跳变。修完 bug 的第一天，历史曲线通常会「正常」得有点突兀 —— 那是在补齐之前被污染的数据。