把 HomeAssistant 的现成插件拆了，自己写了一个

HomeAssistant 是我折腾得最久的一个项目。从最开始在树莓派上装，到后来整套自动化编排，前前后后两年多。这篇文章记录一次典型的”现成的不够用，那就自己来”的过程。

需求从哪来的

我的自动化体系里有一个环节：某些设备的状态变化要触发一系列后续动作，但中间夹着一些现成插件处理不了的逻辑。具体来说，某个传感器的值要经过一个比较复杂的判断，才能决定要不要触发，而判断依据里包含时间、其他设备状态、甚至历史数据。

现成的自动化引擎能做到条件组合，但组合的粒度不够。写一大堆 yaml 条件，又长又难维护，每次加逻辑都要小心别把前面的弄坏。我当时的想法很朴素：这个判断逻辑，如果我能在插件里用代码实现，会干净得多。

拆的过程

既然决定自己写，第一步是把现有的同类插件拆开看。看什么呢？不是看它怎么实现功能的，而是看它的骨架：怎么注册实体、怎么处理状态变更、怎么跟 HA 的事件总线交互、配置是怎么加载的。

这里有个经验：抄功能是最没价值的，抄架构才值钱。一个成熟插件的骨架，是作者踩过无数坑之后沉淀出来的，你直接把它摸清楚，能省掉大量摸索。

拆完之后的结论是：HA 的插件模型比我想象的开放。你可以写一个自定义集成，注册自定义实体，然后在实体的状态更新里做任何事。整个流程走一遍之后，你会发现 HA 的抽象层设计得很干净，事件驱动的核心让自定义逻辑可以完全融入体系，而不像一个外挂。

写完之后的感受

代码量其实不大，核心逻辑两百行左右。但带来的改变是：我所有之前用 yaml 硬堆的条件逻辑，全部收进了插件里，配置面板干净了，逻辑也变成可测试的了。后来改需求，改的是插件代码，跑一遍测试，完事。这在 yaml 时代是不可想象的。

这件事给我最大的收获不是插件本身，而是一个判断：在成熟的生态里，先别急着找现成方案。先拆一个看它的架构，如果架构允许，自己写往往比将就更快。表面上是多花时间，实际上是在给后面省时间。

顺带一提，HA 社区有个特点，官方文档写得很全，但”怎么从零写一个集成”的完整示例不多。如果你也想拆，我的建议是从一个最小集开始，别一上来就做完整功能，先把实体注册和状态更新这条链路跑通，再往里加东西。