HomeKit 从零完全入门指南（一）：认识 HomeKit

如果你对智能家居有所了解，那应该或多或少听人聊起过 HomeKit。由 Apple 开发并主推的的 HomeKit 既因为产品选择少、价格高而难以成为主流，又因其独特的优秀体验和「出身名门」而成为智能家居领域的焦点。HomeKit 究竟是什么？能做什么？怎么做到的？在《HomeKit 从零完全入门指南》的第一篇里，就让我们从核心原理的角度来解答一下这个核心的问题。

HomeKit 是什么？

想要准确描述 HomeKit，定义是不可或缺的第一步。然而，HomeKit 和相关的术语其实长期被不少人所混淆。我们来看看 Apple 自己是怎么定义 HomeKit的：

这是 Apple 推出的一组软件开发工具。用 HomeKit 创建的 App 可让您从 Apple 设备控制家中已连接的配件（如电灯、锁或暖气和冷气）。

——《Apple 词典》

以上的定义说明，HomeKit 的本质其实是一个「开发套件」。它包含了很多常常被大家简称为 HomeKit 的部分，包括：

• iOS 等系统上的 HomeKit 框架
• 智能家居设备采用的 HomeKit 设备协议（HomeKit Accessory Protocol，以下简称 HAP 协议）
• HomeKit 设备开发工具包（HomeKit Accessory Development Kit）
• 等等

有些人还可能将 iOS 等系统上预装的「家庭」app 同 HomeKit 混淆，但两者完全不同，我们将在之后对「家庭」app 作进一步的介绍，这里就不做展开说明。

有了这个定义，我们也就不难理解「Works with Apple HomeKit」这一 HomeKit 官方认证的真实含义了——它表明这一外设兼容于 HomeKit，可以和其它兼容 HomeKit 的软硬件进行交互。那么「Works with Apple HomeKit」认证（以下简称 HomeKit 认证）到底有何特殊之处呢？是否经过认证对于一般的 HomeKit 用户来说有影响吗？

Works with Apple HomeKit

「Works with Apple HomeKit」认证（以下简称 HomeKit 认证）是苹果 MFi 计划 的一部分，这意味着想要通过 HomeKit 认证的厂商需要先加入 MFi，然后为单项产品申请 HomeKit 认证。苹果对 MFi 计划有着充分的掌控，说 HomeKit 认证的「含金量」绝大多数来源于其优秀的产品口碑也不为过。

实际上，苹果对 HomeKit 设备的要求并不算高，这一认证成为「品质保障」很大程度上可以说「全靠同行衬托」。与其他智能家居平台直接限制芯片模组的策略不同，目前的 HomeKit 认证并不干涉产品的软件设计和硬件实现，而是对工厂采取备案制。拥有自主生产线的大公司可以为自己的工厂申请资质，通过审查后就获得了生产 HomeKit 认证设备的资格；智能家居领域中占多数的初创公司则可以直接联系已经拥有资质的代工厂，委托其进行生产。这样的模式可以为代工厂带来新的订单，同时也杜绝了「小作坊」生产的可能性。

除了生产上的管控外，苹果还要求 HomeKit 申请者拥有其它标准组织例如 Wi-Fi 联盟或蓝牙技术联盟的认证。HomeKit 视觉元素的使用同样受到严格的限制。HomeKit 的设备一般采用静态设置码进行配对，厂商需要根据规范印刷设置码，并保证随机生成、一机一码。对许多 HomeKit 用户来说，设置码贴纸已经成为了 HomeKit 最具代表性的要素之一。

截至目前，「Works with Apple HomeKit」认证同商用版 HAP 协议是高度绑定的。如果没有申请 HomeKit 认证，设备厂商就无法获取商用版 HAP 协议文档；HomeKit 认证也只面向实现了商用版 HAP 协议的设备开放。不过，在 WWDC21 大会上，苹果已经宣布 HomeKit 将包括对 CHIP（Matter）协议的支持¹，因此未来这一认证很有可能将向符合要求的 Matter 设备开放。由于 Matter 设备尚未上市，且暂时无法认证，如果没有特殊说明，在以后的文章中「HomeKit 设备」均指代 HAP 设备。

