智能家居与物联网入门：断网以后家还能用吗？本地控制与云端依赖一次拆清

智能家居与物联网入门：断网以后家还能用吗？本地控制与云端依赖一次拆清

[!NOTE] 设备连着家里的Wi-Fi，并不代表控制过程完全发生在家里。 手机按钮可能先经过厂商云端，语音可能先上传处理，初次登录和日常控制也可能使用不同依赖。 本课把“断网”拆成互联网、局域网、控制中心和单台设备四种故障，用一个离线依赖分析器推演哪些能力会失效。你将得到一份按功能划分的依赖表，而不是一句含糊的“支持本地”。

学习位置：第一阶段·建立地图｜第005课 / 共100课。

先修：协议分层与需求表。 本课不要求你拔掉家庭路由器，也不修改任何联网设备。 故障推演全部使用虚构拓扑与本地程序。

一、问题背景与技术选型

“断网”不是一个明确故障

互联网中断时，家里的局域网可能仍然正常。 无线接入点故障时，有线主机可能仍然互相可达。 控制中心停止时，设备自己的按钮可能仍可使用。 只有某个传感器离线时，其他设备也不应一起被判故障。

把这些情况都叫“断网”，会导致排查顺序混乱。 正确方法是问：哪一段连接或哪一个服务不可用了？ 然后检查哪些功能直接或间接依赖它。

三种路径的区别

表里的“可能”不是回避问题。 不同型号和集成方式确实可能具有不同表现。 本课教的是如何取得证据，不替所有产品作保证。

本地方案也需要维护

本地运行可以减少部分外部依赖。 但主机供电、存储、升级和备份仍由使用者承担。 不能把“本地”理解成无需维护，也不能把“云端”一概等同不可靠。

你真正需要的是：关键功能有哪些依赖，故障后还有哪些替代入口。 这是一项逐功能判断，而不是品牌标签判断。

二、前置准备与环境说明

软件与材料

• Python 3.12标准库。
• 第003课的功能需求表。
• 任意文本编辑器。
• 不安装服务，不扫描家庭网络。
• 不读取实际账号、Token或设备日志。

Home Assistant安装与集成文档是本课的平台事实入口。 查阅时文档基线为2026.8.3。 示例里的依赖图由本课自行设计，不代表任何品牌的真实架构。

依赖表应该按功能建立

一台设备可能同时支持多条控制路径。 不能因为物理按钮可用，就说它的云端App也能离线使用。 也不能因为云端语音失效，就推断全部本地自动化都失效。

建议分别列出：

• 物理按钮。
• 局域网内手动控制。
• 传感器触发的自动化。
• 外网远程控制。
• 语音转写与意图理解。
• 固件更新与初次绑定。

这些功能可能具有不同前提。 初次配对需要云端，并不直接证明日常控制也需要云端。 反过来，日常短时离线成功，也不证明长期离线认证永远有效。

三、核心配置与代码详解

第一步：画功能依赖图

physical_button
└─ device_power

local_dashboard
├─ device_power
├─ lan
└─ hub

cloud_voice
├─ device_power
├─ lan
├─ hub
├─ internet
└─ voice_cloud

这是用于推演的简化模型。 真实系统可能还有DNS、时钟同步、授权服务器和消息代理。 刚开始可以先画最主要的依赖，再通过实验逐步补充。

第二步：明确失效后的显示

功能不可用时，界面不能只保持原来绿色的“在线”。 需要区分最后一次状态和当前可达性。 旧读数可以保留用于历史参考，但不能伪装成当前采样。

最后温度：24.1°C
最后收到时间：60秒前
当前采集状态：不可用
允许自动动作：否
人工入口：实验灯物理按钮

温度值为教学示例。 真正决定是否能继续自动化的是数据质量与新鲜度规则。 后续MQTT与可靠性课程会进一步实现这些检查。

第三步：运行一个依赖分析器

保存为dependency_lab.py：

"""离线推演功能依赖：只计算，不接触真实设备。"""

# 基础部件自身没有进一步依赖，便于教学阅读。
GRAPH = {
"device_power": [],
"lan": [],
"hub": ["lan"],
"internet": ["lan"],
"voice_cloud": ["internet"],
"physical_button": ["device_power"],
"local_dashboard": ["device_power", "lan", "hub"],
"cloud_voice": ["device_power", "hub", "voice_cloud"],
}

def unavailable_reason(name: str, failed: set[str], trail=()) –> str | None:
# 模型里不存在的组件不能被默认为可用。
if name not in GRAPH:
return f"unknown:{name}"
# 检测循环依赖，避免递归无限继续。
if name in trail:
return "cycle:" + "->".join((*trail, name))
# 当前组件被故障场景明确标记时，立即报告。
if name in failed:
return f"failed:{name}"
# 逐层检查依赖，保留首次发现的具体原因。
for dependency in GRAPH[name]:
reason = unavailable_reason(dependency, failed, (*trail, name))
if reason is not None:
return reason
# 所有模型依赖都正常时，返回无阻断原因。
return None

