认识蓝牙mesh模型

 什么是蓝牙mesh模型？ 根据蓝牙mesh术语表所述： “模型(Model)——定义的是一系列状态、状态转换、状态绑定、消息和其他相关性能的集合。节点中的元素必须支持一个或多个模型，并且模型定义了相关元素的功能。蓝牙技术联盟定义了许多模型，其中大部分模型被特意定位为能够在各类设备中使用的‘通用’模型。” 相关术语，请参阅蓝牙mesh术语表和蓝牙mesh技术概览。 从本质上讲，模型是标准软件组件的技术规格，决定了mesh设备的功能。模型是独立的组件，并且一个产品包含多个模型。总之，从网络角度来看，可以说模型决定了设备的功能。

 状态  模型包含各种状态，而状态是显示设备状况的数据项，例如开/关或高/低。简单状态可能只包含单个值，而复杂状态可包含多个字段，类似于C语言等编程语言中的结构体。 有时，不同状态项之间存在某种关系，这些关系被称为状态绑定。状态绑定指的是如果相关联的一方状态发生变化，另一方状态的数值则需要重新进行计算。有时，状态绑定需要满足一定的条件并且可能由其他状态启用或禁用。对于使用中的模型所定义的状态绑定，开发人员必须实现必要的逻辑并在需要时执行该逻辑。 相反，对于《蓝牙mesh模型规格》(Bluetooth Mesh Model Specification)中未明确定义的状态绑定，这种状态只能独立运行。例如，当通用开/关状态显示某设备当前处于关闭状态时，用户无法识别通用级状态的增加。通过将通用开/关状态设定到1，设备切换至开启状态，同时设备将开始在已设定的级别上运行。这一点很容易理解，设想它是一个旋转调光按钮，既可以通过转动旋钮调整房间内灯的亮度，也可以按下开关开灯或关灯。在关灯状态，转动旋钮不会产生任何变化，但如果在转动旋钮后按下开关，灯就会在之前所设定的亮度打开。  

模型类别 模型分为不包含状态的客户端和包含状态的服务器两大类。状态是表示设备某方面状况的数据项术语，例如开启或关闭状态以及当前的级别。 一些服务器模型与另一个服务器模型相关联，其名称也与另一个模型名称类似，但包含“SetUp(设定)”字样。例如，与“传感器服务器模型”相关联的是“传感器设定服务器模型”。在技术层面，设定服务器模型与其他服务器模型没有区别，它们都包含状态并能够生成和使用特定类型的消息。其用途是允许将模型的配置设置与主模型状态项分离，从而可以采取不同的访问控制策略。通常，网络管理员可以通过设定服务器模型对该模型的关联参数进行配置，而标准用户一般不允许执行此项操作。  

 

模型通信和性能 模型通过发送和接收消息进行相互通信。消息分为许多类型，这些类型被定义为每个模型规范的一部分，从而清楚展示模型可以产生、接收和理解的信息类型。 消息将状态值传递至其他设备，或是更改状态值，从而引发设备作出响应，并且这些响应通常是可见的。  软件开发者和蓝牙mesh模型  面向对象 对于软件开发人员，模型规格可以看作类似于面向对象(object-oriented)软件工程范例中的“类”，并将设备内部代码中的模型实现看作模型或对象实例。 蓝牙mesh技术规格并没有规定任何特定方式来实现代码中的模型，开发者可以根据正在使用的编程语言和应用程序接口(API)进行选择。但模型的确适用于面向对象的方式，并且蓝牙mesh技术规格中关于一个模型对另一个模型进行扩展的概念，也很容易让人联想到面向对象。  SDK变量 目前有许多用于开发mesh固件的软件开发人员工具包(SDK)，其中有些来自专门为自身模块创建SDK的蓝牙模块供应商，而Zephyr RTOS SDK等其他SDK属于跨硬件平台的SDK，可以为许多不同的目标板创建固件。目前，Zephyr支持100种不同的目标板。 无论您使用的是哪种SDK，实现mesh固件所涉及的原则都是相同的。本文将从开发者的角度，并以使用Zephyr SDK创建的代码为例进行说明。

