Home Assistant KNX 集成 knx.read 动作详解主动向 KNX 总线发送 GroupValueRead 读取请求【免费下载链接】home-assistant.io:blue_book: Home Assistant User documentation项目地址: https://gitcode.com/GitHub_Trending/ho/home-assistant.ioknx.read是 Home Assistant KNX 集成 提供的一个核心动作action用于向一个或多个 KNX 组地址主动发送GroupValueRead请求主动询问总线上的设备当前值而不是被动等待设备自行上报。读完本文你将掌握在 UI 与 YAML 两种方式下配置knx.read的完整方法理解它与state_address、sync_state、knx.telegram触发器之间的协同关系并能直接用现成示例实现窗帘移动后同步位置按需刷新设备状态等实战自动化。一、knx.read 是什么主动读取与被动接收在 KNX 协议中设备之间的通信通过组地址Group Address上的电报telegram完成其中与读取相关的电报服务APCI 服务主要有三种文档中对此有明确界定见 KNX 集成文档GroupValueWrite主动写入一个值GroupValueRead主动发出请告诉我当前值的读取请求GroupValueResponse对读取请求的应答。Read from KNX busknx.read动作所做的事情就是向指定的组地址发送GroupValueRead请求。请求发出后返回的电报可以通过knx.telegram触发器KNX telegram trigger在自动化中消费返回的值会被 KNX 实体sensor、binary_sensor、cover 等处理并更新状态。这一机制最适合的场景是当你需要主动问一台 KNX 设备当前值而不是等它自己上报时。原文档给出的典型例子是窗帘持续移动了一段时间后主动刷新它的位置值避免 Home Assistant 中的状态与真实位置不同步。需要特别注意的是文档明确指出如果你只是想一次性刷新某个实体全部状态地址的值不必逐条发knx.read直接使用 Home Assistant: Update entity 动作即可——它会强制一个或多个实体立即刷新数据其配置项为entity_id对应One or more entities to refresh right away。二、在自动化 UI 中使用 knx.read原文档给出了完整的 UI 操作步骤对应Settings Automations scenes界面打开SettingsAutomations scenes自动化与场景。打开一个现有的自动化或脚本或选择Create automation创建自动化Create new automation创建新自动化。如果是新建自动化在When当……时部分添加一个触发器。脚本则不需要触发器——脚本是在被其他东西调用时才运行的。在Then do然后执行部分选择Add action添加动作。在搜索框中搜索并选择KNX: Read from KNX bus。填写要读取的Group address组地址。选择Save保存。UI 中唯一的必填选项是Group address其定义为UI 选项说明是否必填Group address要发送读取请求的组地址可提供列表以一次读取多个组地址是此外knx.read不支持 targets——在 UI 中不会提示你选择区域、设备、实体或标签它只针对你填写的组地址生效。三、YAML 配置knx.read 的参数与完整示例在 YAML 中该动作以knx.read为动作名引用。原文档给出的基础示例action: knx.read data: address: 1/0/15这段配置会向组地址1/0/15发送一个GroupValueRead请求。YAML 参数只有一项参数类型说明是否必填addressstring / list要发送读取请求的组地址使用列表可一次读取多个组地址是从 KNX 集成文档可以看到组地址的书写格式Group addresses 小节既支持三级的1/2/3结构也支持两级的1/2和自由结构的1可写成字符串或整数。因此address既可以是单个组地址也可以是一次读取多个地址的列表例如action: knx.read data: address: - 1/0/15 - 1/0/16实战示例窗帘移动后同步位置原文档提供了一个非常实用的自动化模板当窗帘移动电报到达后等待 10 秒再主动读取窗帘的位置地址让 Home Assistant 与真实位置保持同步automation: alias: Update cover position triggers: - trigger: knx.telegram # Cover move trigger destination: 0/4/20 actions: - delay: 0:0:10 - action: knx.read data: # Cover position address address: 0/4/21这个例子体现了knx.read与knx.telegram触发器配合的典型模式先用触发器感知窗帘开始移动延迟数秒等移动结束后再用knx.read主动拉取最终位置。延迟的作用是给设备留出完成动作并准备应答的时间。四、底层机制state_address、sync_state 与读取超时要真正用好knx.read需要理解 KNX 集成在什么情况下自己就会发GroupValueRead。KNX 集成文档Group addresses 小节指出集成使用配置的state_address或*_state_address来更新功能状态这些地址会在启动时startup以及一小时没有收到任何来电报时默认sync_state行为被GroupValueRead请求读取。也就是说sync_state同步状态机制本身就在周期性使用GroupValueRead它有两个作用层面在实体层面sync_state选项控制是否主动从总线读取该实体的状态值可取true等效于expire 60默认、false不向总线发送任何GroupValueRead电报、every minutes定时更新、expire minutes长时间无电报时读取、init仅启动时初始化等见 binary_sensor 配置在集成层面默认的一小时无电报即主动读取策略保证了长期静默的地址也能保持同步。而knx.read动作的意义在于绕过这些定时策略在你需要的确切时刻主动发起读取。它相当于把按需读取的能力交到自动化作者手中。与此相关的还有读取失败的信号集成文档明确列出了一种常见日志错误见 KNX 集成文档Error: KNX bus did not respond in time (2.0 secs) to GroupValueRead request for: 1/2/3这说明某个组地址没有在超时时间内响应GroupValueRead。文档还特别指出这个 2 秒超时是从请求被调度发送时开始计时的在高负载系统例如 Raspberry Pi 上同时启动大量集成上发送本身可能被延迟导致误报。如果你在自动化中依赖knx.read的结果建议对总线无响应的情况做容错处理例如配合条件判断或重试。五、读取结果的消费方式knx.telegram 触发器与 knx_eventknx.read发出的请求本身没有返回值它的结果通过以下两种途径被消费1. knx.telegram 触发器推荐knx.telegram触发器可以监听传入或传出的 KNX 电报其触发数据非常丰富Available trigger data包括trigger.destination目标组地址trigger.source/trigger.source_name来源独立地址及名称trigger.telegramtype电报 APCI 类型GroupValueWrite、GroupValueRead、GroupValueResponsetrigger.payload原始电报负载DPT 1/2/3 为 0-255 整数其他 DPT 为 0-255 的整数列表trigger.value按 DPT 解码后的值依赖项目数据trigger.dpt_name、trigger.unit等。触发器还提供group_value_write、group_value_response、group_value_read、incoming、outgoing等开关默认均为true用于精确控制触发条件。如果你只想让自动化对应答电报做出反应可以关闭group_value_write和group_value_read。2. knx_event 事件KNX 集成会把匹配event配置中地址模式支持*通配和2-4范围见 Events 小节的电报发布为knx_event事件。事件数据中telegramtype为GroupValueWrite、GroupValueRead或GroupValueResponse时都会产生knx_event若为地址配置了typeDPT解码值会写入事件数据的value键对GroupValueRead电报而言value为None但data键仍保留原始负载。3. 实体状态更新如果读取的地址恰好是某个 KNX 实体的state_address或被动地址返回的GroupValueResponse会被该实体接收并更新其状态——这正是窗帘位置同步示例能生效的底层原因。六、与相关动作的对比与配合knx.read属于 KNX 集成的一组动作之一集成文档中通过include integrations/actions.md统一呈现见 source/_integrations/knx.markdown。与它关系最密切的是动作作用与 knx.read 的关系knx.read向组地址发GroupValueRead主动读取本文主题knx.send向组地址写入数据GroupValueWrite支持按 DPT 编码负载、response: true时以GroupValueResponse发送见 knx.send 动作文档读取的反向操作二者可组合实现一问一答式交互knx.event_register动态在knx_event过滤器中添加/移除组地址让未被建模为实体的地址也能产生事件见 knx.event_register 动作文档可在运行时按需开启对某地址电报的监听homeassistant.update_entity强制一个或多个实体立即刷新数据见 update_entity 动作文档需要刷新实体全部状态地址时的更简捷替代方案一个值得注意的组合场景先用knx.event_register或 YAML 中的event配置把某个地址注册进过滤器再用knx.telegram触发器或knx_event监听该地址最后用knx.read主动拉取——这套流程可以完整覆盖按需监听 主动询问的需求且无需把每个地址都建模成实体。七、使用注意事项小结综合原文档与 KNX 集成文档使用knx.read时有几点需要留意不支持 targets它只对address中列出的组地址生效UI 中不会出现选择区域、设备、实体或标签的步骤。响应不是即时的knx.read发出的是请求设备是否应答、何时应答由总线决定。若在自动化中需要等待结果应配合delay如示例中的 10 秒或依赖knx.telegram触发器在应答到达时再继续。总线无响应是正常现象某些设备对GroupValueRead不响应或响应超时日志中会出现KNX bus did not respond in time错误。此时可检查设备是否支持读取、地址是否配置正确以及系统负载是否过高导致发送延迟见 读取超时说明。能刷新实体就用 update_entity当目标是某个已建模实体的全部状态地址时homeassistant.update_entity比逐条knx.read更简洁。读取的地址必须与设备组对象匹配在 ETS 中确保你要读取的组地址已连接到对应设备的组对象上否则请求将无人应答。通过合理组合knx.read、knx.telegram触发器与knx.send你可以在自动化中实现完整的读取-判断-响应闭环让 Home Assistant 在 KNX 总线上真正成为一个主动参与者而不只是被动接收状态的一方。【免费下载链接】home-assistant.io:blue_book: Home Assistant User documentation项目地址: https://gitcode.com/GitHub_Trending/ho/home-assistant.io创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 5:55:38 · 阅读 1.2k Home Assistant KNX 集成 knx.read 动作详解：主动向 KNX 总线发送 GroupValueRead 读取请求
Home Assistant KNX 集成 knx.read 动作详解主动向 KNX 总线发送 GroupValueRead 读取请求【免费下载链接】home-assistant.io:blue_book: Home Assistant User documentation项目地址: https://gitcode.com/GitHub_Trending/ho/home-assistant.ioknx.read是 Home Assistant KNX 集成 提供的一个核心动作action用于向一个或多个 KNX 组地址主动发送GroupValueRead请求主动询问总线上的设备当前值而不是被动等待设备自行上报。读完本文你将掌握在 UI 与 YAML 两种方式下配置knx.read的完整方法理解它与state_address、sync_state、knx.telegram触发器之间的协同关系并能直接用现成示例实现窗帘移动后同步位置按需刷新设备状态等实战自动化。一、knx.read 是什么主动读取与被动接收在 KNX 协议中设备之间的通信通过组地址Group Address上的电报telegram完成其中与读取相关的电报服务APCI 服务主要有三种文档中对此有明确界定见 KNX 集成文档GroupValueWrite主动写入一个值GroupValueRead主动发出请告诉我当前值的读取请求GroupValueResponse对读取请求的应答。Read from KNX busknx.read动作所做的事情就是向指定的组地址发送GroupValueRead请求。请求发出后返回的电报可以通过knx.telegram触发器KNX telegram trigger在自动化中消费返回的值会被 KNX 实体sensor、binary_sensor、cover 等处理并更新状态。这一机制最适合的场景是当你需要主动问一台 KNX 设备当前值而不是等它自己上报时。原文档给出的典型例子是窗帘持续移动了一段时间后主动刷新它的位置值避免 Home Assistant 中的状态与真实位置不同步。需要特别注意的是文档明确指出如果你只是想一次性刷新某个实体全部状态地址的值不必逐条发knx.read直接使用 Home Assistant: Update entity 动作即可——它会强制一个或多个实体立即刷新数据其配置项为entity_id对应One or more entities to refresh right away。二、在自动化 UI 中使用 knx.read原文档给出了完整的 UI 操作步骤对应Settings Automations scenes界面打开SettingsAutomations scenes自动化与场景。打开一个现有的自动化或脚本或选择Create automation创建自动化Create new automation创建新自动化。如果是新建自动化在When当……时部分添加一个触发器。脚本则不需要触发器——脚本是在被其他东西调用时才运行的。在Then do然后执行部分选择Add action添加动作。在搜索框中搜索并选择KNX: Read from KNX bus。填写要读取的Group address组地址。选择Save保存。UI 中唯一的必填选项是Group address其定义为UI 选项说明是否必填Group address要发送读取请求的组地址可提供列表以一次读取多个组地址是此外knx.read不支持 targets——在 UI 中不会提示你选择区域、设备、实体或标签它只针对你填写的组地址生效。三、YAML 配置knx.read 的参数与完整示例在 YAML 中该动作以knx.read为动作名引用。原文档给出的基础示例action: knx.read data: address: 1/0/15这段配置会向组地址1/0/15发送一个GroupValueRead请求。YAML 参数只有一项参数类型说明是否必填addressstring / list要发送读取请求的组地址使用列表可一次读取多个组地址是从 KNX 集成文档可以看到组地址的书写格式Group addresses 小节既支持三级的1/2/3结构也支持两级的1/2和自由结构的1可写成字符串或整数。因此address既可以是单个组地址也可以是一次读取多个地址的列表例如action: knx.read data: address: - 1/0/15 - 1/0/16实战示例窗帘移动后同步位置原文档提供了一个非常实用的自动化模板当窗帘移动电报到达后等待 10 秒再主动读取窗帘的位置地址让 Home Assistant 与真实位置保持同步automation: alias: Update cover position triggers: - trigger: knx.telegram # Cover move trigger destination: 0/4/20 actions: - delay: 0:0:10 - action: knx.read data: # Cover position address address: 0/4/21这个例子体现了knx.read与knx.telegram触发器配合的典型模式先用触发器感知窗帘开始移动延迟数秒等移动结束后再用knx.read主动拉取最终位置。延迟的作用是给设备留出完成动作并准备应答的时间。四、底层机制state_address、sync_state 与读取超时要真正用好knx.read需要理解 KNX 集成在什么情况下自己就会发GroupValueRead。KNX 集成文档Group addresses 小节指出集成使用配置的state_address或*_state_address来更新功能状态这些地址会在启动时startup以及一小时没有收到任何来电报时默认sync_state行为被GroupValueRead请求读取。也就是说sync_state同步状态机制本身就在周期性使用GroupValueRead它有两个作用层面在实体层面sync_state选项控制是否主动从总线读取该实体的状态值可取true等效于expire 60默认、false不向总线发送任何GroupValueRead电报、every minutes定时更新、expire minutes长时间无电报时读取、init仅启动时初始化等见 binary_sensor 配置在集成层面默认的一小时无电报即主动读取策略保证了长期静默的地址也能保持同步。而knx.read动作的意义在于绕过这些定时策略在你需要的确切时刻主动发起读取。它相当于把按需读取的能力交到自动化作者手中。与此相关的还有读取失败的信号集成文档明确列出了一种常见日志错误见 KNX 集成文档Error: KNX bus did not respond in time (2.0 secs) to GroupValueRead request for: 1/2/3这说明某个组地址没有在超时时间内响应GroupValueRead。文档还特别指出这个 2 秒超时是从请求被调度发送时开始计时的在高负载系统例如 Raspberry Pi 上同时启动大量集成上发送本身可能被延迟导致误报。如果你在自动化中依赖knx.read的结果建议对总线无响应的情况做容错处理例如配合条件判断或重试。五、读取结果的消费方式knx.telegram 触发器与 knx_eventknx.read发出的请求本身没有返回值它的结果通过以下两种途径被消费1. knx.telegram 触发器推荐knx.telegram触发器可以监听传入或传出的 KNX 电报其触发数据非常丰富Available trigger data包括trigger.destination目标组地址trigger.source/trigger.source_name来源独立地址及名称trigger.telegramtype电报 APCI 类型GroupValueWrite、GroupValueRead、GroupValueResponsetrigger.payload原始电报负载DPT 1/2/3 为 0-255 整数其他 DPT 为 0-255 的整数列表trigger.value按 DPT 解码后的值依赖项目数据trigger.dpt_name、trigger.unit等。触发器还提供group_value_write、group_value_response、group_value_read、incoming、outgoing等开关默认均为true用于精确控制触发条件。如果你只想让自动化对应答电报做出反应可以关闭group_value_write和group_value_read。2. knx_event 事件KNX 集成会把匹配event配置中地址模式支持*通配和2-4范围见 Events 小节的电报发布为knx_event事件。事件数据中telegramtype为GroupValueWrite、GroupValueRead或GroupValueResponse时都会产生knx_event若为地址配置了typeDPT解码值会写入事件数据的value键对GroupValueRead电报而言value为None但data键仍保留原始负载。3. 实体状态更新如果读取的地址恰好是某个 KNX 实体的state_address或被动地址返回的GroupValueResponse会被该实体接收并更新其状态——这正是窗帘位置同步示例能生效的底层原因。六、与相关动作的对比与配合knx.read属于 KNX 集成的一组动作之一集成文档中通过include integrations/actions.md统一呈现见 source/_integrations/knx.markdown。与它关系最密切的是动作作用与 knx.read 的关系knx.read向组地址发GroupValueRead主动读取本文主题knx.send向组地址写入数据GroupValueWrite支持按 DPT 编码负载、response: true时以GroupValueResponse发送见 knx.send 动作文档读取的反向操作二者可组合实现一问一答式交互knx.event_register动态在knx_event过滤器中添加/移除组地址让未被建模为实体的地址也能产生事件见 knx.event_register 动作文档可在运行时按需开启对某地址电报的监听homeassistant.update_entity强制一个或多个实体立即刷新数据见 update_entity 动作文档需要刷新实体全部状态地址时的更简捷替代方案一个值得注意的组合场景先用knx.event_register或 YAML 中的event配置把某个地址注册进过滤器再用knx.telegram触发器或knx_event监听该地址最后用knx.read主动拉取——这套流程可以完整覆盖按需监听 主动询问的需求且无需把每个地址都建模成实体。七、使用注意事项小结综合原文档与 KNX 集成文档使用knx.read时有几点需要留意不支持 targets它只对address中列出的组地址生效UI 中不会出现选择区域、设备、实体或标签的步骤。响应不是即时的knx.read发出的是请求设备是否应答、何时应答由总线决定。若在自动化中需要等待结果应配合delay如示例中的 10 秒或依赖knx.telegram触发器在应答到达时再继续。总线无响应是正常现象某些设备对GroupValueRead不响应或响应超时日志中会出现KNX bus did not respond in time错误。此时可检查设备是否支持读取、地址是否配置正确以及系统负载是否过高导致发送延迟见 读取超时说明。能刷新实体就用 update_entity当目标是某个已建模实体的全部状态地址时homeassistant.update_entity比逐条knx.read更简洁。读取的地址必须与设备组对象匹配在 ETS 中确保你要读取的组地址已连接到对应设备的组对象上否则请求将无人应答。通过合理组合knx.read、knx.telegram触发器与knx.send你可以在自动化中实现完整的读取-判断-响应闭环让 Home Assistant 在 KNX 总线上真正成为一个主动参与者而不只是被动接收状态的一方。【免费下载链接】home-assistant.io:blue_book: Home Assistant User documentation项目地址: https://gitcode.com/GitHub_Trending/ho/home-assistant.io创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考