4.2 应用框架：端点、应用对象与应用规范

4.2 应用框架：房间里的布局规则

本节摘要：应用框架规定端点里住什么——应用对象按应用规范实现、用簇组织语义、用属性存状态；应用规范标识声明方言，端点零固定留给设备对象，描述符向外自我介绍。本节承接端点分拣，是第七章集群库的直接前置。

一、从端点到应用对象

上一节把帧送到了端点门口，这一节开门看里面。每个端点里住着一个应用对象——一组实现了特定功能的簇集合。比如一个调光灯的应用对象里，通常有开关簇（管开与关）、调光簇（管亮度与渐变时间）、群组簇（管加入退出分组）。应用对象是"功能的最小可寻址单位"：发现服务问"你有哪些簇"，绑定配置挂到簇粒度，控制命令也发到簇上。

应用对象必须声明自己说的是哪种方言——应用规范标识。两台设备端点都实现调光簇，但一个按家居规范一个按楼宇规范，细节语义可能对不上。应用规范标识写在发现应答与绑定配置里，等于每次握手先对暗号。这段机制的历史背景在第一章讲过：分叉年代各家方言不通，统一版把这些垂直方言收敛成一份基础规范加扩展——落到协议上，就是应用规范标识体系的简化与统一。

一台多合一传感器上的端点布局示例：

端点零    设备对象（总管家）：网络管理 · 设备发现 · 绑定管理
端点一号  温湿度应用对象：温度测量簇 + 湿度测量簇 + 基本信息簇
端点二号  占用感应应用对象：占用感应簇 + 基本信息簇
端点二四二 绿色能源代理对象（若支持无电池设备入网，见第九章）

每个端点对外的自我介绍（描述符）：
  · 端点描述符：端点号 · 应用规范标识 · 设备版本
  · 簇描述符：支持的输入簇列表（我能听懂）· 输出簇列表（我会主动说）
​

二、簇与属性：语义的两级组织

簇是"一类功能"的标准封装，内部再分两级：属性是状态变量（温度值、开闭状态、亮度百分比），命令是操作请求（读属性、写属性、触发动作）。这套组织刻意设计成"声明式优先"——绝大多数控制可以表达为"读一个属性"或"写一个属性"，而不是调用五花八门的命令。声明式的好处是通用工具可以即插即用：任何网关拿到一台陌生设备，只要按标准属性读写，就能完成基础的监视与控制，无需为每家厂商写插件。第七章会把整套簇目录展开细讲，这里记住结构即可：端点住应用对象，应用对象装簇，簇里装属性与命令。

输入与输出簇的区分值得单独一提，它定义了通信的方向习惯：输入簇是"我提供的能力"（传感器把它实现的测量簇列为输入），输出簇是"我会主动发出的语义"（开关把它的开关节点侧簇列为输出）。配对绑定时，一端的输出簇对另一端的输入簇，方向就自然成立——开关对灯，传感器对网关，都是这个逻辑。

三、描述符：设备的自我介绍

设备入网后被问"你是谁、你会什么"，靠描述符作答。节点描述符报告整机信息：设备类型（协调器、路由器还是终端设备）、厂商代码、电源来源；端点描述符报告单端点的方言与簇清单；简单描述符是最常用的浓缩卡片，发现服务逐端点收集简单描述符，就能拼出全网的能力地图。统一配网（第八章）里"发现并绑定"流程的第一步，就是扫一遍目标端点的简单描述符，找到实现目标簇的端点再配绑定。

💡 关键直觉：描述符体系让网络"自描述"。传统工业总线要靠人工录点表（哪个地址是什么设备），这里的网络靠设备自己报家门。规模化的智能家居能"一键添加设备"，底层靠的就是这套自我介绍机制加第六章的安全入网。

图：端点-应用对象-簇的嵌套结构

四、厂商自定义的边界

应用框架给厂商留了自定义空间：非标准功能可以做成私有簇（厂商特定簇编号区段），不影响标准簇的互操作。这个口子的历史教训深刻——分叉年代部分厂商把本该标准化的语义塞进私有簇，产品号称符合规范却只能跟自家网关说话。统一版之后生态明显收敛：核心体验走标准簇，私有簇只放真正的差异化功能。选型时看设备文档里私有簇的占比，基本能预判它跟第三方网关的兼容性。

⚠️ 常见坑：发现到的端点声称支持某标准簇，实际行为不符合规范（属性不存在、命令无声）。互操作测试的意义就在这里——描述符只是自我介绍，是否言行一致要靠认证与实测兜底，第十章的认证流程会接上这一环。

本节要点回顾

• 四级嵌套：设备（地址）→ 端点（分拣号）→ 簇（功能封装）→ 属性与命令（状态与操作）；
• 方言声明：应用规范标识决定簇语义的解释框架，统一版的历史就是方言收敛史；
• 方向约定：输入簇是能听懂的能力，输出簇是会主动说的语义，绑定按输出对输入配对；
• 描述符自描述：节点、端点、简单描述符让网络免人工录点表，是一键添加的底层支撑；
• 私有簇边界：差异化可以私有，核心语义必须标准，私有簇占比是兼容性风向标。

房间布局完毕。下一章聚焦端点零里那位总管家——设备对象如何操持整个网络的生命周期。

延伸：端点模型的行业影响

端点加簇的语义组织影响深远：后来的统一应用层标准（第九章）的数据模型明显继承了"端点承载功能、簇组织语义、属性存状态"的三层结构，桥接翻译因此才可能有"形态对应"。可以说，第四章的组织方式是这套生态最重要的接口遗产——物理层会换代、网络层会被替换，但"设备即端点集合、功能即簇集合"的抽象一直被沿用。学透这一节，等于同时预习了半个新标准的数据模型。

常见问题

一台设备最多能有多少个业务端点？

编号空间给到二百四十，实际受协议栈内存限制，典型实现支持十几个业务端点绰绰有余。真实产品很少超过五六个——把强相关的功能合并进一个端点（共用簇）比拆成多个端点更符合语义组织习惯。

速查：端点编号约定

• 零号：设备对象（全网统一的行政窗口）；
• 一到二百四十：业务端点；
• 二百四十一到二百五十四：保留；
• 二百五十五：广播端点（配合广播地址全呼）。

配套三查：端点在不在（分拣失败）；簇认不认（语义缺失）；规范标识同不同（方言错位）。帧没人理的排查顺序即此三查。

补端点规划的产品设计视角。端点的划分是产品定义的一部分，给三个设计案例。案例一，智能插座单端点：一个端点包含开关与电能计量 cluster——简单产品单端点够用。案例二，多 gang 开关多端点：四路开关面板用四个端点（每路一个开关 cluster），映射到四个独立设备——端点是"逻辑设备"的边界，一个硬件可以伪装成多个逻辑设备。案例三，复合传感器端点分组：一个多合一传感器（温湿度加光照加人体感应）按功能域分端点（环境端点、安防端点），让网关按端点订阅不同的数据。端点设计的反面教材是把所有功能塞进一个端点的所有 cluster——网关的设备类型识别会混乱（它不知道你到底是什么）。端点设计的正反两面的底层原则：端点边界应该与"用户心中的设备边界"一致——用户认为这是几个设备，就做几个端点。