宠物智能硬件品牌 Petlibro 从 8 月 11 日起出现服务故障，旗下智能喂食器等设备无法执行投食这类定时任务。多名用户在社交平台反映，自己的喂食器、猫砂盆和饮水机纷纷显示离线。

官方说本地排程照跑，用户说猫没吃上饭

这次中断中最受关注的争议点，是官方说法与用户实际体验之间的落差。

Petlibro 在服务状态页上写明：「设备本地存储的既有设置和排程将继续按程序运行。」页面同时列出了受影响的范围，包括应用访问、设备控制、设备在线状态、设备绑定，以及部分应用数据和功能。官方还提示，恢复期间设备可能实际仍在正常工作，只是应用会错误显示「离线」或「排程超时」这类状态。

但不少用户给出了相反的反馈。有人报告 RFID 与 Granary 系列的分食器在故障期间错过了定时投喂，对正在外地、无法赶回家的宠物主人来说，这是个相当棘手的问题。除喂食器外，Dockstream 智能饮水机和 Luma 猫砂盆也有用户反映出现异常，配套应用对一部分人干脆打不开。

「当前部分 Petlibro 应用功能出现服务问题。」公司在故障当天的声明中表示，「团队正在积极恢复服务、验证稳定性，并分阶段恢复各项功能。」

恢复分阶段推进，官方提醒别急着重置设备

从官方状态页的时间线看，故障排查始于美国太平洋时间 8 月 11 日凌晨 5 点，此后进入反复的「部分恢复—继续监控」循环：当日下午一度称大部分服务已恢复正常，晚间又实施了系统稳定性更新并分阶段放量，深夜宣布多数应用功能恢复，但设备状态更新和数据相关功能仍在逐步回归。

8 月 12 日下午 2 点 30 分（美国东部时间），Petlibro 更新称「大部分服务已经恢复，应用正在恢复完整运行」。部分用户确认设备重新工作，但也有人反映仍然无法把设备重新连回应用。The Verge 就此向 Petlibro 询问更多信息，未获得即时回复。

官方在恢复期间反复强调一条操作建议：不要解绑、重置或从应用中移除设备。已经完成配置的设备，本地存储的排程应当继续按程序运行；已经解绑或移除设备的用户，也不要反复重置或尝试重连，等服务恢复后再重新添加。这条提示本身就说明，用户在设备「看起来失联」时的本能反应——拔电、复位、重新配网——恰恰是让恢复变得更复杂的动作。

联网家电的老问题，在喂食这件事上格外扎眼

云服务中断本身在智能硬件行业算不上新鲜事，但发生在宠物喂食设备上，性质有些不同。灯不亮、扫地机不扫，事后补救即可；饭点错过就是错过，而且往往发生在主人不在家、无法及时发现的时候。这类设备的容错窗口天然更窄。

值得注意的是，同一次故障中，本地排程「是否照常执行」的判断在官方与用户之间出现了分歧，具体原因目前尚无公开解释。对使用者而言，可以从中提炼的经验是相对朴素的：把定时投喂完全押在一条链路上，风险集中度偏高。有条件的话，长时间外出前把定量粮分装到备用容器、或者搭配一台不依赖联网的机械定时喂食器作为兜底，成本不高，但换来的是故障时的一层缓冲。

选购环节也可以多问一句：设备在断网或厂商服务不可用时，究竟还能做什么。厂商宣传页上的「本地排程」有多种实现深度，是完全脱机执行，还是依赖周期性的云端校时与状态同步，用户很难从参数表上看出来，而这一点恰恰决定了服务中断时的实际表现。

来源：The Verge、Petlibro 官方服务状态页

XDA 撰稿人 Samir Makwana 说，他早年照着论坛帖子拼出来的几条自动化确实能跑，但他也说不清为什么能跑，于是定下规矩：只要不坏就绝不去碰。这种「不敢碰」的状态，在 2026 年 7 月 1 日发布的 Home Assistant 2026.7 之后有了改变——目的化触发器和条件（purpose-specific triggers and conditions）从 Labs 实验区毕业，成为所有人的默认选项。它此前已在 Labs 里打磨了半年多。

区别在于起点：过去要先想「该用状态触发器、数值状态触发器还是设备触发器」，现在直接从「想让家里发生什么」选起。

一、把数值触发器换成场景触发器

以温度为例，过去要用数值状态触发器盯着一个原始读数，还得自己定阈值。现在新建自动化时直接选「Temperature crossed threshold（温度越过阈值）」，填上数字即可，比如卧室低于 18°C 就开暖气。

电池同理。以前得知道每个设备是按百分比、电压还是布尔值上报电量，撰稿人干脆随便挑了个数字凑合。现在选「Battery low（电量低）」并指向传感器，阈值由 Home Assistant 按传感器类型自行判断。前提是设备要正确声明自己是电池传感器——自己搭的节点需要先配置好，否则识别不到。

二、把自动化绑到区域，而不是单个设备

撰稿人客厅的灯光自动化原先绑定一个 PIR 人体传感器的实体名。后来为补盲区加了第二个传感器，就得回自动化里手动往触发器列表添加，每换一个设备都要重来一遍。

