系列介绍

很久没有写文章了，近来断断续续地在思考一些东西。在去工作的地铁上，终于想好，决定分享自己在智能家居方面的思考。本系列文章计划分为7部分，不排除会对部分内容合并。

智能门锁
中控屏
智能音箱
智能家居平台设计
关于供应链、ID、MD、电子设计等
关于销售、售后、弱电集成、工程管理等
智能家居之智能

智能家居平台4要素：人、设备、家（空间）、场景（联动）

智能家居平台的4个要素，家、用户、设备、场景（场景联动）。当下任何一个智能家居平台，都需要同时覆盖这4个要素，这4个要素中前3个要素是基础，场景是点睛之笔。

家庭

智能家居是离不开“家”，这个家有两层含义。初始含义是指代一个物理空间，是人除了工作场所之外主要待的地方。第二层含义是家庭，是一个象征，中国人对家庭是非常在意。这两层含义映射到智能家居平台中，衍变成家庭成员（用户）和一个与实体家对应的虚拟空间概念。

不过，当下，可能更多是把家庭当作物理空间的居多，当作是设备分类的反而少一些。毕竟智能家居智能家居，如果脱离了实在的家（空间），那么就不叫智能家居了。从心智上也是如此，因此，家庭这个概念是非常重要的。

多家庭

确定家庭概念之后，就要面临一个问题，是否支持多家庭。对于大部分人而言，多家庭在现实生活中是指自己家、父母家（或者老家）。如果按照这个场景来看，支持多家庭是天然正确的。但是作为设计者，仍需要更深地思考一下，多家庭是否符合当前面临的业务场景。

抛出两个问题：

华为的智慧生活为什么只支持1个家庭
天猫精灵APP为什从只支持1个家庭变为支持多个家庭（自5.0版本开始支持多家庭）

基于手机为中心的生态和基于音箱的生态区别是蛮大的。基于手机为中心的生态手机能连一切，比如汽车、车载硬件、家庭硬件、个人硬件，此时只要手机能够连上设备，无所谓是哪个家（一切尽在手机，一直被连接）。另外一种可能性是经过统计发现每个家的硬件数量不多且多个家庭的需求不高。

基于音箱的智能家居，整个智能家居是承载在智能音箱上的。智能音箱大部分是固定在家庭中并不会随身携带，且智能音箱作为家庭场景的入口，天然支持单个家庭。在这个场景中，更多是通过音箱控制当前空间的设备，而非通过这个音箱控制远在几十、几百几千公里外的另外一个家中的智能家居硬件。

那为什么天猫精灵APP从5.0后开始支持多家庭呢？个人揣测。天猫精灵在国内拥有至少千万级用户（大概4、5千万台设备），很多消费者购买之后给自己、给父母用，由于父母一般不怎么会使用，消费者会配置好之外再给父母使用。随着周边设备的增多，消费者需要区分这个家的设备和父母家的设备（天猫精灵的设定，其实是很容易不小心控制到其它家的设备）；二来，天猫精灵在逐渐加强家庭场景的深入和突破。此时，如果能够拆成多个家庭，便于天猫精灵搞清楚用户到底有几个家，这样可以针对家庭做推荐、细化家庭场景。所以，支持多个家，可能是商业、数据和用户驱动的结果。

空间

家庭，是对实体空间的映射。在智能家居场景中，最常见的空间概念是房间。那么在智能家居平台中，也需要引入房间这一概念，此外按照实体建筑来说，除了房间还有楼层。不过一般城市中，别墅或者复式的较少，故可以仅设计房间（如果用于地产或者别墅项目的，可以考虑增加楼层）。比如客厅、餐厅厨房、主卫生间、卫生间、主卧、次卧、儿童间、玄关（标准的三室2厅2卫，一般是2卫）。

除了与实体空间映射外，空间还有另外一个重要的作用—设备附着。为什么要做这个，这个其实跟人的大脑有很大的关系。大脑是懒惰的，大脑不习惯记忆众多的无规则的东西，大脑喜欢有序的有规则的。而生活中，大部分设备都是固定在某个房间中（除了可穿戴或者可移动的），在寻找设备时，记住这个设备所在的房间就可以快速找到设备。

