1. 从“十八个实体”说起Home Assistant 实体到底是什么刚接触 Home Assistant 的人十有八九会被“实体”这个词绕晕。你打开配置文件看到的是light.yeelight_ceiling、sensor.temperature_living_room、switch.wall_plug_1这样的东西官方文档管它们叫 Entity中文翻译过来就是“实体”。但问题是这个“实体”到底指什么是一个设备一个功能还是一个数据点我刚开始玩 HA 的时候以为一个设备就是一个实体。买了一个温湿度传感器觉得应该就是一个实体。结果接入之后发现它至少生成了三个实体温度、湿度、电池电量。后来我又以为一个实体就是一个开关结果一个 RGB 灯带能生成十几个实体——开关、亮度、颜色、色温、模式、场景……每个都是独立的实体。所以先把这件事说清楚在 Home Assistant 里实体是系统能操作和读取的最小逻辑单元。它不一定对应一个物理设备也不一定对应一个功能模块。一个实体代表的是一个“状态”加上一组“属性”以及可以对这个状态执行的操作。温度是一个实体灯的开关状态是一个实体窗帘的开合程度也是一个实体。它们各自独立存在各自有各自的 ID、状态、属性和可用服务。那“十八”这个数字是怎么来的其实它不是一个固定的标准而是很多人在搭建自己的 HA 环境时一个房间、一个区域或者一套设备组合下来刚好会涉及到的实体数量级。比如一个客厅灯光、窗帘、空调、电视、音箱、传感器加起来很容易就凑到十几个到二十个实体。这个数字本身不重要重要的是理解这十八个实体各自是什么类型、怎么组织、怎么联动、怎么排错。这篇文章就是围绕这个核心展开的。我会从实体的分类讲起然后拆解实体属性的结构再讲怎么在实际操作中管理这些实体最后分享一些我在配置过程中踩过的坑和总结出来的排查方法。不管你是刚装好 HA 准备接入第一个设备还是已经有一堆实体但管理得乱七八糟应该都能从里面找到有用的东西。2. 实体分类与核心属性拆解2.1 按功能划分的实体类型Home Assistant 的实体类型非常多官方文档列出来的 domain 就有几十种。但在实际使用中最常打交道的其实就那么几类。我按自己的使用频率排了个序顺便把每类的核心特点说一下。灯类实体light是最常见的。它的状态只有开和关但属性里会带亮度、颜色、色温、效果等信息。这里有个容易混淆的地方亮度在 HA 里的取值范围是 0 到 255但很多灯具厂商的 App 里用的是 0 到 100。你在配置自动化的时候如果直接拿百分比去填灯要么不亮要么直接满亮度。我一般会在模板里做一次换算或者直接用brightness_pct这个属性来写HA 会自动帮你转。开关类实体switch和灯很像但通常没有亮度、颜色这些属性。它就是一个纯粹的通断控制。不过要注意有些设备虽然物理上是个开关但接入 HA 之后可能被识别成light或者fan这取决于集成是怎么写的。遇到这种情况不用慌可以在自定义配置里手动改 domain或者干脆用模板实体包一层。传感器类实体sensor是数量最多、变化最频繁的。温度、湿度、光照、功率、电量、PM2.5、CO2……全都是 sensor。sensor 的状态是一个数值或者字符串属性里会带单位、测量时间、设备信息等。这里有个坑有些传感器的状态是unknown或者unavailable前者表示设备在线但读不到数据后者表示设备离线。在写自动化的时候一定要把这两种情况考虑进去不然很容易触发误操作。二元传感器binary_sensor只有两个状态on 和 off。门窗开合、人体移动、烟雾报警、漏水检测都是这一类。它的状态语义取决于设备类型比如门窗传感器 on 表示打开人体传感器 on 表示有人。写自动化的时候要特别注意这个语义别搞反了。气候类实体climate是空调、地暖、温控器这类设备的抽象。它的状态是当前模式制冷、制热、送风、自动等属性里带目标温度、当前温度、风速、摆风等。climate 实体的服务调用比较复杂不同厂商支持的功能差异很大配置的时候要仔细看集成文档。媒体播放器media_player是电视、音箱、投影仪这类设备。状态包括播放、暂停、空闲、关闭等属性里有音量、当前媒体、封面图等。这个类型的实体在自动化里很有用比如“电视打开时自动调暗灯光”就是靠 media_player 的状态来触发的。窗帘类实体cover控制窗帘、卷帘、车库门。状态有打开、关闭、打开中、关闭中属性里有当前位置0 到 100。有些 cover 只支持全开全关有些支持任意位置配置的时候要看设备能力。摄像头实体camera比较特殊它的状态通常是一个快照图片的 URL属性里有品牌、型号、支持的功能等。摄像头实体本身不存储录像它只是提供一个实时画面的入口。除了这些还有fan、vacuum、lock、scene、script、automation、input_boolean、input_number、input_select、input_text、timer、counter、person、device_tracker、weather、sun、zone等等。一个典型的智能家居环境里十八个实体可能覆盖了其中五六种类型每个类型都有自己的状态语义和属性结构。2.2 实体属性的三层结构很多人看 HA 的开发者工具只关注实体的状态state忽略了属性attributes。但真正做自动化的时候属性往往比状态更重要。我举个例子一个 climate 实体的状态是cool但你要判断它是不是在制冷光看状态不够还要看hvac_action这个属性它可能是cooling、idle或者fan。状态是cool只代表模式设定为制冷不代表压缩机正在工作。实体的属性大致可以分成三层第一层是身份属性包括friendly_name、device_class、icon、entity_id本身。这些属性决定了实体在界面上怎么显示以及在自动化里怎么被引用。device_class特别重要它会影响状态的显示格式和单位。比如同样是数值 25device_class: temperature会显示成 25°Cdevice_class: humidity会显示成 25%device_class: power会显示成 25W。如果你发现传感器的单位不对大概率是 device_class 没设对。第二层是状态属性包括unit_of_measurement、state_class、last_changed、last_updated。state_class决定了这个实体能不能被统计和图表化取值有measurement、total、total_increasing。如果你想把传感器的数据接入能源面板或者做长期统计这个属性必须设对否则 HA 不会记录历史数据。第三层是设备属性这部分因设备类型而异。灯的brightness、color_temp、rgb_color空调的current_temperature、target_temp_high、target_temp_low窗帘的current_position媒体播放器的volume_level、media_title都属于这一层。这些属性是写自动化时最常用的判断条件和动作参数。我自己的习惯是每接入一个新设备先去开发者工具里把它的所有实体和属性过一遍把关键的属性名记下来。这个习惯帮我省了很多调试时间因为很多问题不是出在自动化逻辑上而是出在属性名写错了或者属性根本不存在。2.3 实体 ID 的命名逻辑与规划实体 ID 是 HA 里引用实体的唯一标识格式是domain.object_id。比如light.living_room_ceiling、sensor.bedroom_temperature。domain 是实体类型object_id 是你自己起的名字。很多人一开始不在意命名设备接进来是什么就是什么结果实体多了之后完全分不清谁是谁。我见过最夸张的一个配置里面有十几个switch.smart_plug_1到switch.smart_plug_15根本不知道哪个插头接的是哪个电器。我的建议是在接入设备之前先想好一套命名规则。我自己的规则是这样的区域前缀living_room、bedroom、kitchen、bathroom设备类型ceiling_light、floor_lamp、curtain、ac功能后缀temperature、humidity、power、battery组合起来就是sensor.living_room_temperature、light.bedroom_ceiling_light、cover.kitchen_curtain。这样一眼就能看出实体属于哪个区域、是什么设备、是什么功能。如果设备已经接入了实体 ID 已经生成也可以在 HA 的界面上手动改。在实体列表里点进去右上角有个齿轮图标可以修改 entity_id。不过要注意改了之后所有引用这个实体的自动化、脚本、仪表盘都要跟着改不然会报错。所以最好是在接入之前就规划好避免后期返工。还有一个技巧是用 HA 的“区域”和“设备”功能来组织实体。在配置里给每个设备分配区域给每个实体关联设备这样在自动化的界面里可以按区域筛选实体不用在长长的列表里翻找。这个功能在实体数量超过二十个之后会变得非常有用。3. 实体管理实操从接入到联动3.1 设备接入与实体生成过程接入一个设备到 HA本质上就是让 HA 发现这个设备然后为它创建一个或多个实体。不同的接入方式实体的生成逻辑不一样。最常见的是通过集成Integration接入。比如你有一个支持局域网的灯具在 HA 的“设置 设备与服务”里添加对应的集成输入设备的地址或账号HA 就会自动发现设备并生成实体。这个过程通常是自动的你不需要手动写配置。但有时候集成会生成很多你不需要的实体比如一个灯带可能生成十几个实体其中大部分你根本用不到。这时候可以在实体设置里把它们禁用掉眼不见心不烦。另一种方式是通过配置文件手动定义。比如用template平台创建一个虚拟传感器或者用mqtt平台订阅一个主题。这种方式更灵活但需要你对 YAML 配置比较熟悉。我一般只在集成不支持或者需要自定义逻辑的时候才用这种方式。还有一种是通过configuration.yaml里的homeassistant部分自定义实体的显示名称和图标。这个不算创建实体只是修改已有实体的显示属性。不管用哪种方式接入之后都要做一件事去开发者工具里确认实体是否正常生成状态是否可读属性是否完整。我遇到过好几次集成显示“已连接”但实体状态一直是unavailable的情况。后来发现是设备固件版本太老集成不支持。这种问题只能通过升级固件或者换集成来解决。3.2 实体分组与区域划分十八个实体如果散落在仪表盘上找起来会很累。HA 提供了几种分组方式我按自己的使用体验说一下。区域Area是最粗粒度的分组。你可以把实体按房间划分比如客厅、卧室、厨房、卫生间。在自动化的界面里选择区域之后只会显示该区域下的实体大大缩小了选择范围。区域的配置在“设置 区域”里可以给每个区域设置图标和别名。设备Device是比区域更细的分组。一个设备可以关联多个实体比如一个温湿度传感器关联温度、湿度、电量三个实体。在设备页面里可以看到这个设备的所有实体以及设备的基本信息品牌、型号、固件版本。设备还可以分配到区域这样区域和设备就形成了两级结构。标签Label是 HA 后来加入的功能比区域和设备更灵活。你可以给实体打多个标签比如“照明”“需要监控”“高功耗”。然后可以在自动化里按标签筛选实体。这个功能在实体数量多、分类维度复杂的时候特别好用。分组Group是更传统的做法通过 YAML 配置把多个实体组合成一个组。组本身也是一个实体状态取决于组内实体的状态。比如把所有灯组成一个组组的状态是“任意一个灯亮”或者“所有灯都亮”取决于你选的组类型。组的好处是可以一次性控制多个实体比如一个服务调用把整个组的灯都关掉。我自己的做法是区域按房间分设备按物理设备分标签按功能分。比如客厅的吸顶灯区域是“客厅”设备是“吸顶灯”标签是“照明”“可调光”。这样不管从哪个维度找都能快速定位到它。3.3 自动化中引用实体的正确姿势写自动化的时候引用实体是最容易出错的地方。我见过很多新手直接复制实体 ID 到自动化里结果因为拼写错误或者实体 ID 变了导致自动化不触发。正确的做法是在自动化的界面编辑器里用实体选择器来选实体而不是手动输入。实体选择器会列出所有可用的实体并且会根据你选择的动作类型自动过滤。比如你选了一个“开灯”的动作选择器只会显示light类型的实体不会把sensor也列出来。如果你要写模板或者用 YAML 直接编辑那就要注意实体 ID 的格式。states(light.living_room_ceiling)是获取状态state_attr(light.living_room_ceiling, brightness)是获取属性。这两个函数在模板里用得最多一定要记熟。还有一个常见的坑是在自动化里引用实体时如果实体不存在或者不可用自动化会直接报错而不是跳过。所以在写自动化之前最好先用开发者工具的“模板”页面测试一下你的模板能不能正常返回结果。我一般会加一层判断比如{% if states(sensor.temperature) ! unavailable %}避免因为传感器离线导致自动化失败。另外HA 的自动化支持“触发条件”和“状态条件”两种判断方式。触发条件是自动化的入口状态条件是执行动作前的检查。很多人把两者搞混结果自动化要么不触发要么触发了但动作不执行。我的经验是触发条件用“状态变化”或者“数值变化”状态条件用“当前状态是否满足”。比如“温度超过 28 度时开空调”触发条件是温度传感器的数值变化状态条件是温度大于 28。3.4 实体状态的历史记录与统计HA 默认会记录实体的状态变化历史可以在“历史”面板里查看。但默认只保留十天左右而且不是所有实体都会被记录。如果你想让某个实体的数据长期保存需要做两件事一是设置state_class二是配置recorder和history集成。state_class有三个取值measurement表示瞬时测量值比如温度、湿度total表示累计值可以增加也可以减少比如净电量total_increasing表示只增不减的累计值比如总用电量、总用水量。设对了 state_classHA 才能正确地做统计和图表。recorder集成控制哪些实体被记录、记录多久。默认配置会记录所有实体的状态但只保留十天。如果你想把某些实体的数据保留更久可以在configuration.yaml里单独配置。比如recorder: purge_keep_days: 30 include: entities: - sensor.living_room_temperature - sensor.living_room_humidity - sensor.power_meter这样只有指定的实体被记录而且保留三十天。这样做的好处是数据库不会膨胀得太快查询速度也能保持。如果你想把数据导出到外部数据库或者做更复杂的分析可以接入 InfluxDB 或者 Prometheus。这两个我都用过InfluxDB 更适合做长期趋势分析Prometheus 更适合做监控告警。配置起来都不复杂但需要对各自的查询语言有一定了解。4. 常见问题与排查技巧实录4.1 实体状态异常排查速查表实体状态出问题是 HA 使用中最常见的情况。我把遇到过的问题整理成了一张表方便快速定位。现象可能原因排查方法解决方法状态显示unavailable设备离线、集成断开、网络问题检查设备是否通电、网络是否正常、集成是否显示已连接重启设备、重新加载集成、检查 IP 地址是否变化状态显示unknown设备在线但数据读取失败查看设备日志、检查集成配置重启集成、更新固件、检查设备权限状态不更新轮询间隔太长、设备上报频率低查看last_updated时间调整集成轮询间隔、检查设备上报设置属性缺失集成不支持该属性、设备固件版本低对比集成文档和设备能力升级固件、换用其他集成、用模板补充实体 ID 冲突多个设备生成了相同的 object_id在实体列表里搜索重复 ID手动修改 entity_id、禁用不需要的实体自动化不触发实体 ID 写错、状态条件不满足用开发者工具测试模板、查看自动化日志修正实体 ID、调整状态条件、加调试日志这张表里的每一行我都实际遇到过。最让我头疼的是unavailable和unknown的区分。一开始我以为这两个是一回事后来才发现unavailable是设备完全联系不上unknown是设备能联系上但读不到有效数据。排查方向完全不一样。4.2 实体 ID 变更后的连锁反应实体 ID 变更是一个很容易被忽视的问题。你在 HA 界面上改了一个实体的 ID看起来只是改了个名字但实际上所有引用这个实体的地方都会失效。自动化、脚本、仪表盘、模板传感器、甚至其他集成里的配置都可能因为这个变更而报错。我踩过一次坑把一个温度传感器的 ID 从sensor.temp_1改成了sensor.living_room_temperature结果三个自动化全部失效两个仪表盘卡片显示空白。花了一个多小时才把所有引用改回来。从那以后我改实体 ID 之前一定会做三件事第一在开发者工具的“模板”页面里搜索旧 ID看看有哪些地方引用了它。HA 的模板页面支持搜索可以快速定位。第二在“设置 自动化与场景”里逐个检查自动化看有没有用到这个实体。HA 的自动化列表支持按实体筛选这个功能很实用。第三改完之后立即测试所有相关的自动化和仪表盘确认没有遗漏。如果实体数量多、引用关系复杂可以考虑用customize来修改显示名称而不是改 entity_id。显示名称改了不影响引用只是界面上显示的名字变了。这个办法虽然不够彻底但胜在安全。4.3 实体数量膨胀后的性能优化HA 跑久了实体数量会越来越多。我一开始只有十几个实体后来慢慢加到一百多个明显感觉到界面加载变慢、自动化响应变迟钝。后来做了一轮优化情况好了很多。第一个优化是禁用不需要的实体。很多集成会生成一堆你根本用不到的实体比如设备的信号强度、固件版本、重启按钮。这些实体在后台仍然会被轮询和记录白白消耗资源。在实体设置里把它们禁用掉能省不少资源。第二个优化是调整轮询间隔。有些集成默认的轮询间隔很短比如每 5 秒一次。对于温度、湿度这种变化缓慢的传感器完全没必要这么频繁。在集成配置里把间隔调到 30 秒或者 60 秒能显著降低系统负载。第三个优化是精简 recorder 配置。默认情况下 HA 会记录所有实体的状态变化数据库会越来越大。把不需要记录的实体排除掉只保留关键的传感器和开关数据库体积能缩小一半以上。第四个优化是用模板实体替代复杂计算。如果你在多个自动化里重复计算同一个值不如创建一个模板传感器把计算结果存下来其他自动化直接引用这个传感器。这样既减少了重复计算又方便统一管理。我做完这四项优化之后HA 的启动时间从四十多秒降到了十几秒界面切换也流畅了很多。实体数量不是问题问题是有多少实体在真正被使用。4.4 实体属性图与可视化调试“实体属性图”这个词在 HA 的语境里我理解成两种东西一种是实体之间的关联关系图另一种是实体属性的可视化展示。关联关系图在 HA 里没有原生的功能但可以通过一些自定义卡片来实现。比如用auto-entities卡片按条件筛选实体用mini-graph-card展示实体的历史数据用apexcharts-card做更复杂的图表。这些卡片都是通过 HACS 安装的配置起来需要一点 YAML 基础但效果很好。属性可视化方面我常用的是attributes卡片和template卡片。attributes卡片可以直接显示一个实体的所有属性调试的时候特别方便。template卡片可以用模板语法提取和格式化属性值比如把亮度从 0-255 转换成百分比显示。如果你想把实体的属性数据导出做外部分析可以用 HA 的 API。/api/states/entity_id这个接口会返回实体的完整状态和属性格式是 JSON。用 Python 或者 Node.js 写个脚本定时拉取就能把数据存到外部数据库里。我用这个办法把家里的温度、湿度、用电数据都同步到了自己的服务器上做了一些简单的趋势分析。5. 实体扩展与进阶玩法5.1 用模板实体创建自定义逻辑模板实体是 HA 里最强大的功能之一。它允许你基于其他实体的状态和属性创建一个新的虚拟实体。这个新实体可以像普通实体一样被引用、被自动化、被显示在仪表盘上。我举几个我自己用过的例子。第一个是“平均温度”传感器。家里有三个温度传感器我想知道全屋的平均温度。用模板传感器可以这样写template: - sensor: - name: Average Temperature unit_of_measurement: °C state: {% set temps [ states(sensor.living_room_temperature) | float, states(sensor.bedroom_temperature) | float, states(sensor.kitchen_temperature) | float ] %} {{ (temps | sum / temps | length) | round(1) }} device_class: temperature state_class: measurement这个传感器会实时计算三个温度的平均值并且有正确的单位和 device_class可以直接接入图表和统计。第二个是“有人在家”的二元传感器。结合多个设备追踪器和人体传感器判断家里是否有人template: - binary_sensor: - name: Someone Home state: {{ is_state(device_tracker.phone_1, home) or is_state(device_tracker.phone_2, home) or is_state(binary_sensor.motion_living_room, on) }}这个传感器可以用来触发“离家自动关灯”之类的自动化比单独判断每个设备要简洁得多。第三个是“用电量统计”传感器。基于功率传感器的数值累计计算用电量template: - sensor: - name: Daily Energy unit_of_measurement: kWh state: {{ states(sensor.daily_energy) | float (states(sensor.power_meter) | float / 1000 / 60) | round(3) }} state_class: total_increasing device_class: energy这个稍微复杂一点需要配合自动化定时触发更新。但思路是一样的用模板把原始数据转换成你想要的形式。模板实体的好处是灵活坏处是需要一定的模板语法基础。我建议从简单的开始比如先做一个平均值传感器熟悉了之后再尝试更复杂的逻辑。5.2 实体与场景、脚本的配合场景Scene和脚本Script是 HA 里两种不同的自动化形式。场景是“一次性设置多个实体的状态”脚本是“按顺序执行一系列动作”。两者都离不开实体。场景的配置很直观你选一个场景然后设置每个实体在场景激活时的状态。比如“观影模式”场景把灯调到 20% 亮度、窗帘关上、电视打开。场景激活时HA 会一次性把这些实体设置到指定状态。脚本更灵活可以包含条件判断、延时、循环等逻辑。比如“晚安脚本”先关灯等 5 秒再关电视再等 10 秒最后锁门。脚本里引用的实体和自动化里一样用实体 ID 或者实体选择器。我自己的做法是简单的状态切换用场景复杂的流程控制用脚本。场景配置快脚本逻辑强。两者可以互相调用脚本里可以激活场景场景也可以作为脚本的一个步骤。有一个细节要注意场景激活时如果某个实体当前状态和场景里设置的一样HA 默认不会重复设置。这个行为在大多数情况下没问题但如果你希望场景激活时强制刷新所有实体状态可以在场景配置里关掉“只设置变化的实体”这个选项。5.3 实体数据的长期存储与外部集成HA 自带的数据库是 SQLite适合日常使用但不适合长期存储大量数据。如果你想把实体数据保留几年甚至更久或者想做复杂的数据分析就需要把数据导出到外部系统。我目前用的是 InfluxDB 加 Grafana 的组合。InfluxDB 负责存储时序数据Grafana 负责可视化。配置过程不复杂第一步在 HA 的configuration.yaml里添加influxdb集成influxdb: host: 192.168.1.100 port: 8086 database: homeassistant username: ha password: your_password max_retries: 3 measurement_attr: unit_of_measurement tags_attributes: - friendly_name include: entities: - sensor.living_room_temperature - sensor.living_room_humidity - sensor.power_meter第二步在 InfluxDB 里创建对应的数据库和用户。第三步在 Grafana 里添加 InfluxDB 数据源然后创建仪表盘。这样配置之后指定的实体数据会实时写入 InfluxDBGrafana 可以做出比 HA 自带图表更丰富的可视化效果。我用这个方案做了全屋的温度分布图、用电趋势图、湿度变化曲线效果比 HA 自带的图表好很多。如果你不想自己搭服务器也可以用 HA 的长期统计功能。HA 从 2021 年开始支持长期统计可以把传感器的数据按小时、按天聚合存储保留时间不受 recorder 的十天限制。配置方法是在传感器上设置state_class然后在能源面板或者统计面板里查看。这个功能适合不想折腾外部系统的用户。5.4 实体安全与权限管理实体多了之后权限管理就变得重要了。HA 支持多用户每个用户可以有不同的权限。比如你可以给家人创建一个普通用户只能控制灯和窗帘不能修改配置和查看摄像头。用户权限的配置在“设置 人员”里。每个用户可以设置是否允许登录、是否允许修改配置、是否可以查看所有实体。对于摄像头这类敏感实体可以设置成只有管理员才能查看。还有一个安全相关的功能是“可信网络”。你可以配置哪些网络可以免密登录哪些网络需要密码。这个功能在家庭内网里很方便在外面访问时又保证了安全。另外实体的历史数据也可能包含隐私信息。比如设备追踪器会记录你什么时候在家、什么时候不在家。如果你不想让这些数据被记录可以在 recorder 配置里排除对应的实体。我一般会把设备追踪器的历史记录关掉只保留当前状态。6. 我踩过的坑与实操心得6.1 实体命名不规范导致的返工前面提过命名规范的重要性这里再展开说一下。我刚开始用 HA 的时候实体命名完全是随意的。设备接进来是什么 ID 就用什么 ID有的是厂商默认的有的是自动生成的。结果半年之后实体列表里出现了sensor.temperature_1、sensor.temperature_2、sensor.temperature_3这样的名字完全分不清哪个是哪个房间的。后来我花了一个周末的时间把所有实体重新命名了一遍。过程很痛苦因为要改自动化、改仪表盘、改脚本。但改完之后整个系统的可维护性提升了一个档次。现在我看到任何一个实体 ID都能立刻知道它在哪、是什么、干什么。我的建议是在接入第一批设备之前就定好命名规则。哪怕一开始只有三五个实体也要按规则来。后面实体多了你会感谢当初的自己。6.2 实体状态轮询与推送的取舍HA 获取实体状态有两种方式轮询和推送。轮询是 HA 定时去问设备“你现在状态是什么”推送是设备主动告诉 HA“我状态变了”。轮询的优点是兼容性好几乎所有设备都支持。缺点是实时性差而且会消耗更多资源。推送的优点是实时性好、资源消耗低缺点是需要设备支持而且配置起来可能复杂一些。我自己的选择是对于变化频繁的实体比如人体传感器、门窗传感器尽量用推送对于变化缓慢的实体比如温度、湿度轮询就够了。如果设备同时支持两种方式优先选推送。有些集成允许你配置轮询间隔。我一般会把温度传感器的间隔设成 60 秒湿度设成 120 秒电量设成 300 秒。这样既保证了数据的及时性又不会给系统太大压力。6.3 实体不可用时的自动化容错实体不可用是常态不是异常。网络波动、设备重启、固件升级都会导致实体短暂不可用。如果你的自动化没有容错机制就会频繁报错甚至误触发。我的做法是在自动化里加两层保护。第一层是触发条件里加from和to的判断避免实体从unavailable变成on时触发。比如trigger: - platform: state entity_id: binary_sensor.motion_living_room from: off to: on这样只有从off变成on才会触发从unavailable变成on不会触发。第二层是动作里加条件判断确认相关实体都可用condition: - condition: template value_template: {{ states(sensor.living_room_temperature) not in [unavailable, unknown] }}这样即使触发了如果温度传感器不可用动作也不会执行。这两层保护加上之后我的自动化误触发率降低了 90% 以上。6.4 实体数量与系统资源的平衡最后说一个很多人关心的问题HA 能支持多少个实体官方没有明确的数字但根据我的经验和社区里的讨论在普通的树莓派或者迷你主机上几百个实体是没问题的。关键是看这些实体有多活跃。如果一个实体每秒都在变化那它消耗的资源会很大。如果一个实体一天才变化一次那它几乎不占资源。所以与其关注实体总数不如关注活跃实体的数量。我的系统目前有一百五十多个实体其中活跃的每天至少变化一次大概有四十个。跑在一台四核迷你主机上CPU 占用率平时在 5% 以下内存占用 1GB 左右。这个配置对我来说完全够用。如果你发现系统变慢可以先检查一下哪些实体在频繁变化然后考虑调整轮询间隔或者禁用不必要的实体。大多数情况下优化几个关键实体就能明显改善性能。实体是 HA 的核心理解了实体就理解了 HA 的大半。从接入第一个设备到管理上百个实体这个过程需要不断学习和调整。但一旦你掌握了实体的分类、属性、命名、联动和排查方法HA 就会从一个“玩具”变成一个真正好用的智能家居中枢。