ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Home Assistant Philips Dynalite 集成:使用 dynalite.request_channel_level 动作请求通道亮度级别

Home Assistant Philips Dynalite 集成:使用 dynalite.request_channel_level 动作请求通道亮度级别 Home Assistant Philips Dynalite 集成使用 dynalite.request_channel_level 动作请求通道亮度级别【免费下载链接】home-assistant.io:blue_book: Home Assistant User documentation项目地址: https://gitcode.com/GitHub_Trending/ho/home-assistant.io本指南讲解 Home Assistant 中 Philips Dynalite 集成的dynalite.request_channel_level动作它如何通过 Dynet 网络向指定区域area的通道channel发送回报当前级别的指令以及如何从 UI 和 YAML 两种方式在自动化automation与脚本script中调用它。读完本文你将掌握该动作的完整参数host、area、channel、默认行为不指定 host 时的广播语义、它与dynalite.request_area_preset的配合关系以及底层发送网络指令、由回报回调驱动状态更新的工作原理。背景Dynalite 的 Area / Channel / Preset 模型在深入动作本身之前先理解 Philips Dynalite 的拓扑模型因为request_channel_level的参数area、channel、host全部来自这套模型。根据 Philips Dynalite 集成文档Dynet 网络一个 Dynalite hub网关连接到的底层总线网络由区域areas、通道channels和预设presets组成。Area区域通常对应一个物理空间如一个房间每个区域包含一个或多个通道。Channel通道区域内的具体设备通道可以对应可调光灯dimmable light或其他设备。Preset预设定义区域内所有通道的行为组合有时会触发额外动作。典型约定是区域内的 preset 1 表示开preset 4 表示关其余预设可用于场景和调光。request_channel_level的动作目标正是某个区域中的某个通道——这就是它不支持 Home Assistant 实体entity作为 targets、而是直接填写数字编号的原因Dynalite 通道级别是网络层面的概念与实体状态没有一一对应关系。相关说明见 request_area_preset 文档其中指出某些安装对特定区域需要使用非默认通道来请求预设。动作语义发送查询指令而非返回数值dynalite.request_channel_level的官方描述是Asks a Dynalite channel to report its current level.请 Dynalite 通道回报其当前级别。动作文档在开篇给出了一个非常关键的注意事项该动作不返回级别数值。它发送一条网络指令要求通道回报其级别当通道回报时系统会捕获并处理该回报。这与dynalite.request_area_preset的语义完全一致同样不返回预设、只发送查询指令见关联动作文档。因此该动作是单向触发的返回值不代表查询结果查询结果通过 Dynalite 集成的Local Push本地推送能力异步回到 Home Assistant由集成内部捕获并处理catches and handles回报数据从而刷新对应实体状态。这也是为什么该动作最适合用在状态可能不同步、需要主动向网络要一次最新值的场景例如重启后校准灯具亮度、或对疑似被面板/遥控器改变过的通道做一次状态同步。从 UI 使用该动作自动化与脚本根据动作文档中的 UI 操作步骤对应公共模板 ui_header.md在可视化编辑器中调用该动作的流程为进入Settings设置Automations scenes自动化与场景文档中通过{% my automations %}链接直达。打开一个现有的自动化或脚本或选择Create automation创建自动化Create new automation创建新自动化。若是新建自动化在When当部分添加一个触发器。脚本script不需要触发器——它们在被其他东西调用时才运行。在Then do然后执行部分选择Add action添加动作。在搜索框中搜索并选择Philips Dynalite: Request channel level。填写Area区域和Channel通道Host主机为可选项。选择Save保存。UI 表单中的字段定义如下来自文档的{% options_ui %}块字段说明必填Host要发送命令的网关 IP 地址。留空时命令发送给所有已配置的网关否Area包含该通道的 Dynalite 区域是Channel要请求级别信息的通道是再次强调该动作不支持 targetsUI 中直接输入 Dynalite 区域和通道数字而不是选择实体。这与普通动作如light.turn_on以实体为操作对象有本质区别操作时需注意。从 YAML 使用该动作如果你直接编写 YAML或在 UI 生成的配置中查看底层结构动作名称为dynalite.request_channel_level。文档给出的基础示例对应公共模板 yaml_header.md为action: dynalite.request_channel_level data: area: 2 channel: 1即向区域 2 的通道 1 发送回报级别指令。该示例可直接放入自动化或脚本的action列表alias: Sync kitchen dimmer level on startup triggers: - trigger: homeassistant event: start actions: - action: dynalite.request_channel_level data: area: 2 channel: 1YAML 参数参考文档的{% options_yaml %}块给出了完整参数定义字段类型与必填性如下参数类型必填默认值说明hoststring否无要发送命令的网关 IP 地址。留空时命令发送给所有已配置网关areainteger是无包含该通道的 Dynalite 区域channelinteger是无要请求级别信息的通道与dynalite.request_area_preset对比见关联动作文档后者的channel为可选参数、留空时默认使用通道 1而request_channel_level的channel是必填项——因为请求级别必须明确指向某个具体通道语义上不存在区域内所有通道的批量查询。关于host参数的广播语义host参数在 UI 和 YAML 中的描述一致The IP address of the gateway to send the command to. When left empty, the command is sent to all configured gateways.要发送命令的网关 IP 地址留空时命令发送给所有已配置的网关。这意味着如果你只配置了一个 Dynalite 网关host可以放心省略如果配置了多个网关且目标区域/通道属于特定网关建议显式传入host以避免命令发往所有网关若同一网络中存在编号重叠的区域省略host时可能需要在多个网关上验证回报结果。与 Dynalite 集成配置的配合该动作的正确使用离不开正确的集成配置。根据 Philips Dynalite 集成文档Dynalite 几乎没有自动发现能力需要通过UI 配置流config flow添加 hub然后使用Dynalite 面板仅对 admin 级别用户开放完成配置最重要的部分是手动定义区域使其与现有 Dynalite 安装的实际配置匹配。对于不知道区域/通道映射的用户集成提供autodiscover选项开启后组件会跟踪 Dynet 网络设备每次被使用时自动加入 Home Assistant初始显示为 Area 123 Channel 7 这类名称便于你在真实操作中对照。完成映射后建议将autodiscover设为false因为系统内部通信存在大量假通道和区域。集成以Local Push本地推送方式工作支持 light、switch、cover 三类平台request_channel_level正是利用这种本地网络交互能力来主动请求状态回报。因此一个典型的最佳实践组合是先用autodiscover摸清区域/通道映射 → 手动配置好正式的区域定义 → 关闭自动发现 → 在需要状态校准时调用dynalite.request_channel_level。与 Dynalite 事件机制的关系request_channel_level的回报结果会流入 Dynalite 集成的事件与状态体系见集成文档的 Events 章节事件触发时机关键字段dynalite_preset某区域选择了预设时host网关 IP、area区域号、preset所选预设dynalite_packet网络上出现 Dynalite 数据包时host网关 IP、packet含校验和的 8 字节数据包整数列表从源码结构可以推断request_channel_level发送的查询指令会促使通道回报数据包随后由集成解析这些数据包这正是dynalite_packet事件可见的底层流量并更新对应实体状态。如果你在做调试可以订阅dynalite_packet事件观察网络流量或配合dynalite_preset事件确认区域状态变化。快速验证在 Actions 工具中试运行想立刻验证动作效果而不写 YAML根据公共模板 try_it.md打开Settings Tools Actions文档中通过{% my developer_services %}链接直达搜索该动作填写字段选择Perform action执行动作即可在真实设备上看到效果。注意因为动作不返回级别观察点是目标通道对应实体的状态是否随之更新而不是动作执行返回的数值。故障排查与延伸阅读如果发送命令后实体状态没有变化先确认area/channel编号与 Dynalite 实际安装一致可临时开启autodiscover对照见集成文档多网关场景下检查是否需要显式指定host。想请求整个区域当前所选预设请使用姊妹动作dynalite.request_area_preset其channel可选、默认通道 1两者已在文档 frontmatter 中通过related_actions互相关联集成文档也通过actions.md统一列出。若自动化/脚本执行遇到问题文档末尾引用的公共模板 stuck.md 提供了一般的排障指引检查动作名称、参数必填性、目标可用性等。要点回顾dynalite.request_channel_level是一个请求状态回报型动作——必填area与channel整数host可选留空则广播到所有网关它不直接返回级别数值而是通过 Dynet 网络指令驱动通道回报由集成异步捕获并刷新状态该动作不支持实体 targets只能在自动化/脚本中按区域通道寻址并与dynalite.request_area_preset、dynalite_preset/dynalite_packet事件共同构成 Dynalite 集成的主动查询能力。【免费下载链接】home-assistant.io:blue_book: Home Assistant User documentation项目地址: https://gitcode.com/GitHub_Trending/ho/home-assistant.io创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表