models – an array of specific model definitionsstatic struct bt_mesh_model sig_models[] = {BT_MESH_MODEL_CFG_SRV&(cfg_srv),BT_MESH_MODEL_CFG_CLI(&cfg_cli),BT_MESH_MODEL_HEALTH_SRV(&health_srv, &health_pub),BT_MESH_MODEL(BT_MESH_MODEL_ID_GEN_ONOFF_SRV, generic_ onoff_op,&generic_onoff_pub, NULL),BT_MESH_MODEL(BT_MESH_MODEL_ID_GEN_LEVEL_SRV, generic_level_op,&generic_level_pub, NULL)};// elements – contains arrays of SIG models and vendor models (none in this case)static struct bt_mesh_elem elements[] = {BT_MESH_ELEM(0, sig_models, BT_MESH_MODEL_NONE),};// node composition – contains an array of elementsstatic const struct bt_mesh_comp comp = {.elem = elements,.elem_count = ARRAY_SIZE(elements),};

 节点组合 mesh固件开发者必须完成的首要关键任务之一是定义产品的mesh节点组合，即在代码中定义每个节点的元素个数以及每个元素所包含的模型。以上的节点图显示了节点、节点中的元素、元素中的模型以及每个模型所包含的状态项之间的关系。 各SDK在细节上会有所不同，但是在使用Zephyr SDK节点组合时需要创建一系列数组，每个数组都包含SDK提供的宏定义的结构。这似乎看起来与上面的示例很像：四个模型都属于同一个元素，而该元素是节点的唯一元素。  属性 蓝牙mesh模型中的数据项有两种形式。 状态值隶属于特定模型，其值的含义由模型规格定义。它们不具有自我描述性，并且与消息相关的状态可以从消息的操作码中推断来。 而属性，则是需要在特定上下文中解释的特征实例。 特征也与通用属性配置文件( GATT)一起使用。特征定义了其值所包含的字段，比如允许值及其含义。在与GATT一起使用时，特征包含通用唯一标识符(UUID)形式的显式类型标识符 。当在GATT中使用时，特征隶属于服务，而特征所属的服务可提供解释和使用该特征的上下文。例如，警报级别特征可以隶属于链路损耗(Link Loss)服务或即时警报(Immediate Alert)服务。特征的含义的变化取决于它所属服务的不同，这一点在GATT服务标准中也有所定义。
蓝牙mesh不使用GATT服务，而是由属性提供解释相关特征的上下文。

“温度8特征是一种表示温度测量的类型，它采用uint8格式，以0.5摄氏度为单位。蓝牙mesh模型已为该特征定义了若干属性，使其能够在各种上下文中被解释。当前室内环境温度属性表示温度8特征应被解释为在室内进行的测量，而当前室外环境温度属性则是在室外进行的测量。当前环境温度属性不取决于位置类型，而是将从其他位置属性派生。”

属性通过属性ID明确标识。在使用属性的模型中，属性ID和属性值包含状态值。例如，传感器数据状态包含一对或多对属性ID和相应的传感器值。 属性使相同的模型能够与各种数据类型一起使用。这对于像传感器服务器模型这样的模型而言是非常有利的, 鉴于任何类型的传感器数据都可以在定义了合适属性的情况下，在任何上下文中处理和解释而如果没有这种数据描述和封装方法，就会需要许多不同类型的传感器模型，或者传感器服务器模型因可能需要具有大量状态，来支持的每一类传感器数据。 客户端和服务器去耦(Decoupling) 在实现模型时，客户端模型和服务器模型务必对彼此的实现细节一无所知。例如，服务器无须知道或选择利用客户端可能发送的特定值的知识。双方对于彼此都相当于一个“黑匣子”。 编码模型 除了规定节点组合中每个元素所包含的模型之外，开发者还需要做些什么才能加入为其产品选择的模型？有时，开发者什么都不需要做。而一些模型是强制性存在的，比如医疗服务器模型等，并且SDK可以为此类模型提供一个完整实现，使开发者能够轻松地将它加入到节点组合中。 在大多数其他情况中，还需要执行多个额外步骤：

