I have IR receiver with M5Stack Atom to get keypresses from universal remote and Broadlink RM4 to send commands to my TV, receiver, Roku…
Simple code in ESP fires homeassistant.event with every received sony code and HA automation sends commands with Broadlink to devices.
All this works, but with one key press on remote, IR code is detected several times.
It means, my automation also sends one command several times.
Obviosly not good for example ‘Channel_up’
Tried different things, but can’t find solution to prevent repeated events
remote_receiver:
pin:
number: GPIO32
inverted: true
dump: all # sony
# In this lambda, x is an SonyData. x.data is a uint32_t that identifies the button pressed.
on_sony:
then: # Listen to events: esphome.Remote
- homeassistant.event:
event: esphome.Remote
data_template:
value: !lambda "return x.data;"
- logger.log:
format: "Recieved IR: %0X" # "Recieved IR: %0f"
args: [ 'x.data']
If you don’t find a quick answer here, you might try this web site, forum and products. These are some real infrared gurus : ‘AnalysIR - All about infrared remote control, IR decoding and more’, main web site link below.
and fyi, it’s ‘i before e, except after c’. I’ve spend my life hating on human language
Recieved => Received
IR signals is really prone to distortion so many IR transmitters send the signal multiple times and then let the receiver handle the multiple repeated signal.
Because the IR remote and the IR receiver device is usually made together then it can be handled easily, but when we come in with a device and try take over things can go wrong here and there.
We can record a signal with multiple repeats and reuse that for other signals that do not have the repeats and our devices can be slower to transmit the repeated signal, which means the grace period in the receiver to not react on the signal is overflown.
Our IR transmitters are generally a better quality than the cheap once that came with the device, so a lower number of repeats can be good enough and often a single signal without repeats is fine too.
You need to remove the repeats here.
No experience with IR, but for similar things, I’ve found adding a short delay to the automation at the end will prevent repeats. Maybe start with 100ms and fine-tune?
I use a Sonoff RF Bridge, so I see each signal I record and only one signal per line.
It is also then quite easy to see the repeats and the distortion from signal to signal.
I can’t change what signals are coming from my remote control, so there is no point to investigate incoming signals. I must deal with this what I get.
I try to add delay in esp automation and hope that IR input stream in not queued somewhere in buffer.
I would keep the esp clean and have the HA automation that is listening to the events check if it has run recently. That way you keep full control and kan e.g. still detect long press v.s. short press.
With binary sensor I must make for every command separate sensor and also separate automations for every operation. I try to stay with one automation which decodes commands and sends them to right device
‘I can’t change what signals are coming from my remote control, so there is no point to investigate incoming signals. I must deal with this what I get.’
If as was pointed out by @WallyR that some ‘clone’ IR copying hardware does a poor job of cloning the signals and ‘solves’ their poor ability by sending the code multiple times, you have a real challenge. Does the original remote transmit the signal multiple times?
How are you going to differentiate between you wanting to press the button multiple times and remote resending the signal? Seems link you are going to end up with a less than ideal user experience by trying to ‘debounce’ in some way.
It is actually not the cloning hardware that does this.
It is the original transmitter hardware.
This is why you often get a high, low and mid value from a recording.
