天猫精灵蓝牙mesh设备模型解析

简介: 本文根据《蓝牙mesh协议》,介绍与天猫精灵适配的蓝牙mesh设备在软件上的模型架构;希望通过该文章让初次接触蓝牙mesh的同学掌握蓝牙mesh设备的模型概念,理解蓝牙mesh设备模型与设备之间的关联。根据《蓝牙mesh协议》中定义,蓝牙mesh设备的模型架构主要分为Element(元素)、Model(模型)两部分;天猫精灵蓝牙mesh设备在这两部分的基础上增加属性概念(具体可参考《蓝牙mesh扩展协议》)。在创建一个适配于天猫精灵生态的蓝牙mesh设备时,我们先根据产品具体特性,抽象出产品具体属性,然后根据属性选择对应的Model,最后再根据设备特性确定Element。

一、蓝牙mesh设备模型概念介绍

1.1 产品属性
产品属性是一个类型产品具体要实现的功能抽象。
例:
一个灯要具备开关功能,则该设备需要具备“开关”属性。
一个风扇需要能支持控制左右摇头,则该设备需要具备“摇头”属性。
具体一个产品需要支持的基础属性可以参考相应品类的《产品规范》。

1.2 Model
根据《蓝牙mesh协议》定义,Model分为Server Model和Client Model;在天猫精灵蓝牙mesh设备上配置的Model均为Server Model,表示该设备具有特定的业务能力。
在《蓝牙mesh协议》中,将不同场景下的一系列相关操作定义为Model;可以认为Model就是对一系列特定属性的操作合集。
类似的,在天猫精灵生态中,根据产品抽象的属性,选择对应的Model。可以认为每个Model对应一个特定的业务。
《蓝牙mesh协议》中定义了Configuration Server Model和Health Server Model用于配置和管理蓝牙mesh网络。其中Configuration Server Model仅存在于设备的Primary Element(主元素)上,其他Element不需要添加该model;Health Server Model必须存在于设备的Primary Element上,其他Element则可以根据需要选择是否添加该模型。

1.3 Element
天猫精灵蓝牙mesh设备定义一个Element代表一个具有完整功能属性的设备;对于重复型设备(比如多位开关/插座),每个独立控制单元做为一个Element;对于复合型设备(比如风扇灯),不同Element控制设备上对应的设备属性(比如风扇和灯由2个不同的Element控制)。
根据《蓝牙mesh协议》定义,Element定义了mesh设备所支持的Model。每个Element上可以存在多个不同的Model,相同的Model也可以存在于一个设备不同的Element上。

1.4 天猫精灵蓝牙mesh设备Model
1.4.1 Configuration Server Model
如上文所述,该Model存在于设备Primary Element上。
1.4.2 Health Server Model
天猫精灵蓝牙mesh设备的Health Server Model主要用于上报心跳包,因此规定需要在Primary Element上添加该Model,其他Element上不用添加Health Server Model。
1.4.3 业务相关Model
除上述Configuration Server Model和Health Server Model之外,天猫精灵蓝牙mesh设备还使用了5种Model来实现设备具体功能。
• Generic OnOff Server Model
• Lightness Server Model
• CTL Server Model
• Scenes Server Model
• Vendor Server Model
当一个设备需要有一个开关属性时,则必须配置Generic Onoff Server Model。
Lightness Server Model、CTL Server Model、Scenes Server Model这3个model分别对应设备的亮度、色温、场景属性。
设备定义的其他属性均在Vendor Server Model中实现,具体看参考《蓝牙mesh扩展协议》。

二、模型范例

2.1 灯
2.1.1 属性分析
灯是目前天猫精灵生态中应用最广泛的产品品类,该类型产品包含各种不一样的灯具,常见的除了支持开关的普通灯外,还有调光灯、色温灯、彩灯、色温+彩色灯;部分灯具还会有场景模式要求;因此该类型设备需要用的属性分别是开关、亮度、色彩、色温、场景共5个属性。根据前面提到的天猫精灵蓝牙mesh设备支持的5种设备模型,此类设备需要支持的Model是Generic OnOff Server Model、Lightness Server Model、CTL Server Model、Scenes Server Model与Vendor Server Model。

2.1.2 设备模型
具体该品类设备模型如下表:
image.png