通过这样的设计，就在软件中模拟了实体空间和实体设备以及它们之间的关系。

关于房间的全关和全开操作

国内智能家居中对于这个的操作不怎么见，比如我要关掉房间的所有灯（假定有主灯、床头灯、灯带共3路照明），一般是逐个关、做一个场景全部关、或者做一个开关（用于打开或关闭房间的设备）。目前来看，国内以前两者为主；国外有的智能家居是支持房间的开、关操作。我曾经接触过某个智能家居平台，他们支持房间级别的设备操作，并且支持定制（比如房间的开关操作是否针对某些特定设备）

家庭成员

家庭成员是在围绕在家这个概念下用户与用户之间不同关系的一种叫法。小到家庭大至国家，都是有自己的一套组织，而家庭下的用户与用户之间，同样存在组织和分工。在一个家庭中，一般都会有一个一家之主，这个在智能家居系统中，叫做管理员或者家庭拥有者。除家庭拥有者外，更多是使用者，这些使用者在智能家居的角色就是普通用户。如果存在多个管理员，那么就需要有个带头大哥，这个带头大哥一般可以叫做超级管理员或者就叫家庭拥有者。既然是家庭拥有者，那自然可以存在转让或者退位让贤。

一般来说，有两种设计家庭成员的方式。

基于家庭的设计

在以家庭为中心的平台设计中，设备和用户都是从属于家庭。在家庭中，需要区分各个成员的角色，通常分为家庭拥有者、管理员、普通用户3个级别，少数平台中会设计儿童这一角色（我设计过，但是未大规模使用，不一定真能用）。

家庭拥有者，创建家庭的用户，拥有最高权限，可以移除管理员（主要是解决管理员互相管理的问题），维护管理员、用户、设备
管理员：维护设备和普通用户
用户：纯粹使用设备
儿童：不常见，比用户的限制会更多一些。一方面并不好定义哪些操作或者哪些设备不能被儿童使用；一方面以国情来看，不少儿童很早就使用电子产品（原因有很多），那么更多来说儿童模式反而更好用一些（借鉴设备上的童锁或者手机音箱上的儿童模式）。电子产品的儿童模式，主要是在内容上做区分，具体功能上可能不大（除了下单支付类的）

基于家庭的设计方案中，对于那些随身或跟随用户的产品，则不能放置在某个家庭中，而是会显示在所有家庭中但仅该用户可见，这一条需要注意。

基于分享的设计

基于分享的设计，典型代表是小米。在基于分享的设计当中，设备和家都属于这个分享者的，至于家庭成员，更多是分享的一种方式。

基于分享的设计，家庭或者家庭成员这个概念是很轻的，而且家庭成员是为了完成设备分享这个任务而设计的。在这种模式下，一般分享者是管理员，其他成员都是普通用户（当然也可以把管理员的权限分享出去）。

这种设计好辨认，只有找到分享就大致能看出来，比如小米米家的分享入口（下图左）和华为智慧生活的分享入口（下图右），可以清晰看到共享分为共享家庭和共享设备两个维度。

设备

实体设备和虚拟设备

智能家居平台中的设备分为两大类，一类是实体设备，一类是虚拟设备。实体设备是真实存在的，和平台中的设备是一一对应。且这种设备都有自己的唯一编码或者编号。

虚拟设备往往是由某个实体设备衍生出来的，为了方便用户操作而设计的。因此虚拟设备一般不是真实存在，它的设备编号更多是平台内部的一个标识。但是从用户角度来看，虚拟设备往往和现实中的设备是能够一一对应上的。比如万能遥控器，它可以学习电视机、空调、风扇、机顶盒等设备的红外码。为了方便用户操作，平台中会虚拟出电视机、空调、风扇、机顶盒等设备然后与万能遥控器关联（一般是在万能遥控器下增加虚拟设备），这样用户跟使用电视机、空调等设备遥控器一样使用。虽然大家使用的是遥控器，但是从用户的心智来说，他就是在用电视等设备，而非遥控器本身。

从用户角度来看，这虚拟出来的设备在现实中是存在的，比如刚刚说的电视机、空调，这些是真实存在并且就在用户眼前。

