Decoding 433 MHz remote

I recently purchased a superheterodyne 433 MHz receiver, which I have used to decode a 433 Mhz button with rc_switch in ESPHome. I would now like to decode a 433 MHz remote but have not yet had any success; I do not get any output in the log when I press the buttons on the remote.

I’d be happy to go through the motions of adjusting tolerance, filter, etc. but I don’t know what each parameter means, nor do I know what the reasonable limits are. For instance, if I set the buffer to 20kb, what does that do, and is it more or less likely to help in my case? …perhaps I should start with a buffer of 1kb and stop at an upper boundary of 10kb (?), increasing the buffer by 1kb with every attempt (?). I’m flying completely blind.

Would someone be willing to point me toward some info on the Internet that will help me to understand these parameters so I can approach this more intelligently? Or, if not, perhaps someone would be able to tell me the boundaries I should stay within for each parameter?

_https://github.com/merbanan/rtl_433

Have you played with the dump raw/all?

I’ve used both of those remotes you’ve linked to (or very similar) and decoded them using my hardware hacked Sonoff RF bridge running ESPHome.

I wouldn’t think you’d need to adjust the buffer. Maybe tinker with the other filter values too make the filters less restrictive initially.

There’s quite a lot of info buried in various threads.

Edit: I just checked my settings and these work for decoding similar buttons/remotes to yours using my Sonoff RF Bridge.

remote_receiver:
  pin: 
    number: 4
  dump: rc_switch
  filter: 100us
  tolerance: 50%
  idle: 2ms

Thank you both for your input. @Mahko_Mahko I tried the config you provided and it didn’t work. I’m beginning to wonder whether the remote might be faulty, and so I have ordered another.

@oldfart101 that looks like an interesting way to approach this. If my second remote doesn’t work with the usual config in ESPHome I’ll look into your solution more deeply.

1 Like

I take it the remote led goes on when you press it - so remote battery/power is probably ok?

Do you get anything at all in logger when you press a remote button if you set it to very verbose?

remote_receiver:
  - id: rc_receiver
    pin:
      number: GPIO22
      inverted: True
    dump: rc_switch
    tolerance: 60%
    filter: 250us
    idle: 4ms
    buffer_size: 2kb
1 Like

My new remote control arrived. It’s the same item as the first, but from a different seller on AliExpress. I used the config provided by @Mahko_Mahko and it worked flawlessly. So, my issue was caused by a faulty remote.

Thank you for your help, folks.

2 Likes

Case closed.

Here’s how I’m using mine.

Hi guys,

that’s awesome stuff here for me to learn from.

I am currently trying to make my WAREMA awning to work with HA.
So I am considering this Sonoff bridge to teach it the original remote signals and use it from HA to control the awening using RFLink.
Sonoff - RF Bridge 433MHz - WLAN / 433MHz, 14,90 € (besmart24.de)

@Mahko_Mahko
Is this the one you are using or the previous (black) model?

Thanks in advance.

I’ve got a “hardware hacked” older black model.

Not sure what the latest and greatest way to do it is…

What kind of hardware change did you do?
And: was this required?)

My assumption was, that I can read the signals from the original remote control and teach the RF Bridge to send it out.
I could then trigger the Bridge to send it out by using RFLink.

Is this assumption wrong?

The link you have sent contains a lot of electronic modification - which I would like to avoid (due to missing competencies on my side :wink:

The “electronic modifications” are the “hardware hack”. I was similarly inexperienced at the time

If I was you I would dig around in the forums a fair bit and find out the latest best solution before buying.

If you just need to learn codes and send them, you may be better off with a Broadlink.

Here’s some more of my experiences.

@lordzid, the configuration you shared works amazingly well for detecting the door, window, and water sensors I have. I have been using Sonoff RF Bridges with them for a LONG time but I’d like to be able to build my own with the super cheap 433MHZ receivers (https://www.aliexpress.us/item/2251832695760291.html for example).

Anyway, I plugged your settings in and voila the data lined up with my expectations on what codes I should be seeing from the sensors. However, occasionally, I get bogus codes mixed in and I’m trying to figure out how to filter those out.

Here’s an example from one of my window sensors:

[12:01:21][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:21][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:21][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:21][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:21][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:22][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:22][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:22][D][text_sensor:064]: 'Last Code Received': Sending state '332d0e'
[12:01:22][D][text_sensor:064]: 'Last Code Received': Sending state '199687'
[12:01:26][D][sensor:094]: 'Testing Uptime Raw': Sending state 19.45300 s with 0 decimals of accuracy
[12:01:29][D][text_sensor:064]: 'Last Code Received': Sending state '332d0a'
[12:01:29][D][text_sensor:064]: 'Last Code Received': Sending state '332d0a'
[12:01:30][D][text_sensor:064]: 'Last Code Received': Sending state '332d0a'
[12:01:30][D][text_sensor:064]: 'Last Code Received': Sending state '332d0a'
[12:01:30][D][text_sensor:064]: 'Last Code Received': Sending state '332d0a'
[12:01:30][D][text_sensor:064]: 'Last Code Received': Sending state '332d0a'

This is the close (332d0e) and open (332d0a) codes but you can see that at the end of the group of close codes, I got a 199687. That one is bogus.

Here’s another example from one of my water/moisture sensors:

[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:58][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '2b6900'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state 'ada'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2'
[12:15:59][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state 'ada40'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state '56'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state 'ada4'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state 'ada400'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state '15b'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:16:00][D][text_sensor:064]: 'Last Code Received': Sending state '56d2001d'
[12:16:01][D][text_sensor:064]: 'Last Code Received': Sending state '2b69000e'
[12:16:01][D][text_sensor:064]: 'Last Code Received': Sending state 'ada'
[12:16:01][D][text_sensor:064]: 'Last Code Received': Sending state '15b'
[12:16:01][D][text_sensor:064]: 'Last Code Received': Sending state 'ada400'

You can see here what the real code is but there’s a bunch of noise around it, especially toward the end. I think if I could watch for like 4 of the same code or more in a row, that would help filter out a bunch of the junk. I just can’t wrap my head around how to perform that type of filter given the ESPHome options. :expressionless:

Initial thoughts:

  1. Why not just listen for one correct code? I doubt you’ll get false positives? Just false negatives, which is probably ok? The presence of bogus codes doesn’t really matter?
  2. If you would prefer to look for multiple consecutive codes, you could look at on_multi_click.

I’ve got a separate Python demuxer script for decoding of the codes and mapping them to actual things – it’s MUCH easier to maintain a dictionary of the codes and their purposes outside of a hard-coded ESPHome YAML. The ESPHome device acts as just a translator, reading the 433MHz code from the air and passing it to Home Assistant so the Python script can do the heavy lifting. See this thread for the detail: Sonoff RF Bridge. Strategies for receiving data

If you’re doing more than two 433MHz devices in your house, I highly recommend the demuxing strategy. It’s fast, easy and completely maintainable. I’ve been using Sonoff RF Bridges to handle the translation from 433MHz to Home Assistant and they work great but these small signal readers seem to offer much more configuration/customization.

This is not a bad suggestion. I’ll play aroudn with this and see if I can get it to work. Thank you!

1 Like

Hmm right yeah I can see how a dictionary could be easier to maintain than big blocks of yaml.

I mostly just have a bunch of rf remotes I use for “quick access” tasks.

It’s been very solid and I don’t think improved maintainability is quite enough of a motivation for me just now though. Cheers.