记修改欧瑞博CT30W ESPHome代码暨调试remote_receiver组件

在我的文章《改装欧瑞博CT30W添加射频遥控功能》中提到使用remote_transmitter组件重构代码, 让代码更简洁. 但是这里涉及到一个协议解码的问题.

我使用下述代码打印红外遥控器的值

remote_receiver:
  - id: irrecv
    pin: 5
    tolerance: 15%
    #unknown_threshold: 12
    idle: 10ms
    dump: all

它打印出来的值是:

[remote.pronto:231]
Received Pronto: data=
[remote.pronto:233]
0000 006D 0022 0000 015E 00AC 0019 0015 0018 0015 0019 0014 0018 0015 0018 0015 0018 0015 0018 0015 0018 0015 0018 003E 0018 003E 0018 003E 0018 003E 0019 003D 0019 003D 0019 003D 0019 003D 0019 003D 0018 0015 0018 0015 0018 0015
[remote.pronto:233]
0018 0015 0018 0015 0018 0015 0019 0014 0018 0015 0018 003E 0018 003E 0018 003E 0018 003E 0018 003E 0018 003E 0018 003E 0018 0180

[remote.pronto:231]
Received Pronto: data=
[remote.pronto:233]
0000 006D 0002 0000 015E 0056 0018 0180

可以看到它根本识别不出来这个遥控器的协议. 之后我又使用如下代码构造了NEC协议的红外信号

button:
  - platform: template
    name: Rotate Right
    id: clockwise
    # friendly_name: 顺时针转动
    # Optional variables:
    icon: "mdi:rotate-right"
    web_server:
      sorting_group_id: sorting_group_button
      sorting_weight: 0
    on_press:
      - remote_transmitter.transmit_nec:
          transmitter_id: ir_transmitter
          address: 0x00ff
          command: 0x807f
          command_repeats: 1

它依然没有识别出来NEC协议:

[remote.pronto:231]
Received Pronto: data=
[remote.pronto:233]
0000 006D 0022 0000 015B 00AB 0017 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0015 0016 0015 0016 0040
[remote.pronto:233]
0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0040 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0180

这就很奇怪了, 这里肯定是NEC信号无疑了, 却还是识别不出来. 我尝试增大了buffer_size, 减少tolerance都没用. 咨询了ChatGPT后, 它推荐了个工具IrScrutinizer, 可以用它分析Pronto格式的红外信号值.

分析过程

Pronto是一种红外信号的表示方式, 与之类似的是RAW格式. 把信号值直接粘贴到IrScrutinizer工具中, 可以看到工具也没能识别出来信号的协议

但是在工具的IRP中给出了{38.0k,194,msb}<3,-3|3,-1627u>(9651u,-4523u,A:32,3,-9651u){A=0xff906f}. 把这个序列告诉DeepSeek, DeepSeek很快给出了分析结果. 它认为这个协议应该是一个NEC扩展协议, 使用两个16位数字表示地址码和命令码. 而<地址码><命令码>序列就是后面的{A=0xff906f}.

代码

使用的代码是这个:

button:
  - platform: template
    name: Rotate Left
    id: anticlockwise
    # friendly_name : 逆时针转动
    # Optional variables:
    icon: "mdi:rotate-left"
    web_server:
      sorting_weight: 1
      sorting_group_id: sorting_group_button
    on_press:
      - remote_transmitter.transmit_nec:
          transmitter_id: ir_transmitter
          address: 0xff00
          command: 0xf609
          command_repeats: 1

根据官方文档中的remote_transmitter组件remote_transmitter.transmit_nec中的相关说明, 这里的address和command应该使用MSB格式的数据. 所以把0xff906f换成了地址码0xff00和命令码0xf609.

DeepSeek的分析结果 - 可在gist查看