除遥控器外，其实还有一些设备支持虚拟设备，比如咱们常见的灯光面板。生活中，咱们更多时候不叫它xx开关，而是叫它xx灯，那么这个时候，就可以把一个多路开关虚拟出众多的灯来。只是这种设计在国内并不常见，个人推测这跟使用方式有关系（国内更多是用户自己买自己装）。我明明添加了一个开关面板，为什么会同时出来好几个灯；而且，这个开关可能是用于其它设备的，不一定是灯。基于这种情况，所以国内大多是按照开关来设计界面，而非按照灯光来设计。毕竟国内的智能家居APP都允许用户DIY，除非把配置端和使用端有效地分离开（同时又不增加用户的使用难度），那么就可以了。用UE的话，don't make me think。

总结，有多个相同功能组合的设备，都可以虚拟出其它设备来。

设备的绑定和配网

设备绑定和设备配网是两个步骤，只是在智能家居平台中，这两个步骤往往都揉到一块。设备绑定是指将设备和用户/家庭建立一个关联关系，表明这个用户/家庭能够获取到设备的数据；设备配网是指将设备连接到互联网的过程，以便设备激活和与IoT平台之间传输数据。

设备配网是智能家居的一个门槛，至今来说，只有零配/它配的方式较为理想，但是也需要一次配网。现在零配方案主要集中在智能音箱，通过智能音箱发现其它设备并配网

关于设备绑定，可以看这篇文章《物联网Wi-Fi配网方式，你知道几种？》，里面介绍了几种最常见的配网方式。除了这几种方式之外，还有NFC配网（这一点华为是做的比较突出的，一碰传、一碰连接wifi等）、二维码配网（多用于摄像头）。

二维码配网

用户打开设备的客户端（APP、微信小程序），填入ssid和密码后客户端生成二维码，然后将手机屏幕贴近摄像头，摄像头扫码到二维码后根据二维码中的ssid和密码去配网。这种配网方式要求摄像头具备二维码解析能力并且要做二维码检测（检测是否有二维码）

NFC配网

以NFC方式将ssid和密码传给设备，主要场景并不是在智能家居相关硬件上。目前常见的是手机通过NFC将wifi分享给另外一个手机；或者手机获取路由器上的wifi。

声波配网

声波配网，即通过手机发出声波，将SSID、password等信息传给设备的一种配网方式。通过手机播放声波把的初始化连接信息传递给智能设备，让设备识别完成初始化流程建立网络连接。

一定程度上，声波传输可以理解为类似NFC的一种近场通讯技术。适用于没有触屏或触屏较小不易于信息输入，但是拥有麦克风的智能设备，如对话机器人，智能音响等。其优点是配网速度快、可人耳感知，缺点是受环境干扰较大。

还有一种配网方式Wi-Fi Easy Connect，这种目前还没有商用，能够搜索到的信息不多。

设备绑定

设备绑定，目前业内就两种设计方式，一种是设备到家庭，一种是设备到人。前者为大部分厂家采用，后者主要是小米。无论两种方式，在前端体验上都可以做成完全相同。这两种设计可以通过查看分享来做区分。

设备到人：

可以灵活分享，比如用户A分配1-n个设备给用户B，而不需要把B设置为家人。此时用户A的其它设备不会被用户B看到，有助于个人隐私的保护

设备到家：

与用户心智最贴近，大部分智能设备都是存在某个家庭的空间，而该空间下的每个人都有权力使用这些智能设备，因为这些智能设备是为整个家庭成员使用的而不是为某个人
如果某个设备不想让其他家庭成员知道，此时设备就不能够添加到家庭成员所在的家庭中

绑定类型

设备绑定是指将设备绑定在用户/家庭，设备绑定类型有：

独占式：一旦被用户绑定，其他用户无法添加上此设备。一般涉及到安全或者数据隐私的设备可以采取此方案，比如摄像头、门锁、监控类
共享式-有管理员：设备被用户绑定后，该用户成为设备管理员；其他用户来添加时，自动成为此管理员用户的子用户。这种类型的设备多用于无数据隐私、但是需要区分管理者和使用者。
共享式-无管理员：设备可以被所有的用户绑定，这些用户的关系都是平等的。这种情况多适用于那些没有数据隐私也不涉及到安全类的设备，比如家里的一些传感器设备（漏水、人体红外、门窗磁等）。这类设备只采集数据，没有额外的配置。