HomeKit 认证的核心之一是「Works with Apple HomeKit」标志的使用许可。通过 HomeKit 认证的产品可以将「Works with Apple HomeKit」标志打印在产品的包装和说明书上，或者在官网、电商等平台使用这一商标进行宣传。与「Made for iPhone」等其它 MFi 标志类似，智能家居厂商可以利用苹果的品牌宣传自己的产品，这一定程度上可以提升产品的溢价。

与长期处于争议焦点的 MFi 认证芯片类似，HomeKit 认证也需要使用定制的安全芯片。厂商需要在此基础上进行设计，并且向苹果申请少量安全模块进行试产，试产品通过认证后方能量产。在 2019 年，HomeKit 认证开放了服务器验证方案。选择软件（服务器）验证的厂商可以直接进行预生产，并将产品提交认证；在获得认证后，苹果服务器将同步认证信息，产品也就可以通过 HomeKit 框架的检验了。

HomeKit 认证设备还可以使用更多的 HomeKit 功能。诸如自适应照明、HomeKit 安全视频等 HomeKit 进阶功能都必须通过 HomeKit 认证才能激活。如果说未经过 MFi 和 MFM（Made for MagSafe）认证的第三方充电线无法激活 iPhone 快充仅仅是让充电变得更慢，那缺少设备 HomeKit 认证可就会带来实打实的功能缺失了。

未认证的 HAP 设备

在发布之初，HomeKit 仅支持本地的硬件验证。只要正确使用了 HomeKit 安全芯片，即使产品本身尚未取得认证也能通过 HomeKit 的检验。然而，用于试产的芯片数量少，管控严格，几乎没有流向市场，一般消费者很难接触到。在购买时，消费者可能遇到的「未认证 HomeKit 设备」主要有两种情况：采用软件验证方式并且未获得认证的，采用非商用版 HAP 协议的。在通过 HomeKit 添加设备时，如果所添加的设备未能通过验证，系统将通过弹窗进行提醒。

由于软件验证方案不需要特殊硬件，商用版 HAP 协议的绝大多数基础功能如今均已经被破解且可以直接使用。大名鼎鼎的 HomeBridge 项目就是基于逆向破解的 HAP 协议。HomeKit 会通过「HomeKit 已认证」属性来标记认证状态。在「家庭」app 中，这一属性默认隐藏，只在验证不通过时展示；「家庭」app 还会在顶部横幅提示「此配件尚未经过认证，可能无法配合 HomeKit 稳定运行」。

非商用版 HAP 协议无法获得认证，也不会有横幅提示，它的使用体验更接近一般的认证设备。任何注册的 Apple 开发者都可以在网站上获取该协议，但采用非商用版 HAP 协议的设备不得用于商业目的，也不能公开分发或者销售。这实际上是不少人坚持使用破解版协议而不是公开的非商用版协议的原因。不过，由于两种协议的原理和设计基本一致，下文的原理介绍均基于非商用版协议进行讲解。

值得注意的一点是，无论是以上哪种情况，未认证的 HomeKit 设备均不能使用「Works with Apple HomeKit」商标进行宣传；采用非商用版 HAP 协议的设备更是不允许公开销售。如果大家在选购 HomeKit 设备前后发现了相关的违规情况，应该考虑向苹果举报并进行维权。

HAP 的通信机制和安全性

在之前的图例中，我们已经展示了 iOS 设备上的 HomeKit 框架是如何工作的，而其中的 HAP 子框架和 HAP 设备之间通信的「语言」正是 HAP 协议。HAP 协议包含了为基于 IP 的设备和基于低功耗蓝牙（Bluetooth LE，以下简称 BLE）的设备设计的两套安全的通信协议。我们可以通过了解 HAP 通信协议一窥 HomeKit 设备与终端（指 iPhone 等控制端设备）设备日常通信的方式。

