写在前面：有了AI真的很方便，其中很多节点都是由AI编写的，已经持续用了一个月了，体验很好。所以分享一下，新人首分享~

也是和大家交流一下思路，参考了本论坛很多大佬们之前的分享，在此感谢！！！！！

另外，我是个懒人，所以帖子内容也由AI编写了包括代码也经过了AI脱敏处理，当前代码接入的是minimax模型，反正欢迎语巡检这种简单的任务其实任何模型都差不多~

附件为可导入的json文件

这套 Node-RED 流程是我在日常使用中一点点完善出来的，主要围绕 回家、离家、语音播报、设备联动和状态巡检 展开。

目前已经稳定运行了一段时间，逻辑不算特别复杂，但涉及的场景比较多，所以整理并脱敏后分享出来，供同样使用 Home Assistant 和 Node-RED 的朋友参考。

通过米家中枢网关产生“联动回家”事件，Node-RED 接收到事件后，会先判断当前是否处于离家状态。

确认回家后，会执行以下流程：

• 根据家中光照情况自动开灯

• 更新家庭在家状态

• 判断本次回家人员

• 获取天气、温度等信息

• 生成并播放个性化欢迎语

• 检查家中部分设备和耗材状态

• 根据室内温度判断是否需要询问打开空调

• 用户确认后，自动设置空调模式及目标温度

欢迎语并不是固定文本，而是会根据回家人员、时间、天气和家中状态动态生成。

为了避免欢迎语还没有播完，后续提醒就开始播放，我还根据欢迎语字数增加了动态延迟，等欢迎语播放结束后，再继续播报耗材或设备提醒。

离家模式不是开门后立即执行，而是会进行延迟判断，尽量避免取快递、倒垃圾等短时间外出被误判为真正离家。

主要逻辑包括：

• 门内开锁后启动离家状态检测

• 定时检查手机或设备群是否离线

• 离线达到指定时间后确认离家

• 更新家庭离家状态

• 关闭空调、热水器等设备

• 满足条件时启动扫地机器人

• 扫地机器人每天只自动运行一次

• 支持“临时离开”事件取消本次检测

回家后，如果室内温度过高或过低，会通过小爱音箱询问是否需要打开空调。

询问时会把待执行方案临时保存，包括：

• 制冷或制热模式

• 建议目标温度

• 当前室内温度

• 触发原因

• 生成时间

随后可以通过米家自动化产生：

• “确认打开空调”

• “取消打开空调”

两个事件。

确认后，Node-RED 会读取刚才保存的方案，自动设置空调模式和温度，并播报执行结果。

为了避免误操作，待确认方案设置了有效期，超时后不会继续执行。

回家后会检查部分设备或耗材状态，例如：

• 净水器初滤剩余比例

• 净水器 RO 膜剩余比例

• 软水机剩余盐量

• 其他需要定期维护的设备

只有达到设定阈值时才会生成提醒，正常状态不会播报。

提醒内容会先汇总，再等待欢迎语播放结束后统一播报，避免多个音频互相打断。

睡前巡检同样通过米家中枢网关产生“睡前巡检”事件，再由 Node-RED 进入独立的宠物设备巡检流程。
这部分主要检查喂食器、智能猫厕所和饮水机，具体包括：

• 喂食器是否在线

• 喂食器粮仓是否偏低

• 猫厕所垃圾箱是否已满

• 猫砂是否缺少

• 猫厕所垃圾箱是否安装到位

• 当前猫砂剩余比例

• 是否触发猫厕所频繁使用检测

• 当天猫厕所使用次数

• 饮水机是否缺水

• 当天饮水次数

检查完成后，流程会把结果分成四个级别：

• 需要马上处理：例如喂食器离线、垃圾箱已满、猫砂严重不足、垃圾箱未安装到位或饮水机缺水

• 需要留意：例如粮仓偏低、猫砂余量偏低、猫厕所频繁使用、当天未使用猫厕所或使用次数过多

• 状态未知：设备离线、实体不可用或跨日数据无法准确确认

• 状态正常：没有发现需要额外处理的问题