PS：如果是基于家庭的设计，只要把用户改为家庭即可。

此外，有的平台设计了抢占式的绑定方式。这种方式约定：设备只与最后一个用户/家庭绑定，一旦有新的绑定，之前的绑定关系就被解除掉。这种设定的场景是：这种绑定关系的确定，大概率是设备必须在用户身边，而且需要用户和设备端同时做一定的操作之后才能进行绑定。比如智能手环（蓝牙版），要绑定这个手环，需要将手环重置之后并且手环上要确认之后才能与用户绑定，那么这种情况下，就适用于抢占式。

无论哪种绑定类型，都需要设计一个后台解绑的功能。一旦出现异常问题比如退换货，那就需要通过客服人员从后台做解绑操作。

设备添加类型

设备添加类型主要有两类，一类是设备添加包含了设备配网和设备绑定，一类是设备添加就是设备绑定，前者是主流。

前者成为主流的原因是，添加设备时完成了设备寻找、设备配网和设备绑定，经过此步骤后，用户才能真的使用设备。如果缺少其中一步，用户有可能找错了设备（比如输错了某一位，设备上的编码存在印刷错误等）或者不能通过应用控制设备。

后者只是把设备和用户/家庭关联上，但是能否通过客户端管理设备却要依赖于设备是否已经配网。因此这种方式，一般需要有人给设备配网，比如提供上门安装的服务人员、某个对电子设备比较熟或者好奇心动手能力强的人。由于目前绝大部分智能硬件都需要通过客户端（APP、小程序）进行配网，故此种添加方式，就必需支持一个设备被多个用户绑定（除非提供额外一个工具给配网的人员使用）

为什么前者会成为主流，主要是厂商没有能力提供上门安装的服务，其次是智能家居硬件产品是要降低门槛（价格和使用门槛）以吸引更多的消费者（包括小白用户）

售价原因：国内硬件厂商的价格战非常激烈，厂商没有足够的利润空间；同理，渠道商往往也没有足够的利润空间来支持他们提供上门安装服务
盈利模式：大部分厂商是通过硬件本身盈利，并不能通过内容和后期服务来盈利（或者盈利不足以覆盖上门安装成本）

设备组

设备组的概念也不算多见，但是在智能灯泡（wifi、zigbee或者ble mesh）慢慢兴起的背景下，设备组尤其是用于照明的设备组就比较好用了。比如我在客厅装了两个智能灯泡，我如果要关灯，要么是一个一个关，要么找到墙壁上的开关面板关灯，或者呼叫“天猫精灵，关掉客厅的灯）。目前来说，设备组的概念并没有得到普及，大部分智能家居APP还看不到设备组。想想也正常，用户家里就那么几个设备，没有必要整的那么复杂，让用户能够更简单的操作岂不快哉。

ps：我的一个前同事，告诉我他的前东家（某智能家居品牌厂商），平均每个家庭下的设备不超过10个，也就是2屏（一屏能够展示6-8个设备，n*2布局）。

智能灯应该要考虑设备组的概念。一方面，通过设备组可以统一调整这几个灯的亮度、颜色、色温。考虑到家庭用户对精准调色并没有很强的诉求，现在的UI设计都是用调色板来做颜色的调整和进度条来设置亮度。这种情况下，想要把几个灯调整成一致是非常困难或者说是不可能的。除非由其它的工具，比如通过智能音箱把几个灯的亮度调成一样的。此时，用设备组就比较合适了（前提是同类型的）。另外一种做法是，设备组只负责通用功能，这样不同类型的灯也可以放到一个组中，比如统一的开关、亮度调整。

偶然间留意到，小米米家有一个灯组，不过我没有小米的智能灯，所以不能进行测试。

从设备角度来看，分享分为单设备分享和多设备分享，单设备是一次只能分享一个设备，多设备分享是指可以批量分享设备，比如我一次分享5个设备给某个用户。多设备分享的一种方式是家庭成员（前面已经提及过）。

设备分享一般是只分享使用权，允许其他用户查看数据、使用设备。

从问题解决/任务实现角度来看，分享是解决设备添加这个问题的。只要某个用户添加设备后，其他用户就可以不添加设备就能够使用这些设备。

