聊到智能家居，我们难免联想到那些科幻电影中的场景：漂浮在空中的全息屏幕，或者像《钢铁侠》里的贾维斯那样，是一个无所不能、理解我们需求的智能管家。确实，这些场景完美地符合了我们对于一个智能家庭的终极想象：一个能感知我们生活节奏的聪明「伙伴」，能全自动地、能真正「读懂」我们需求的空间。
然而，实际情况却远比科幻电影里要「笨拙」且复杂得多。当我们真的试图写成一条条自动化的操作时，就会感受到问题接踵而至。设备之间的兼容问题、平台的封闭与开放、自动化规则的设置与场景的触发条件——每一条轻微改变，都会产生蝴蝶效应。
尽管有这些阻碍，自动化依然是智能家居体验的核心。缺少了自动化的智能家居，便捷性和魅力也无从谈起。正因如此，在这条探索之路上遇到的种种「坑」，并没有劝退我，反而让我对智能家居的自动化有了更深的理解。
因此便有了这篇自动化的指南。希望我的一些经验和教训，能够帮助你绕开这些陷阱，让你的智能家居之旅走得更顺畅。
入门设备的选择
家居设备是自动化的基础，没有它们便无从谈起后续的内容。你所拥有的智能家居设备越多，你能够打造的自动化就更丰富、更智能、更契合你心意。不过，如果此刻的你还是个入门玩家，家里只有屈指可数的几个玩意，却也不见得是一件坏事。毕竟，设备少则说明自动化的设定更加简单。这能让你更好地了解自动化设定的逻辑与操作，在后续有更进阶的需求时，也能更好的指引你精准地购买所需设备，少花冤枉钱。
如果你是完全零基础，那么优先推荐的设备是空调伴侣、开关和插座，而不是灯、风扇、路由器乃至大型智能家电这些时下大火的产品。这三者的共同的特点是可以轻松地将不智能的旧设备变成现代化的新玩意，感受智能家居便利的同时，成本也不高，是尝鲜的好选择。后续无论你是点到为止还是深入学习，都有进退的余地。
平台的选择
如果说设备决定了自动化的下限，那么平台算是决定了自动化的上限。
放眼互联网，当前国内的智能家居逐渐呈现米家依靠数量和市场占有率领跑， Apple 家庭和华为紧追不舍，涂鸦、海尔智家、美的美居、三星 SmartThings 等各种厂商持续耕耘自家平台的局面。不过，当我们把视角切回并不对科技数码有深入了解的普罗大众，其实还有很多名不见经传的小平台和私人定制方案，在线下遍地开花。
来源：小米澎湃智联IoT开发者平台到底哪来那么多乱七八糟的协议？
说到了平台，就不得不提智能家居中那些让人晕头转向的协议。简单来说，协议就是设备与设备之间沟通的方式，如同人类之间讲的语言。目前，智能家居的主要协议有以下几种：
Thread：一种基于 IPv6 的低功耗无线网状协议，功耗低、反应速度快且无需额外的网关（但需要一个支持 Thread 的边缘路由器），被视为面向未来的智能家居「完美协议」；Zigbee：一种低速短距离传输的协议，具有低耗电、低成本、支持大量网络节点等优势，但必须要一个网关。若网关掉线所有连接到网关的设备都会掉线；低功耗蓝牙 Mesh：与 Zigbee 类似，基于低功耗蓝牙的网状传输协议，同样需要网关也会面临和 Zigbee 一样的问题；Wi-Fi：功耗很高但传输速度快。一般用于持续通电的设备，如网关、一些灯泡、智能音响和大家电等；PLC：借助电力线进行传输的协议，主要开发者为华为。平台与协议的捆绑
理解了协议，就让我们再用一个简单的比喻来理解平台：它就像是各个设备的「国籍」。例如，一个灯泡可能会讲「Thread」和「蓝牙」两种话，但它只能添加到 Apple 家庭里去使用，那么它的「国籍（支持的平台）」就只有 Apple 家庭一个。
作为国际大厂推出的平台，Apple 家庭、三星 SmartThings、Google Home 和亚马逊 Alexa 等国际大平台主打一个包罗万象，只要能给授权费就给发「护照」。用什么协议接入更是来者不拒，对新协议的支持也更加积极。
然而，国内的智能家居平台却呈现了平台与协议捆绑的趋势：米家和易来这样的米家第三方生态已经铁了心一头扎进蓝牙 Mesh；Aqara 当前的设备几乎都是 Zigbee，但也有转向新兴的 Thread 协议迹象；而华为 HiLink 坚持研发 PLC......
平台、协议、设备，三个维度组合出了无数种可能，也更让人晕头转向。但经过这些年的探索，从智能家庭自动化的角度，我还是总结了几条规律：
协议并不是那么重要，但平台选定了却不容易变。其实，上面所提到的那些智能家居协议，在稳定性和响应速度并无显著差距。Thread 很好，但设备少且贵，有条件才选择；米家的蓝牙 Mesh 或许会出现不稳定的问题，但胜在产品种类和数量庞大，更重要的是便宜。只是依照目前国内平台与协议绑定的态势，选定了平台之后再想要切换，所需付出的成本不容小觑，且跨平台自动化希望渺茫或操作十分复杂；一个设备能接入的平台越多，就意味着它能联动的设备越多。例如，一个门窗更传感器如果能同时接入米家和 Apple 家庭，那么你就可以用它来联动两个平台内的设备，而不是当传感器在米家而灯泡在 Apple 家庭时，彼此看着平台壁垒无可奈何。一个平台给出的自动化条件越丰富，就意味着它可以实现的自动化效果越丰富。尽管一些设备支持多个平台接入，但在不同平台上的自动化条件可能天差地别。例如一个人体存在传感器在 Aqara Home 里可以有 20 多个自动化触发条件，但在 Apple 家庭里可能只有屈指可数的两种。跨平台自动化与开源智能家居平台
上面我们所提到的这些平台，无一不是行业内知名的企业开发，都是厂商的专有平台和软件。不同平台的设备之间出于各种原因，彼此互不联动，想要实现跨平台自动化难上加难。然而作为消费者，我们想要的是更便宜、更多元的产品选择，并让它们能彼此倾力协作，而不是被厂家「捆绑」在一条船上。
不过我们也不是毫无办法。有一些开关设备可以通过特定方式生成一些虚拟开关，并可以同时接入多个平台，利用他们来进行中转，就能实现跨平台自动化。例如，一个虚拟开关 A 同时接入了米家和 Apple 家庭，那么我们就可以这样来制作跨平台自动化：
首先设定 Apple 家庭中的自动化：
当温湿度传感器检测到湿度较低 → 打开 Apple 家庭中的虚拟开关 A。
此时，米家中的虚拟开关 A 也会被同时被打开，接着再到米家设定好自动化：
当虚拟开关 A 被打开 → 打开加湿器。
尽管能够实现我们想要的效果，但这样操作属实麻烦，而且虚拟开关设备的生成也较为复杂。而这种时候，开源智能家居平台就挺身而出了。
所谓开源智能家居平台，是指源代码发布于公众的智能家居平台，而非某个企业或个人专有。目前，最知名的开源家居平台当 Home Assistant 莫属。2013 年，其作者 Schoutsen 因为想「用自己想要的任何方式控制自己的智能灯但厂商却不给我这么干」，而用 Python 写出了 Home Assistant。后来且得益于全世界智能家居开发者社区的努力，Home Assistant 能让上千种不同平台、协议和品牌的设备一起接入，并提供了极为丰富的自动化条件，给了我们「大一统」的希望。
可等等，既然能接入也能调用......为什么是希望？
虽然 Home Assistant 可以通过设备官方的或第三方开发者的插件接入不同品牌的设备，但并不是所有人都懂得如何去使用。闭源平台就像是厨师直接做好的菜，你直接点然后上桌吃饭就搞定，而开源平台则需要你来当厨师，学会怎么买菜（选择硬件）、备菜（安装）、炒菜（接入设备）和调味（设定自动化）。没有外语阅读能力和代码基础的普通用户，也许看到安装教程中的英文介绍心中就已经猛打起了退堂鼓。
基于上一节的三条规律和这一节关于开源平台的介绍，我也总结了几个适合国内用户的平台选择建议：
如果没有技术基础纯粹就只是用户，尽量选择大平台，以及能接入这些平台的产品。大平台在设备种类、产品设计和自动化的丰富程度上，相比小平台有无可比拟的优势；可以根据家庭成员主要使用的手机系统来挑选平台和产品。iOS 选择能接入 Apple 家庭的设备，如 Aqara、易来等都对 Apple 家庭有很好的支持；Android 可以选择米家；华为可以选择 HiLink 或米家；选定了一个主要平台后就不要再有大变动。跨平台联动目前由于品牌壁垒而导致困难度极高，同一平台下的联动会简单高效很多；可以选择购买支持多个平台接入的设备。不过如同上面的例子所述，它们可能会遇到不同平台下自动化条件不同的问题。若出现了这样的情况，可以在产品本身的 App 内进行自动化设定；如果你愿意自己折腾 Home Assistant 这类开源平台，那么上面的总结除了第一条就不是那么重要了。值得一提的是，有些品牌提供了官方接入 Home Assistant 的插件，而大品牌的设备开发者的积极程度也更高，插件类型更丰富。Matter 初现曙光，但可能不是当下的好选择
很多厂商其实也意识到这样的壁垒会严重影响用户的使用体验，因此 Matter 协议应运而生。
Matter 是一项智能家居的开源标准，由连接标准联盟制定、认证、推广，该标准基于互联网协议（IP），遵循该标准的智能家居设备、移动应用程序和云服务能够进行互联和通信。
Matter 协议虽然也叫协议，但和上面所说的协议却有所不同。它不是智能家居之间说话的「语言」，而更像是一种「通用护照」。如果继续用国家来举例子，那么 Matter 就可以理解为「申根护照」。只要你拿到了它，无论说什么语言，就能在申根区国家之间任意来往。也就是说，借助 Matter 协议这个通用「护照」，设备就可以同时接入 Apple 家庭、Aqara Home、Google Home、三星 SmartThings 等各个支持 Matter 的智能家居平台，实现方便的跨平台自动化，不再被高墙所阻拦。
看起来，这种由智能家居厂商官方推动的「大一统」有着无可比拟的优势，平台之间的隔阂正在消弭，然而，它在中国大陆却一直不温不火。Matter 协议推向用户已经 2 年，国内除了 Aqara 、魅族 Lipro 和涂鸦等少数厂商之外，小米米家、华为 HiLink 和几个主要的智能家电平台都对它冷眼旁观，具体原因我们仍然不得而知。
但有意思的是，即便自家设备和平台均不支持，但他们其实都早早加入了 Matter 背后的开放标准联盟组织。
依据当下的情况，想要依靠 Matter 在国内百花齐放的智能家居平台中实现跨平台联动，尚属一个正在做的梦。但好在，它已经初现曙光：随着越来越多厂家入局，Matter 设备的价格已经呈现下降趋势，品类越来越丰富的同时，支持的平台也在逐步增加。回到实际的应用中，我们在选购智能家居时，应当优先选择支持 Matter 的设备。或许在未来的某一天，米家、HiLink 或者哪个大平台宣布大规模支持 Matter，这个梦就不就实现了吗？
本地与云端
自动化流程的执行过程中，必然会调用设备中的数据。因此，一个自动化执行的速度，就取决于数据在设备中获取和传递的速度。
在过去，许许多多自动化需要通过云端来执行，即当自动化触发的条件达成时，数据的传递需要经由网络发送到厂商服务器，再从服务器中返回后续的数据，再向后执行如开关灯这样的具体操作。
这样做的好处是可以节约本地的智能家居设备算力，只需要一个便宜的能连上网的网关，就能带动家里的设备实现自动化，无需购买智能家居中枢设备。
当然，其弊端也显而易见：自动化的执行会受到网络的严重影响。如果网络出现异常或厂商的服务器出现问题，就极容易导致自动化执行缓慢甚至直接停摆。其次，由于数据经过网络进行传输，也可能存在隐私泄露等安全问题。
因此，本地自动化逐渐显露头角。设备数据只需要在本地局域网内获取和流转，大大提高了自动化的响应速度、稳定性和安全性，哪怕是断网也不受影响。
只不过，想实现自动化的本地运行，就要求整个自动化流程上不能有需要联网查询的判断条件（如时间、地点和日出日落这类信息），且所有设备都得支持才行。如果其中有任何不支持的因素，那么就只能通过云端来实现。而且，想要自动化在本地执行，一个算力和存储足够的中枢设备也不可或缺。如 Apple 的 Apple TV 或 HomePod，小米的中枢网关、Aqara 的方舟中枢 M3 等，也是一笔不小的投入。
你可以在对应的平台 App 中查看自动化的运行类型。例如，米家和 Aqara 的自动化可以通过在「编辑自动化 > 更多设置」中进行查看。其它一些智能家居平台也可以通过类似步骤查看，这里就不细表。
日常使用中，我认为不必过于纠结某条自动化是在本地还是在云端。能在本地实现自动化当然更好，体验也更优，但于用户而言却意味着更高成本的投入，对厂商而言是更复杂的开发流程。虽然过去存在智能家居厂商服务器故障导致设备控制和自动化停摆的事故，但这依旧属于小概率事件，且基本上能在一天内修复，不会造成十分严重的问题。
不过值得一提的是，Apple 家庭由于有「家居中枢」这样设备的存在，以及 Home Assistant 需要安装在树莓派、NAS 或其它本地计算设备中，而家具中枢和这些本地设备的算力大都远高于厂商推出的智能家居中枢，所以 Apple 家庭和 Home Assistant 的自动化基本都是在本地执行。而作为 Home Assistant 的忠实用户，我选择它不仅仅是因为它拥有本地自动化执行时速度快、断网可用和安全的特点，更是因为 Home Assistant 极为丰富的自动化触发及判断条件。
只要有代码基础，你甚至还可以完全自己写一个 Home Assistant 的前端界面了解了智能家居的基础设施和平台选择，我们终于可以开始探讨如何真正实现那些便捷的自动化场景。在下篇中，让我们继续深入，看看如何将日常习惯转化为智能化的自动操作。