对于基于 BLE 的设备，iCloud 将跨设备同步配对信息，因此可以直接用 BLE 建立设备间的点对点通信。为满足 BLE 的数据包大小限制，HAP 协议还规定了数据包拆分发送的规则。对于基于 IP 的设备，HAP 则充分利用了自家的 Bonjour 协议进行广播和发现，并利用 HTTP 进行通信。HomeKit 请求都是由终端设备向 HomeKit 设备发起，然后 HomeKit 设备将按要求更新状态并向终端设备返回信息。HomeKit 还规定了包括加密流（stream）传输在内的其他连接形式，但应用较少，我们就不多介绍了。

终端设备每发现一台已配对的 HomeKit 设备，就会尝试与之建立会话（session）。HomeKit 设备在初始配置时会生成一对永久密钥。二者会根据交换的随机数据和已记录的永久密钥生成一对临时密钥，其有效期仅维持到当前会话结束为止。所有通信均采用带数据校验的对称加密，因此可以保证可靠性和安全性。任何解码错误或连接断开都会结束当前会话，从而最大程度地防范攻击风险。

说到这里，其实 HomeKit 最大的特点已经呼之欲出了：与其它智能家居协议通过服务器或者智能音箱作为「中介」进行操作不同，HAP 通信协议在设计上就有点对点、本地和安全这三大特点。这也意味着 HomeKit 完全可以在没有互联网²的恶劣环境中正常工作——我们将在介绍 HomeKit 安全路由器时详细分析其应用。也正是因为这点，HomeKit 无法像其它平台那样通过服务端控制来筛选认证设备，只能采用本地安全芯片。即使后来开放了软件验证选项，在无法联网验证的环境下也只会显示警告，并不会影响使用。

HomeKit 本地运行机制详解

HomeKit 设备列表、永久密钥和房间分组等信息由 iCloud 负责管理与同步，而实际的设备控制等操作全部在本地完成。为了保障安全性，终端通过 HAP 控制 HomeKit 设备的过程相比其它智能家居平台要繁琐不少——当然，这些差异对用户几乎是无感知的。

如果你有兴趣对 HomeKit 的控制方式进行更深入的了解，我们可以一起来深入探究一下 HomeKit 工作的每一个环节，并且还可以从中发现 HomeKit 体验不佳的症结，当然跳过这一节也对后续内容的理解不会产生任何影响。

为了成功建立会话，HomeKit 设备和终端设备需要进行双向的配对。HomeKit 设备上记录了所有可信任设备的列表，一旦发生变化，iCloud 就会通过终端向 HomeKit 设备发送指令来进行更新，以保证其他设备可以正常连接。不在列表中的设备会被直接拒绝访问。对于 BLE 设备而言，这种机制十分接近 AirPods 的「通过 iCloud 自动连接」，可以实现一次配对、多设备无感连接。

对于基于 IP 的 HomeKit 设备，它们将根据 mDNS（多播 DNS，Multicast DNS）协议在局域网中广播自己的 .local 本地域名³和 IP 地址⁴。mDNS 的原理就好比是在一个随机入住的酒店里，房客可以时不时向所有房间广播自己的名字和房间号，认识他的其他房客会将他当前的房间号保存下来。根据本地缓存的 mDNS 信息，终端设备就可以用固定的域名访问到局域网中的某个 HomeKit 设备，而无需担心其 IP 地址发生变化。

Bonjour 是苹果在十几年前基于 mDNS 和 DNS-SD（DNS 服务发现，DNS Service Discovery）开发的一套软件，它在二者的基础上提供了更高级的接口。HomeKit 设备会使用 Bonjour 注册一个专属服务，HomeKit 则通过查询服务信息来判断该设备是否属于当前「家庭」。终端设备同样会与基于 IP 的 HomeKit 设备自动建立会话。如果终端设备有监视 HomeKit 设备状态的需求（例如传感器的状态变化通知，或家庭中枢的自动化触发等），它将通过 HTTP 维持一个 TCP 长连接来接收实时消息。

如果 HomeKit 设备数量增加呢？我们假设当前家庭中注册了 30 个基于 IP 的 HomeKit 设备（其中 5 个状态受到监视）和 10 个 基于 BLE 的 HomeKit 设备，那么每台终端设备都需要：

• 和 10 台蓝牙外设保持连接；
• 和 5 个 IP 设备维持 HTTP 长连接。