新触发器支持直接指向整个区域。把条件改成「客厅有移动」之后，自动化不再关心房间里有几个传感器，后续增加、更换或删掉某个都不用再改动它。

三、修那条躲了一年的自动化

他还有一条「回家观影模式」：夜里回到家就把灯调暖调暗、打开电视。它靠手机定位从 not_home 变为 home 来触发，可信号一抖就先变成 unavailable 再落回 home，结果不是漏触发，就是拿旧值提前触发。当时他靠加一堆额外条件勉强绕过去，从此不敢再动。

新的到家触发器内部已处理 unknown 与 unavailable 这类中间状态，换上之后那些补丁式条件全部删掉，运行至今没再出过问题。

注意事项

• 已有的自动化不会被改动，照常运行，旧的触发器类型也继续保留。
• 习惯写 YAML 的人不必担心，目的化触发器同样能对应写进 YAML，不是只有界面才能用。
• 集成可以自带触发器，例如洗衣机集成提供「洗衣完成」，电价集成提供「今天电价最低时」，不用再去解读它们各自的状态码。

同版本还顺带把日志本改名为 Activity 并重做成时间线，更新页面则按系统、集成、应用、设备分组，每组带一个 Update All 按钮，核心系统更新单独留在外面手动确认。

来源：XDA Developers

论文提交于 2026 年 3 月 4 日，题为《Zigbee vs. Matter over Thread: Understanding IoT Protocol Performance in Practice》，作者为 Massimo Nobile 等五人。

两套协议的根本分歧

Zigbee 最早在 2005 年标准化，是一套成熟、垂直集成的通信栈，但它并非基于互联网协议（IP）：网络层用的是 16 位短地址，整个网络围绕一个唯一的协调器（Coordinator）呈星型层级拓扑，由它负责建网、分发密钥和对外桥接。它的路由基于 AODV 反应式协议——节点没有去往目标的路由时，会向全网广播路由请求，直到抵达目标再回传。

Matter over Thread 则把 Thread 作为底层网络：Thread 在 2015 年标准化，原生基于 IP。其上层的 Matter 是由连接标准联盟牵头定义的统一应用层，目标就是打通不同生态之间的互通。它的路由由具备路由能力的节点用 MLE（网格链路建立）协议主动维护——路由器周期性地交换带链路质量度量的路由通告，算出一条累积路径开销，并且可以部署多个边界路由器互为冗余、无缝切换。

正因为 Thread 跑在互联网协议上，它要靠 6LoWPAN 适配层把标准的 40 字节 IPv6 报头压缩到最小的 6 到 7 字节，才能塞进 IEEE 802.15.4 那窄小的帧里。

测试怎么搭的

研究团队用一台树莓派 4（4GB 内存）运行 Home Assistant 作为智能家居中枢：对 Zigbee 它充当协调器，对 Thread 充当边界路由器。Zigbee 侧用德州仪器的 CC2531 加密狗刷上 Z-Stack 协调器固件；Thread 侧用基于硅 Labs EFR32MG21 方案的 Sonoff ZBDongle-E 刷上 OpenThread 边界路由器固件。六个 ESP32-C6 开发板充当网格节点，再加一台被动抓包器记录链路层和应用层行为。

关键是，两套方案跑在同一个 2.4 GHz 频段、250 kbps 的原始速率上，用着几乎一样的无线电硬件，所以性能差异只能归因于协议本身，而不是芯片优劣。控制指令每五秒下发一次，既有链式拓扑（指令始终发往链路末端以拉满跳数），也有全连通网格拓扑（目的节点随机挑选）。网络规模从小到大逐级放大。

结果：小网络 Zigbee 更灵敏，大网络 Matter 更稳

吞吐上，Zigbee 在单跳直连时峰值最高，约 75 kbps，但每增加一跳就迅速劣化；Matter over Thread 在多跳下始终保持明显更高的吞吐。

路由恢复速度则是 Zigbee 的强项。它平均只用 0.36 秒就能从断链中恢复——这正体现了 AODV 反应式路由「一断就广播重找」的特性。Thread 的恢复过程要漫长得多：平均通信中断约 24 秒，研究者还用 OpenThread 网络模拟器交叉验证了这个结果。

真正拉开差距的是可扩展性和容错。在五跳实验中，Zigbee 只成功送达了 180 条控制指令里的 94 条；到了六跳，Zigbee 协调器多次意外崩溃，连稳定的数据点都采不到。Matter over Thread 则从头到尾保持稳定。

怎么选

论文给出的结论很清晰：Zigbee 基础开销更低、路由恢复更快，在静态、小规模部署里更「跟手」，适合节点少、拓扑固定的轻量场景；Matter over Thread 在可扩展性和健壮性上更胜一筹，能在多跳、异构、规模更大的网络里保住稳定的吞吐和可预期的延迟。

换句话说，两套协议是在「敏捷」与「效率、可扩展」之间做了不同取舍。给一套小公寓里几十个传感器组网，老牌 Zigbee 依然划算；要是打算把全屋几十种不同品牌的设备织成一张大网，Matter over Thread 才是更不容易在某一跳上塌掉的那一个。

来源：arXiv:2603.04221（Politecnico di Milano）