#define BT_MESH_MODEL_OP_GENERIC_ONOFF_GET BT_MESH_MODEL_OP_2(0x82, 0x01)
#define BT_MESH_MODEL_OP_GENERIC_ONOFF_SET BT_MESH_MODEL_OP_2(0x82, 0x02)
#define BT_MESH_MODEL_OP_GENERIC_ONOFF_SET_UNACK BT_MESH_MODEL_OP_ 2(0x82, 0x03)
#define BT_MESH_MODEL_OP_GENERIC_ONOFF_STATUS BT_MESH_MODEL_OP_ 2(0x82, 0x04)
// each array member contains opcode, min msg len, handler function
static const struct bt_mesh_model_op generic_onoff_op[] = {
{BT_MESH_MODEL_OP_GENERIC_ONOFF_GET, 0, generic_onoff_get},
{BT_MESH_MODEL_OP_GENERIC_ONOFF_SET, 2, generic_onoff_set},
{BT_MESH_MODEL_OP_GENERIC_ONOFF_SET_UNACK, 2,
generic_onoff_set_unack},
BT_MESH_MODEL_OP_END,
};

01 RX消息处理函数 所有与每个模型相关联且节点可能接收的(RX)消息操作码都需要进行寄存，并实现用于处理此类消息的一个或多个函数。上面的Zephyr代码便是如此。 模型接收的消息或是会更改状态值，(设定)或是通过请求在状态消息中报告特定状态的当前值(获取)。设定消息分为两种形式：无需响应(未确认)的消息和需要在状态消息中回复新状态值的消息。“设定”这一术语集有时被用于指代这两个变量中的任何一个。 在处理设定消息产生的状态更改时，开发者必须处理任何已定义的和活动的状态绑定，并根据需要重新计算其他随之变化的状态值。

02 TX消息生成器函数 模型几乎都需要发送(TX)和接收消息。因此需要编写一些函数来编制mesh消息和使用相应的API发送消息，并且可以通过合适的事件或设备交互(例如用户按下按钮或转动旋钮)来触发函数的执行。开发者应主要关注消息的访问层部分，而非与堆栈较低层相关的字段，不过也可能有例外情况。为了避免设备被视为可疑重放攻击而遭到拒绝，需要显著增加SEQ 字段，否则软件框架也会自动执行这一操作。

03 将应用程序密钥绑定到模型 为增加网络模式分析攻击的难度，所有mesh消息都使用AES-CCM进行加密和认证，同时标头字段也经过了混淆处理。堆栈上层的字段使用应用程序密钥加密，而堆栈下层的字段使用网络密钥加密，从而使网络与应用程序安全性分离，并允许节点执行网络功能，例如在无需或不具备消息应用负载解密能力的情况下收发消息。 一个好的mesh软件框架能够在设置设备时使用网络和应用程序密钥进行加密和混淆，自动保护消息的安全。但一个节点可能有多个应用程序密钥，并且每个应用程序密钥必须通过被称为“密钥绑定”的过程与特定模型相关联。这可以确保堆栈知道要使用哪种应用程序密钥以及哪种类型的消息。开发者必定需要在他们的代码中执行显式应用程序密钥绑定。在Zephyr上，应用程序密钥绑定如下：

/* Bind to generic level server model */err = bt_mesh_cfg_mod_app_bind(net_idx,addr,addr,app_idx,BT_MESH_MODEL_ID_GEN_LEVEL_SRV,NULL);

net_idx和app_idx属于索引值，它们引用一个或多个网络和应用程序密钥列表中的特定密钥，这些密钥是一个节点在最初设置和配置时就已配备的密钥。 应用程序密钥绑定是蓝牙mesh网络访问控制的基础。通过向网络管理员发放绑定到传感器设定服务器模型的应用程序密钥，使该用户能够更新相应模型状态并配置相关的传感器服务器模型。其他未获得此应用程序密钥的用户无法配置传感器设定服务器。  智能家居中的蓝牙mesh模型 自2019年1月起，蓝牙智能家居专项组就致力于创造能够集成到日常智能家居设备中的新蓝牙mesh模型。尽管这些模型是为智能家居所开发的，但它们也可以无缝应用于商业和工业智能建筑环境中。   您可通过以下视频了解蓝牙智能家居专项组如何实现智能化、一体化的智能家居体验。  蓝牙mesh模型完整介绍 您可在”硬禾学堂“后台回复 “蓝牙” 获取《蓝牙mesh模型——技术概览》全文来全面了解蓝牙mesh模型。这篇文章概述了泛型如何支持许多设备类型所具有的基本功能、如何通过照明模型满足商业照明需求以及如何使用传感器为其他设备提供可触发自动响应的环境数据。