不仅如此，在每台终端设备初次激活 HomeKit 时，会发送多达 60 条 HTTP 请求来进行配对；整个局域网中至少存在着 30 个 Bonjour 节点，它们在不停进行着 mDNS 广播。当我们打开「家庭」app 时，它会通过 HomeKit 请求所有包含在「家庭状态」和「常用配件」中的配件状态，而这些 HTTP 和蓝牙请求全部是「瞬发」的！

从以上的例子中，我想大家应该已经发现了 HomeKit 体验的「杀手」所在。

HomeKit 体验的两大杀手

大量 mDNS 节点、瞬发 HTTP 请求、长连接，这些 HomeKit 的行为对路由器产生了巨大的压力，使路由器成为 HomeKit 体验的最大瓶颈和头号杀手。传统的智能家居平台只需要在每台 IP 设备和服务器间维持一个 TCP 长连接，终端设备的所有控制指令和状态获取都直接向服务器进行请求，再由服务器下发到设备上。而 HomeKit 的点对点特性则规定任何指令都需要独立的本地 HTTP 请求，对路由器的瞬时交换能力提出了不小的挑战。

由于 HomeKit 设备发现完全依赖 Bonjour，这对路由器的 mDNS 兼容性也是不小的考验。如果没有进行针对性的优化，路由器很可能因为频繁的 mDNS 广播报文而导致性能下降；如果优化策略有问题，也可能导致 HomeKit 无法正常工作。

HomeKit 体验的另一大杀手则是蓝牙——相比基于 IP 的局域网通信，蓝牙通信虽然功耗低、成本低，但速度也远远不及 Wi-Fi。为保障安全性和通用性，相比其它智能家居协议，HomeKit 指令体积更大、数量也更多，传输速度自然也就更慢。即使是经过优化后，蓝牙设备发送状态更新消息（也就是触发自动化和推送通知）的延迟也只能达到亚秒级，是一般 TCP 请求的百倍，已经处于人可感知的范畴。此外，蓝牙设备信号覆盖范围有限，单个蓝牙设备很难做到全屋可连接；因此通过个人终端连接时很可能出现「未响应」的情况。在后文中我们将看到 HomeKit 是如何通过「家居中枢」来优化蓝牙设备的使用体验的。

HomeKit 对 Wi-Fi 系统的挑战

相较于路由器，HomeKit 对于 Wi-Fi 的性能需求并不突出，但 Wi-Fi 系统的孱弱仍然有可能成为影响 HomeKit 体验的隐患。这样的挑战是目前阶段绝大多数智能家居平台中普遍存在的，下面我们来简要介绍一下。

目前，大部分 Wi-Fi 智能家居设备只支持 2.4GHz 频率的 Wi-Fi 4 协议，而且功率较低，穿墙性能和抗干扰能力都较弱。摄像头、传感器等智能家居设备还往往被放在家中的角落，靠单一路由器进行覆盖很可能出现死角。此外，智能家居设备几乎都不支持 MIMO；为了服务这些设备，其他无线设备（例如手机、电脑）的信号很可能受到影响。

考虑到 Wi-Fi 接入目前仍然是智能家居单品的主流入网方式，在布置 HomeKit（以及其他智能家居系统）前建议先升级自己的无线 AP 布局。对于已经入住的家庭来说，mesh 路由系统是扩展无线覆盖最省心的选择；还在装修阶段的也可以提前布局 AC+AP 方案。为智能家居布设 Wi-Fi 应当尽量确保所有可能安装智能家居设备的位置都有较强的 2.4GHz 信号覆盖，以免设备发生断连掉线。

HomeKit 家居中枢工作原理

HomeKit 家居中枢是 HomeKit 另一个十分特别的存在——在其他智能家居平台中，往往由服务器或网关来承担自动化和远程访问等功能。云端自动化功能灵活，但十分依赖互联网访问，并且可能存在安全和隐私风险；物联网网关虽然位于本地，是离设备最近的「关卡」，但它性能有限，难以承担复杂的逻辑，也往往不支持并行处理多个自动化，容易成为自动化性能的「瓶颈」。