以下是您提供的IRP分析结果的详细解释： --- ### **IRP格式解析：`{38.0k,194,msb}(9651u,-4523u,A:32,3,-9651u){A=0xff906f}`** #### **1. 载波与协议基础参数** `{38.0k, 194, msb}` - **38.0k**：载波频率为 **38 kHz**（常见于NEC、Sony等协议）。 - **194**：每个脉冲的 **周期数**（即每个高电平脉冲由194个载波周期构成）。 - 计算公式： $$ \text{脉冲时间 (μs)} = \frac{\text{周期数}}{\text{频率}} \times 10^6 = \frac{194}{38000} \times 10^6 \approx 5.1 \, \mu\text{s} $$ 但实际协议中脉冲通常为数百微秒（如NEC的560 μs），此处可能为协议定义的占空比参数。 - **msb**：数据传输顺序为 **最高有效位优先**（Most Significant Bit first）。 --- #### **2. 逻辑位定义** `` - **逻辑位由两部分组成**： - **`3`**：高电平脉冲持续时间（单位：载波周期数 × 时间基数）。 - **`-3` 或 `-1627u`**：低电平间隔时间（负号表示低电平）。 - **逻辑0**：`3,-3` - 脉冲时间：3 × 5.1 μs ≈ **15.3 μs** - 间隔时间：3 × 5.1 μs ≈ **15.3 μs** - 总时长：30.6 μs（极短，可能为协议特殊定义或捕获误差）。 - **逻辑1**：`3,-1627u` - 脉冲时间：同上 **15.3 μs** - 间隔时间：`1627u` 直接以微秒为单位 → **1627 μs**（约1.627 ms） - 总时长：15.3 μs + 1627 μs ≈ **1.64 ms** --- #### **3. 引导码与重复码结构** `(9651u, -4523u, A:32, 3, -9651u)` - **引导码**： - **9651u**：高电平脉冲持续 **9651 μs**（约9.65 ms）。 - **-4523u**：低电平间隔持续 **4523 μs**（约4.52 ms）。 - **典型协议对比**： - NEC协议引导码为 **9 ms 高电平 + 4.5 ms 低电平** → 与当前值高度吻合。 - **地址/命令码**： - **`A:32`**：后续数据为 **32位地址/命令码**（通常分为16位地址 + 16位命令）。 - **重复码**： - **`3, -9651u`**：重复信号时发送的高电平脉冲（15.3 μs） + 长低电平间隔（9651 μs）。 --- #### **4. 实际数据值** `{A=0xff906f}` - **地址/命令码**：`0xff906f`（十六进制） - 转换为二进制：`11111111 10010000 01101111` - **注意**：该值为24位（而非32位），可能表示： - **地址部分**：`0xff90`（16位） - **命令部分**：`0x6f`（8位） - 剩余8位可能为校验码或扩展位。 --- ### **协议类型推测** - **疑似 NEC 扩展协议**： - 引导码（9.65 ms + 4.52 ms）和逻辑位定义与标准 NEC 一致。 - 区别在于地址/命令码扩展为32位（标准NEC为16位地址 + 16位命令）。 --- ### **关键验证步骤** 1. **载波验证**：使用38 kHz红外发射器发送此编码，观察目标设备是否响应。 2. **数据解析**：将 `0xff906f` 分解为地址和命令： - 地址：`0xff90` → 十进制 65424 - 命令：`0x6f` → 十进制 111 3. **重复码测试**：长间隔（9651 μs）可能触发设备的重复响应（如音量连续增加）。 --- ### **总结** 此IRP描述了一个 **类NEC的32位扩展协议**，适用于需要长地址/命令的家电设备（如高端空调或投影仪）。若需生成此信号，可借助Arduino库（如`IRremote`）配置为32位模式，并填充地址`0xff90`与命令`0x6f`。

记修改欧瑞博CT30W ESPHome代码暨调试remote_receiver组件

作者: ciaoℒy

时间: 2025-03-09

分析过程

代码