2.2 单孔插座
2.2.1 属性分析
单孔插座类型的产品需要具备最基础的开关功能,同时部分插座有定时开关的功能需求;因此此类设备需要支持的Model是Generic OnOff Server Model与Vendor Server Model。
2.2.2 设备模型
具体该品类设备模型如下表:
image.png

2.3 多位面板/多孔插座
2.3.1 属性分析
多位面板/插座功能属性于单孔插座一致,但需要支持更多的控制位/孔位;因此定义此类设备为多Element设备,每个Element需要支持的Model是Generic OnOff Server Model与Vendor Server Model。
2.3.2 设备模型
具体该品类设备模型如下表:
image.png
image.png

2.4 风扇灯
2.4.1 属性分析
风扇灯品类是一个复合型产品,灯和风扇都要有独立的开关控制;因此定义此类设备为多Element设备,不同Element分别对应风扇的属性操作和灯的属性操作。控制风扇的Element包括Generic OnOff Server Model用于控制风扇开关,以及Vendor Server Model用于控制风扇其他属性,如:风速、摇头、定时等。控制灯的Element参考本文1.1章节。
2.4.2 设备模型
具体该品类设备模型如下表:
image.png

相关文章
|
1月前
|
机器学习/深度学习 数据可视化 算法
机器学习-可解释性机器学习:随机森林与fastshap的可视化模型解析
机器学习-可解释性机器学习:随机森林与fastshap的可视化模型解析
111 1
|
1月前
|
Go 开发者
Go语言并发模型概览:CSP模型解析
【2月更文挑战第17天】Go语言以其强大的并发处理能力在编程领域崭露头角。其中,CSP(Communicating Sequential Processes)模型作为Go语言并发模型的核心之一,在并发编程中发挥着至关重要的作用。本文将深入解析CSP模型的基本原理及其在Go语言中的应用,帮助读者更好地理解Go语言的并发编程特性。
|
3月前
|
SQL 存储 人工智能
探索语义解析技术和AI人工智能大模型的关系
探索语义解析技术和AI人工智能大模型的关系
75 1
|
4月前
|
数据采集 自然语言处理 文字识别
大模型升级与设计之道:ChatGLM、LLAMA、Baichuan及LLM结构解析(下)
大模型升级与设计之道:ChatGLM、LLAMA、Baichuan及LLM结构解析(下)
321 0
|
4月前
|
机器学习/深度学习 数据采集 人工智能
大模型升级与设计之道:ChatGLM、LLAMA、Baichuan及LLM结构解析(上)
大模型升级与设计之道:ChatGLM、LLAMA、Baichuan及LLM结构解析(上)
416 0
|
26天前
|
存储 NoSQL 算法
【Redis技术进阶之路】「底层源码解析」揭秘高效存储模型与数据结构底层实现(字典)(二)
【Redis技术进阶之路】「底层源码解析」揭秘高效存储模型与数据结构底层实现(字典)
41 0
|
4月前
|
IDE Linux KVM
云计算|OpenStack|社区版OpenStack安装部署文档(十二--- openstack的网络模型解析---Rocky版)
云计算|OpenStack|社区版OpenStack安装部署文档(十二--- openstack的网络模型解析---Rocky版)
76 0
|
30天前
|
机器学习/深度学习 人工智能 自然语言处理
大模型落地实战指南:从选择到训练,深度解析显卡选型、模型训练技、模型选择巧及AI未来展望---打造AI应用新篇章
大模型落地实战指南:从选择到训练,深度解析显卡选型、模型训练技、模型选择巧及AI未来展望---打造AI应用新篇章
大模型落地实战指南:从选择到训练,深度解析显卡选型、模型训练技、模型选择巧及AI未来展望---打造AI应用新篇章
|
1月前
|
数据库 数据库管理
构建信息蓝图:概念模型与E-R图的技术解析
构建信息蓝图:概念模型与E-R图的技术解析
29 0
|
6月前
|
运维 Java Serverless
深度解析四大主流软件架构模型:单体架构、分布式应用、微服务与Serverless的优缺点及场景应用
深度解析四大主流软件架构模型:单体架构、分布式应用、微服务与Serverless的优缺点及场景应用
419 0

推荐镜像

更多