def show_scenario(label: str, failed: set[str]) –> None:
# 场景名称帮助读者区分不同类型的“断网”。
print(f"scenario={label}")
# 只检查三项教学功能，不推断真实产品能力。
for feature in ("physical_button", "local_dashboard", "cloud_voice"):
reason = unavailable_reason(feature, failed)
status = reason if reason else "model_available"
print(f" {feature}: {status}")

# 每个场景只改变一个故障变量，便于解释因果。
SCENARIOS = [
("normal", set()),
("internet_down", {"internet"}),
("hub_down", {"hub"}),
("lan_down", {"lan"}),
("device_power_down", {"device_power"}),
]

# 直接运行脚本才展示结果，作为固定输入的课堂实验。
if __name__ == "__main__":
for label, failed in SCENARIOS:
show_scenario(label, failed)

程序输出model_available，而不是“实测在线”。 这是为了提醒：模型只能说明你写入的依赖关系。 漏掉了认证云依赖，程序也不会神奇地知道它存在。

第四步：为每项结论标注证据级别

不要把模拟结论提升为实测。 也不要把一次实测提升成永远有效的产品承诺。 固件、平台与账号状态变化后，应重新检查相关功能。

四、实操验证与运行结果

运行所有场景

# 查看解释器版本，记录实验软件基线。
python3 –version

# 执行本地依赖推演，不需要互联网。
python3 dependency_lab.py

互联网中断场景的教学预期：

scenario=internet_down
physical_button: model_available
local_dashboard: model_available
cloud_voice: failed:internet

这个结果来自示例图里定义的路径。 它不能被引用为某件真实设备断网可用的证据。

比较控制中心与局域网故障

控制中心停止时，模型中的物理按钮仍可用。 本地界面和云语音因为依赖控制中心而不可用。 局域网故障时，按钮也仍可用，但两条网络路径都中断。

两种场景看起来都可能是“App点了没反应”。 具体原因却不同，因此修复动作也应该不同。 不要未区分原因就重置全部设备。

修改模型观察变化

给local_dashboard增加voice_cloud依赖。 再运行互联网故障场景，它也会变为不可用。 这说明“本地界面”这个名字本身不保证本地路径。

恢复修改后，给图增加一条循环依赖。 例如在lan依赖里加入hub。 分析器应报告cycle，而不是无限运行。

真实验证前的准备清单

• 只选择低风险实验对象。
• 先告知会受影响的使用者。
• 保留独立人工入口。
• 记录恢复步骤。
• 一次只中断一个环节。
• 记录实际时间和观察结果。
• 完成后确认网络与设备恢复。

本课到此只完成准备，不要求执行真实中断。 尤其不要为了学习影响家庭工作网络、照护设备或安全系统。

五、适用边界与踩坑兜底

误区：短时离线成功等于永久脱云

有些功能可能使用缓存状态或尚未过期的凭证。 短时间测试成功，不代表数天后仍然成功。 需要根据产品说明设计合理的验证周期，并记录测试边界。

误区：重启是一种无害验证

重启可能改变自动化状态、计时器和待处理动作。 它还可能导致设备使用默认状态。 因此重启本身也应该有测试用例，而不是排错时随手执行。

常见错误怎样排查

如果模型报告unknown:组件名，先修正拼写与定义。 如果报告cycle，查看依赖是否被错误地写成互相依赖。 这两类结果描述的是文档问题，不是实际网络故障。

如果脚本出现IndentationError，检查缩进是否混入制表符。 不要删除递归保护逻辑来消除报错。 应先恢复示例，然后每次只改一个字段。

云端与隐私

选择云端能力时，了解会传输哪些数据及保留多久。 语音、家庭作息与设备状态可能组合出敏感生活信息。 在线AI日志分析前先脱敏，并只提供解决问题所需片段。

六、总结与后续思考

可靠的判断单位是“某项功能的一条依赖路径”。 Wi-Fi、本地、云端和AI都只是描述系统的某一部分。 把失败环节与剩余能力分别写清楚，才有可执行的退化方案。

下一课会从第一套实验器材的供电、接口和兼容性入手。 你将用同样的方法区分“能插上”“电气兼容”和“软件能支持”。

你最希望在互联网中断时保留哪一项功能？ 先为它写一条依赖路径，再继续学习《智能家居与物联网-全速入门【持续更新中】》。 这条路径会成为后续备份、故障演练与AI降级设计的依据。

参考资料

• Home Assistant安装说明：自有硬件与平台运行方式。
• Home Assistant集成概念：集成与外部服务关系。
• Home Assistant本地语音助手：语音处理中的本地与远程路线。

资料查阅日期：2026-08-31；依赖图与推演结果为原创模拟示例。