1. 从“十八个实体”说起为什么实体是 Home Assistant 的灵魂刚接触 Home Assistant 的人十有八九会被“实体”这个词绕晕。你打开配置文件看到的是light.yeelight_ceiling、sensor.temperature_living_room、switch.sonoff_basic这类东西它们统称为实体。而“十八 Home Assistant 实体”这个说法通常指的是一个入门级的练手项目——用十八个左右的实体把家里最核心的设备接入进来跑通自动化形成一个最小可用的智能家居系统。为什么是十八个这不是随便定的数字。一个普通两居室如果把灯光、插座、温湿度、门窗、人体感应、遥控器这些基础设备都算上差不多就是十五到二十个实体的量级。少于这个数自动化玩不出花样多于这个数新手容易在命名和分组上翻车。所以“十八”更像是一个经验值代表“够用且不失控”的临界点。这篇文章适合两类人一类是刚装好 Home Assistant、手里有一堆设备但不知道怎么组织的入门玩家另一类是已经跑了一段时间但实体越加越乱、自动化越写越糊涂的中级用户。我会从实体的本质讲起把命名、分组、属性、状态、自动化联动这些事拆开揉碎最后给出一套可以直接抄的十八实体落地方案。全程不扯虚的都是我在实际部署中踩过坑之后总结出来的做法。先明确一个核心认知实体不是设备实体是设备在 Home Assistant 里的一个功能切面。一个温湿度传感器在 HA 里至少会暴露两个实体——一个温度实体、一个湿度实体可能还有一个电量实体。一个智能灯可能同时有开关实体、亮度实体、色温实体。所以“十八个实体”不等于“十八个设备”这一点如果一开始没搞明白后面做分组和自动化时会非常痛苦。2. 实体、属性、状态三个概念理不清后面全白搭2.1 实体 ID 的命名逻辑与常见误区实体 ID 是 Home Assistant 里唯一标识一个实体的字符串格式是domain.object_id。domain 是领域比如light、switch、sensor、binary_sensor、climate、media_player等object_id 是你自己起的名字。很多人图省事接入设备后直接用系统自动生成的 ID比如switch.sonoff_1000a1b2c3结果过两个月自己都不知道这是哪个开关。我的做法是接入设备的第一件事就是改实体 ID改成“位置_设备_功能”的格式。比如客厅的 Yeelight 吸顶灯ID 改成light.living_room_ceiling主卧的温湿度传感器温度实体改成sensor.bedroom_temperature湿度改成sensor.bedroom_humidity。这样在写自动化时看到 ID 就知道是什么不用再去翻设备列表。这里有个坑要提醒改实体 ID 会断开已有的自动化和仪表盘引用。所以正确的顺序是——先接入所有设备、改好 ID、确认无误再去写自动化和做仪表盘。如果你已经写好了自动化再改 IDHA 不会自动帮你更新引用你得手动去automations.yaml里一个个改非常容易漏。2.2 状态与属性的区别以及什么时候该用哪个实体有两个核心数据状态state和属性attributes。状态是一个单一的值比如灯的on或off温度传感器的23.5人体传感器的on或off。属性是一个字典挂载在实体上比如灯的brightness、color_temp、rgb_color气候实体的current_temperature、hvac_action。写自动化时触发条件用状态条件判断和模板里经常要用属性。举个例子你想让灯在亮度低于 50 时自动调亮触发不能用状态因为状态还是on没变得用属性触发或者模板触发。再比如你想判断空调是不是在制冷不能看状态状态是cool还是heat取决于模式得看hvac_action属性是不是cooling。提示在开发者工具里可以实时查看任意实体的状态和属性调试自动化之前先在这里确认数据是否符合预期能省掉大量猜测时间。2.3 实体注册表与设备注册表的联动关系Home Assistant 从 2021 版本开始引入了设备注册表和实体注册表。设备注册表记录物理设备的信息厂商、型号、固件版本实体注册表记录实体与设备的归属关系。一个设备可以关联多个实体一个实体也可以不归属任何设备比如手动创建的模板实体。这个机制带来的好处是当你在集成里删除一个设备时它关联的所有实体会一起被清理不会留下孤儿实体。但坏处是如果你手动改了实体 ID然后又重新接入设备可能会出现重复实体。我的经验是每次批量接入设备后去“设置 → 设备与服务 → 实体”里按“最近添加”排序检查一遍有没有重复或命名混乱的实体及时清理。3. 十八个实体的选型与分组一套可直接复用的最小系统3.1 哪些设备值得优先接入不是所有能接入的设备都值得接入。我的原则是只接入能参与自动化的设备。一个不能触发自动化、也不能被自动化控制的设备接进来只是增加噪音。按照这个原则十八个实体的选型如下类别实体示例数量接入理由灯光light.living_room_ceiling、light.bedroom_lamp4自动化调光、离家关灯开关/插座switch.tv_power、switch.fan3远程断电、定时控制温湿度sensor.living_room_temperature、sensor.living_room_humidity4联动空调、加湿器人体感应binary_sensor.hallway_motion、binary_sensor.bathroom_motion2人来灯亮、人走灯灭门窗binary_sensor.front_door、binary_sensor.balcony_door2安防提醒、空调联动遥控/按钮sensor.remote_action1场景切换气候climate.living_room_ac1温控自动化媒体media_player.living_room_tv1观影场景联动这十八个实体覆盖了“感知—决策—执行”的完整链路温湿度和人体感应负责感知自动化负责决策灯光、开关、空调、媒体负责执行。门窗传感器既是感知也是安防。遥控器是手动干预的入口。3.2 用区域和分组把实体管起来十八个实体如果平铺在仪表盘上找起来很费劲。Home Assistant 提供了“区域Area”和“分组Group”两种组织方式。区域是物理空间的抽象比如客厅、主卧、厨房分组是逻辑集合比如“所有灯”“所有窗户”“所有温湿度”。我的做法是区域按房间分分组按功能分。区域在设备接入时就指定好分组在configuration.yaml里用group域手动定义。比如group: all_lights: name: 所有灯光 entities: - light.living_room_ceiling - light.living_room_floor - light.bedroom_lamp - light.bathroom_light all_windows: name: 所有窗户 entities: - binary_sensor.front_door - binary_sensor.balcony_door分组的好处是在自动化里可以一次性控制一组实体不用逐个列举。比如“离家模式”关所有灯直接调用group.all_lights就行。但要注意分组的状态是聚合状态——只要组里有一个灯是on组状态就是on。这个特性在做“是否有灯未关”的判断时非常有用。3.3 实体命名规范一套用了就回不去的规则我见过太多人把实体命名成switch.1、sensor.temp1、light.abc过一个月自己都看不懂。我的命名规则是位置在前功能在后light.living_room_ceiling而不是light.ceiling_living_room用下划线分隔全小写HA 的实体 ID 只允许小写字母、数字和下划线避免缩写temperature不要写成temphumidity不要写成hum同类设备加序号如果有两个客厅灯用light.living_room_ceiling_1和light.living_room_ceiling_2这套规则看起来啰嗦但在写自动化和模板时你会发现命名一致性带来的效率提升是巨大的。尤其是用模板批量处理实体时统一的命名模式可以让你的模板代码复用率提高好几倍。4. 从实体到自动化让十八个实体真正活起来4.1 人体感应联动灯光的完整配置与避坑人体感应联动灯光是最经典的自动化场景但也是最容易翻车的。常见问题有三个触发太频繁、关灯太早、白天也亮灯。我的解决方案是automation: - alias: 走廊人来灯亮 trigger: - platform: state entity_id: binary_sensor.hallway_motion to: on condition: - condition: numeric_state entity_id: sensor.living_room_lux below: 50 action: - service: light.turn_on target: entity_id: light.hallway data: brightness_pct: 80 - alias: 走廊人走灯灭 trigger: - platform: state entity_id: binary_sensor.hallway_motion to: off for: minutes: 2 action: - service: light.turn_off target: entity_id: light.hallway这里的关键点是for: minutes: 2——人走之后等两分钟再关灯避免你只是路过一下灯就灭了。另外加了光照条件白天光照充足时不触发。如果你的人体传感器是电池供电的还要注意它的off延迟可能本身就有几十秒实际关灯时间要相应调整。注意不同品牌的人体传感器上报频率不同有的只在状态变化时上报有的会定期上报。如果你的传感器不支持for条件可以用timer辅助元素来实现延迟关灯。4.2 温湿度联动空调与加湿器的逻辑设计温湿度联动空调的核心是回差控制不是简单的“高于 28 度开空调”。如果只用单点触发空调会频繁启停。我的做法是温度高于 28 度且空调关闭 → 开制冷温度低于 25 度且空调开启 → 关空调湿度低于 40% 且加湿器关闭 → 开加湿器湿度高于 55% 且加湿器开启 → 关加湿器这个 3 度的回差和 15% 的湿度回差是我实测下来比较舒服的区间。回差太小设备频繁启停回差太大体感波动明显。当然这个值因人而异你可以根据自己的体感调整。另外空调联动一定要加门窗条件——窗户开着的时候不要开空调。这就是门窗传感器派上用场的地方condition: - condition: state entity_id: binary_sensor.balcony_door state: off4.3 离家与回家模式的实体编排离家模式是十八个实体协同工作的典型场景。触发方式可以是手动按钮、手机定位、或者遥控器。执行动作包括关所有灯、关空调、关电视插座、开启安防监控。automation: - alias: 离家模式 trigger: - platform: state entity_id: sensor.remote_action to: leave_home action: - service: light.turn_off target: entity_id: group.all_lights - service: climate.turn_off target: entity_id: climate.living_room_ac - service: switch.turn_off target: entity_id: switch.tv_power - service: notify.mobile_app data: message: 离家模式已执行回家模式则相反但要注意不要一回家就全开灯那样太刺眼。我的做法是回家只开玄关灯和客厅灯亮度 50%其他灯保持关闭。等人体传感器检测到有人进入某个房间再开那个房间的灯。4.4 用模板实体把多个传感器合成一个“虚拟实体”十八个实体里温湿度是分开的但有时候你需要一个“舒适度”实体来综合判断。这时候可以用模板传感器template: - sensor: - name: 客厅舒适度 unit_of_measurement: % state: {% set temp states(sensor.living_room_temperature) | float %} {% set hum states(sensor.living_room_humidity) | float %} {% if temp 18 or temp 28 or hum 30 or hum 70 %} 不舒适 {% elif temp 20 or temp 26 or hum 40 or hum 60 %} 一般 {% else %} 舒适 {% endif %}这个虚拟实体不增加物理设备但让自动化条件更简洁。你可以直接在自动化里判断sensor.living_room_comfort的状态而不用每次都写一堆模板。5. 实体管理中的那些坑我踩过的五个典型问题5.1 实体 ID 冲突与重复注册最常见的问题同一个设备通过不同集成接入产生了重复实体。比如一个 Zigbee 灯既通过 Zigbee2MQTT 接入又通过厂商云集成接入结果出现两个light.xxx。解决办法是只保留一个集成在“设备与服务”里禁用或删除多余的集成。如果已经产生了重复实体去实体注册表里删除不需要的那个。另一个坑是手动在configuration.yaml里定义的实体和集成自动生成的实体 ID 冲突。HA 会在启动时报错但错误信息不一定直观。我的经验是手动定义的实体统一加前缀比如sensor.manual_xxx避免和自动生成的冲突。5.2 实体不可用Unavailable的排查链路实体显示unavailable是家常便饭排查顺序应该是检查设备是否在线——Zigbee/WiFi 设备可能掉线了检查集成是否正常加载——去“设备与服务”看集成状态检查 MQTT 连接——如果是 MQTT 设备看 MQTT broker 是否正常检查实体是否被禁用——实体注册表里可能被手动禁用了检查 HA 日志——home-assistant.log里通常有具体错误我遇到最多的情况是 Zigbee 设备掉线尤其是电池供电的传感器。解决办法是增加 Zigbee 路由设备比如常供电的插座增强网络覆盖。5.3 状态刷新延迟与轮询间隔有些集成是轮询方式获取数据的比如某些云平台集成。默认轮询间隔可能是 30 秒甚至更长导致状态更新不及时。如果这个实体参与自动化延迟就会影响体验。解决办法是在集成配置里调整轮询间隔或者改用本地推送方式的集成。对于本地设备比如 ESPHome状态是实时推送的基本没有延迟。所以如果条件允许优先选择本地推送的集成而不是云平台轮询。5.4 实体属性丢失与单位换算有些传感器上报的是华氏度但你想用摄氏度有些上报的是帕斯卡但你想用百帕。这时候需要在集成或模板里做单位换算。HA 支持在实体级别设置单位但换算逻辑要自己写。比如template: - sensor: - name: 客厅温度摄氏 unit_of_measurement: °C state: {{ (states(sensor.living_room_temperature_f) | float - 32) * 5 / 9 | round(1) }}注意round(1)保留一位小数避免显示一长串数字。5.5 实体历史数据与数据库膨胀HA 默认会记录所有实体的状态历史时间长了数据库会膨胀到几个 GB。解决办法是在recorder配置里排除不需要记录的实体recorder: exclude: entities: - sensor.living_room_temperature - sensor.living_room_humidity domains: - automation - script温湿度这类高频更新的实体如果不需要长期历史可以排除掉或者设置purge_keep_days缩短保留天数。我的设置是保留 10 天数据库稳定在 200MB 左右。6. 进阶让十八个实体支撑更复杂的场景6.1 用脚本Script封装多步操作自动化适合“触发—条件—动作”的线性逻辑但复杂场景往往需要多步操作和条件分支。这时候用脚本更合适。比如“观影模式”script: movie_mode: sequence: - service: light.turn_on target: entity_id: light.living_room_floor data: brightness_pct: 20 rgb_color: [255, 100, 0] - service: light.turn_off target: entity_id: light.living_room_ceiling - service: climate.set_temperature target: entity_id: climate.living_room_ac data: temperature: 25 - service: media_player.turn_on target: entity_id: media_player.living_room_tv脚本可以被自动化调用也可以被遥控器按钮直接触发。这样逻辑更清晰也更容易复用。6.2 用场景Scene保存实体状态快照场景和脚本的区别是场景是“状态快照”脚本是“动作序列”。场景适合保存一组实体的特定状态比如“阅读模式”就是客厅灯 80% 亮度、色温 4000K、其他灯关闭。定义好场景后一键激活即可。scene: - name: 阅读模式 entities: light.living_room_ceiling: state: on brightness_pct: 80 color_temp_kelvin: 4000 light.living_room_floor: state: off场景的好处是激活速度快而且可以在仪表盘上直接放按钮。缺点是状态是静态的不能根据条件动态调整。6.3 实体与仪表盘Lovelace 卡片选型建议十八个实体在仪表盘上怎么展示我的建议是灯光和开关用entities卡片或light卡片支持直接控制温湿度用gauge卡片或sensor卡片直观显示数值人体和门窗用binary_sensor卡片或glance卡片显示状态空调用thermostat卡片支持调温媒体用media-control卡片不要把所有实体都堆在一个视图里。按房间分视图每个视图放该房间的实体。再做一个“总览”视图放分组实体和关键传感器。这样既不会太乱又能快速找到需要的控制项。6.4 实体自动化中的条件优先级与互斥处理多个自动化同时触发同一个实体时会出现“打架”的情况。比如人体感应开灯同时定时关灯也触发了灯就会闪烁。解决办法是用条件互斥在关灯自动化里加条件判断人体传感器是否还是on在开灯自动化里加条件判断当前是否在“手动模式”。更优雅的方案是用input_boolean做一个“手动模式”开关。当用户手动操作灯光时打开这个开关自动化就跳过该灯的控制。等一段时间后自动关闭手动模式恢复自动化控制。automation: - alias: 手动模式超时重置 trigger: - platform: state entity_id: input_boolean.manual_mode to: on for: minutes: 30 action: - service: input_boolean.turn_off target: entity_id: input_boolean.manual_mode这个技巧在实际使用中非常实用避免了自动化和手动操作之间的冲突。7. 关于实体管理我最后想分享的几条经验十八个实体只是一个起点。当你跑通这套最小系统之后会自然而然地想接入更多设备、写更复杂的自动化。但我的建议是每增加一个新实体先问自己三个问题——它能触发什么自动化它能被什么自动化控制它需要出现在仪表盘上吗如果三个问题都答不上来这个实体暂时不值得接入。另外实体 ID 一旦确定尽量不要改。如果非要改改完之后一定要全局搜索automations.yaml、scripts.yaml、scenes.yaml和 Lovelace 配置把所有引用都更新一遍。我吃过这个亏改了一个实体 ID结果三个自动化静默失效过了好几天才发现。最后定期备份configuration.yaml和.storage目录。实体注册表、设备注册表、区域和分组信息都存储在.storage里一旦损坏重建成本很高。我的做法是每次大改之前手动备份一次同时用 Git 做版本管理。这样即使改错了也能快速回滚。
