IR RX hardly usable in latest releases

[ghtester]

I don't know if it's only my issue but i found IR RX plugin almost unusable in many latest ESP Easy Mega versions as 1 of about 5 IR codes is detected properly. I am currently using Samsung IR transmitter. The ESP HW is the same, ESP Easy Mega builds from early 2018 was working OK with IR plugin. The latest tested build ESP_Easy_mega-20190404_normal_IR_ESP8266_4M.bin even reboots if I hold a key on IR transmitter for a while.

[jimmys01]

IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF

Fast or prolonged presses of the remote button won't register correcly, this is a known issue. Some time ago, prolonged presses would have cause a reboot of the ESP. The plugin runs (loops) 10 times per second in easy esp and in IRrecDumpV2 runs as fast as the prossesor can loop throught the code. This also affects the timing and probably this is the reason why repeated presses will not register. @crankyoldgit maybe can pitch in for this?

[ghtester]

Well, I would recommend to use a RC5 Remote Control if you can, it's more reliable with ESP Easy IR plugin.

[crankyoldgit]

Hi, I'm the owner of IRremoteESP8266 library.

I can't speak for ESPeasy as to their use of the library, but I'm going to take an educated guess.

The NEC protocol works like this:

When the button on a remote is pressed, it sends a 32 bit message that indicates what code/button was pressed, and approx every 1/10th of a second it sends a special 1-bit message that is 'hey, that last button is still held down' message for as long as the button is held down. a.k.a. A repeat message.

If there is no state kept by the remote/device/etc (i.e. the last message I saw 1/10th of a second ago) a NEC repeat message will mean "Huh? What was repeated? I've got no idea." NEC & a couple of other protocols have this protocol type. i.e. a special repeat code. Most just, ya know, actually repeat the message which has the data/code in it again till the button is released.

My guess is ESPEasy doesn't store the state of the previous full NEC message. FYI, the IRremoteESP8266 library doesn't either (NOT a guess, fact! ;-).

What you are seeing in IRrecvDumpV2 is exactly as @jimmys01 is describing. That program has NOTHING else to do but check if it received another message. You are not seeing it magically understand the protocol any more than ESPEasy appears to be doing. It's just doing it much faster.

If you want to use a NEC-style IR remote to do prolonged button presses and do meaningful things on it. You are going to have to do the maintain the state thing yourself. e.g. Have an external program etc that says "Gosh, I saw an NEC message that is 0xDEADBEEF, which I want to do "Pour some tea", I better remember that for the next 200ms in case I get a NEC repeat message. Oh look, I did. So "Pour some tea" again, remember that I'm pouring tea, and wait again another 200ms etc for a repeat. If I don't see anything for 200ms, then I'm going to assume no more tea is needed and I can forget that I'm in "Pour some tea" mode. Oh, If I get some other message like "Pour some milk" etc, then rinse and repeat the entire process again but in "milk" mode.

You can't expect the IRremoteESP8266 library OR ESPEasy to do that for you. How you want to deal with the messages a protocol gives you (i.e. how to handle repeats etc) is up to you. It gives the end user the maximum flexibility. i.e. If it tried to understand the protocol a bit more for you, which we'd call "cooking" it a bit (e.g. not "raw"), it may be easier for you to use, but it also reduces flexibility, detail & granularity for everyone else.

If you want 'I just want to get constant "pour some tea" messages when I hold down the remote button' then as @ghtester as correctly pointed out, use a remote that has a protocol that doesn't have it's own data-less repeat message.

TL;DR: You are kind of trying to get blood out of a stone when trying to receive messages from a remote that uses NEC and want to handle long presses/repeats. You will have to do a lot of the leg work, just like a TV/stereo/real device has too to handle those cases.

IRrecvDumpV2, Similar to a "real" device is effectively using a dedicated micro controller to sit there all day/every day decoding IR messages, so it is not going to miss any valid message that falls on it's sensors. ESPEasy is not just doing that one dedicated thing, thus it can't just service every IR message that falls on it. It's going to get most of them, but it can't get all of them.

To give you an impression of how tight that time limit is, I had to design the library to continue capturing messages while it was attempting to decode the previous message, because previous versions of the library were missing messages during the decode process. If say, you have the audacity to print the message to serial etc you can print about 12 characters to serial at 115200 baud for every milli-second. Thus you've only got time to print just over ~1000 characters before the next "repeat" comes in. And that's not counting time it has to spend decoding the message etc.

I guarantee you IRrecvDumpV2 misses some messages when you are holding down a button. It is often printing thousands of characters per message.

(edit: Fix some typos and wrong baud rate math)

[ghtester]

FYI I have quickly tested recent custom selfcompiled build using Vagrant & sources 20190926 with IRRX plugin and it looks working better at least with SAMSUNG Remote Control - it's quite reliable like in very old builds. But the crash trouble (when keypressed long) is still there. As the earlier test with @jimmys01 's test firmware firmware15.zip was not crashing to me, perhaps kTimeout=15 could be set if possible.

[TD-er]

As the earlier test with @jimmys01 's test firmware firmware15.zip was not crashing to me, perhaps kTimeout=15 could be set if possible.

Do you keep track of these kind of remarks, @jimmys01 ? Or should we make it into a new issue?

[crankyoldgit]

FYI, the timeout can be set at run-time if you want to make this a user tuneable parameter in ESPEasy. See: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/IRrecv.cpp#L131-L150

[jimmys01]

I do keep track of those things. I do not really know how to implement settings and check boxes in ESPEasy in the plugin webpage, mainly because of time limitations, since I can deduce how to it is done from other plugins. I have more parameters that I would like to set from the plugin settings.

[ghtester]

Well, during last several days I tested a build from the latest sources 20191003 and IRRX works quite good. I don't say it's impossible but I could not crash the node down by long infrared Remote Control key presses (nor by quick long/short key press handling) even with default kTimeout=50. That's why I decided to close the issue. Instead I am now struggling with Home Assistant (openHAB) MQTT controller (default settings) which reboots a node quite often if there's a bad WiFi connectivity. But it's really Off Topic here. Thanks a lot to all contributors for a huge improval of (not only) IR subsystem, it's a really great progress! :-)