没有云的物联网：始终能用的本地优先设计

本地优先的物联网把控制回路留在设备上，把云端当作可选项。这样一来，一次断网或者一轮拉闸限电只是麻烦，而不会让设备变成一块砖。

本地优先的设备靠自己的硬件和本地网络完成主要工作，把互联网当作加分项而不是必要条件。当云端只是可选项时，断网或一轮拉闸限电带来的只是短暂的不便，而不是一台报废的设备。本文讲清楚三件事：依赖云端的小玩意为什么会变成砖头、哪些做法能让设备离线时照常工作，以及买之前可以做的一个简单测试。

依赖云端的设备为什么会变成砖头

很多智能产品把"思考"放在了别处。墙上的按钮自己不做任何决定，它把消息发给服务器，服务器做决定，答案再从互联网传回来。一切正常时，这一来一回是看不见的；链路一断，它立刻现形。

在南非，链路经常断。拉闸限电会把路由器和光猫一起弄停。手机流量用完了，或者慢得像爬。厂商的服务器过载，或者公司悄悄停掉这条产品线，连同背后的服务一起关掉。只要发生其中一件，一个需要云端才能开关同一面墙上灯泡的开关，就不工作了。硬件没坏，只是它的大脑住得太远。

最糟的情况来得很慢。一台设备可以完美工作两年，然后在厂商认定这项云服务不值得再维护的那天，变成电子垃圾。你以为买下的是一件产品，其实租的是一份依赖。

本地优先不是反对互联网，它关心的是重要的决定发生在哪里。在本地优先的设计里，核心控制回路跑在设备自己身上，或者跑在你自家网络里的一台小主机上。云端只留给那些确实需要外部世界的活儿：人不在家时也能连上设备、保存长期历史数据、下发软件更新，以及把使用权分享给别人。

可以把它看成三层。设备端的逻辑负责眼前这件事；本地网络的协同让手机在家里就能通过 Wi-Fi 和设备对话，不必绕出门；可选的云端同步负责其余的一切，而且只在有连接时才做。抽掉最上面一层，下面两层照常运转。

不必会设计硬件，也能认出好习惯。有几种做法，把能扛过一次断网的设备和扛不过的设备区分开来。

这里面的大部分，第一个晚上、退货期结束之前就能判断出来。把设备装好，然后有意让它面对一个断掉的互联网。

关掉路由器，或者停掉手机数据，再去用它的核心功能。开关还能开关吗？传感器还有反应吗？
在互联网仍然断着的情况下重启设备。它能自己回到可用状态，还是卡在那里等着向厂商报到？
在同一个 Wi-Fi 下、完全没有互联网时打开 App。它还能不能发现并控制这台设备？
直截了当地问厂商一个问题：如果你们把服务关掉，这台硬件会怎样？答得干脆，通常意味着有本地兜底。
找一找开放协议，比如 Matter、Zigbee，或者连到你自己 broker 的 MQTT。你自己掌握的标准，决定了以后是换个 App 就行，还是所有东西重买一遍。

如果一台设备连前两步都过不了，它就不是智能设备，而是别人家服务器的一个遥控器。

这种直觉越早养成越容易。在程序就跑在板子上的硬件上学编程的孩子，长大后会默认一台设备该拥有自己的逻辑。当代码住在芯片里，一个灯加传感器的项目，不管房间里有没有 Wi-Fi 都照常运行，学习者也能清清楚楚看到决定是在哪里做出的。

我们的 sheenbot∞ 主板用的就是这个模式：程序在单片机上执行，所以一个项目在家庭网络里、在学校里，或者在一张完全没有连接的桌子上，表现都一样。用它来说明"智能"不一定等于"联网"，很实在。想看我们怎么教，我们的学院会一步步带着做这些项目，你可以预约一节体验课，主板和套件都在商店里。

云端对远程访问、历史数据和更新很有用，但把设备最基本的可用能力寄存在那里，是个坏主意。优先选择那些核心回路在本地运行、数据先存下来再同步而不是直接丢弃、并且用开放协议让你不被一家公司锁死的产品。然后花一个晚上做一遍离线可用测试。通过测试的那些设备，就是下次停电时仍然在工作的那些。

不是。本地优先保证核心功能在没有互联网时照样工作，设备仍然可以把远程访问作为一项可选的附加能力。区别在于，丢掉这项附加能力，不会妨碍设备干它的主要活儿。

不是。长期历史数据、空中升级，以及人在外面时连回设备，云服务都是合适的工具。原则是：需要外部世界的事情交给云，设备自己能做的决定不要交给云。