其中猫砂余量低于或等于 20% 时会作为重要问题提醒，21%～40% 时作为一般提醒；猫厕所当天使用次数为 0 次或达到 8 次以上时，也会提示关注。饮水次数为 0 时会提醒确认，次数较少时则只作为一项记录播报。
跨日计数处理因为猫厕所和饮水机的“今日次数”会在每天零点清零，而我有时会在零点以后睡觉，所以流程专门增加了跨日修正。
每天 23:59 会保存一次猫厕所使用次数和饮水次数快照。如果睡前巡检发生在 0:00～5:00，则使用：
23:59 保存的次数＋零点后的新增次数
作为本次睡前周期的实际数据。
如果凌晨执行巡检时没有有效快照，并且当前次数刚好是 0，流程不会直接判断“今天没有喝水”或“没有使用猫厕所”，而是把结果标记为无法准确确认，避免零点清零造成误报。
AI 生成自然播报所有检查结果会先汇总为结构化数据，再交给大模型生成一段适合智能音箱朗读的睡前提醒。
播报会根据巡检级别调整内容：

• 有严重问题时，优先告诉我睡前需要处理什么

• 有一般问题时，用比较温和的方式提醒留意

• 有设备状态未知时，说明哪些项目没有成功确认

• 全部正常时，简单说明喂食器、猫厕所和饮水机状态正常

最终内容通过卧室的小爱音箱播报。
为了避免大模型接口故障导致完全没有提醒，流程还准备了本地兜底文本。即使 API 请求失败、返回内容异常或者生成文字不符合要求，也会根据实际巡检结果生成基础播报，不影响睡前检查的核心功能。

我把多个米家自动化事件统一交给中枢网关产生，再由 Node-RED 根据事件名称进行分流。

目前包括：

• 联动回家

• 联动离家

• 临时离开

• 我要洗澡

• 净化器最大档

• 净化器静音

• 确认打开空调

• 取消打开空调

• 睡前巡检

这样做的好处是，米家负责设备侧触发，Home Assistant 和 Node-RED 负责复杂判断和执行，后期增加新场景也比较方便。

这套流程主要解决了几个实际使用中的问题：

避免简单粗暴地判断回家和离家

没有直接使用开锁事件作为最终结果，而是结合家庭状态、设备在线状态和延迟时间进行判断，减少误触发。

播报之间不会互相打断

欢迎语、耗材提醒、空调提醒都增加了顺序控制，并根据文本长度动态计算延迟。

尽量减少无意义播报

设备正常时不播报，只有存在需要处理的事项时才提醒。

支持二次确认

开空调等操作不会在温度达到条件后直接执行，而是先询问，确认后才执行。

流程可以继续扩展

后续可以继续加入：

• 门窗未关闭提醒

• 燃气和用水巡检

• 洗衣机完成提醒

• 宠物设备状态

• 空气质量联动

• 睡前统一巡检

• 到家后根据人员执行不同场景

分享文件已经进行了隐私脱敏，里面的姓名、城市、设备账号编号和实体 ID 均已替换为示例内容。

因此导入后不能直接运行，需要根据自己家中的实际情况修改：

• Home Assistant 服务器配置

• 米家设备实体 ID

• 中枢网关事件实体

• 手机或设备在线状态实体

• 空调、灯光、热水器等设备实体

• 小爱音箱通知实体

• 天气实体

• 耗材传感器实体

• 各类 input_boolean 和状态存储实体

另外，流程中使用了一些 Home Assistant 的 Node-RED 节点，需要提前安装：

• node-red-contrib-home-assistant-websocket

如果需要使用大模型生成欢迎语，还需要自行配置对应的 API 地址和 Key。分享文件中没有包含任何真实 API Key。

建议不要一次性把整套流程全部启用。

可以按照以下顺序逐步测试：

1. 先配置 Home Assistant 服务器

2. 测试网关事件能否正常进入 Node-RED

3. 修改并测试回家模式

4. 修改并测试离家模式

5. 测试语音播报

6. 最后再启用空调和设备控制

涉及空调、热水器、门锁等设备时，建议先把服务调用节点改成调试节点，确认判断逻辑没有问题后再正式执行。

这套流程并不是一个开箱即用的通用方案，因为每个人家里的设备、实体 ID 和使用习惯都不同。

我分享它的主要目的，是提供一个相对完整的思路：

让米家负责触发，让 Home Assistant 负责状态，让 Node-RED 负责判断和流程控制。

大家可以直接拆其中的某一部分使用，也可以根据自己的设备重新组合。

如果有更好的判断方法、流程结构或者优化建议，也欢迎一起交流。

▼▼▼

更多详情内容见原帖…