ps：被分享者部分，分享的设备不属于他的任何一个家，故设备会在该用户每一个家中展示。

场景联动

场景联动是当下智能家居的自动化解决方案，在智能长大之前，场景联动可能也是当下最合适的解决方案（尽管也被世人诟病为“伪智能”、不智能）。场景联动目前基本上分为场景和自动化，这两个区别不大，前者是人触发的场景，后者是设备或者满足某种条件触发的。在平台中，这两种都称为场景联动，无论是人触发、系统触发或者设备触发，都只是是触发的一种形式而已。

场景联动分为2要素或者3要素，2要素是触发条件和动作，3要素是触发、条件和动作。3要素是将触发条件拆分成触发和条件，触发是前提，条件是判断。2要素和3要素区别并不大，实际使用中，2要素已经足够。3要素更灵活一些，不过需要用户较高的参与度。

当下，场景联动大部分是做在云端的，少部分在家庭侧实现了场景联动。位于家庭侧的场景联动可以称为本地联动，通常是做在网关或者家庭主机中，比如小米的智能网关。

触发条件的设定大多数来自于设备属性或属性的变化、设备事件，比如当温度变化时、当设备状态发生变化时等等。触发条件可以在产品上线前确定，也可以随时动态更新。从平台操作角度来看，如果是设备属性或属性变化，那么在平台中创建产品时可以根据物模型同时创建；如果是与属性相关的触发，则需要平台自行设置。

下图所示的触发条件方式来自于设备属性

网关

按照端边云应/管用来说，这种网关已经有边缘网关的影子但远不够。此外，在2015年左右，涌现过很多的网关或者家庭主机，那会儿还没有边缘节点的概念，各种网关/主机/路由器层出不穷，只为了将网关的属性淡化，让用户愿意买（不用藏起来）。于是那会儿有花瓶、花盆形状的网关/主机，一点都不为奇。

智能家居平台产品 vs 智能硬件产品

智能家居平台产品和智能硬件产品要解决的问题不一样，尽管可能殊途同归。

智能家居平台产品面临的是：

平台中接入的产品非常多，如何标准化和快速上线新品
平台除接入新产品化，还需要考虑对接企业内部的业务系统
平台需要考虑如何对外赋能

智能硬件产品面临的是（我理解的智能硬件产品包含了软件和硬件，未做拆分）：

人机体验，关注人性，统筹整体的用户体验（硬件+软件）
注重体验，兼顾实现
生产、供应链管理、售后管理
其它

小结一下，智能硬件产品要求文（软）武（硬件）双全，要权衡和取舍，既要考虑当下更要有着眼未来；智能能家居平台产品关注标准化和能力（服务）化，小步快走（快速迭代）。

关于智能硬件产品，在这安利一本书《硬件产品经理手册：手把手构建智能硬件产品》。

智能家居平台 VS 业务平台

智能家居平台本身可以当作是一种特殊平台，负责处理智能硬件的业务。通常来看，智能家居业务平台是跟物联网平台紧密在一起，与具体业务是分开的。比如说，智能电饭煲里面带了很多菜谱，可以根据菜谱来自动做，这些菜谱都算是智能电饭煲业务平台提供的并非是智能家居平台提供。智能家居平台提供的人和设备、家庭的关系，设备控制是由IoT平台负责，菜谱这些是通过电饭煲本身平台提供。从这个角度就可以区分业务平台和智能家居平台，业务平台是指此硬件设备自带的一些业务属性而非功能属性。功能属性是指硬件设备自身的，比如电饭煲的预约、煮饭模式、保温等等（这些功能背后是加热）；在这些功能之上与具体场景相结合，就可以对用户提供服务，比如刚刚提及到的菜谱就是额外服务，非设备自身能力。

所以相应的还有，智能门锁提供上门安装、维修，或者提供报警服务，或者提供类似酒店锁的服务，这些都是由锁的业务平台提供的。燃气报警器提供火灾险或者上门抢险服务，这些都算是业务上的。

只是通过智能家居APP上未必能够发现这到底是业务平台提供的服务还是由智能家居平台提供的服务。

