esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 34 forks source link

Dooya RF Remote possible off-by-one #5721

Closed pedrovanzella closed 1 month ago

pedrovanzella commented 3 months ago

The problem

When receiving an RF Remote with the Dooya protocol, ESPHome detects it with ID 0x00b2c5a9. However, both a Flipper Zero and a HackRF Portapack with the Mayhem firmware read the same remote as ID 0x004d3a56. If you add 0x00b2c5a9 and 0x004d3a56, you get 0x00ffffff, so this is probably an off-by-one error somewhere.

The Button, Check and Channel codes also look weird. Channel 0 reads as 127, and channel 1 as 126, and so on. Button Up, short press reads as Code 14, check 1, and long press as Code 14 check 14.

If I try to send the decoded content back through an RF Transmitter with the Dooya protocol and all the same data (ID, Channel, Button, Check etc), my blinds don't respond, and I'm not able to decode the signal in the Flipper or the HackRF, even though I do see some signal being output, indicating the transmitter is indeed trying to send something.

If I plug in the data from the Flipper dump, I'm not able to get the blinds to respond either. Note that I can control the blinds from the Flipper or the HackRF with those dumps.

Reference: https://github.com/esphome/esphome/pull/6488

Which version of ESPHome has the issue?

2024.4.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

No response

Component causing the issue

No response

Example YAML snippet

remote_receiver:
  pin: GPIO04
  dump: dooya
  tolerance: 50%
  filter: 250us
  idle: 7ms

remote_transmitter:
  pin: GPIO05
  carrier_duty_percent: 100%

cover:
  - platform: template
    id: blind_0
    name: "Blind Chan 0"
    optimistic: true
    assumed_state: true
    open_action: 
      - remote_transmitter.transmit_dooya:
          id: 0x004d3a56
          channel: 127
          button: 14
          check: 14

Anything in the logs that might be useful for us?

No response

Additional information

No response

ms40724 commented 2 months ago

I have the same problem, sending the same decoded content back with the Dooya protocol does not work as expected.

deejaybeam commented 1 month ago

Same problem here - sending captured values does not work.

jesserockz commented 1 month ago

It is not off by one, the 1s and 0s are flipped completely.

>>> correct = 0x004d3a56
>>> bin(correct)
'0b010011010011101001010110'
>>> wrong = 0x00b2c5a9
>>> bin(wrong)
'0b101100101100010110101001'
jesserockz commented 1 month ago

Try the linked PR:

external_components:
  - source: github://pr#6947
    components: remote_base
deejaybeam commented 1 month ago

No - does not work. It works if I send the captured RAW data, but does not work if I try to re-send the (new/changed) Dooya data. Old Dooya data was: [I][remote.dooya:116]: Received Dooya: id=0x00BAF9E5, channel=174, button=10, check=10 New Dooya data is: [I][remote.dooya:116]: Received Dooya: id=0x0045061A, channel=81, button=5, check=5 RAW-Data I send is: code: [4759, -1556, 306, -764, 670, -402, 304, -764, 306, -765, 306, -763, 671, -403, 303, -764, 671, -405, 307, -760, 310, -760, 310, -762, 308, -763, 307, -759, 676, -397, 674, -397, 309, -763, 313, -758, 312, -758, 312, -760, 675, -393, 677, -395, 312, -753, 682, -392, 314, -760, 316, -754, 680, -391, 316, -754, 681, -389, 317, -755, 315, -754, 317, -751, 682, -394, 319, -754, 681, -390, 316, -753, 682, -390, 317, -749, 685, -387, 319, -750, 685, -404]

ssieb commented 1 month ago

@deejaybeam what do you receive when you transmit? Maybe come to the esphome discord where it's easier to interactively discuss it.