从 MajorDoMo 迁移到 osysHome：无停机时间的分步指南

# 家居自动化迁移：从 MajorDoMo 无中断切换到 osysHome

在运行 MajorDoMo 作为主要家居自动化平台八年之后，作者遇到了维护复杂度急剧飙升的瓶颈。任何脚本微调都需要一连串检查，将日常任务变成彻夜马拉松。从自定义构建的 osysHome 切换纯粹出于迫切需要——为了大幅降低管理系统时的认知负担。本文分解了一个分步零中断迁移方案、关键陷阱，以及适用于任何大规模自动化系统的策略。

为什么 MajorDoMo 不再胜任

原本作为测试平台的东西，在八年里演变为关键基础设施。对象数量达到 200 个，从物理传感器到虚拟实体和工具逻辑。核心问题是系统性的：

• 自动化响应变慢 — 后台进程开始争抢资源
• 数据碎片化 — 难以追踪对象间的连接
• 权限不透明 — 每个新脚本都需要手动设置权限
• 脚本脆弱 — 任何修改都需验证依赖关系

转折点是“小修小补”陷阱：原本 10 分钟的任务，常常膨胀成数小时调试。对于这种规模的系统，维护难题已盖过新增功能。

并行启动策略

迁移的最大错误？试图“一刀切”。相反，我们采用分阶段移交，确保每步都保持系统运行：

• 独立 osysHome 启动 — 与 MajorDoMo 并行安装在同一硬件上（SOYO M4 AIR N95 16GB+512GB，运行 Ubuntu Server 25.10）
• 集成验证 — 通过 MQTT、Zigbee2MQTT 和 ESPHome 手动测试设备控制
• 对象模型重构 — 不是简单复制，而是为长期维护重组
• 自动化复制 — 新逻辑仅在确认正常后上线

这消除了全面中断风险。发现问题？系统自动回退到 MajorDoMo，避免深夜紧急处理。

设备迁移策略

设备按功能组迁移，而不是物理位置。这样减少了脑力负担，加速了故障排除：

• 阶段 1： 核心基础设施（MQTT 代理，Zigbee 网关）
• 阶段 2： 按设备类型（照明、气候、安全）
• 阶段 3： 复杂生态系统（Xiaomi 的吸尘器、水晶吊灯、加湿器）

Xiaomi 设备是个麻烦——它们的 API 行为古怪，占去了 30% 的迁移时间。就连看似简单的宠物饮水器，也因为异步通知花了两个晚上。

迁移中的意外收获

迁移引发了对过时部分的 refactoring。同时，我们：

• 用统一界面的 ESPHome 替换了 Tasmota 继电器
• 添加了 Bluetooth 网关用于温度传感器数据
• 将 Modbus 电表适配器转为原生支持
• 通过 MAX7219 优化了滚动 ticker 显示

这优于简单移植。在迁移中清除技术债，降低了长期支持成本，尽管短期工作量增加。

切换后变化

个人指标显示运维成本下降：

• 编辑时间锐减 — 标准脚本从 2 小时降到 15 分钟
• 权限简化 — 集中式权限管理取代手动调整
• 稳定性提升 — 更清晰的对象模型杜绝了误触发

话虽如此，osysHome 也有局限。新手缺少现成脚本难以上手。文档落后于代码库，有些功能（如 ThinQ 集成）需手动配置。对作者来说，这些权衡换来了认知负担的减轻。

关键经验

• 并行运行不可或缺，适用于零中断系统
• 功能分组加速调试，比物理布局快 2–3 倍
• 迁移是重构遗留组件的最佳时机
• 可维护性胜过功能，对 5 年以上系统尤甚
• 为 Xiaomi 设备预留 30% 额外时间，因 API 怪癖

整个切换花了两周，每晚 2–3 小时。大收获：不再畏惧脚本编辑。稳定的 MajorDoMo 系统无需此举，但随着复杂度增长，渐进式转变物超所值。主要教训：选平台看长期可维护性，而非规格。

— Editorial Team