HomeKit 创新性地采用了「家居中枢」作为自动化设备。家居中枢位于同一局域网内，HTTP 请求仅有毫秒级延迟。即使是数年前的 A8 芯片，相比其他智能家居设备所使用的芯片依旧拥有碾压级的性能，完全不用担心并行和复杂逻辑问题。由于操作系统「师出同门」，HomeKit 家居中枢甚至支持「快捷指令」这样高度自由的自动化方案。曾经有朋友吐槽过同样的自动化逻辑使用 HomeKit 这样的「外挂」执行速度竟然快于米家的网关自动化，这正暴露出网关设备的性能不足。HomeKit 自动化「纾解」了网关设备的「非网关功能」，反倒提升了整个智能家居系统的性能。

除此之外，HomeKit 家居中枢还承担着多重意义上的「网关」职能。家居中枢可以作为「代理」执行 HomeKit 指令，并且将非 IP 设备桥接到局域网中。由家居中枢代理的 HomeKit 请求和终端设备直接发出的请求 几乎没有差异。

对于蓝牙设备来说，它是将蓝牙设备桥接到局域网的网关。蓝牙设备只需要和家居中枢保持连接，HomeKit 就可以通过 HTTP 访问家居中枢进行代理操作，而无需每个终端设备都进行连接。这样以来既减轻了蓝牙设备的压力，又通过「信号择优」的方式提高了蓝牙的设备的响应性能。

以上方案充分扩展了蓝牙设备的连接范围，但还没有彻底解决传输速率不足和延迟高的问题。HomePod mini 上首先引入的基于 Thread 的 HAP 协议作为对蓝牙 BLE 的补充，不仅大大提高了响应性，还利用Thread 稳定、低延迟的 mesh 组网进一步扩大了 HomeKit 设备的「朋友圈」。在接入 HomeKit 后，支持 Thread 的蓝牙 HomeKit 设备可以被家居中枢所识别，然后自动加入包含家居中枢的 Thread 网络。如此一来，家居中枢就成为了设备的 Thread 网关，接收到相关请求后会通过 Thread 而不是蓝牙来进行通信，由此解决了延迟问题。

除了蓝牙和 Thread 网关，家居中枢还是所有 HomeKit 设备的「互联网网关」。如果 iPhone 等个人终端并不处于同一局域网中，它们将首先通过 iCloud 连接到家居中枢，并通过家居中枢「代理」进行远程访问。家居中枢和 HomeKit 设备间、家居中枢和个人终端间会分别建立点对点加密会话，iCloud 虽然可能进行二次加密，但并不能获取真正传递的信息，可以说是一种将安全性做到极致的设计。

理解 HomeKit 抽象模型

在上文中，我们介绍了 HomeKit 的底层通信机制，它根据设备采用的通信协议分为两种不同的类型。在这些协议的基础上，HomeKit 建立了统一的抽象模型来描述它的智能逻辑。相比为了安全性而不惜将问题「复杂化」的通信协议，HomeKit 的抽象模型设计十分简洁。它只包含三个不同层次的核心概念：

• 设备（accessory）
• 服务（service）
• 属性（characteristic）。

「服务」是对某一类设备功能的抽象。除了名为「设备信息」，用于展示制造商、序列号、固件版本等信息的一个必须的服务外，大部分设备只包含一个服务，和自己的功能相匹配。为了最大程度的抽象和复用，部分服务类型会可能「附加」其它服务。例如「空气净化器」就可以附加「风扇」服务；如果一个设备同时包含「空气净化器」和「风扇」服务，HomeKit 会推断出这是一台空气净化器，「风扇」控制的是空气净化器的风速，并且二者的开关状态应当同步。

每个服务都规定有可选和必选属性，例如「设备信息」服务中制造商、型号等属性都是必须提供的。属性反映设备的某个特征或者状态，例如开关状态、传感器数据等。属性支持多种不同的权限组合：设备制造商信息是只读（paired read）的，开关既可读（paired read）又可写（paired write），传感器数据等可以用于触发自动化的则必须具备通知（notify）权限。支持推送消息的关键属性则需要在通知的基础上实现事件（event）。除此之外，还有立即写（timed write）、写返回（write with response）、广播（broadcast）、隐藏（hidden）等权限。设备还可以定义私有属性，这些属性在「家庭」app 中将向一般用户隐藏，但可以被 HomeKit 用于控制以及自动化等操作。

