一、智能家居平台4要素：人、设备、家（空间）、场景（联动）
智能家居平台的4个要素，家、用户、设备、场景（场景联动）。当下任何一个智能家居平台，都需要同时覆盖这4个要素，这4个要素中前3个要素是基础，场景是点睛之笔。
1.家庭
智能家居是离不开“家”，这个家有两层含义：
这两层含义映射到智能家居平台中，衍变成家庭成员（用户）和一个与实体家对应的虚拟空间概念。
不过，当下，可能更多是把家庭当作物理空间的居多，当作是设备分类的反而少一些；毕竟智能家居智能家居，如果脱离了实在的家（空间），那么就不叫智能家居了；从心智上也是如此，因此，家庭这个概念是非常重要的。
多家庭：
确定家庭概念之后，就要面临一个问题，是否支持多家庭。
对于大部分人而言，多家庭在现实生活中是指自己家、父母家（或者老家）；如果按照这个场景来看，支持多家庭是天然正确的；但是作为设计者，仍需要更深地思考一下，多家庭是否符合当前面临的业务场景。
抛出两个问题：
基于手机为中心的生态和基于音箱的生态区别是蛮大的，基于手机为中心的生态手机能连一切，比如汽车、车载硬件、家庭硬件、个人硬件；此时只要手机能够连上设备，无所谓是哪个家（一切尽在手机，一直被连接）；另外一种可能性是经过统计发现每个家的硬件数量不多且多个家庭的需求不高。
基于音箱的智能家居，整个智能家居是承载在智能音箱上的；智能音箱大部分是固定在家庭中并不会随身携带，且智能音箱作为家庭场景的入口，天然支持单个家庭；在这个场景中，更多是通过音箱控制当前空间的设备，而非通过这个音箱控制远在几十、几百几千公里外的另外一个家中的智能家居硬件。
那为什么天猫精灵APP从5.0后开始支持多家庭呢？
个人揣测，天猫精灵在国内拥有至少千万级用户（大概4、5千万台设备），很多消费者购买之后给自己、给父母用；由于父母一般不怎么会使用，消费者会配置好之外再给父母使用；随着周边设备的增多，消费者需要区分这个家的设备和父母家的设备（天猫精灵的设定，其实是很容易不小心控制到其它家的设备）。
二来，天猫精灵在逐渐加强家庭场景的深入和突破；此时，如果能够拆成多个家庭，便于天猫精灵搞清楚用户到底有几个家，这样可以针对家庭做推荐、细化家庭场景；所以，支持多个家，可能是商业、数据和用户驱动的结果
空间：
家庭，是对实体空间的映射；在智能家居场景中，最常见的空间概念是房间，那么在智能家居平台中，也需要引入房间这一概念；此外按照实体建筑来说，除了房间还有楼层；不过一般城市中，别墅或者复式的较少，故可以仅设计房间（如果用于地产或者别墅项目的，可以考虑增加楼层）；比如客厅、餐厅厨房、主卫生间、卫生间、主卧、次卧、儿童间、玄关（标准的三室2厅2卫，一般是2卫）
除了与实体空间映射外，空间还有另外一个重要的作用—设备附着（类似设备分类）；为什么要做这个？这个其实跟人的大脑有很大的关系，大脑是懒惰的，大脑不习惯记忆众多的无规则的东西，大脑喜欢有序的有规则的；而生活中，大部分设备都是固定在某个房间中（除了可穿戴或者可移动的），在寻找设备时，记住这个设备所在的房间就可以快速找到设备。
通过这样的设计，就在软件中模拟了实体空间和实体设备以及它们之间的关系。
关于房间的全关和全开操作：
国内智能家居中对于这个的操作不怎么见，比如我要关掉房间的所有灯（假定有主灯、床头灯、灯带共3路照明），一般是逐个关或者做一个场景一键全部关，其实还可以做一个房间的总开关。
目前来看，国内以前两者为主；国外有的智能家居是支持房间的开、关操作。
家庭成员：
家庭成员是在围绕在家这个概念下用户与用户之间不同关系的一种叫法，小到家庭大至国家，都是有自己的一套组织；而家庭下的用户与用户之间，同样存在组织和分工。
在一个家庭中，一般都会有一个一家之主，这个在智能家居系统中，叫做管理员或者家庭拥有者；管理员负责家庭下的一切管理，比如房间、成员、设备的增删修改；除家庭拥有者外，更多是使用者，这些使用者在智能家居的角色就是普通用户，普通用户只能使用设备或者定义场景。
如果存在多个管理员，那么就需要有个带头大哥，这个带头大哥一般可以叫做超级管理员或者就叫家庭拥有者/家庭所有者；既然是家庭拥有者，那自然可以存在转让或者退位让贤。
一般来说，有两种设计家庭成员的方式。
基于家庭的设计：
在以家庭为中心的平台设计中，设备和用户都是从属于家庭。在家庭中，需要区分各个成员的角色。通常分为家庭拥有者、管理员、普通用户3个级别，少数平台中会设计儿童这一角色。
基于家庭的设计方案中，对于那些随身或跟随用户的产品，则不能放置在某个家庭中，而是会显示在所有家庭中但仅该用户可见，这一条需要注意。
2.设备
实体设备和虚拟设备：
智能家居平台中的设备分为两大类，一类是实体设备，一类是虚拟设备；实体设备是真实存在的，和平台中的设备是一一对应，且这种设备都有自己的唯一编码或者编号。
虚拟设备往往是由某个实体设备衍生出来的，为了方便用户操作而设计的；因此虚拟设备一般不是真实存在，它的设备编号更多是平台内部的一个标识。
但是从用户角度来看，虚拟设备往往和现实中的设备是能够一一对应上的；比如万能遥控器，它可以学习电视机、空调、风扇、机顶盒等设备的红外码；为了方便用户操作，平台中会虚拟出电视机、空调、风扇、机顶盒等设备然后与万能遥控器关联（一般是在万能遥控器下增加虚拟设备），这样用户跟使用电视机、空调等设备遥控器一样使用；虽然大家使用的是遥控器，但是从用户的心智来说，他就是在用电视等设备，而非遥控器本身。
从用户角度来看，这虚拟出来的设备在现实中是存在的，比如刚刚说的电视机、空调，这些是真实存在并且就在用户眼前。
除遥控器外，其实还有一些设备支持虚拟设备，比如咱们常见的灯光面板；生活中，咱们更多时候不叫它xx开关，而是叫它xx灯，那么这个时候，就可以把一个多路开关虚拟出众多的灯来；只是这种设计在国内并不常见，个人推测这跟使用方式有关系（国内更多是用户自己买自己装）。
我明明添加了一个开关面板，为什么会同时出来好几个灯；而且，这个开关可能是用于其它设备的，不一定是灯。
基于这种情况，所以国内大多是按照开关来设计界面，而非按照灯光来设计；毕竟国内的智能家居APP都允许用户DIY，除非把配置端和使用端有效地分离开（同时又不增加用户的使用难度）。
小结，有多个相同功能组合的设备，都可以虚拟出其它设备。
设备配网：
设备配网是指将设备连接到互联网的过程，以便设备激活和与IoT平台之间传输数据
设备配网是智能家居的一个很大门槛，至今来说，只有零配/它配的方式较为理想，但是也需要一次配网；现在零配方案主要集中在智能音箱，通过智能音箱发现其它设备并配网；目前很多厂商都先后推出了自己的零配方案，比如小米的一键配网。
关于设备绑定，除了最常见的配网方式；除了这几种方式之外，还有NFC配网（这一点华为是做的比较突出的，一碰传、一碰连接wifi等）、二维码配网（多用于摄像头）。
个人推崇零配方式或者小米的一键配网，都是主动发现未配网的设备，省去选择/输入SSID和密码、寻找设备的过程。
NFC配网：
声波配网：
声波配网，即通过手机发出声波，将SSID、password等信息传给设备的一种配网方式；通过手机播放声波把的初始化连接信息传递给智能设备，让设备识别完成初始化流程建立网络连接。
一定程度上，声波传输可以理解为类似NFC的一种近场通讯技术。适用于没有触屏或触屏较小不易于信息输入，但是拥有麦克风的智能设备，如对话机器人，智能音响等；其优点是配网速度快、可人耳感知，缺点是受环境干扰较大。
Wi-FiEasyConnect：
还有一种配网方式Wi-FiEasyConnect，这种目前还没有商用，能够搜索到的信息不多。
设备绑定：
设备绑定，目前业内就两种设计方式，一种是设备到家庭，一种是设备到人；前者为大部分厂家采用，后者主要是小米。
设备绑定：设备到人
设备绑定：设备到家
设备绑定：绑定类型
设备绑定是指将设备和用户/家庭建立关联关系，表明这个用户/家庭能够获取到设备的数据。
设备绑定是指将设备绑定在用户/家庭，设备绑定类型有：
PS：如果是基于家庭的设计，只要把用户改为家庭即可。
此外，有的平台设计了抢占式的绑定方式。这种方式约定：设备只与最后一个用户/家庭绑定，一旦有新的绑定，之前的绑定关系就被解除掉。
这种设定的场景是：这种绑定关系的确定，大概率是设备必须在用户身边，而且需要用户和设备端同时做一定的操作之后才能进行绑定；比如智能手环（蓝牙版），要绑定这个手环，需要将手环重置之后并且手环上要确认之后才能与用户绑定，那么这种情况下，就适用于抢占式。
无论哪种绑定类型，都需要设计一个后台解绑的功能。一旦出现异常问题比如退换货，那就需要通过客服人员从后台做解绑操作。
设备添加类型：
设备添加类型主要有两类，一类是设备添加包含了设备配网和设备绑定，一类是设备添加就是设备绑定，前者是主流。
前者成为主流的原因是，添加设备时完成了设备寻找、设备配网和设备绑定，经过此步骤后，用户才能真的使用设备；如果缺少其中一步，用户有可能找错了设备（比如输错了某一位，设备上的编码存在印刷错误等）或者不能通过应用控制设备。
下图来自米家：
后者只是把设备和用户/家庭关联上，此时不一定能通过客户端控制设备；因此这种方式，一般需要有人给设备配网，比如提供上门安装的服务人员、某个对电子设备比较熟或者好奇心动手能力强的人。
为什么前者会成为主流，主要是厂商没有能力提供上门安装的服务，其次是智能家居硬件产品是要降低使用门槛以吸引更多的消费者（包括小白用户）。
设备组：
设备组的概念也不算多见，但是在智能灯泡（wifi、zigbee或者blemesh）慢慢兴起的背景下，设备组尤其是用于照明的设备组就比较好用了；比如我在客厅装了两个智能灯泡，我如果要关灯，要么是一个一个关，要么找到墙壁上的开关面板关灯，或者呼叫“天猫精灵，关掉客厅的灯）。
目前来说，设备组的概念并没有得到普及，大部分智能家居APP还看不到设备组；想想也正常，用户家里就那么几个设备，没有必要整的那么复杂，让用户能够更简单的操作岂不快哉。
ps：我的一个前同事，告诉我他的前东家（某智能家居品牌厂商），平均每个家庭下的设备不超过10个，也就是2屏（一屏能够展示6-8个设备，n*2布局）。
智能灯应该要考虑设备组的概念，一方面，通过设备组可以统一调整这几个灯的亮度、颜色、色温，考虑到家庭用户对精准调色并没有很强的诉求，现在的UI设计都是用调色板来做颜色的调整和进度条来设置亮度；这种情况下，想要把几个灯调整成一致是非常困难或者说是不可能的，除非由其它的工具，比如通过智能音箱把几个灯的亮度调成一样的；此时，用设备组就比较合适了（前提是同类型的）。
另外一种做法是，设备组只负责通用功能，这样不同类型的灯也可以放到一个组中，比如统一的开关、亮度调整。
偶然间留意到，小米米家有一个灯组，不过我没有小米的智能灯，所以不能进行测试。
3.场景联动
场景联动是当下智能家居的自动化解决方案，在智能长大之前，场景联动可能也是当下最合适的解决方案（尽管也被世人诟病为“伪智能”、不智能）；场景联动目前基本上分为场景和自动化，这两个区别不大，前者是人触发的场景，后者是设备或者满足某种条件触发的。
在平台中，这两种都称为场景联动，无论是人触发、系统触发或者设备触发，都只是是触发的一种形式而已。
场景联动分为2要素或者3要素，2要素是触发条件和动作，3要素是触发、条件和动作。3要素是将触发条件拆分成触发和条件，触发是前提，条件是判断。2要素和3要素区别并不大，实际使用中，2要素已经足够。3要素更灵活一些，不过需要用户较高的参与度。
当下，场景联动大部分是做在云端的，少部分在家庭侧实现了场景联动。位于家庭侧的场景联动可以称为本地联动，通常是做在网关或者家庭主机中，比如小米的智能网关。
触发条件的设定大多数来自于设备属性或属性的变化、设备事件，比如当温度变化时、当设备状态发生变化时等等；触发条件可以在产品上线前确定，也可以随时动态更新。
下图所示的触发条件方式来自于设备属性：
4.网关
网关分为两种实体网关和虚拟网关，实体网关是指特定的硬件设备来承担数据转发，比如Zigbee网关、Lora网关、RS485网关、KNX网关、蓝牙网关等等。
虚拟网关是指通过软件实现了数据转发功能，比如智能手环通过手机应用连接到了智能家居平台，从平台来看，手机和手机上的应用共同承担了网关这个功能。
二、智能家居平台产品（经理）经VS智能硬件产品（经理）
智能家居平台产品和智能硬件产品要解决的问题不一样，尽管可能殊途同归。
智能家居平台产品面临的是：
智能硬件产品面临的是（我理解的智能硬件产品包含了软件和硬件，未做拆分）：
三、智能家居平台VS业务平台
智能家居平台本身可以当作是一种特殊平台，负责处理智能硬件的业务。
通常来看，智能家居业务平台是跟物联网平台紧密在一起，与具体业务是分开的；比如说，智能电饭煲里面带了很多菜谱，可以根据菜谱来自动做，这些菜谱都算是智能电饭煲业务平台提供的并非是智能家居平台提供。
智能家居平台提供的人、设备、家庭的关系，设备控制是由IoT平台负责，菜谱这些是通过电饭煲本身平台提供；从这个角度就可以区分业务平台和智能家居平台，业务平台是指此硬件设备自带的一些业务属性而非功能属性。
功能属性是指硬件设备自身的，比如电饭煲的预约、煮饭模式、保温等等（这些功能背后是加热）；在这些功能之上与具体场景相结合，就可以对用户提供服务，比如刚刚提及到的菜谱就是额外服务，非设备自身能力。
所以相应的还有，智能门锁提供上门安装、维修，或者提供报警服务，这些都是由锁的业务平台提供的。
以云米的智能冰箱为例，在米家中只显示了一些冰箱的通用功能比如当前温度、工作模式等，如下图所示；至于下单购买生鲜水果、提供如何烹饪食材的视频和步骤等这些服务都是通过智能冰箱上的屏幕来操作，而非通过米家；与此相似的还有小米手环，米家查看一些基本信息，小米运动中展示更全更丰富的信息和应用。
四、智能家居平台VS物联网平台
这两个平台其实蛮像的，在实际业务中，这两个平台其实并不会刻意区分，除非物联网平台是一个通用性的平台，否则大概率上智能家居平台就是物联网平台；比如涂鸦IoT、小米IoT这两个IoT平台，虽然叫IoT实际上也是智能家居平台；而阿里就不一样，阿里云IoT是IoT平台，飞燕平台（阿里生活物联网）则是智能家居平台。
如果硬要拆分，那么物联网平台是基础建设，负责物的接入；智能家居平台是面向用户端的，是业务应用平台，属于上层建筑。
在我的设计中，我拆分过这两个平台，两个平台的物模型是公用的；这种比较类似于阿里的飞燕平台（智能生活物联网）和阿里IoT之间的关系，在飞燕平台中创建的产品会同步至IoT。
拆分的好处是——IoT可以独立对外提供设备接入的服务。
本文@wweiru原创发布于人人都是产品经理，未经许可，不得转载。