大众汽车封锁Home Assistant集成：智能家居车主遭遇新障碍

大众汽车最近对第三方应用接入其车联网API做了重大调整——要求客户端断言（client assertion），直接导致广受欢迎的Home Assistant大众汽车集成插件失效。这个事件在Hacker News上引发了316分的热议，再次把”汽车厂商 vs 开源社区”的老话题推上了风口浪尖。

发生了什么

homeassistant-volkswagencarnet是GitHub上一个流行的Home Assistant集成项目，让用户可以通过智能家居系统远程控制大众汽车——查看电量、预热空调、锁定车门等。大众汽车最近在API层面增加了client assertion认证要求，这意味着只有官方授权的应用才能调用车联网接口。

简单来说，大众把自家车的API大门关上了，第三方开发者拿着钥匙也进不去了。

这不是个案

大众并不是第一个这样做的汽车厂商。近年来，越来越多的车企收紧了第三方API访问：

特斯拉：虽然有官方API，但限制越来越多，第三方应用的生存空间不断被压缩。

宝马：早在2024年就开始限制第三方应用的远程控制功能。

奔驰：API文档不公开，第三方开发者只能通过逆向工程获取接口信息。

这种趋势的背后是车企对数据安全和用户隐私的考量，但更深层的原因是车企希望自己掌控用户数据和应用生态，而不是让第三方”白嫖”。

对Home Assistant用户的影响

如果你是Home Assistant用户，同时又是大众车主，这个变化意味着：

1. 远程控制失效：通过HA控制大众汽车的所有功能将无法使用——包括查看电量、远程启动空调、检查车门状态等。

2. 自动化场景中断：如果你设置了基于车辆状态的自动化（比如到家自动开灯、离家自动锁车），这些都会受影响。

3. 没有官方替代方案：大众自己的APP虽然能用，但功能有限，不支持自定义自动化和跨品牌联动。

应对方案

目前社区正在讨论几种应对方案：

方案1：等待社区逆向——开源社区可能会找到绕过client assertion的方法，但这需要时间，而且大众可能随时再次封堵。

方案2：使用官方API申请——一些开发者建议通过官方渠道申请API访问权限，但这通常只面向企业客户。

方案3：使用中间件服务——一些第三方服务（如Tessie for Tesla的模式）可能会出现，提供付费API代理。

方案4：物理方案——OBD设备+蜂窝网络，绕过云端API直接与车辆通信，但成本高且复杂。

站长和开发者应该关注什么

这个事件不只是车主的问题，它反映了一个更大的趋势：

1. API即权力：越来越多的硬件厂商把API当作生态控制工具，而不是开放接口。买车不等于拥有完整的数据访问权。

2. 智能家居的脆弱性：Home Assistant这类平台的优势在于整合各种设备，但这种整合依赖于厂商的API开放程度。一旦厂商收紧政策，整个自动化体系可能崩塌。

3. 开源项目的法律风险：逆向工程厂商API可能面临法律风险。大众这次的做法，本质上是在法律框架内封锁第三方访问。

4. 数据主权意识：用户购买了车辆，但车辆产生的数据归谁？这是一个越来越重要的问题，欧盟的GDPR和数据法案正在尝试解决。

长远来看

汽车厂商封锁第三方API的趋势短期内不会逆转。对于开发者来说，与其寄希望于厂商开放API，不如关注以下方向：

– 支持数据主权立法，推动用户数据可携带权

– 开发标准化的车联网协议，减少对厂商API的依赖

– 参与开源硬件项目，探索不依赖云端的车控方案

大众这次的操作，某种程度上也在倒逼社区寻找更可靠的替代方案。短期是痛点，长期可能推动整个领域向前发展。

本文参考来源：GitHub Issue #967 | HN讨论（316分）