以云米的一块智能冰箱为例（图来源于网络），在米家中只显示了一些冰箱本身的简单功能，如下图所示。

但是这款智能冰箱上是可以通过冰箱上的智能面板下单购买生鲜水果，并且能识别放入冰箱的食材，还能够提供如何烹饪食材的视频和步骤。这部分功能并不是在米家中呈现，而是透过别的应用。同理，小米手环是能够通过米家查看，但是只是看到一点点数据，更多的数据和应用还是要通过小米运动来查看。

智能家居平台 VS 物联网平台

这两个平台其实蛮像的，在实际业务中，这两个平台其实并不会刻意区分，除非物联网平台是一个通用性的平台，否则大概率上智能家居平台就是物联网平台。比如涂鸦IoT、小米IoT这两个IoT平台，虽然叫IoT实际上也是智能家居平台。而阿里就不一样，阿里云IoT是IoT平台，飞燕平台（阿里生活物联网）则是智能家居平台。

如果硬要拆分，那么物联网平台是基础建设，负责物的接入；智能家居平台是面向用户端的，是业务应用平台，属于上层建筑。

在我的设计中，我拆分过这两个平台，但是在物模型这部分是完全通用的，可以由IoT提供接口给智能家居平台。这种比较类似于阿里的飞燕平台（智能生活物联网）和阿里IoT之间的关系，在飞燕平台中创建的产品会同步至IoT。拆分的好处是，IoT可以独立对外提供设备接入的服务。

智能家居系列之智能家居平台设计相关推荐

Homekit智能家居系列一智能触摸面板开关
触摸开关,即通过触摸方式控制的墙壁开关,其感官场景如同我们的触屏手机,只需手指轻轻一点即可达到控制电器的目的,随着人们生活品质的提高,触摸开关将逐渐将换代传统机械按键开关. 触摸开关控制原理触摸开关 ...
I-000 智能家居系列--需求梳理
智能家居系列 1 智能家居 2 系统框架 3 组成部分 4 开发思路 5 当前的进展 1 智能家居智能家居的目的旨在提高人们的生活水平,确保人们的生活更加舒适. 2 系统框架下图只是初版,在具体的 ...
基于树莓派+STM32+OneNET云平台打造智能家居系统（一）硬件设计篇
本次分享的是之前一个课程设计, 会分为几篇博文进行分享.智能家居是目前研究与发展的一大热点,本设计是结合STM32微处理器/树莓派(Raspberry Pi)3b+.温湿度传感器.继电器以及ESP ...
智能家居物联网服务平台设计-论文
智能家居物联网服务平台设计摘要随着物联网.大数据.云计算等技术的发展成熟,推动了物联网应用的蓬勃发展,智能家居作为物联网技术的一个重要应用领域,近几年来得到了广泛的研究,也出现了大量的应用产品.目 ...
【Android开发—智能家居系列】（三）：手机连接WIFI模块
[Android开发-智能家居系列](三):手机连接WIFI模块概述实现连接WIFI的功能会用到一个工具类,源码可以点击链接下载.网上这些类似的工具类里的代码差不多是一样的.连接无线网主要有两个方 ...
【Android开发—智能家居系列】（二）：用手机对WIFI模块进行配置
[Android开发-智能家居系列](二):用手机对WIFI模块进行配置版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/u010924834/art ...
智能家居系列之Home Assistant
智能家居系列之Home Assistant 智能家居话题本身就是一个技术领域,它的目的是让智能家居变得更加简单,更加实用. 系列定位本系列的定位是智能家居入门系列. 背景最近看了下家中的智能家居设 ...
【Android开发—智能家居系列】（一）：智能家居原理
来到JCZB公司的第二天,就接到了开发类似于小米智能家庭APP的任务.组长让我在手机上安装上此款APP,给了我个小米智能插座,就让我开始了解需求.这便开启了我的智能家居旅程.说实话,我也真是out的无 ...
智能家居DIY系列之智能灯泡
一.什么是智能灯传统的灯泡是通过手动打开和关闭开关来工作.有时,它们可以通过声控.触控.红外等方式进行控制,或者带有调光开关,让用户调暗或调亮灯光. 智能灯泡内置有芯片和通信模块,可与手机.家庭智能 ...

智能家居系列之智能家居平台设计