IR Receive - filling buffer when the input GPIO is permanently HIGH

[ghtester]

It is probably a minor issue but I have encountered a difference in latest ESP Easy build.
There's a test ESP Easy node without IR sensor connected but the IR Receive plugin enabled and configured:


The issue (which did not happen with earlier builds) is that now with the same IR Receive plugin configuration the log is 'spammed' with the warning :
IR: WARNING, IR code is too big for buffer. Try pressing the transmiter button only momenteraly

[TD-er]

I think we can at least add some deduplication to the logs, if lines are repeated often in succession, then just count it and log it once more with the nr of duplicates. Just like syslog does.

Have to check if the IR library was updated between builds (not unlikely).
Sounds like this is more of an issue for the original library: https://github.com/crankyoldgit/IRremoteESP8266
Maybe @crankyoldgit has an idea whether something has been changed recently which could explain this behavior?

[crankyoldgit]

Have to check if the IR library was updated between builds (not unlikely).
Sounds like this is more of an issue for the original library: https://github.com/crankyoldgit/IRremoteESP8266
Maybe @crankyoldgit has an idea whether something has been changed recently which could explain this behavior?

It's been a very long time since anything to do with the capture buffer and how it is initialised/used has been changed in the library.
e.g. crankyoldgit/IRremoteESP8266#1517 (6 Jul 2021)
crankyoldgit/IRremoteESP8266#1046 (Feb 2020)

The only other things are: Is it an ESP32-C3? (crankyoldgit/IRremoteESP8266#1768) (9 Mar 2022)

Got any idea what version of our (IRremoteESP8266) library was last working as expected for you?

Have you checked the basics? Like, have you set a large enough capture buffer for your signals?

Any raw IR data collected that you can share?

[TD-er]

Is it an ESP32-C3?

That's something I can answer: Nope, as ESPEasy is not yet ported to the C3. (and if it was, I have not yet seen a PR for it...)

Any raw IR data collected that you can share?

Based on the issue title, I think the raw data is easy to reproduce ;)

[ghtester]

I am not sure about earlier ESP Easy build installed on that node but I believe it was compiled 2022-02-12 and did not generate that warnings.
Yes I think it's reproducible easily. When I changed the plugin configuration (to uncheck Internal PullUp, save, check again, save), the warnings disappeared, after the reboot it came back again. I did not spend more time for an issue analysis as it looks the IR Receive plugin works OK when the IR sensor is attached.

[crankyoldgit]

Without the pull up (or pull down) resistor, the voltage will be floating, thus it will randomly fluctuate. That's the signal(s) you're getting.

I.e. not a library problem, but an electrical one.

[crankyoldgit]

See https://www.mouser.com/blog/dont-leave-your-pins-floating

[ghtester]

The issue is with Internal PullUp checked so it's not the pin floating case. Also the Values input is 0 so there's something wrong.

[TD-er]

The internal pull-up resistors are of quite high resistance (50k - 100k)
Meaning that it doesn't take much current/energy to change the state of that pin.
If you have some wires connected to it, you may indeed pick up some signals.

The issue is with Internal PullUp checked so it's not the pin floating case. Also the Values input is 0 so there's something wrong.

What do you mean with the value being 0? You're pulling the pin low, or is that the value reported by ESPEasy when checking the state of that pin?
Noise can have quite short pulses, which can easily be missed.

[ghtester]

See the Devices picture above, where the Input Values of IR Receive plugin is displayed and equal to 0.
I really don't think the internal pull-up resistor's resistance is too high that the unconnected GPIO pin should be floating. In this case it would be an useless feature. From my point of view it's a SW issue which did not exist in earlier IR Receive plugin but I don't care if you don't agree... ;-)

[TD-er]

From my point of view it's a SW issue which did not exist in earlier IR Receive plugin but I don't care if you don't agree

Well I never said it could not be a software issue.
It is just that I want to understand what's happening here to get an idea what may be the related change or fix.

[tonhuisman]

Input Values of IR Receive plugin is displayed and equal to 0.

The Values 'input' contains the decoded 'content' of the received bitstream from the IR receiver. As the stream is invalid, the decoded result is not determined, so remains at (initial) 0.

[ghtester]

Yeah but if the input should be floating, soon or later a some valid value would be displayed. This does not happen. Also if the input bitstream is detected but not decoded successfully, the RAW value is written to log. This also does not happen. Only the "IR code too big for buffer " warning is recorded to log.
The issue closed, nothing to do... ;-)

[crankyoldgit]

@ghtester can I suggest you replicate/test/collect data with IRrecvDumpV2 from the IRremoteESP8266 library.
That way we can see in more detail what is happening, and indicate if there is a software problem, where it may lay.

[ghtester]

Well, thanks all of you for your help. In the end I cleared the configuration with the Factory Reset button, configured the same plugins again with the same parameters from scratch and despite there was no change in the hardware circuit, I am not able to replicate the issue anymore... So I am sorry for confusing, this is a test ESP node and I was playing a lot with configuration & rules, maybe I made something wrong there...

[TD-er]

Hmm this gives me an idea that maybe it is best to erase all bytes where settings can be stored when adding a task to ESPEasy.
These kind of issues have been reported for ages and it just doesn't feel right that "erase all and start over" is the best remedy for those issues.