本地部署全屋AI自动化方案Miloco是我今年在智能家居上做得最值的一次决定。家里传感器越装越多联动规则写了几十条住进去之后才发现大部分自动化只是在机械执行固定条件——场景稍微复杂一点就误触发或者几条规则互相打架。Miloco本质上是一套跑在私有云上的自动化决策引擎它把所有厂商的传感器、网关、执行器统一成一套连续状态模型用“状态判断”代替“单点触发”再叠加几个轻量AI决策模块处理真实居家场景。这篇文章会拆解完整部署过程、核心决策模型、规则配置思路以及跑了一个多月之后踩过的坑。如果你也在被多平台割裂、规则僵化、误触发这些问题折磨或者手头正好有一台长期在线的私有云/NAS想利用起来这篇文章应该能给你完整可落地的参考。1. 先从最痛的体验说起写死的联动规则为什么会失灵1.1 一个真实翻车场景客厅灯光与“观影模式”打架讲个我家真实发生过的场景。客厅装了人体传感器和光照传感器原始规则很简单光照低于某个值且检测到有人就开灯。听起来没问题对吧但晚上一家人坐在沙发上看电影的时候屏幕亮光会让人体传感器周期性触发加上窗帘拉上后光照传感器读数掉到阈值以下客厅灯就被反复点亮。我设置过“观影模式”可观影模式本身也是一条规则一旦客厅灯被点亮观影模式就必须再写一条“检测到灯开了就关掉”的反制规则。最后两个规则互相竞争灯一会被点亮一会被熄灭。这就是典型的“单点条件触发”问题。大多数平台的自动化规则是事件驱动传感器上报一个“有人”事件就去执行开灯动作。可真实居家场景里“有人”这个状态是连续的、会变化、有噪声的它必须结合时间、光照、房间内其他传感器数据、甚至当前其他设备状态一起判断才能得出“现在该不该开灯”的结论。单点触发天生做不到这件事。1.2 Miloco不是又一个App而是自动化决策的“中枢”这也是我后来愿意在私有云上折腾Miloco的原因。Miloco的思路和那些App里做“条件—动作”联动的逻辑不一样它先维护一套“当前家居状态”的实时模型比如人在哪个房间、房间里有没有持续活动、光照处于什么水平、当前处于什么时序模式白天/夜间/睡眠然后自动化规则不再直接响应“传感器事件”而是响应“状态变化”。用人话说普通联动回答的是“发生了什么”Miloco回答的是“现在是什么状态因此应该做什么”。传感器事件进来之后先进入Miloco的统一状态模型里更新状态状态变化满足条件后再触发动作。这样“看电影时灯被点亮”这种问题就很好解决只要判断到客厅处于“观影模式”这个状态亮度自动开灯这条规则就会被抑制不需要再写一条反制规则。我选择本地部署而不是依赖各平台云端的另一个原因是家里自动化的执行链路如果全部拉到云端每次决策都要经过云服务器中转延迟高不说一旦断网或者平台服务波动整个家的自动化就瘫痪了。Miloco跑在私有云上传感器数据进入局域网内决策引擎动作指令也从局域网内发出外部网络断开时核心自动化依然能跑。2. 部署“这台私有云”之前我做了哪些硬件与系统准备2.1 为什么坚持本地闭环而不是云端定时刚开始我考虑过直接用某个智能家居平台自带的自动化功能毕竟最省事。但用了一个月问题就暴露了第一规则能力上限低复杂条件要么写不了要么只能通过大量叠加规则变相实现第二所有自动化依赖云端平台服务一波动家里的灯就“智力退化”第三隐私问题全屋传感器数据上传到平台云端这件事我始终不太舒服。本地闭环意味着所有传感器数据在局域网内完成汇聚、判断和控制指令下发。隐私上家里哪些时段有人活动、夜间几点起床这类数据只存在于自己的设备里。稳定性上断网不影响自动化运行。延迟上局域网内指令一般几十毫秒就能到达设备比云端链路快一个量级。2.2 设备底盘梳理清单从传感层到执行层部署之前先把家里的设备盘了一遍Miloco本身不直接和物理设备通信它依赖已有的智能家居平台或网关来做设备接入。所以要先理清哪些设备可以暴露本地接口哪些只能通过云端控制哪些设备有状态上报哪些只有控制能力没有反馈。我的设备底盘大概是这样的传感层人体存在传感器多个房间、门窗磁、温湿度、光照、水浸、燃气报警网关层各厂商的局域网网关、部分设备自带Hub执行层智能灯、开关面板、窗帘电机、空调红外控制器、空气净化器、加湿器设备梳理这一步很关键因为Miloco做“状态决策”的前提是感知层数据足够可靠、足够丰富。如果只有一个传感器状态模型再先进也白搭。我的建议是至少保证目标房间有一路“存在检测”加一路“环境检测”比如人体传感器温湿度这样状态模型才有两个维度可以参考。2.3 私有云选型时的三条硬性标准Miloco本质上是一个需要长期在线运行的服务选私有云设备时我定了三条硬性标准。第一是低功耗常驻我不会为了跑这套自动化专门养一台高功耗的服务器理想是整机功耗控制在较低水平日常24小时开着不心疼电费。第二是必须支持Docker容器Miloco以容器方式分发和更新如果设备不支持容器部署会很麻烦市面上常见的NAS和私有云设备基本都满足这一点。第三是存储和日志要可靠自动化引擎跑久了配置文件、状态快照、日志都会持续增长需要有稳定的磁盘和简单的备份恢复手段。手头这台私有云是ARM架构的四盘位机型8GB内存跑Miloco容器之外还同时跑着下载服务和备份任务。选型的时候也考虑过用一台小主机加开源NAS系统但最后选择私有云设备是因为它对家庭用户更友好系统维护成本低统磁盘管理和备份方案都是现成的不适合在这种基础设置上浪费太多时间。3. Miloco部署实操容器编排、目录结构、启动检查3.1 用Docker Compose拉起一个最小可用实例Miloco的官方镜像很小部署起来比我想象中简单。我先建立了一个工作目录用来放配置文件、数据文件和日志再用docker-compose.yml定义服务。services: miloco: image: miloco/miloco:latest container_name: miloco restart: unless-stopped ports: - 8080:8080 volumes: - ./config:/app/config - ./data:/app/data - ./logs:/app/logs environment: TZ: Asia/Shanghai MILOCO_STORAGE: sqlite MILOCO_LOG_LEVEL: info几个关键点说明一下。restart: unless-stopped保证设备重启后容器自动拉起来这是全屋自动化最基础的要求——不能人不在家重启了设备结果回家发现灯都不会亮。volume挂载的config、data、logs三个目录分别对应配置、状态数据库、日志这三个目录必须放在宿主机持久化存储上否则容器升级或重建后所有配置和自动化状态全部丢失。TZ: Asia/Shanghai时区必须设置对Miloco所有时间窗口判断都依赖本地时区比如“日落前不开灯”这种规则时区错了一切都乱。存储引擎选了sqlite对家庭规模这套自动化完全够用。3.2 接入设备源先从“状态上报”而不是“控制接口”开始Miloco支持接多种设备源但我强烈建议从状态上报类接口开始而不是控制类接口。原因很简单自动化的第一步是感知第二步才是控制。先把传感器的数据流跑通让Miloco能实时看到每个传感器的当前值之后写规则才有数据基础。控制接口可以逐步接比如先接灯的开关再接窗帘电机。当时我先接入的是两路人体存在传感器和一路温湿度传感器。Miloco的配置目录下有个device_sources.yaml里面定义了设备源的适配器类型、连接参数和实体映射关系。我用的是局域网直连方式不经过厂商云端这样传感器状态每几秒就能上报一次而不是依赖云端的推送延迟。device_sources: - name: living_room_sensors type: local_gateway host: 192.168.1.100 port: 8899 entities: - entity_id: sensor.living_room_presence device_type: presence - entity_id: sensor.living_room_temp device_type: temperature配置完成后Miloco会为每个实体生成一个标准化的entity_id后续所有规则直接用这个id引用。这一步相当于给全屋设备建立了一套“统一语言”——不管底层是什么厂商的设备在Miloco里都变成了一组标准状态。3.3 第一版规则卫生间人来灯亮、人走延时关灯跑通传感器接入之后我写的第一个正式规则是卫生间的灯光自动化。之所以选卫生间是因为它场景足够简单、状态边界清晰非常适合验证自动化是否可靠。规则用YAML写在automations目录下。我把它命名为bathroom_light核心逻辑做了两个关键设计一个是“持续时间过滤”人体传感器从无人变有人后要持续有人在超过2秒才判定为有人避免传感器瞬时抖动造成误触发另一个是“自动关闭延时”有人时开灯并启动一个3分钟延时定时器持续检测到有人就不断重置定时器直到无人超过3分钟才关灯。automations: bathroom_light: enabled: true trigger: type: state entity: sensor.bathroom_presence to: present for: 2s actions: - service: light.turn_on target: light.bathroom - service: timer.start entity: timer.bathroom_auto_off duration: 3m这里有个重要的设计思路我把开灯和关灯拆成了两条独立规则而不是一条规则里同时写开和关。开灯规则由“有人”状态变化触发关灯规则由定时器到期触发。这样做的好处是两个动作的触发条件完全独立未来如果要调整“有人时保持长亮”或“夜间降低亮度”只改其中一条规则就行互不牵连。3.4 验证自动化是否生效的检查清单规则上线后不要急着加新规则先花一两天验证这套最基本的自动化。我的验证清单是这样的事件日志里能看到传感器状态变化和规则触发记录确认规则确实被触发手动开灯后离开房间确认延时关灯能兜底不会出现灯一直亮着的情况白天和夜间分别测试确认光照条件没有影响这个场景人为在传感器附近停留但不动确认“持续存在”状态能维持不会误关灯这个阶段也是观察Miloco事件日志的最好时机。日志里能看到每条规则的完整判断链路传感器上报、状态更新、条件检查、动作执行哪一步出了问题都能定位。我在日志里发现的第一件事就是最初的人体传感器上报频率过低导致“for: 2s”的持续判定经常因为上报间隔而失效后来把上报频率调高才稳定。4. AI到底在Miloco里做了什么五个落地的决策模型4.1 多传感器置信度聚合两路存在感比一路可靠先把Miloco里“AI”这件事说清楚不是搞一个模型包打天下而是每个具体场景用一个轻量决策方法解决一个具体问题。第一个落地点是传感器置信度聚合。单个人体传感器的误触发概率其实不低尤其是家里有宠物、窗帘飘动、阳光变化都会造成误判。Miloco可以同时接入多路数据做交叉验证。比如卫生间的存在判断我接了人体传感器、门窗磁和湿度传感器三个维度人体传感器上报“有人”但湿度没有变化、门磁状态也没有变化那这个“有人”置信度就不高反过来如果人体传感器和门磁同时确认有人进入湿度还在短时间内明显上升那基本可以确定卫生间真的有持续活动。实现上不需要什么复杂模型就是一个简单的加权计分。Miloco有个内置的aggregate实体类型可以配置每个输入源的权重和有效条件。我的卫生间配置是这样人体传感器权重0.5门磁状态权重0.3湿度变化率权重0.2总分超过0.6才算“有人存在”。实践下来误触发率从单传感器的平均一天两三次降到了基本没有尤其是洗澡时水蒸气导致人体传感器频繁误报的问题被彻底解决了。4.2 睡眠状态估计夜间活动窗口判定何时进入睡眠第二个落地场景是睡眠状态估计。做自动化的都知道“睡眠模式”是刚需但怎么判断“已经睡了”是个难点。最简单的方案是定一个固定时间比如晚上十一点强制进入睡眠模式但休息日、加班晚归的时候固定时间就很蠢。Miloco的做法是基于活动窗口所有房间的传感器如果连续一段时间没有检测到人活动就判定家庭成员可能已经入睡。这个“连续一段时间”不是写死的而是用一个滑动窗口统计——如果过去二十分钟内活动次数低于某个阈值就认为进入睡眠状态。一旦进入睡眠状态夜间灯光自动化的触发条件会自动加上“亮度压低延时缩短”的规则空调温度曲线也会切到睡眠曲线。这个模型虽然简单但效果出乎意料地好。它不会因为某一次起夜活动就退出睡眠状态而是要求一段时间内活动达到一定频率才会切换状态。我实测下来凌晨去次卫生间这种短活动不会打断睡眠模式但周末早上九十点高频活动后系统会自动切回日间模式。判断逻辑维护在Miloco的state_estimators配置里本质上是一个带遗忘因子的活动计数不需要每天去改时间表。4.3 离家/回家场景的多条件确认避免误锁门误断电离家回家场景是最容易误触发的自动化因为门磁传感器一开一关就能模拟一次出入但取快递、丢垃圾都会造成门磁变化。如果只靠门磁判断离家就会出现人还在门口换鞋家里已经执行了全屋断电的尴尬情况。Miloco处理离家场景用了多条件加权确认门磁状态变化是第一条件室内所有传感器在门磁变化后持续无活动是第二条件手机Wi-Fi从家里的路由器断开是第三条件。三个条件同时满足才判定真正离家然后才执行关闭灯光、关闭非必要设备、布防安防系统这些动作。回家场景的判断逻辑类似但权重分配不同门磁打开后室内传感器在短时间内出现活动或者手机Wi-Fi重新加入都会快速确认“有人回家”。Miloco里有一个专门的decision_models配置区可以定义这类组合判断。这一块是我觉得最有价值的AI应用场景因为它把“多路信号交叉验证”变成了实际减少误操作的能力。4.4 跨平台设备冲突时的优先级裁决设备多了之后不同自动化指令之间会冲突。比如客厅空调的温度传感器报告温度偏高触发制冷但卧室的睡眠模式又希望全屋温度稍高一些。两个场景都想要控制空调到底听谁的Miloco的解决方案是给每条自动化设置优先级并且支持“状态互斥”。在观影模式下客厅的亮度自动化和窗帘自动化都会被设置为suppressed状态不会执行。在睡眠模式下除了夜灯和安防相关规则其他规则全部降权或暂停。优先级裁决本质上不是AI模型但它解决的是多目标冲突问题而Miloco把它做成了规则引擎的一等公民每个实体在当前状态下都会有明确的信任等级。我一开始并没有设置优先级结果出现了窗帘电机和空调联动“互相打架”的情况——空调制冷触发后温度快速下降又触发了窗帘关闭减少阳光的规则但窗帘一关房间变亮光照传感器测出亮度不足又触发了开灯规则。三条规则同时执行场面一度很混乱。后来给各条自动化设了明确的优先级别又在观影模式和睡眠模式下声明互斥实体才彻底解决。4.5 异常状态提醒不靠阈值靠“持续观察”漏水、燃气泄漏、长时间无人这些异常场景传统做法是传感器触发就告警但误报率高。水浸传感器偶尔被溅湿、燃气传感器因为湿度变化波动都会造成半夜被手机轰炸。Miloco的做法是异常不靠瞬时阈值而是“持续观察”水浸传感器状态为“湿”且持续时间超过30秒才告警燃气浓度超过阈值且连续保持3分钟才推送。对有持续性特征的异常事件这个策略完美过滤了瞬时误报对真正需要急响应的场景比如燃气浓度异常高可以用更短的持续时间窗口但依然保留至少几秒的确认。这个模型唯一的代价是告警有延迟对急性安全事件不友好。我的做法是区分两级一级告警用短确认窗口比如3秒二级告警用长确认窗口比如1分钟。短窗口处理真正的安全风险长窗口处理水管渗漏这类慢性问题。所有告警都会附带状态证据推送到手机的时候能看到触发依据避免了“报警了但不知道为什么”的困惑。5. 把居家场景写成状态机规则配置里最容易犯的三个错误5.1 直接堆if-else的后果很多人在配置自动化时的第一反应就是把现实逻辑翻译成条件如果A发生就做B。这个思路在场景简单的时候没问题但场景一复杂就会变成if-else堆砌。一条规则里塞十几个条件任何一个条件波动就会导致整个判断失效调试起来头都大了。Miloco的规则模型更接近有限状态机每个场景是一组状态场景内自动化根据实体状态变化在状态之间迁移。不是“厨房有人就开灯”这种单条规则而是“厨房空置态—厨房使用态—厨房保持态”这样清晰的状态流转。配置方式是声明目标状态而不是声明动作条件。刚开始接触这套思路确实不太适应但真的改换过来之后规则的可维护性提升非常明显。5.2 三个特别容易犯的配置错误第一个错误是忽略状态保持。人体传感器从“有人”变成“无人”之后如果后续传感器因电量低暂停上报状态会停在“有人”导致灯一直亮着。需要在规则里加上状态超时保护让“无人”状态在持续一段时间后自动确认。第二个错误是条件顺序不对。Miloco的判断顺序是trigger先触发然后检查condition最后执行action。很多人会把“太阳落山后”这类条件放在trigger里写成“太阳落山时触发出门灯开启”这会让同一时间窗口内其他非相关事件也被卷进来。正确做法是保持trigger是纯粹的状态变化事件所有时间、环境的附加判断都放到condition里。第三个错误是不考虑场景互斥。睡眠模式和起夜模式本质上对光照的需求冲突如果没有声明互斥起夜的灯光可能会触发睡眠模式的“全屋灯光关闭”形成逻辑矛盾。在配置里明确哪个场景优先、哪个场景会抑制其他场景是避免这类问题的最基本手段。5.3 事件节流一次误触发引发的“全家联动风暴”有个晚上我经历了一次“全家联动风暴”厨房的人体传感器误报了一次有人然后厨房灯亮、客厅灯亮、空气净化器开机、背景音乐播放全家都被唤醒了。根因是那条厨房规则触发了之后由于光照条件忽然变化又带动了其他几条自动化执行形成链式反应。Miloco的解决方法是事件节流。两条机制第一是最小间隔时间同一自动化在设定时间内不能重复执行第二是动作合并短时间内对同一设备的多条指令会被合并成一条避免没必要的重复控制。我把厨房灯、客厅灯这些高频自动化的最小间隔时间设成了60秒效果立竿见影——即使传感器出现偶发抖动也不至于每一次抖动都触发全屋灯光变化。这个“全家联动风暴”也让我意识到一个道理自动化规则写到一定数量真正重要的不是新增功能而是控制联动爆炸。Miloco的事件日志里会显示每条规则执行带来的后续变化通过观察这些日志可以很清楚地看到哪些动作对整体状态产生了连锁影响然后针对性地设节流和抑制。6. 跑了一个多月之后的调优清单与避坑建议6.1 传感器掉线后状态卡死怎么办自动化跑久了最头疼的不是逻辑写错而是传感器本身出问题。有一个深夜卫生间的存在传感器意外掉线状态一直停留在“有人”导致整个晚上卫生间的灯一直亮着。Miloco的做法是给传感器状态加“心跳监控”和“状态超时”。在实体配置里设置一个heartbeat_timeout超过这个时间没有收到心跳上报实体状态自动变为unknown。同时给自动化规则设置unknown状态的处理策略unknown时既不当作有人也不当作无人而是直接跳过该自动化保留当前设备状态不变。这样即使传感器掉线灯也会保持原有状态不会执行错误动作。这个调优是从那次“整晚亮灯”中学到的教训。现在我的所有核心存在传感器都有心跳监控状态超时设置成传感器上报间隔的三倍左右。掉线不再直接造成错误状态而是会触发一个“传感器离线”的通知提醒我可以及时去检查传感器而不是等发现问题的时候已经被错误联动折腾了一晚上。6.2 手动干预和自动化自动覆盖的优先级问题这是很多人都会遇到的问题你手动把客厅灯调到一个亮度希望保持这个状态但自动化规则因为某种条件变化又被触发马上覆盖了你的手动操作。Miloco建议的模式是给每条自动化声明mode分别是auto、manual和hybrid。hybrid模式会记录最近一次设备状态变化是手动还是自动化引起的如果是手动引起则在指定时间内暂停该设备上的所有自动化等待手动操作状态被用户明确清除。这个设计非常实用。我还在Miloco配置里专门做了一个manual_override实体手动操作一次就会设为true持续几小时期间相关自动化全部跳过避免刚调好又被自动化覆盖。现在家里装修调节、临时场景切换都用这个机制自动化不会在你想手动控制的时候捣乱。6.3 性能与日志这套引擎到底吃多少资源跑了一个多月给关注性能的朋友一个真实参考。Miloco容器在私有云上稳定运行内存占用大概在350MB左右CPU平时基本是零只有规则触发时会有短暂波动。sqlite存储文件一个月下来大概几十MB日志每天几MB对磁盘几乎没压力。整套系统对私有云的性能影响完全可以忽略。日志这块建议开启日志轮转否则日志文件会随着规则数量和触发频率增长。私有云有自带的docker日志大小限制最好配置上限制单个日志文件在100MB以内保留最近五个文件。我曾经因为日志没配置轮转一周日志涨到了近1GB虽然不影响运行但清理起来很烦。6.4 想入坑的人我给三条朴实建议第一条从小场景开始。不要一开始就想做全屋一键离家模式先把一个房间、一个设备、一个传感器从“手动控制”变成“自动控制”跑习惯了再扩展。第二条维护事件日志习惯。Miloco最值钱的不是规则引擎本身而是它能记录每一次状态变化和判断链路。每周花十分钟翻一遍日志你会发现自己家庭里很多隐藏的设备使用习惯这些才是调优自动化的真正依据。第三条永远保留手动入口。自动化的目标不是取代手动控制而是减少手动控制。我家里每个执行器都保留了物理开关或者场景面板入口万一自动化出了什么问题随手一按就能恢复手动控制这种安全感比任何“智能”都重要。7. 一些还没解决但值得继续折腾的方向部署Miloco到现在主要痛点已经解决但有几个方向我还在继续琢磨。一是语音识别的本地化。现在回家场景的语音指令还需要依赖外部语音平台数据绕了一圈出去再回来。如果能把语音识别也完全本地化整个自动化链路的数据就彻底不离开局域网了延迟和隐私都会有质的提升。二是多家庭成员的状态画像。目前Miloco能判断家里“有人没人”和“大概在哪个房间”但区分不了具体是谁。不同的人对温度、亮度的偏好差异很大如果能把家庭成员的身份识别做到可靠全屋自动化的个性化程度会高很多。三是从“人走灯灭”到“行为预测”。现在的自动化本质还是“响应状态变化”下一步我想尝试用历史数据预测接下来的行为模式比如根据工作日和休息日的活动规律提前调整空调温度和热水器状态。Miloco的传感器数据和事件日志已经积累了一个多月理论上这些数据已经足够支撑轻量级的预测模型训练了。这个内容后续的扩展空间确实挺大。说回最开始的问题全屋智能自动化真正值得做的不是让所有设备都服从指令而是让它们在你需要的时候刚好在做对的事。Miloco让我的注意力从“写规则控制设备”转移到了“理解家里的真实状态”这一点是我这一年折腾下来最核心的收获。 
长河君 · 2026/10/18 10:48:33 · 阅读 1.2k 本地部署全屋AI自动化Miloco：从规则僵化到状态决策
本地部署全屋AI自动化方案Miloco是我今年在智能家居上做得最值的一次决定。家里传感器越装越多联动规则写了几十条住进去之后才发现大部分自动化只是在机械执行固定条件——场景稍微复杂一点就误触发或者几条规则互相打架。Miloco本质上是一套跑在私有云上的自动化决策引擎它把所有厂商的传感器、网关、执行器统一成一套连续状态模型用“状态判断”代替“单点触发”再叠加几个轻量AI决策模块处理真实居家场景。这篇文章会拆解完整部署过程、核心决策模型、规则配置思路以及跑了一个多月之后踩过的坑。如果你也在被多平台割裂、规则僵化、误触发这些问题折磨或者手头正好有一台长期在线的私有云/NAS想利用起来这篇文章应该能给你完整可落地的参考。1. 先从最痛的体验说起写死的联动规则为什么会失灵1.1 一个真实翻车场景客厅灯光与“观影模式”打架讲个我家真实发生过的场景。客厅装了人体传感器和光照传感器原始规则很简单光照低于某个值且检测到有人就开灯。听起来没问题对吧但晚上一家人坐在沙发上看电影的时候屏幕亮光会让人体传感器周期性触发加上窗帘拉上后光照传感器读数掉到阈值以下客厅灯就被反复点亮。我设置过“观影模式”可观影模式本身也是一条规则一旦客厅灯被点亮观影模式就必须再写一条“检测到灯开了就关掉”的反制规则。最后两个规则互相竞争灯一会被点亮一会被熄灭。这就是典型的“单点条件触发”问题。大多数平台的自动化规则是事件驱动传感器上报一个“有人”事件就去执行开灯动作。可真实居家场景里“有人”这个状态是连续的、会变化、有噪声的它必须结合时间、光照、房间内其他传感器数据、甚至当前其他设备状态一起判断才能得出“现在该不该开灯”的结论。单点触发天生做不到这件事。1.2 Miloco不是又一个App而是自动化决策的“中枢”这也是我后来愿意在私有云上折腾Miloco的原因。Miloco的思路和那些App里做“条件—动作”联动的逻辑不一样它先维护一套“当前家居状态”的实时模型比如人在哪个房间、房间里有没有持续活动、光照处于什么水平、当前处于什么时序模式白天/夜间/睡眠然后自动化规则不再直接响应“传感器事件”而是响应“状态变化”。用人话说普通联动回答的是“发生了什么”Miloco回答的是“现在是什么状态因此应该做什么”。传感器事件进来之后先进入Miloco的统一状态模型里更新状态状态变化满足条件后再触发动作。这样“看电影时灯被点亮”这种问题就很好解决只要判断到客厅处于“观影模式”这个状态亮度自动开灯这条规则就会被抑制不需要再写一条反制规则。我选择本地部署而不是依赖各平台云端的另一个原因是家里自动化的执行链路如果全部拉到云端每次决策都要经过云服务器中转延迟高不说一旦断网或者平台服务波动整个家的自动化就瘫痪了。Miloco跑在私有云上传感器数据进入局域网内决策引擎动作指令也从局域网内发出外部网络断开时核心自动化依然能跑。2. 部署“这台私有云”之前我做了哪些硬件与系统准备2.1 为什么坚持本地闭环而不是云端定时刚开始我考虑过直接用某个智能家居平台自带的自动化功能毕竟最省事。但用了一个月问题就暴露了第一规则能力上限低复杂条件要么写不了要么只能通过大量叠加规则变相实现第二所有自动化依赖云端平台服务一波动家里的灯就“智力退化”第三隐私问题全屋传感器数据上传到平台云端这件事我始终不太舒服。本地闭环意味着所有传感器数据在局域网内完成汇聚、判断和控制指令下发。隐私上家里哪些时段有人活动、夜间几点起床这类数据只存在于自己的设备里。稳定性上断网不影响自动化运行。延迟上局域网内指令一般几十毫秒就能到达设备比云端链路快一个量级。2.2 设备底盘梳理清单从传感层到执行层部署之前先把家里的设备盘了一遍Miloco本身不直接和物理设备通信它依赖已有的智能家居平台或网关来做设备接入。所以要先理清哪些设备可以暴露本地接口哪些只能通过云端控制哪些设备有状态上报哪些只有控制能力没有反馈。我的设备底盘大概是这样的传感层人体存在传感器多个房间、门窗磁、温湿度、光照、水浸、燃气报警网关层各厂商的局域网网关、部分设备自带Hub执行层智能灯、开关面板、窗帘电机、空调红外控制器、空气净化器、加湿器设备梳理这一步很关键因为Miloco做“状态决策”的前提是感知层数据足够可靠、足够丰富。如果只有一个传感器状态模型再先进也白搭。我的建议是至少保证目标房间有一路“存在检测”加一路“环境检测”比如人体传感器温湿度这样状态模型才有两个维度可以参考。2.3 私有云选型时的三条硬性标准Miloco本质上是一个需要长期在线运行的服务选私有云设备时我定了三条硬性标准。第一是低功耗常驻我不会为了跑这套自动化专门养一台高功耗的服务器理想是整机功耗控制在较低水平日常24小时开着不心疼电费。第二是必须支持Docker容器Miloco以容器方式分发和更新如果设备不支持容器部署会很麻烦市面上常见的NAS和私有云设备基本都满足这一点。第三是存储和日志要可靠自动化引擎跑久了配置文件、状态快照、日志都会持续增长需要有稳定的磁盘和简单的备份恢复手段。手头这台私有云是ARM架构的四盘位机型8GB内存跑Miloco容器之外还同时跑着下载服务和备份任务。选型的时候也考虑过用一台小主机加开源NAS系统但最后选择私有云设备是因为它对家庭用户更友好系统维护成本低统磁盘管理和备份方案都是现成的不适合在这种基础设置上浪费太多时间。3. Miloco部署实操容器编排、目录结构、启动检查3.1 用Docker Compose拉起一个最小可用实例Miloco的官方镜像很小部署起来比我想象中简单。我先建立了一个工作目录用来放配置文件、数据文件和日志再用docker-compose.yml定义服务。services: miloco: image: miloco/miloco:latest container_name: miloco restart: unless-stopped ports: - 8080:8080 volumes: - ./config:/app/config - ./data:/app/data - ./logs:/app/logs environment: TZ: Asia/Shanghai MILOCO_STORAGE: sqlite MILOCO_LOG_LEVEL: info几个关键点说明一下。restart: unless-stopped保证设备重启后容器自动拉起来这是全屋自动化最基础的要求——不能人不在家重启了设备结果回家发现灯都不会亮。volume挂载的config、data、logs三个目录分别对应配置、状态数据库、日志这三个目录必须放在宿主机持久化存储上否则容器升级或重建后所有配置和自动化状态全部丢失。TZ: Asia/Shanghai时区必须设置对Miloco所有时间窗口判断都依赖本地时区比如“日落前不开灯”这种规则时区错了一切都乱。存储引擎选了sqlite对家庭规模这套自动化完全够用。3.2 接入设备源先从“状态上报”而不是“控制接口”开始Miloco支持接多种设备源但我强烈建议从状态上报类接口开始而不是控制类接口。原因很简单自动化的第一步是感知第二步才是控制。先把传感器的数据流跑通让Miloco能实时看到每个传感器的当前值之后写规则才有数据基础。控制接口可以逐步接比如先接灯的开关再接窗帘电机。当时我先接入的是两路人体存在传感器和一路温湿度传感器。Miloco的配置目录下有个device_sources.yaml里面定义了设备源的适配器类型、连接参数和实体映射关系。我用的是局域网直连方式不经过厂商云端这样传感器状态每几秒就能上报一次而不是依赖云端的推送延迟。device_sources: - name: living_room_sensors type: local_gateway host: 192.168.1.100 port: 8899 entities: - entity_id: sensor.living_room_presence device_type: presence - entity_id: sensor.living_room_temp device_type: temperature配置完成后Miloco会为每个实体生成一个标准化的entity_id后续所有规则直接用这个id引用。这一步相当于给全屋设备建立了一套“统一语言”——不管底层是什么厂商的设备在Miloco里都变成了一组标准状态。3.3 第一版规则卫生间人来灯亮、人走延时关灯跑通传感器接入之后我写的第一个正式规则是卫生间的灯光自动化。之所以选卫生间是因为它场景足够简单、状态边界清晰非常适合验证自动化是否可靠。规则用YAML写在automations目录下。我把它命名为bathroom_light核心逻辑做了两个关键设计一个是“持续时间过滤”人体传感器从无人变有人后要持续有人在超过2秒才判定为有人避免传感器瞬时抖动造成误触发另一个是“自动关闭延时”有人时开灯并启动一个3分钟延时定时器持续检测到有人就不断重置定时器直到无人超过3分钟才关灯。automations: bathroom_light: enabled: true trigger: type: state entity: sensor.bathroom_presence to: present for: 2s actions: - service: light.turn_on target: light.bathroom - service: timer.start entity: timer.bathroom_auto_off duration: 3m这里有个重要的设计思路我把开灯和关灯拆成了两条独立规则而不是一条规则里同时写开和关。开灯规则由“有人”状态变化触发关灯规则由定时器到期触发。这样做的好处是两个动作的触发条件完全独立未来如果要调整“有人时保持长亮”或“夜间降低亮度”只改其中一条规则就行互不牵连。3.4 验证自动化是否生效的检查清单规则上线后不要急着加新规则先花一两天验证这套最基本的自动化。我的验证清单是这样的事件日志里能看到传感器状态变化和规则触发记录确认规则确实被触发手动开灯后离开房间确认延时关灯能兜底不会出现灯一直亮着的情况白天和夜间分别测试确认光照条件没有影响这个场景人为在传感器附近停留但不动确认“持续存在”状态能维持不会误关灯这个阶段也是观察Miloco事件日志的最好时机。日志里能看到每条规则的完整判断链路传感器上报、状态更新、条件检查、动作执行哪一步出了问题都能定位。我在日志里发现的第一件事就是最初的人体传感器上报频率过低导致“for: 2s”的持续判定经常因为上报间隔而失效后来把上报频率调高才稳定。4. AI到底在Miloco里做了什么五个落地的决策模型4.1 多传感器置信度聚合两路存在感比一路可靠先把Miloco里“AI”这件事说清楚不是搞一个模型包打天下而是每个具体场景用一个轻量决策方法解决一个具体问题。第一个落地点是传感器置信度聚合。单个人体传感器的误触发概率其实不低尤其是家里有宠物、窗帘飘动、阳光变化都会造成误判。Miloco可以同时接入多路数据做交叉验证。比如卫生间的存在判断我接了人体传感器、门窗磁和湿度传感器三个维度人体传感器上报“有人”但湿度没有变化、门磁状态也没有变化那这个“有人”置信度就不高反过来如果人体传感器和门磁同时确认有人进入湿度还在短时间内明显上升那基本可以确定卫生间真的有持续活动。实现上不需要什么复杂模型就是一个简单的加权计分。Miloco有个内置的aggregate实体类型可以配置每个输入源的权重和有效条件。我的卫生间配置是这样人体传感器权重0.5门磁状态权重0.3湿度变化率权重0.2总分超过0.6才算“有人存在”。实践下来误触发率从单传感器的平均一天两三次降到了基本没有尤其是洗澡时水蒸气导致人体传感器频繁误报的问题被彻底解决了。4.2 睡眠状态估计夜间活动窗口判定何时进入睡眠第二个落地场景是睡眠状态估计。做自动化的都知道“睡眠模式”是刚需但怎么判断“已经睡了”是个难点。最简单的方案是定一个固定时间比如晚上十一点强制进入睡眠模式但休息日、加班晚归的时候固定时间就很蠢。Miloco的做法是基于活动窗口所有房间的传感器如果连续一段时间没有检测到人活动就判定家庭成员可能已经入睡。这个“连续一段时间”不是写死的而是用一个滑动窗口统计——如果过去二十分钟内活动次数低于某个阈值就认为进入睡眠状态。一旦进入睡眠状态夜间灯光自动化的触发条件会自动加上“亮度压低延时缩短”的规则空调温度曲线也会切到睡眠曲线。这个模型虽然简单但效果出乎意料地好。它不会因为某一次起夜活动就退出睡眠状态而是要求一段时间内活动达到一定频率才会切换状态。我实测下来凌晨去次卫生间这种短活动不会打断睡眠模式但周末早上九十点高频活动后系统会自动切回日间模式。判断逻辑维护在Miloco的state_estimators配置里本质上是一个带遗忘因子的活动计数不需要每天去改时间表。4.3 离家/回家场景的多条件确认避免误锁门误断电离家回家场景是最容易误触发的自动化因为门磁传感器一开一关就能模拟一次出入但取快递、丢垃圾都会造成门磁变化。如果只靠门磁判断离家就会出现人还在门口换鞋家里已经执行了全屋断电的尴尬情况。Miloco处理离家场景用了多条件加权确认门磁状态变化是第一条件室内所有传感器在门磁变化后持续无活动是第二条件手机Wi-Fi从家里的路由器断开是第三条件。三个条件同时满足才判定真正离家然后才执行关闭灯光、关闭非必要设备、布防安防系统这些动作。回家场景的判断逻辑类似但权重分配不同门磁打开后室内传感器在短时间内出现活动或者手机Wi-Fi重新加入都会快速确认“有人回家”。Miloco里有一个专门的decision_models配置区可以定义这类组合判断。这一块是我觉得最有价值的AI应用场景因为它把“多路信号交叉验证”变成了实际减少误操作的能力。4.4 跨平台设备冲突时的优先级裁决设备多了之后不同自动化指令之间会冲突。比如客厅空调的温度传感器报告温度偏高触发制冷但卧室的睡眠模式又希望全屋温度稍高一些。两个场景都想要控制空调到底听谁的Miloco的解决方案是给每条自动化设置优先级并且支持“状态互斥”。在观影模式下客厅的亮度自动化和窗帘自动化都会被设置为suppressed状态不会执行。在睡眠模式下除了夜灯和安防相关规则其他规则全部降权或暂停。优先级裁决本质上不是AI模型但它解决的是多目标冲突问题而Miloco把它做成了规则引擎的一等公民每个实体在当前状态下都会有明确的信任等级。我一开始并没有设置优先级结果出现了窗帘电机和空调联动“互相打架”的情况——空调制冷触发后温度快速下降又触发了窗帘关闭减少阳光的规则但窗帘一关房间变亮光照传感器测出亮度不足又触发了开灯规则。三条规则同时执行场面一度很混乱。后来给各条自动化设了明确的优先级别又在观影模式和睡眠模式下声明互斥实体才彻底解决。4.5 异常状态提醒不靠阈值靠“持续观察”漏水、燃气泄漏、长时间无人这些异常场景传统做法是传感器触发就告警但误报率高。水浸传感器偶尔被溅湿、燃气传感器因为湿度变化波动都会造成半夜被手机轰炸。Miloco的做法是异常不靠瞬时阈值而是“持续观察”水浸传感器状态为“湿”且持续时间超过30秒才告警燃气浓度超过阈值且连续保持3分钟才推送。对有持续性特征的异常事件这个策略完美过滤了瞬时误报对真正需要急响应的场景比如燃气浓度异常高可以用更短的持续时间窗口但依然保留至少几秒的确认。这个模型唯一的代价是告警有延迟对急性安全事件不友好。我的做法是区分两级一级告警用短确认窗口比如3秒二级告警用长确认窗口比如1分钟。短窗口处理真正的安全风险长窗口处理水管渗漏这类慢性问题。所有告警都会附带状态证据推送到手机的时候能看到触发依据避免了“报警了但不知道为什么”的困惑。5. 把居家场景写成状态机规则配置里最容易犯的三个错误5.1 直接堆if-else的后果很多人在配置自动化时的第一反应就是把现实逻辑翻译成条件如果A发生就做B。这个思路在场景简单的时候没问题但场景一复杂就会变成if-else堆砌。一条规则里塞十几个条件任何一个条件波动就会导致整个判断失效调试起来头都大了。Miloco的规则模型更接近有限状态机每个场景是一组状态场景内自动化根据实体状态变化在状态之间迁移。不是“厨房有人就开灯”这种单条规则而是“厨房空置态—厨房使用态—厨房保持态”这样清晰的状态流转。配置方式是声明目标状态而不是声明动作条件。刚开始接触这套思路确实不太适应但真的改换过来之后规则的可维护性提升非常明显。5.2 三个特别容易犯的配置错误第一个错误是忽略状态保持。人体传感器从“有人”变成“无人”之后如果后续传感器因电量低暂停上报状态会停在“有人”导致灯一直亮着。需要在规则里加上状态超时保护让“无人”状态在持续一段时间后自动确认。第二个错误是条件顺序不对。Miloco的判断顺序是trigger先触发然后检查condition最后执行action。很多人会把“太阳落山后”这类条件放在trigger里写成“太阳落山时触发出门灯开启”这会让同一时间窗口内其他非相关事件也被卷进来。正确做法是保持trigger是纯粹的状态变化事件所有时间、环境的附加判断都放到condition里。第三个错误是不考虑场景互斥。睡眠模式和起夜模式本质上对光照的需求冲突如果没有声明互斥起夜的灯光可能会触发睡眠模式的“全屋灯光关闭”形成逻辑矛盾。在配置里明确哪个场景优先、哪个场景会抑制其他场景是避免这类问题的最基本手段。5.3 事件节流一次误触发引发的“全家联动风暴”有个晚上我经历了一次“全家联动风暴”厨房的人体传感器误报了一次有人然后厨房灯亮、客厅灯亮、空气净化器开机、背景音乐播放全家都被唤醒了。根因是那条厨房规则触发了之后由于光照条件忽然变化又带动了其他几条自动化执行形成链式反应。Miloco的解决方法是事件节流。两条机制第一是最小间隔时间同一自动化在设定时间内不能重复执行第二是动作合并短时间内对同一设备的多条指令会被合并成一条避免没必要的重复控制。我把厨房灯、客厅灯这些高频自动化的最小间隔时间设成了60秒效果立竿见影——即使传感器出现偶发抖动也不至于每一次抖动都触发全屋灯光变化。这个“全家联动风暴”也让我意识到一个道理自动化规则写到一定数量真正重要的不是新增功能而是控制联动爆炸。Miloco的事件日志里会显示每条规则执行带来的后续变化通过观察这些日志可以很清楚地看到哪些动作对整体状态产生了连锁影响然后针对性地设节流和抑制。6. 跑了一个多月之后的调优清单与避坑建议6.1 传感器掉线后状态卡死怎么办自动化跑久了最头疼的不是逻辑写错而是传感器本身出问题。有一个深夜卫生间的存在传感器意外掉线状态一直停留在“有人”导致整个晚上卫生间的灯一直亮着。Miloco的做法是给传感器状态加“心跳监控”和“状态超时”。在实体配置里设置一个heartbeat_timeout超过这个时间没有收到心跳上报实体状态自动变为unknown。同时给自动化规则设置unknown状态的处理策略unknown时既不当作有人也不当作无人而是直接跳过该自动化保留当前设备状态不变。这样即使传感器掉线灯也会保持原有状态不会执行错误动作。这个调优是从那次“整晚亮灯”中学到的教训。现在我的所有核心存在传感器都有心跳监控状态超时设置成传感器上报间隔的三倍左右。掉线不再直接造成错误状态而是会触发一个“传感器离线”的通知提醒我可以及时去检查传感器而不是等发现问题的时候已经被错误联动折腾了一晚上。6.2 手动干预和自动化自动覆盖的优先级问题这是很多人都会遇到的问题你手动把客厅灯调到一个亮度希望保持这个状态但自动化规则因为某种条件变化又被触发马上覆盖了你的手动操作。Miloco建议的模式是给每条自动化声明mode分别是auto、manual和hybrid。hybrid模式会记录最近一次设备状态变化是手动还是自动化引起的如果是手动引起则在指定时间内暂停该设备上的所有自动化等待手动操作状态被用户明确清除。这个设计非常实用。我还在Miloco配置里专门做了一个manual_override实体手动操作一次就会设为true持续几小时期间相关自动化全部跳过避免刚调好又被自动化覆盖。现在家里装修调节、临时场景切换都用这个机制自动化不会在你想手动控制的时候捣乱。6.3 性能与日志这套引擎到底吃多少资源跑了一个多月给关注性能的朋友一个真实参考。Miloco容器在私有云上稳定运行内存占用大概在350MB左右CPU平时基本是零只有规则触发时会有短暂波动。sqlite存储文件一个月下来大概几十MB日志每天几MB对磁盘几乎没压力。整套系统对私有云的性能影响完全可以忽略。日志这块建议开启日志轮转否则日志文件会随着规则数量和触发频率增长。私有云有自带的docker日志大小限制最好配置上限制单个日志文件在100MB以内保留最近五个文件。我曾经因为日志没配置轮转一周日志涨到了近1GB虽然不影响运行但清理起来很烦。6.4 想入坑的人我给三条朴实建议第一条从小场景开始。不要一开始就想做全屋一键离家模式先把一个房间、一个设备、一个传感器从“手动控制”变成“自动控制”跑习惯了再扩展。第二条维护事件日志习惯。Miloco最值钱的不是规则引擎本身而是它能记录每一次状态变化和判断链路。每周花十分钟翻一遍日志你会发现自己家庭里很多隐藏的设备使用习惯这些才是调优自动化的真正依据。第三条永远保留手动入口。自动化的目标不是取代手动控制而是减少手动控制。我家里每个执行器都保留了物理开关或者场景面板入口万一自动化出了什么问题随手一按就能恢复手动控制这种安全感比任何“智能”都重要。7. 一些还没解决但值得继续折腾的方向部署Miloco到现在主要痛点已经解决但有几个方向我还在继续琢磨。一是语音识别的本地化。现在回家场景的语音指令还需要依赖外部语音平台数据绕了一圈出去再回来。如果能把语音识别也完全本地化整个自动化链路的数据就彻底不离开局域网了延迟和隐私都会有质的提升。二是多家庭成员的状态画像。目前Miloco能判断家里“有人没人”和“大概在哪个房间”但区分不了具体是谁。不同的人对温度、亮度的偏好差异很大如果能把家庭成员的身份识别做到可靠全屋自动化的个性化程度会高很多。三是从“人走灯灭”到“行为预测”。现在的自动化本质还是“响应状态变化”下一步我想尝试用历史数据预测接下来的行为模式比如根据工作日和休息日的活动规律提前调整空调温度和热水器状态。Miloco的传感器数据和事件日志已经积累了一个多月理论上这些数据已经足够支撑轻量级的预测模型训练了。这个内容后续的扩展空间确实挺大。说回最开始的问题全屋智能自动化真正值得做的不是让所有设备都服从指令而是让它们在你需要的时候刚好在做对的事。Miloco让我的注意力从“写规则控制设备”转移到了“理解家里的真实状态”这一点是我这一年折腾下来最核心的收获。