原本小编是想将Element(元素)和Model(模型) 拆分开成两篇独立的文章来讲解，但是实在没有办法做到；因为它们两者之间的绑定实在太深了，如何非要将他们剥离之后单独讲解会很容易导致理解不连贯；如果用过BLE的读者应该就会比较好理解这两个新的名词，其分别类似于profile与service的关系。当然啦，新人也不必悲观，下面我用两幅图来让大家先有一个基础的了解。
元素包含定义一个节点功能的实例，每个节点都可以包括一个或者多个元素，且至少存在一个叫首要元素的元素，就类似于一个BLE设备可以包括一个或者多个profile一样。举个例子，一个调光的灯泡通常会有一个元素，这个元素就会向外公开其具备的一个或者多个功能，例如通用开关和亮度控制功能。在这个例子中，Light Lightness Server Model就用于实现开/关和亮度等级控制功能。
另外一个例子就是调光灯泡还包含有一个占用传感器，此时这个节点将会有两个Element(元素):
- 用于灯泡的控制
- 用于传感器的控制
首要元素用于灯泡控制，第二个元素用于传感器的控制，如下图所示：
节点中的每个元素都有一个唯一的地址，称为单播地址。这允许每个元素独立于同一节点内的其他元素进行寻址，也就是说可以通过单播地址找到节点的各个元素。
起初，小编刚看到这个名词一时半会也难于理解这是啥玩意啊？就跟下图的反应一样：
其实，模型就是定义了节点的真正的功能，其汇集了一个元素的状态、转换、绑定、信息的概念。也就是小编上面提及到的Model(模型)就类似于正常BLE设备的Service。而Mesh的模型又分为三种类型：
服务端模型可以具有跨越一个或多个元素的一个或多个状态，服务器模型定义了模型可以发送和接收的消息，它还定义了基于这些消息的Element的行为。换句话说，服务端模型公开了可以被客户端读取或控制的元素的状态。一个服务端模型的应用实例就是：对外公开传感器状态的传感器或者存储当前灯光状态的灯泡
客户端模型定义了一组请求并更改服务端状态的消息。例如，ON/OFF开关（作为客户端运行）可以向ON/OFF服务端发送消息以更改设备的状态
最终的应用程序可以使用服务端模型或客户端模型，或两者以及控制逻辑。服务端和客户端模型的任意组合都会产生控制模型。
但是上图的 “Message A/B/C” 的箭头方向应该是有问题的，正确的应该是Client-->Service，除了上面的之外，模型可以扩展其他模型的功能。也就是说，模型可以是分层的。例如，灯光亮度模型扩展了通用开关服务端模型和通用等级服务端模型。这意味着如果你在应用程序中实现灯光亮度模型，你将获得所有控制灯光、通用等级以及通用开关的功能。不扩展其他模型的模型称为 “根模型”
这个状态以及属性又是从模型中引出的概念，因此了解了状态与属性也是加深理解模型的重要关键。
元素可能处于各种情况;在SIG Mesh中，这些条件存储在被称为状态的值中。每个状态都是元素中包含的某种类型的值。除了值之外，状态还具有与该状态关联的行为，状态由蓝牙SIG定义。例如，称为 “通用OnOff” 的状态，其可能具有两个值ON或OFF(行为)。这对于灯泡或风扇电机等设备非常有用。术语 “通用” 用于表示此状态及其行为可能在不同类型的Mesh设备中都有用。
属性还包含与元素相关的值;但是与状态不同的是属性提供了解释状态的上下文。例如，要发送温度状态值的设备，温度状态可以是 “当前室内环境温度”或“当前室外环境温度”。在这种情况下，将使用属性来提供温度状态值的上下文。属性可以是制造商属性，它们是只读或管理员属性，允许读写访问。
状态转换可以是瞬时的，或者可以在称为转换时间的时段内执行。
状态可以被绑定在一起，使得一个状态的变化导致另一个状态的变化。一个状态可以被绑定到多个其他的状态。例如，由调光器开关控制的灯将具有一个称为Generic OnOff的状态，另一个称为Generic Level的状态来控制灯的亮度。如果灯处于ON状态但是变暗到Level变为0时，那么OnOff状态将转换为OFF，这就是状态绑定的一个实际的案例。