通过以上介绍我们不难发现，HomeKit 规定了每个设备只能拥有一个主要服务，它反映了该设备的主体功能。然而，HomeKit 中的服务定义又十分克制，很多带有额外传感器的 HomeKit 设备并不能用单一设备来描述。HomeKit 中每个物理设备（即单个 IP 或 BLE 设备）可以对应一个或多个逻辑设备（以下简称子设备），HomeKit 可以通过接口获取逻辑设备列表。在「家庭」app 中，我们可以通过「作为单一板块整体显示」和「作为单独板块分开显示」按钮将子设备聚合或分开显示。

桥接器（网关）是一类特殊的设备，它承担着将非 BLE 或 IP 设备接入 HomeKit 的功能。通过桥接器接入 HomeKit 的设备可以以「产品组合」的形式通过 HomeKit 认证，宣传和销售时除了印刷「Works with Apple HomeKit」标志，还需注明支持 HomeKit 的桥接器型号。有些设备既有自己的功能，又可以用作桥接器（例如 Aqara 空调伴侣 P3）；也有一些设备只有桥接功能，「家庭」app 将它们隐藏到了「家庭设置 > 中枢与桥接」中。我们可以在这一页面查看或移除桥接器。

HomeKit 设备入网与初始化

作为「HomeKit 原理」的最后一块拼图，我们需要谈谈 HomeKit 设备的入网和初始设置流程。为了在本地完成设备的配置和认证，HomeKit 不像米家等平台那样提供「支持设备列表」和操作指南，而是完全依靠蓝牙和 Bonjour 发现（discover）附近的设备。这样反倒创造出了更一致的设备添加流程，成为了 HomeKit 的一大标志性体验。

对于 BLE 设备来说，未经注册的设备会不停「广播」一个特殊的「HAP 配对」服务，HomeKit 将监听这类广播消息，从而识别附近正在等待配对的设备。Wi-Fi 设备的入网则实际上使用了 MFi 无线设备配置功能；这一功能只对 MFi 计划的认证硬件开放，并且需要专用 BLE 蓝牙芯进行服务广播片以被 iOS 设备发现。还有一类 IP 设备并不通过 HomeKit 的配对流程接入局域网。它们可能使用有线连接，或者拥有更复杂的功能（例如电视机），因此这类设备将直接通过 Bonjour 被发现。

个人终端设备将结合设置码来自动发现对应的 HomeKit 设备，确认它还未添加到 HomeKit，然后为设备配网。绝大多数 HomeKit 设备采用的静态设置码会以贴纸的形式出现在机身或者说明书等位置，目前主要有二维码贴纸和 NFC 贴纸两种。使用 iOS 或 iPadOS 设备的摄像头或 iPhone 的 NFC 扫描对应贴纸都可以激活配对流程。使用动态设置码的带屏幕设备需要在屏幕上展示二维码供扫描，例如电视机和机顶盒。

已经正确配对或接入后后，下一步需要进行初始设置。整个流程采用安全远程密码交换协议（Secure Remote Password protocol），需要进行三个来回的信息传递，期间将验证设置码的有效性，并为 HomeKit 设备生成一个长期密钥。这一密钥在还原出厂设置前都将保持不变。设置完成后，HomeKit 就会尝试和该设备建立会话，以上流程全部无错误则设备添加成功。

小结

在《HomeKit 从零完全入门指南》的第一篇里，我们将 HomeKit 从添加、连接到控制的整个流程进行了完整的分析，并介绍了 HomeKit 为安全性所做的努力以及一些常见的可能影响 HomeKit 体验的硬件设施。我们还介绍了远程访问、Thread 以及自动化等家庭中枢的专属功能的实现原理。在接下来的章节中，我们将告别底层原理，从实际应用的角度来谈谈 HomeKit 的「使用姿势」。

© 本文著作权归作者所有，并授权少数派独家使用，未经少数派许可，不得转载使用。