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.

[TD-er]

I don't know much about the IR plugins and the library they use. But I do know it is a rather extensive library nowadays which has some brand specific code wrapped in defines (to include/exclude during builds) What brand is your remote? Maybe it is not included in the current builds?

[ghtester]

As mentioned above, I am using Samsung IR transmitter (a standard TV remote control). Sometimes it's detected as SAMSUNG code, sometimes as RAW and it's very unreliable.

[jimmys01]

For me it is the exact opposite, it decodes a lot better. Since you mention that in earlier builds everything was ok, what you can do is load the https:github.com/markszabo/IRremoteESP8266/tree/master/examples/IRrecvDumpV2 and try decoding just with it for sanity check. I wait forward for your check. This may have to do with the P016_TIMEOUT (kTimeout in the IRrecvDumpV2) that I have changed. In the library developers words:

kTimeout is the Nr. of milli-Seconds of no-more-data before we consider a message ended. This parameter is an interesting trade-off. The longer the timeout, the more complex a message it can capture. e.g. Some device protocols will send multiple message packets in quick succession, like Air Conditioner remotes. Air Coniditioner protocols often have a considerable gap (20-40+ms) between packets. The downside of a large timeout value is a lot of less complex protocols send multiple messages when the remote's button is held down. The gap between them is often also around 20+ms. This can result in the raw data be 2-3+ times larger than needed as it has captured 2-3+ messages in a single capture. Setting a low timeout value can resolve this. So, choosing the best kTimeout value for your use particular case is quite nuanced. Good luck and happy hunting.

Also keeping the button pressed will send multiple signals to the RX and the library won't handle those because it cannot differentiate the start of a signal and the end of it. The purpose of that plug in is mainly to decode the IR signal in order to replay it. So press the buttons only momentarily

There are multiple frequencies for the receiver, the most common one is 38khz. Make sure that you have that one first. Having said that there are 30khz 33khz 36khz 38khz 40khz 56khz receivers. Also there are 2 IR bands... If the remote does not match the receiver you can have erraticall behavior with the decoding of the signal. I have seen it in one of my AC units.

[ghtester]

Thanks for your feedback & effort regarding to IR RX/TX plugin improvement. As I have not enough knowledge about ESP code compiling and it's not easy for me to do it, I am relying on official builds. I know there could be the receiver / transmitter type difference but I am using still the same HW and in past it worked better for me. Perhaps there's also an issue with the specific ESP module (many firmware releases flashed and it looks the complete flash memory clearing should be done) or the coincidence with other plugins I am using but I tried to disable them and the issue was still the same.

To be sure that there's an issue with IR RX, I updated another ESP module with the latest firmware build ESP_Easy_mega-20190404_normal_IR_ESP8266_4M.bin over older ESP_Easy_mega-20181030_normal_IR_ESP8266_4096.bin. This module has a different IR receiver and different other plugins. The IR detection is better than on my first ESP module but about the same on both firmware releases (20190404 and 20181030), not always reliable but acceptable. The main difference is that holding button on IR remote control does not reboot 20181030 but release 20190404 always crashes:

... ... 68322 : EVENT: IR#input=3728595130 69947 : IR: WARNING, IR code is too big for buffer. 70098 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output)

Exception (28): epc1=0x40277c00 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont sp: 3ffffc00 end: 3fffffd0 offset: 01a0

stack>>> 3ffffda0: 3fff371c 00000af0 00000af0 4010020c 3ffffdb0: 00000041 0000006b 3fff246c 402706d0 3ffffdc0: 000002eb 3fff19f0 3ffffe4c 40274a80 3ffffdd0: 3ffe9656 3fff19f0 3ffffe4c 402316f0 3ffffde0: 00001750 3ffffe40 3ffffe40 00000002 3ffffdf0: 00000000 3ffffe90 3fff19f0 40235a0f 3ffffe00: 3fff2134 3ffffe90 3ffffe40 401006dc 3ffffe10: 00000001 00000001 3ffffe40 00000002 3ffffe20: 3fff2134 3ffffe90 3fff19f0 40235ac8 3ffffe30: 3fff2134 3ffffe90 3fff19f0 40253e9a 3ffffe40: 00000000 00000000 00000000 3fff95ac 3ffffe50: 0000173f 00001738 3fff8dcc 0000001f 3ffffe60: 00000011 00000000 402acddd 40222686 3ffffe70: 00000000 00000000 00000000 00000002 3ffffe80: 3fff2134 00000005 3ffffe90 40238191 < 3ffffe90: 3fff8cf4 0000000f 00000000 3fff8d44 3ffffea0: 0000000f 00000000 3fff8d5c 0000000f 3ffffeb0: 00000000 3fff8d9c 0000000f 00000000 3ffffec0: 3fff8db4 0000000f 00000000 00000000 3ffffed0: 00000000 00000000 00000000 00000000 3ffffee0: 00000000 00000000 00000200 02140800 3ffffef0: 00001005 3fff22c8 3fff5e38 402324b4 3fffff00: 0000000f 042af8bc 0000018b 3fff277a 3fffff10: 0429ffe6 3fffff40 00011149 10000002 3fffff20: 042a009c 3fff2134 3ffeb0c4 4025282d 3fffff30: 3fff204c 0429ffb2 00000002 402325d1 3fffff40: 00011149 10000002 40272784 10000002 3fffff50: 3fff204c 0429ffb2 3ffeb0c4 4026dad9 3fffff60: 3fff204c 0429ffb2 00000002 4026dbed 3fffff70: 3fffdad0 000110e5 0429ff98 3fff35c0 3fffff80: 3fffdad0 00000000 3fff2120 3fff35c0 3fffff90: 3fffdad0 00000000 3fff2120 4026dd01 3fffffa0: 00000000 00000000 00000000 402727a5 3fffffb0: 3fffdad0 00000000 3fff35ba 40272814 3fffffc0: feefeffe feefeffe 3ffe87d0 40100721 <<<stack<<<

last failed alloc call: 40271653(5968)

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d vbb28d4a3 ~ld ٪U59 :

INIT : Booting version: mega-20190404 (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support) 60 : INIT : Free RAM:28096 60 : INIT : Warm boot #3 - Restart Reason: Exception 63 : FS : Mounting... 88 : FS : Mount successful, used 76555 bytes of 957314 460 : CRC : program checksum ...OK 472 : CRC : SecuritySettings CRC ...OK 580 : INIT : Free RAM:25352 582 : INIT : I2C 582 : INIT : SPI not enabled 653 : PN532: Found chip PN532 FW: 1.6 IR RX Init 669 : INIT: IR TX 1758 : INFO : Plugins: 49 [Normal] [IR] (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support) 1760 : EVENT: System#Wake 1878 : WIFI : Set WiFi to STA ... ...

[jimmys01]

Please check if this resolves the restart issue. firmware.zip

And check this, it the same as the above but with kTimeout=15 as it was before I made it 90 firmware15.zip

[ghtester]

Thanks a lot, quickly tested both versions on both ESPs... Firmware.zip still reboots (not so often like 20190404 but still when playing with a long press key on remote control). Firmware15 so far did not reboot so it looks better for me. The IR code detection is still bad on my ESP_1 and usable on ESP_2 and I can't say which (firmware or firmware15) is better. But a very old firmware releases were working a bit better from my point of view (regarding to what I need and even on my ESP_1 ), for instance:

Build	20000 - Mega (core 2_3_0)
GIT version	mega-20180104
Plugins	72 [Normal] [Testing] [Development]

It was also working with remote control long key press which is now ignored.

[jimmys01]

That old releases had a drasticaly older and less capable IR library, so much so that you cannot compare them imo.

Any way I will add a small commit to remedie the reboot issue when there are long IR transmits.

For the rest, in order to be able to 'play' with the variables like P016_TIMEOUT it is not in my abilities and time constraints to do that. So please @TD-er can you aid me into adding some parameters to the GUI P016_TIMEOUT: int 15 to 90 Enable RAW2 encoding: boolean checkbox RAW2 Percent tolerance: int 0 to 99 (5-15 are logical values) Enable RAW timmings to serial: boolean checkbox :-)

[ghtester]

Yes I know you are right but if there's no need of newest features, using even quite old firmware versions make sense I think, even there are some bugs fixed later. If the ESP does perfectly all I need and if it's rock stable, I can accept that. :-) Thanks a lot, I'll try to make my ESP_1 working with IR RX better (perhaps whole flash needs to be cleared) and if I find a reason why it works so bad in my case, I'll put it here.

[jimmys01]

Can you also test this for stability on long key presses? I have added yield() functions in order for the ESP to resume wifi or whatever backround tasks it has to do. Also I put the P016_TIMEOUT to 50. firmware.zip

[ghtester]

Thanks again, this firmware also sometimes reboots when playing with long and short IR remote control key press. No change with IR code detection reliability. Tested also with RC5 12 bit remote control, it works much better than Samsung. So the custom Firmware15 is my favorite so far as it looks more stable. BTW. I don't know how the IR code detection works but it looks to me like the part of wrongly detected IR code sometimes stays in buffer and pushing the key (on remote control) again does not read a fresh IR code but adds it to buffer so the next IR code is detected wrong again. So it looks to me when the IR code is not recognized, sometimes the second or even third detection is also wrong.

[jimmys01]

I cannot dublicate your results with my remotes and my setup, perhaps its because the SAMSUNG protocol is a new addition and I see they still are making corrections to it(and I dont own a samsung remote) and also there is still the possibility that the remote you have does not match the receiver.

[ghtester]

Well, I tested also a LG remote control which is using the NEC protocol. Looks there's a similar issue like with Samsung, I would say it's due to protocol length / complexity. Also some IR sensor incompatibility could be an issue. Tried another IR sensor grabbed from old Samsung TV with the same results. It also looks that number of plugins used also have some impact to IR code detection reliability. When using SAMSUNG remote control with mega-20180104 firmware release, it works fine. Regarding to reboot issue - it looks it also depends on if the ESP is connected to WiFi AP (crashing) or not (did not crash on the latest custom firmware so far when playing with remote control key long/short press). I have also encountered ESP_1 and ESP_2 crash at the same time (there are different plugins, different IR sensors, different power supplies but receiving the same remote control) when playing with Samsung RC. RC5 remote control looks working fine on both ESPs. I couldn't get crashed the ESP with LG (NEC) remote control so far. It is sending an autorepeat code when a key is pressed for a long time so that's perhaps why there's no crash.

[TD-er]

If the number of plugins used is having an impact on this bug, then we're running into free memory related issues.

Either the stack does then overflow or the heap doesn't have enough free space (or large enough free block) Can you test to see if a difference in bursts of IR commands also results in lower numbers of the free memory?

And then especially these lines (example from one of my nodes)

param	value
Free Mem:	12256 (9816 - sendContentBlocking)
Free Stack:	3600 (976 - parseTemplate)
Heap Max Free Block:	11064
Heap Fragmentation:	15%

N.B. The last two lines are only available on the more recent core 2.6.0 builds. The value between () is the lowest value seen and the function in which this lowest value has been seen.

[jimmys01]

Either the stack does then overflow or the heap doesn't have enough free space (or large enough free block)

Trying to fix that possibility already markszabo/IRremoteESP8266#670

[ghtester]

What I want to say is that it looks to me that number of used plugins may perhaps have some impact to IR decoding reliability regarding to (at least) SAMSUNG and NEC protocols in many recent ESP Easy firmwares and some old firmwares worked a bit better regarding to IR decoding. But I have to say that I am using various IR sensors (usually unknown types grabbed from a bad TVs). Shorter RC5 codes are detected quite good and more reliable.

Also the most recent ESP firmwares (except custom firmware15.zip above from @jimmys01 ) can often crash when receiving SAMSUNG codes, usually with long key press. The memory status looks like this:

custom latest firmware.zip (crashing): Free Mem: 10232 (8688 - sendContentBlocking) Free Stack: 3536 (928 - addToLog)

Free Mem: 9936 (8528 - sendContentBlocking) Free Stack: 3552 (1548 - sendData)

Free Mem: 10248 (8528 - sendContentBlocking) Free Stack: 3552 (1548 - sendData) Boot: Manual reboot (14) Reset Reason: Exception

custom firmware15.zip (not crashing): Free Mem: 9904 (8496 - sendContentBlocking) Free Stack: 2928 (1308 - parseTemplate)

Even though firmware15 has a less free memory, it does not crash but I suppose @jimmys01 could say what could be wrong / what's the difference. All custom firmwares above are based on core 2_4_2.

[crankyoldgit]

For the rest, in order to be able to 'play' with the variables like P016_TIMEOUT it is not in my abilities and time constraints to do that.

FYI, increasing the RX timeout value will make it capture more "repeated" messages as a single big message. If you want it to pick up the individual messages, you are better off lowering the value, not raising it. e.g. to ~10ms.

I would really strongly suggest you avoid values up near 90 unless you have a good reason.

What version of IRremoteESP8266 was included in the versions of ESPEasy you are discussing here? I can try to look back to see if there was some other issue. Also, what is the capture buffer sizes in each case? e.g. IRrecv irrecv(kRecvPin, kCaptureBufferSize, kTimeout, true);

[jimmys01]

kCaptureBufferSize = 1024 kTimeout = was 90 in the latest PR (not merged) 50

[crankyoldgit]

For me it is the exact opposite, it decodes a lot better. Since you mention that in earlier builds everything was ok, what you can do is load the https:github.com/markszabo/IRremoteESP8266/tree/master/examples/IRrecvDumpV2 and try decoding just with it for sanity check. I wait forward for your check.

I'd also STRONGLY recommend that, it will at least give us an indication of what exactly is the message that may be causing the problem,

[jimmys01]

Keep in mind that the 'earlier' build that he mentions are ancient :-p

[crankyoldgit]

kCaptureBufferSize = 1024

You may want to lower the value in your IRrecv object instantiation. I use 1024 in IRrecvDumpV2 because memory isn't an issue in that case. Most IR messages will fit comfortably with in 400-ish. That's potentially 600+ bytes you could be saving.

[crankyoldgit]

Keep in mind that the 'earlier' build that he mentions are ancient :-p

I gathered. Hence the curiosity.

[crankyoldgit]

Either the stack does then overflow or the heap doesn't have enough free space (or large enough free block)

Trying to fix that possibility already markszabo/IRremoteESP8266#670

FYI, unless @ghtester is trying to decode an AirCon IR message, your PR is not really going to help sadly. Normal Samsung (not Samsung A/C) won't touch strings much if at all.

[ghtester]

No, it's a standard Samsung TV Remote Control (various types but the protocol is the same).

[TD-er]

Cool to see @crankyoldgit also joining here for the IR support :)

[crankyoldgit]

No, it's a standard Samsung TV Remote Control (various types but the protocol is the same).

It's very likely it is a standard Samsung (protocol) remote, but we came across a different non-A/C Samsung protocol recently. See https://github.com/markszabo/IRremoteESP8266/issues/621 for more details. e.g. A Samsung Blu-ray player remote.

[crankyoldgit]

Cool to see @crankyoldgit also joining here for the IR support :)

Happy to help if @ summoned. :-)

[ghtester]

Thanks for the link and for all info shared. I am too lazy to compare technical details regarding to RC5 and SAMSUNG IR protocols so I don't know how different the decoding must be but RC5 works quite good in ESP Easy. NEC is much worse and SAMSUNG worst in my case. It's a pity I would like to use SAMSUNG Remote Control. :-) Yes it's from an old SAMSUNG TV so no Blu-Ray.

[crankyoldgit]

@ghtester The one of the reasons we are asking you to compile/upload/use the IRrecvDumpV2 example code from the IRremoteESP8266 arduino library (https://github.com/markszabo/IRremoteESP8266) is so we can have more information to help debug what the problem with code might be.

That is, that code shouldn't crash and should provide very detailed info about what is going on IR-wise, then if you could provide us with the output from the situation that typically causes the crash and we could see what we are dealing with that might be causing the crash in ESPEasy. ESPEasy has a lot more moving parts than the IRrecvDumpV2 program. If it doesn't cause a problem with IRrecvDumpV2, then they know the problem is somewhere, not with the underlying IR library and vice-versa. e.g. If IRrecvDumpV2 crashes then it's most like a bug the ESPEasy team can't directly fix (i.e. A problem in my library), or an indication there is some hardware issue at play.

We are not asking you to tell or know the difference between the different protocols. Just help us gather more information so we can help you better and easier. ;-)

[ghtester]

Yeah I would like to but I have no idea how to do it exactly... ;-( Although I have some former Pascal / assembler programming skills, the C language is out of my understanding... Also the Arduino developping platforms seems a bit complex for me to prepare it and use... I can test my Remote Control with avrtester (https://www.mikrocontroller.net/topic/248078#2540547) based on ATmega328 where I can make a configuration changes & recompile source code but no experience with Arduino / ESP development...

[jimmys01]

The crash as I understand it happens with prolonged presses of the remote button.

[ghtester]

Yes that's true, not always but quite often. Your custom firmware15 does not crash so I am currently using it. This is an output example - 10 times shortly pressed the same key on Remote Control:

243557 : WD : Uptime 4 ConnectFailures 0 FreeMem 11856 WiFiStatus 3 249558 : IRSEND,SAMSUNG,E0E0E01F 249567 : EVENT: IR#input=3772833823 249592 : ACT : gpio,12,1 249597 : SW : GPIO 12 Set to 1 249600 : ACT : gpio,16,0 249605 : SW : GPIO 16 Set to 0 249662 : IRSEND,RAW2,5484938D7C9D7C8D7,38,134,77 249666 : EVENT: IR#input=1788002071 250919 : IRSEND,RAW2,^1N^1A8F7G7G57537G768465757537G775849E47G7,38,82,107 250923 : EVENT: IR#input=3163649233 251083 : IRSEND,RAW2,^2K^2F3BT4BAB9BTDRBV9AAABBA8BB8TB^108TBABACA8B9ACB8C8ABSBVBRBV9TB,38,54,57 251088 : EVENT: IR#input=3399609685 252629 : IRSEND,RAW2,^18^1335D55435D55435D5545544554D45D5,38,113,128 252638 : EVENT: IR#input=1813916386 252729 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4554, 4500, 582, 1668, 582, 1668, 580, 1688, 568, 620, 496, 546, 698, 422, 580, 544, 580, 544, 696, 1700, 460, 1640, 582, 1668, 580, 656, 468, 542, 582, 542, 582, 544, 580, 662, 466, 1662, 582, 1666, 672, 1656, 502, 544, 612, 634, 456, 676, 448, 562, 586, 518, 582, 542, 588, 538, 662, 496, 592, 1620, 582, 1812, 574, 1530, 582, 1782, 582, 1550, 586}; // UNKNOWN BD119CC2 252741 : EVENT: IR#input=3172048066 254058 : IRSEND,SAMSUNG,E0E0E01F 254062 : EVENT: IR#input=3772833823 254087 : ACT : gpio,12,1 254092 : SW : GPIO 12 Set to 1 254095 : ACT : gpio,16,0 254099 : SW : GPIO 16 Set to 0 255289 : IRSEND,RAW2,^19^1C35G5555G6F5G55535G555557464535555G5,38,112,102 255293 : EVENT: IR#input=563315789 255390 : IRSEND,RAW2,5C55435C55435C8545C5D4C6C6C5,38,108,135 255394 : EVENT: IR#input=1662138076 256789 : IRSEND,RAW2,8^1A31G51531G51531G1515161441551G1,38,576,105 256793 : EVENT: IR#input=4204908993 258221 : IRSEND,RAW2,^20^1K38J38687768K9I8J58638J86886658638J9J8J8,38,71,86 258230 : EVENT: IR#input=2903501586 258382 : IRSEND,RAW2,5111,38,582,1667 258386 : EVENT: IR#input=3017984774 259559 : IRSEND,SAMSUNG,E0E0E01F 259563 : EVENT: IR#input=3772833823 259590 : ACT : gpio,12,1 259595 : SW : GPIO 12 Set to 1 259598 : ACT : gpio,16,0 259602 : SW : GPIO 16 Set to 0 259665 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[47] = {582, 1666, 582, 1666, 584, 576, 548, 570, 606, 626, 458, 558, 692, 412, 724, 1516, 584, 1816, 504, 1594, 582, 542, 580, 544, 580, 544, 676, 446, 584, 570, 552, 566, 558, 544, 584, 668, 586, 1532, 582, 1666, 662, 1748, 552, 1590, 650, 1544, 582}; // UNKNOWN 29263396 259675 : EVENT: IR#input=690369430 260927 : IRSEND,RAW2,^1AP3595533595535A5A498533595A495,38,109,179 260931 : EVENT: IR#input=2885989991 262259 : IRSEND,SAMSUNG,E0E0E01F 262268 : EVENT: IR#input=3772833823 262293 : ACT : gpio,12,1 262298 : SW : GPIO 12 Set to 1 262301 : ACT : gpio,16,0 262305 : SW : GPIO 16 Set to 0 262365 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[32] = {1668, 582, 1666, 582, 1666, 638, 544, 616, 452, 590, 536, 580, 542, 634, 490, 582, 622, 626, 424, 670, 556, 474, 1808, 442, 1666, 642, 1606, 590, 1666, 662, 1578, 584 }; // UNKNOWN B40CD79C 262373 : EVENT: IR#input=3020740508

[jimmys01]

What is basically the difference in firmware15.zip is that the P016_TIMEOUT (kTimeout) is 15 instead of 90. Plus that if the buffer overflows, it wont try to decode the signal.

[jimmys01]

firmware512.zip Halved the kCaptureBufferSize = 512 P016_TIMEOUT = 50; Added F() macro to the IR library.

[ghtester]

I think the timeout 15 is sufficient. The question is why there's so much decoding SAMSUNG / NEC errors on my hardware... This is a NEC example, 10 times short key (the same) pressed: 751087 : IRSEND,RAW2,^4I^1K96969J49697AJ9JB5BI49J969J49698859J9669J9,38,62,86 751095 : EVENT: IR#input=3368988489 752982 : EVENT: Clock#Time=Thu,15:17 753483 : IRSEND,RAW2,^41^1Q87878M487897L8N687M48M878M48796878M8768M8,38,70,77 753492 : EVENT: IR#input=1990153838 753560 : WD : Uptime 13 ConnectFailures 0 FreeMem 11856 WiFiStatus 3 755856 : IRSEND,NEC,20DF40BF 755860 : EVENT: IR#input=551502015 755913 : ACT : gpio,12,1 755918 : SW : GPIO 12 Set to 1 755921 : ACT : gpio,16,0 755925 : SW : GPIO 16 Set to 0 757817 : IRSEND,RAW2,^3V^1R87878M96387896M8M8758M878O78674878M8748M8N7M8,38,71,76 757826 : EVENT: IR#input=2002302923 759488 : IRSEND,RAW2,^41P73838958389898389A938983896838A636898,38,70,178 759493 : EVENT: IR#input=2362313057 761281 : IRSEND,RAW2,^4K^1BA5959G3A5B675AGAG954AG9G968GA5A595A595A5AGA5AGAG9G9H9GAGA,38,61,103 761285 : EVENT: IR#input=1008336045 763081 : IRSEND,RAW2,^3U^1384848D75743848D8D8438D8E6D848D6848D848D8E6D38D8,38,72,129 763090 : EVENT: IR#input=2755056987 764886 : IRSEND,RAW2,^3V87181835818383818383638383818368183816838,38,71,553 764890 : EVENT: IR#input=1901273169 766993 : IRSEND,NEC,20DF40BF 767002 : EVENT: IR#input=551502015 767055 : ACT : gpio,12,1 767059 : SW : GPIO 12 Set to 1 767063 : ACT : gpio,16,0 767067 : SW : GPIO 16 Set to 0 769088 : IRSEND,RAW2,^4I^1B75959G5959G9G959G9H8G9G9G959G6959GB67G59G9,38,63,103 769093 : EVENT: IR#input=1692534373

[ghtester]

Thanks, I'll try that one as well but I am afraid P016_TIMEOUT = 50 is too long as your earlier custom firmware with the same parameter was also crashing...

[crankyoldgit]

My educated guess() on what is happening is ESPEasy is not handling the repeat codes well. (I'm no expert on ESPEasy, so my reading of the logs may be wrong. Take with a grain of salt.) It's seeing the start of the button press on the actual remote as IRSEND,NEC,20DF40BF. If* the button is held down, SAMSUNG & NEC both produce a special repeat message which equates to "hey, I'm still sending the last full message". Those messages come in well before the 15ms gap required by the IR library to signify that a message has finished being sent. Think of it as "The IR capture buffer has a valid NEC message at the start, and a whole pile of NEC 'repeat' messages concatenated after it.". The IR library will decode that buffer and say "hey, this is a valid NEC "20DF40BF" message and ignore the rest of the buffer.

Now depending on what ESPEasy does, it could be filling the buffer up, and reporting it's full or something else. Whilst it's reporting "Hey I saw an NEC message and here is the code" it may or may not have (depends on how they called it) started capturing again. Depending on the timing, it may have started capturing again in the middle of a IR message, thus now have in the start of it's buffer a fragment of an IR message, then more full repeat messages after it. The IR library will say "I've got no clue what this is" and say it's unknown. Which might be what ESPEasy is saying with IRSEND,RAW2,randomchars.

Until there is a long enough gap between incoming IR messages, it won't have a chance to re-sync to the start of a message.

Or, it could just be ESPEasy doesn't know how to report/handle NEC (& Samsung) repeat messages.

Other IR remote protocols (like RC5 etc) just send the same message over and over again when a button is held down, or a different code for when the button is released etc. There are a few protocols that have a special "repeat" message. In general, the generic swiss-army knife nature of the IRremote library does not lend itself well to a constant stream of IR signals sent to it (e.g. holding down a button which keeps hammering messages out). TVs etc only have to expect one protocol and their circuit/controller doesn't need to do the zillion other things ESPEasy is doing at the same time. Due to the nature of the IR library, it's trying to handle 50+ potential different protocols and do it on a device that's doing lots of other things at the same time. i.e. It might miss a message or part of a message. Remotes/protocols that repeat the same message over and over would be better suited to more reliably sending to (and being understood by) the ESP in the "holding the button down" scenario.

That all said, holding it down shouldn't cause the program or device to crash. That's a bug plain and simple. It behaving and operating the way you want, may just be an incompatible design/implementation issue.

TL;DR: Try lowering the timeout value so that it tries to detect a message before the buffer gets filled. It will come at a cost of breaking detection of some protocols

(* I can't say for certain without seeing the output of IRrecvDumpV2)

[jimmys01]

Also ESPeasy checks if (irReceiver->decode(&results)) ten times per second, while IRrecvDumpV2 checks it every loop... Perhaps this is very slow?

TL;DR: Try lowering the timeout value so that it tries to detect a message before the buffer gets filled. It will come at a cost of breaking detection of some protocols

Edit: also i do not think that the plugin job is to decode the signal, even once, so the user can replay it. Having said that we should accommodate for all the remotes, even those with big gaps (kTimeout) and lots of need for buffer space. That's my reasoning for making kTimeout that big. Or perhaps to make all those arguments changeable from the GUI

[ghtester]

@crankyoldgit Thanks for the explanation & tips, it's a great and useful comment! It would be great if we could "preconfigure" the IR library / IR RX plugin to focus on specific protocol(s) only... I mean without recompiling. FYI there are examples of long keypresses on my Samsung and NEC Remote Control (still ESP Easy custom firmware15): SAMSUNG 8643539 : WD : Uptime 144 ConnectFailures 0 FreeMem 11856 WiFiStatus 3 8644840 : IRSEND,RAW2,^1A^235P5R4P55835P358694835P65867585P6O35P5,38,108,67 8644850 : EVENT: IR#input=3409434637 8645000 : IRSEND,RAW2,8115131,38,584,554 8645004 : EVENT: IR#input=2185229499 8645101 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4552, 4502, 580, 1670, 666, 1712, 466, 1786, 528, 464, 580, 544, 684, 440, 636, 496, 576, 612, 510, 1666, 580, 1684, 680, 1678, 454, 552, 574, 666, 502, 596, 488, 604, 514, 542, 598, 1752, 480, 1668, 580, 1668, 638, 504, 602, 504, 592, 532, 580, 542, 688, 490, 528, 590, 558, 518, 582, 546, 654, 1764, 408, 1668, 724, 1602, 504, 1670, 580, 1730, 518}; // UNKNOWN EE162887 8645113 : EVENT: IR#input=3994429575 8645207 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4554, 4508, 574, 1668, 580, 1712, 620, 1586, 580, 678, 446, 544, 630, 582, 492, 604, 686, 378, 652, 1596, 580, 1666, 582, 1816, 434, 678, 446, 544, 580, 626, 502, 540, 582, 562, 562, 1668, 626, 1732, 472, 1668, 582, 542, 582, 626, 498, 548, 610, 510, 626, 498, 584, 542, 718, 406, 636, 588, 486, 1664, 580, 1674, 626, 1616, 582, 1668, 740, 1510, 582}; // UNKNOWN 44CCC353 8645219 : EVENT: IR#input=1154270035 8645375 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4558, 4494, 670, 1630, 642, 1724, 420, 1664, 580, 604, 564, 500, 708, 418, 590, 532, 582, 542, 582, 1668, 654, 1610, 566, 1668, 740, 510, 460, 668, 562, 434, 578, 544, 582, 656, 468, 1764, 602, 1552, 582, 1674, 684, 440, 576, 704, 420, 544, 580, 546, 604, 668, 590, 386, 722, 402, 580, 542, 676, 1598, 562, 1664, 728, 1608, 496, 1666, 622, 1792, 420}; // UNKNOWN 20BCC082 8645387 : EVENT: IR#input=549240962 8645478 : IRSEND,RAW2,438415435,38,135,555 8645482 : EVENT: IR#input=552862610 8645571 : IRSEND,RAW2,5353851453635,38,114,521 8645576 : EVENT: IR#input=3026382000 8645727 : IRSEND,RAW2,A7A73AM5A73AMA7A8A5C5B697A986CKAMANAKCKC,38,60,76 8645731 : EVENT: IR#input=2624755792 8646000 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4576, 4478, 574, 1674, 576, 1670, 582, 1666, 582, 542, 704, 516, 582, 448, 696, 428, 580, 542, 726, 1618, 570, 1586, 580, 1796, 454, 660, 464, 546, 580, 670, 452, 590, 606, 472, 638, 1614, 636, 1610, 580, 1668, 580, 544, 662, 604, 502, 652, 468, 532, 532, 544, 580, 546, 740, 458, 504, 544, 680, 1568, 582, 1668, 582, 1668, 582, 1668, 582, 1670, 578}; // UNKNOWN AADEBE86 8646013 : EVENT: IR#input=2866724486 8646113 : IRSEND,RAW2,9M9M59739M59739M39798A88798B59N8M9M9N7MA,38,62,77 8646117 : EVENT: IR#input=1562040288 8646209 : IRSEND,RAW2,BS5B93BS5B93BSBA89E7A9B9BAA8BA9SBSBSCS9SA,38,54,60 8646213 : EVENT: IR#input=3284869363 8646367 : IRSEND,RAW2,^2CC3SC59CSCSCUBA9BAAC9A9DREQCSC9D9BAC9C9CB99F6CSDUCQCUCQC,38,59,49 8646371 : EVENT: IR#input=3344835835 8646523 : IRSEND,RAW2,67554664J6H6,38,90,96 8646527 : EVENT: IR#input=3719637701 8646697 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[65] = {580, 1668, 582, 1668, 582, 1768, 480, 656, 592, 460, 634, 566, 464, 624, 526, 518, 580, 1722, 676, 1518, 584, 1666, 642, 486, 674, 448, 590, 590, 532, 590, 528, 542, 582, 1710, 540, 1666, 626, 1764, 440, 588, 600, 484, 630, 496, 574, 562, 576, 674, 436, 544, 732, 392, 582, 542, 686, 1594, 552, 1668, 580, 1676, 574, 1670, 578, 1788, 460}; // UNKNOWN DA4D7997 8646708 : EVENT: IR#input=3662510487 8646895 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4556, 4490, 580, 1672, 684, 1688, 454, 1668, 610, 674, 422, 544, 746, 378, 580, 546, 580, 680, 512, 1676, 506, 1780, 464, 1668, 582, 542, 580, 544, 688, 502, 598, 462, 644, 480, 582, 1714, 682, 1694, 410, 1740, 680, 370, 608, 574, 524, 544, 580, 622, 504, 546, 576, 560, 564, 684, 532, 620, 414, 1824, 452, 1798, 424, 1668, 580, 1672, 578, 1676, 572}; // UNKNOWN 32639027 8646911 : EVENT: IR#input=845385767 8647001 : IRSEND,RAW2,8115131,38,583,554 8647005 : EVENT: IR#input=2185229499 8647159 : IRSEND,RAW2,8415435,38,142,556 8647163 : EVENT: IR#input=2185229499 8647336 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4558, 4580, 500, 1708, 536, 1668, 580, 1784, 464, 580, 590, 498, 644, 482, 580, 698, 510, 460, 660, 1594, 618, 1630, 660, 1584, 604, 520, 580, 544, 640, 484, 580, 592, 532, 608, 516, 1672, 670, 1668, 488, 1734, 668, 392, 578, 552, 572, 544, 582, 568, 670, 428, 712, 562, 436, 542, 580, 542, 630, 1620, 738, 1512, 586, 1826, 418, 1668, 582, 1806, 444}; // UNKNOWN D04CF66A 8647349 : EVENT: IR#input=3494704746 8647497 : IRSEND,RAW2,311531,38,556,580 8647501 : EVENT: IR#input=3958580554 8647593 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4552, 4500, 580, 1668, 582, 1668, 580, 1672, 628, 634, 440, 638, 560, 510, 538, 544, 580, 582, 548, 1664, 728, 1524, 582, 1666, 616, 668, 420, 544, 744, 380, 580, 544, 636, 508, 600, 1628, 582, 1668, 662, 1604, 568, 546, 574, 544, 580, 678, 504, 606, 460, 646, 478, 544, 580, 588, 672, 408, 716, 1534, 582, 1692, 580, 1646, 580, 1834, 424, 1660, 582}; // UNKNOWN 9627BCE5 8647605 : EVENT: IR#input=2519186661 8647701 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4556, 4498, 586, 1710, 592, 1612, 728, 1592, 510, 544, 580, 544, 580, 558, 720, 390, 644, 482, 722, 1524, 580, 1668, 580, 1770, 478, 650, 474, 542, 582, 580, 668, 422, 582, 690, 432, 1668, 580, 1724, 526, 1668, 582, 544, 590, 634, 514, 510, 628, 568, 516, 538, 588, 536, 612, 512, 580, 548, 578, 1668, 582, 1724, 524, 1668, 582, 1834, 418, 1666, 580}; // UNKNOWN A56AC5DE 8647713 : EVENT: IR#input=2775238110 8647869 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4554, 4498, 580, 1736, 628, 1712, 422, 1668, 580, 544, 720, 406, 578, 636, 488, 542, 582, 544, 580, 1670, 580, 1714, 600, 1602, 582, 546, 662, 496, 602, 494, 616, 500, 582, 638, 486, 1746, 512, 1690, 550, 1668, 718, 512, 480, 666, 592, 404, 580, 542, 586, 606, 514, 544, 748, 378, 580, 544, 580, 1808, 596, 1512, 580, 1718, 530, 1668, 586, 1662, 606}; // UNKNOWN DBF7BBC2 8647882 : EVENT: IR#input=3690445762 8647972 : IRSEND,RAW2,3381343334,38,554,182 8647976 : EVENT: IR#input=3231812318 8648069 : IRSEND,RAW2,9191831391A191,38,176,605 8648073 : EVENT: IR#input=3466211151 8648226 : IRSEND,RAW2,9P8P8849839P88989899899699889R6PAO8PAO9,38,68,66 8648230 : EVENT: IR#input=2531908582 8648497 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4606, 4450, 670, 1668, 452, 1662, 588, 1660, 698, 426, 582, 544, 632, 492, 586, 538, 734, 390, 580, 1668, 606, 1688, 538, 1694, 678, 420, 582, 696, 428, 544, 580, 638, 492, 546, 580, 1664, 580, 1732, 610, 1580, 574, 548, 634, 494, 574, 568, 552, 544, 584, 540, 612, 512, 702, 422, 588, 536, 682, 1568, 580, 1678, 572, 1700, 658, 1558, 580, 1668, 582}; // UNKNOWN 8EF78A 8648509 : EVENT: IR#input=9369482 8648603 : IRSEND,RAW2,5693J9569J9L7J96697978JBIAKAH9J9,38,86,63 8648607 : EVENT: IR#input=3204088501 8648699 : IRSEND,RAW2,BD5B43BD5B4BDDE9DD494B5A3C584B4B4BEBCBEBCBDE,38,52,129 8648703 : EVENT: IR#input=1054561656 8648858 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[66] = {4512, 574, 1666, 582, 1668, 582, 1668, 580, 544, 580, 542, 582, 544, 580, 544, 582, 542, 580, 1668, 582, 1764, 632, 1538, 634, 534, 520, 546, 580, 668, 550, 450, 754, 370, 644, 1608, 578, 1672, 602, 1642, 726, 398, 582, 548, 578, 660, 592, 414, 700, 426, 580, 646, 650, 378, 590, 674, 434, 1668, 580, 1714, 682, 1688, 420, 1750, 494, 1668, 580 }; // UNKNOWN 5C7BB1C2 8648870 : EVENT: IR#input=1551610306 8649025 : IRSEND,RAW2,11531,38,556,582 8649029 : EVENT: IR#input=3904334734 8649195 : IRSEND,RAW2,BT5B9BTBTCSBCA7BAA9BAATBTBTD7BAB9BAD7B9B9E8ATBTBUCRBV9,38,52,58 8649199 : EVENT: IR#input=4090471297 8649334 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4560, 4496, 634, 1618, 714, 1584, 562, 1642, 746, 500, 454, 664, 566, 438, 580, 542, 740, 384, 652, 1688, 494, 1690, 672, 1670, 460, 544, 580, 544, 654, 504, 610, 478, 616, 508, 580, 1822, 428, 1668, 582, 1668, 708, 416, 680, 474, 640, 602, 454, 524, 580, 670, 472, 526, 580, 544, 616, 652, 494, 1610, 582, 1668, 582, 1668, 580, 1670, 580, 1668, 580}; // UNKNOWN B708C124 8649346 : EVENT: IR#input=3070804260 8649506 : IRSEND,RAW2,^2B^2L3AVAAAAACA7ACAUCT9V5AAAVCSB^107A9C8AAB8AAACA8D9TA^10AUAVA^109,38,61,53 8649510 : EVENT: IR#input=3464619340 8649596 : IRSEND,RAW2,3115131,38,580,553 8649600 : EVENT: IR#input=4043485461 8649686 : IRSEND,RAW2,73871473639,38,80,552 8649690 : EVENT: IR#input=552862609 8649843 : IRSEND,RAW2,4B93BS5B9BUBQBSB9D7C8AA99B9B9BACS8U9SAT9SB,38,54,60 8649847 : EVENT: IR#input=4057883277 8650035 : IRSEND,RAW2,5111,38,583,1670 8650039 : EVENT: IR#input=3017984774 8650198 : IRSEND,RAW2,3131811531,38,554,582 8650202 : EVENT: IR#input=3466211151 8650293 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4552, 4656, 554, 1540, 582, 1796, 452, 1770, 480, 542, 582, 542, 580, 542, 586, 674, 498, 496, 626, 1616, 588, 1686, 558, 1664, 690, 472, 550, 588, 672, 404, 722, 566, 414, 550, 574, 1670, 604, 1650, 574, 1680, 570, 548, 738, 380, 582, 548, 620, 502, 580, 708, 576, 384, 580, 544, 578, 560, 682, 1672, 466, 1688, 668, 1666, 468, 1668, 610, 1640, 720}; // UNKNOWN 2A3B5181 8650306 : EVENT: IR#input=708530561 8650498 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4552, 4512, 676, 1560, 582, 1668, 580, 1830, 512, 600, 432, 692, 430, 542, 582, 608, 668, 392, 578, 1668, 582, 1666, 584, 1780, 572, 438, 584, 542, 580, 586, 682, 400, 742, 388, 576, 1668, 714, 1608, 508, 1666, 582, 670, 510, 488, 638, 566, 504, 540, 580, 666, 462, 572, 598, 496, 608, 518, 578, 1762, 596, 1558, 582, 1730, 680, 1510, 578, 1762, 502}; // UNKNOWN 7B6D1AC9 8650510 : EVENT: IR#input=2070747849 8650636 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4564, 4566, 590, 1582, 582, 1668, 728, 1604, 502, 612, 506, 544, 580, 542, 582, 676, 610, 384, 580, 1668, 582, 1694, 558, 1664, 580, 614, 508, 544, 748, 378, 580, 544, 586, 538, 588, 1660, 698, 1550, 614, 1640, 706, 414, 582, 542, 582, 550, 688, 430, 586, 544, 572, 544, 580, 610, 676, 384, 592, 1656, 580, 1752, 498, 1668, 726, 1524, 700, 1548, 582}; // UNKNOWN FA1907E8 8650648 : EVENT: IR#input=4195944424 8650806 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) IR: RAW TIMINGS: uint16_t rawData[67] = {4554, 4652, 428, 1668, 582, 1672, 576, 1668, 586, 538, 580, 542, 582, 664, 590, 468, 634, 578, 438, 1668, 586, 1736, 556, 1676, 526, 544, 580, 544, 580, 544, 580, 546, 654, 512, 540, 1664, 580, 1760, 488, 1668, 580, 550, 626, 660, 412, 646, 478, 554, 598, 518, 592, 532, 580, 544, 718, 406, 630, 1690, 512, 1822, 424, 1674, 608, 1636, 716, 1608, 566}; // UNKNOWN 1C10874B 8650819 : EVENT: IR#input=470845259 8650905 : IRSEND,RAW2,311531,38,554,582 8650909 : EVENT: IR#input=3958580554 8650990 : IRSEND,RAW2,311531,38,554,583 8650995 : EVENT: IR#input=3958580554 8651147 : IRSEND,RAW2,9U59A*39UA89C9A7AAA8AB7A99U9V9U9^10AR9,38,62,56 8651151 : EVENT: IR#input=3673365892

NEC 8763539 : WD : Uptime 146 ConnectFailures 0 FreeMem 11856 WiFiStatus 3 8766415 : IRSEND,NEC,20DF40BF 8766424 : EVENT: IR#input=551502015 8766477 : ACT : gpio,12,1 8766482 : SW : GPIO 12 Set to 1 8766485 : ACT : gpio,16,0 8766489 : SW : GPIO 16 Set to 0 8766676 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8766680 : EVENT: IR#input=4294967295 8766913 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8766922 : EVENT: IR#input=4294967295 8767076 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8767080 : EVENT: IR#input=4294967295 8767213 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8767217 : EVENT: IR#input=4294967295 8767376 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8767380 : EVENT: IR#input=4294967295 8767448 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8767452 : EVENT: IR#input=4294967295 8767676 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8767680 : EVENT: IR#input=4294967295 8767748 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8767752 : EVENT: IR#input=4294967295 8767976 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8767980 : EVENT: IR#input=4294967295 8768113 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8768117 : EVENT: IR#input=4294967295 8768276 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8768280 : EVENT: IR#input=4294967295 8768529 : EVENT: WiFi#Disconnected 8768679 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 47 m 37 s 8768680 : WIFI : Switch off WiFi 8768842 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8768846 : EVENT: IR#input=4294967295 8769010 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8769014 : EVENT: IR#input=4294967295 8769174 : WIFI : Set WiFi to STA 8769207 : WIFI : Connecting !-!-! attempt #0 8769212 : WIFI : Not configured in Station Mode!!: !-!-! 8769507 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8769511 : EVENT: IR#input=4294967295 8769685 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8769689 : EVENT: IR#input=4294967295 8769860 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8769864 : EVENT: IR#input=4294967295 8770102 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8770106 : EVENT: IR#input=4294967295 8770280 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8770284 : EVENT: IR#input=4294967295 8770457 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8770461 : EVENT: IR#input=4294967295 8770697 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8770701 : EVENT: IR#input=4294967295 8770869 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8770873 : EVENT: IR#input=4294967295 8771038 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8771042 : EVENT: IR#input=4294967295 8771284 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8771288 : EVENT: IR#input=4294967295 8771644 : IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 8771648 : EVENT: IR#input=4294967295

@jimmys01 Yes I think it could be...

[crankyoldgit]

Also ESPeasy checks if (irReceiver->decode(&results)) ten times per second, while IRrecvDumpV2 checks it every loop... Perhaps this is very slow?

I think for @ghtester's use case, yes it probably is. For 99% of use cases, it's probably not an issue. It could result in missed or partial messages if a device is hammering the ESP with IR messages.

e.g. 1/10th of a second is 100ms. That's longer than the entire length of time for a lot of IR messages.

The upshot is, that's fine for the first message in a burst, but it will have issues (depending) with subsequent messages in the burst. (i.e. holding down the button and the remote hammering out messages)

[crankyoldgit]

@ghtester I'll look at those samsung messages later (it's 2am here), but they look valid to me. (yes, I can pretty much read/parse the raw codes in my head now-a-days :) I'll confirm later.

[ghtester]

Thanks a lot for your effort and great help, it's not so urgent... ;-) Take a rest, good night! :-) I think that properly detected Samsung codes are OK. My avrtester says: Sams 07:07, the same key ESP detect (sometimes) as: IRSEND,SAMSUNG,E0E0E01F IR#input=3772833823 I don't care what code is returned (even if it's wrong) but it must be always the same for a specific key. ;-)

[crankyoldgit]

uint16_t rawData[67] = {4552, 4656, 554, 1540, 582, 1796, 452, 1770, 480, 542, 582, 542, 580, 542, 586, 674, 498, 496, 626, 1616, 588, 1686, 558, 1664, 690, 472, 550, 588, 672, 404, 722, 566, 414, 550, 574, 1670, 604, 1650, 574, 1680, 570, 548, 738, 380, 582, 548, 620, 502, 580, 708, 576, 384, 580, 544, 578, 560, 682, 1672, 466, 1688, 668, 1666, 468, 1668, 610, 1640, 720};

I did some analysis, and the SAMSUNG messages @ghtester is capturing via his remote is slightly out of the tolerance range the IR library expects for Samsung messages. (You can tweak this with the general kTolerance Try 30% or so. See: https://github.com/markszabo/IRremoteESP8266/blob/master/src/IRrecv.h#L35

I've marked the "too low" value in bold above. It's that value that causes it to be discarded. You can see the "every other" value is fairly higher. The spec and library are expecting a value of around 560 +/- ~25% (and some other factors) for these mark values. So part of the reason is @ghtester has analogue/external issues with his setup. It could be from any range of sources. i.e. Low batteries; a remote that's now slightly out of spec.; a poor hardware IR receiver module.; some other factor happening on the ESP during the signal reception.

If you look at some of the other captured signals, they have much higher values (in general) for those mark values.

Sadly, IR messages are not in a pure "digital" domain. There are and can be a whole load of external influencing factors.

TL;DR: The library is correctly saying "Whoa! This is not a correct/good samsung signal" due to it being a poor signal/capture. But it's damn close. You probably need to tweak it for your own personal situation.

[TD-er]

@crankyoldgit Just for my understanding, these are analog samples of bits received? Wouldn't it make sense to apply some automatic gain then? For example, if a received value is incorrect, try again with the tolerance increased by 10%-points. If that's helpful for decoding, then store that one as a good alternative and add a function to query that value and some stats on how often the set one was incorrectly decoded and the alternative could decode it. Then we can show those values in the plugin configuration to help improve the setup.

I've added such statistics to a number of plugins lately, to help setup the plugins. (SDM120 / SenseAir / MHz19 - CRC error , GPS a lot of receiver stats, BME/BMP280 - detected type, SenseAir - found serial number and model, etc.)

[crankyoldgit]

Just for my understanding, these are analog samples of bits received?

Kind-of.

Wouldn't it make sense to apply some automatic gain then?

TL;DR: It already is. On several levels.

Longer version: Lets take for instance, this Samsung protocol message. First layer is done by the hardware IR module itself. Ultimately, it's job is converting the carrier and frequency demodulation of the analogue IR signal and involves auto gain control. It converts that into a logical voltage level of a continuous "on" or "off" signal/pulse. That in turn is converted to usecond timings of the length of said pulses via a very tight interrupt routine on the ESP. That's the last of the analogue conversions. At which point we are fully digitised. i.e. we have a signal of some sort. Now begins the job of the signal processing to try to fit the signal to known patterns of timings for ~60 different protocols. After discarding obviously too short messages for a given protocol, it starts trying to fit each individual pulse into a profile for a protocol (+/- a protocol dependant tolerance percentage.) Note: some protocols only differ from each other solely on some of these timings. In some protocols, we are not talking just single bits for each pulse, but almost all have a pulse length encoding. i.e. a slightly longer bit is a zero or a one. Some protocols even store several bits on a single pulse. So, extending the "gain"/tolerance can very quickly lead to incorrect results or even different protocol matching. i.e. You can't have the tolerances overlap between a zero signal and a one. That typically happens around the 40% mark for most protocols. Now, back to the Samsung implementation in the library. It also has an additional level in that it tries to dynamically calibrate itself based on the incoming signal. i.e. if the mark or space signals are slightly shorter or longer than usual in a given signal, adjust it's expected values to the new timings it's being presented with. Sort of self-re-calibration per se.

So, sure, you could keep crank up the "gain" and eventually (given enough signal) you'll match anything. And we give people a knob to do just that if they want. In the single protocol world, this is kind of what happens. e.g. a TV can have very wide tolerances as it is expecting only one type of signal. Everything else it can safely ignore, and if it does happen to cross match with some other remote's protocol, it doesn't have to act if the numeric code produced doesn't match one of the expected codes (e.g. vol up etc). However, if your job is to be a "babel fish" and try to accept every possible input and report what it is without context, you end up having to be more discerning. i.e. Less tolerant.

i.e. It is entirely possible to turn off every other protocol in the library except Samsung, and crank up the tolerances so you can match just about any poor samsung messagem and btw, I'm only interested in 20 odd numbers out of 2^32 of them. e.g. You are kind-of supplying some context to the library, like "Hey, I only want you to accept samsung and don't care to much how bad it is, but I'm only interested in the possible values I expect from your particular remote."

That's different to "Hey, listen to every IR signal, and tell me what language it is speaking, and what the letters are in each messages with no idea what of the person talking to you is about to say and in what language", which is what the library, and your implementation is trying to do.

[ghtester]

@crankyoldgit Thanks for the excellent analysis & details about library. I have checked the batteries, they're about 1,3V. Tried to replace them with a new ones (measured 1,5V ) but there was no positive progress. Also tried another Samsung remote control with new batteries, it's always the same - too many errorneous results. Also tested batteries in my LG (NEC), the're about 1,4V so it should be OK but there are also detection errors. Tested on 2 ESPs with different IR sensors, different plugins but the results are similar. Also the third ESP with old ESP Easy firmware works almost 100% reliable with the same RC (yes there's a different IR sensor type but also grabbed from some TV, most likely Samsung). @jimmys01 Could you please recompile the custom firmware with kTolerance about 33% ? Perhaps based on firmware15. Tested firmware512, so far did not reboot but detection error issue is the same and for Samsung it does not send an autorepeat codes (when a key is long pressed) due to detected full buffer.

[TD-er]

@crankyoldgit Thanks for explaining :) So we should somehow add some selectors in the ESPeasy plugin to give the library some context and also add some of the dials and knobs to make it work more reliable on the remotes at hand.

That sounds easy, but for the few times I've looked into the code, it looks like those decisions to select brands need a recompile and that's not practical.

[crankyoldgit]

Sadly, correct. Currently most of those changes are compile-time options. Feel free to file a feature request/issue for a changeable irrecv object default tolerance setting. That should be doable with considerable effort.

I'm more reluctant to change the current irrecv.decode() method from a compile time option to a dynamic one, but I guess we could add irrecv.selectiveDecode() after setting some parameters etc. OR you could call the individual decode routines directly. e.g. irrecv.decodeSAMSUNG(&decode_results);

I'm hesitant to add dynamic selectivity to the default/main routine as that routine is expensive as it is and is optimised (sort of) for speed and smaller memory footprint.

Again, feel free to file a feature request.

[ghtester]

Thanks to all contributors, tested the latest firmware 20190413 but I am still sometimes experiencing the crashes using SAMSUNG RC after long keypress:

... ... 3195529 : EVENT: IR#input=3772833823 3195554 : ACT : gpio,12,1 3195559 : SW : GPIO 12 Set to 1 3195562 : ACT : gpio,16,0 3195566 : SW : GPIO 16 Set to 0 3196589 : IRSEND,SAMSUNG,E0E0D02F 3196593 : EVENT: IR#input=3772829743 3196622 : ACT : gpio,12,0 3196627 : SW : GPIO 12 Set to 0 3196630 : ACT : gpio,16,1 3196635 : SW : GPIO 16 Set to 1 3197526 : IRSEND,SAMSUNG,E0E0E01F 3197538 : EVENT: IR#input=3772833823 3197590 : ACT : gpio,12,1 3197596 : SW : GPIO 12 Set to 1 3197599 : ACT : gpio,16,0 3197604 : SW : GPIO 16 Set to 0 3198426 : IRSEND,RAW2,^2O^2C3BSB9BAA9B9B93BS5B9BSBUAB8S6B9BSB9BSBSBUARB^OT^2N^2C3BS3B9BABABTBTATBBA9D8BAB9ATBTBABT3BAB9BABABTB9BSBSBTBSB,38,52,59 3198430 : EVENT: IR#input=2985286521 3199289 : IRSEND,SAMSUNG,E0E0D02F 3199293 : EVENT: IR#input=3772829743 3199322 : ACT : gpio,12,0 3199327 : SW : GPIO 12 Set to 0 3199330 : ACT : gpio,16,1 3199335 : SW : GPIO 16 Set to 1 3200188 : IRSEND,SAMSUNG,E0E0E01F 3200193 : EVENT: IR#input=3772833823 3200218 : ACT : gpio,12,1 3200223 : SW : GPIO 12 Set to 1 3200226 : ACT : gpio,16,0 3200230 : SW : GPIO 16 Set to 0 3201126 : IRSEND,RAW2,^2P^2FBUBTBT5BA3BTBABABDB99ACSBTBABU6BABTBA4BTB^PP^2P^2FBTBUBT5BABTBTDS*3BAC9BABTBTBABTBABABCA9BABABTBABTCTBTBTE,38,51,57 3201130 : EVENT: IR#input=1394024849 3203554 : IR: WARNING, IR code is too big for buffer. Try pressing the transmiter button only momenteraly 3204810 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output)

Exception (28): epc1=0x402783f8 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont sp: 3ffffc00 end: 3fffffd0 offset: 01a0

stack>>> 3ffffda0: 3fff7534 00001050 3fff7534 40100698 3ffffdb0: 00000024 40271eaf 00003988 40270f2c 3ffffdc0: 0000020b 00000001 3ffffe4c 402752dc 3ffffdd0: 00000242 3fff1978 3ffffe4c 40231ab0 3ffffde0: 00001050 3ffffe40 3ffffe40 00000002 3ffffdf0: 00000000 3ffffe90 3fff1978 40235e6b 3ffffe00: 3fff1978 3ffffe90 3ffffe40 401006dc 3ffffe10: 00000001 00000001 3ffffe40 00000002 3ffffe20: 3fff1978 3ffffe90 3fff1978 40235f24 3ffffe30: 3fff1978 3ffffe90 3fff1978 402541d2 3ffffe40: 00000000 00000000 00000000 3fffa054 3ffffe50: 0000103f 00001030 3fff81dc 0000001f 3ffffe60: 00000011 00000000 402ad89e 402225ea 3ffffe70: 00000000 00000000 00000000 00000002 3ffffe80: 3fff20bc 00000005 3ffffe90 402392a9 < 3ffffe90: 3fff8194 0000000f 00000000 3fff8fd4 3ffffea0: 0000000f 00000000 3fff9064 0000000f 3ffffeb0: 00000000 3fff7664 0000000f 00000000 3ffffec0: 3fff81c4 0000000f 00000000 00000000 3ffffed0: 00000000 00000000 00000000 00000000 3ffffee0: 00000000 00000000 00000200 02140800 3ffffef0: 00001005 3fff2250 3fff5458 40232908 3fffff00: 0000000f bf038541 00000310 3fff2702 3fffff10: bf028b9a 3fffff40 0030e66b 10000002 3fffff20: bf028c24 3fff20bc 3ffeb010 40252b31 3fffff30: 3fff1fd4 bf028b79 00000002 40232a25 3fffff40: 0030e66b 10000002 40272fe0 10000002 3fffff50: 3fff1fd4 bf028b79 3ffeb010 4026e235 3fffff60: 3fff1fd4 bf028b79 00000002 4026e351 3fffff70: 3fffdad0 0030e607 bf028b6c 4024072c 3fffff80: 00000027 00000000 3fff20a8 3fff3548 3fffff90: 3fffdad0 00000000 3fff20a8 4026e461 3fffffa0: 00000000 00000000 00000000 40273001 3fffffb0: 3fffdad0 00000000 3fff3542 40273070 3fffffc0: feefeffe feefeffe 3ffe87d0 40100721 <<<stack<<<

last failed alloc call: 40271EAF(4176)

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d vbb28d4a3 ~ld ٪U58 :

INIT : Booting version: mega-20190413 (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support) 59 : INIT : Free RAM:28216 60 : INIT : Warm boot #2 - ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d vbb28d4a3 ~ld ٪U59 :

INIT : Booting version: mega-20190413 (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support) 60 : INIT : Free RAM:28216 61 : INIT : Warm boot #3 - Restart Reason: Hardware Watchdog 63 : FS : Mounting... 88 : FS : Mount successful, used 76806 bytes of 957314 463 : CRC : program checksum ...OK 475 : CRC : SecuritySettings CRC ...OK 476 : CRC : binary has changed since last save of Settings 585 : INIT : Free RAM:25368 587 : INIT : I2C 587 : INIT : SPI not enabled 657 : PN532: Found chip PN532 FW: 1.6 IR RX Init 674 : INIT: IR TX 1763 : INFO : Plugins: 49 [Normal] [IR] (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support) 1765 : EVENT: System#Wake ... ... ...

... ... 7086461 : SW : GPIO 12 Set to 1 7086464 : ACT : gpio,16,0 7086469 : SW : GPIO 16 Set to 0 7087212 : IRSEND,SAMSUNG,E0E0D02F 7087224 : EVENT: IR#input=3772829743 7087263 : ACT : gpio,12,0 7087268 : SW : GPIO 12 Set to 0 7087272 : ACT : gpio,16,1 7087277 : SW : GPIO 16 Set to 1 7089562 : IRSEND,SAMSUNG,E0E0E01F 7089566 : EVENT: IR#input=3772833823 7089601 : ACT : gpio,12,1 7089607 : SW : GPIO 12 Set to 1 7089610 : ACT : gpio,16,0 7089615 : SW : GPIO 16 Set to 0 7090050 : IRSEND,SAMSUNG,E0E0E01F 7090054 : EVENT: IR#input=3772833823 7090089 : ACT : gpio,12,1 7090095 : SW : GPIO 12 Set to 1 7090098 : ACT : gpio,16,0 7090103 : SW : GPIO 16 Set to 0 7091866 : IR: WARNING, IR code is too big for buffer. Try pressing the transmiter button only momenteraly 7093798 : IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output)

Exception (28): epc1=0x402783f8 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont sp: 3ffffc00 end: 3fffffd0 offset: 01a0

stack>>> 3ffffda0: 3fff36a4 0000090f 0000090f 4010020c 3ffffdb0: 0000003f 0000006b 3fff23f4 40270f2c 3ffffdc0: 000002d5 00000001 3ffffe4c 402752dc 3ffffdd0: 00000248 3fff1978 3ffffe4c 40231ab0 3ffffde0: 000016a0 3ffffe40 3ffffe40 00000002 3ffffdf0: 00000000 3ffffe90 3fff1978 40235e6b 3ffffe00: 3fff1978 3ffffe90 3ffffe40 401006dc 3ffffe10: 00000001 00000001 3ffffe40 00000002 3ffffe20: 3fff1978 3ffffe90 3fff1978 40235f24 3ffffe30: 3fff1978 3ffffe90 3fff1978 402541d2 3ffffe40: 00000000 00000000 00000000 3fff9574 3ffffe50: 0000168f 00001687 3fff7f34 0000001f 3ffffe60: 00000011 00000000 402ad89e 402225ea 3ffffe70: 00000000 00000000 00000000 00000002 3ffffe80: 3fff20bc 00000005 3ffffe90 402392a9 < 3ffffe90: 3fff7b24 0000000f 00000000 3fff7ad4 3ffffea0: 0000000f 00000000 3fff7724 0000000f 3ffffeb0: 00000000 3fff456c 0000000f 00000000 3ffffec0: 3fff4584 0000000f 00000000 00000000 3ffffed0: 00000000 00000000 00000000 00000000 3ffffee0: 00000000 00000000 00000200 02140800 3ffffef0: 00001005 3fff2250 3fff5460 40232908 3fffff00: 0000000f a6cfda65 0000019a 3fff2702 3fffff10: a6cee097 3fffff40 006c3d8b 10000002 3fffff20: a6cee129 3fff20bc 3ffeb010 40252b31 3fffff30: 3fff1fd4 a6cee072 00000002 40232a25 3fffff40: 006c3d8b 10000002 40272fe0 10000002 3fffff50: 3fff1fd4 a6cee072 3ffeb010 4026e235 3fffff60: 3fff1fd4 a6cee072 00000002 4026e351 3fffff70: 3fffdad0 006c3d27 a6cee061 4024072c 3fffff80: 00000027 00000000 3fff20a8 3fff3548 3fffff90: 3fffdad0 00000000 3fff20a8 4026e461 3fffffa0: 00000000 00000000 00000000 40273001 3fffffb0: 3fffdad0 00000000 3fff3542 40273070 3fffffc0: feefeffe feefeffe 3ffe87d0 40100721 <<<stack<<<

last failed alloc call: 40271EAF(5792)

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d vbb28d4a3 ~ld ٪U59 :

INIT : Booting version: mega-20190413 (ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 PUYA support) 60 : INIT : Free RAM:28216 61 : INIT : Warm boot #7 - Restart Reason: Exception 63 : FS : Mounting... 88 : FS : Mount successful, used 77057 bytes of 957314 464 : CRC : program checksum ...OK 501 : CRC : SecuritySettings CRC ...OK ... ...

[TD-er]

Yep, looks like a memory allocation error.

[rivman]

Log esp easy.txt Hello. Since I have exact the same problem I will not open a new Issue. Here is the log file :

Copied: "264627: IR: No replay solutions found! Press button again or try RAW encoding (timmings are in the serial output) 264673: EVENT: Receiver#IR=3711532465 270296: IRSEND,NEC,2FD48B7 270300: EVENT: Receiver#IR=50153655 270316: ACT : gpio,13,1 270320: SW : GPIO 13 Set to 1 270323: ACT : timerSet,1,1 270332: Command: timerset 270349: SW : GPIO=13 State=1 Output value=1 270384: EVENT: Ampli#State=1.00 271510: EVENT: Rules#Timer=1 271524: ACT : gpio,13,0 271527: SW : GPIO 13 Set to 0 271593: SW : GPIO=13 State=0 Output value=0 271597: EVENT: Ampli#State=0.00 272080: WD : Uptime 5 ConnectFailures 0 FreeMem 10240 WiFiStatus 3 276740: IRSEND,RAW2,^2K86515361435535153515351515335153515353513535^27^2K45,38,108,563 276778: EVENT: Receiver#IR=4287175326 276815: IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 276819: EVENT: Receiver#IR=4294967295 276994: IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 276998: EVENT: Receiver#IR=4294967295 287596: IRSEND,NEC,2FD48B7 287600: EVENT: Receiver#IR=50153655 287617: ACT : gpio,13,1 287620: SW : GPIO 13 Set to 1 287624: ACT : timerSet,1,1 287633: Command: timerset 287647: SW : GPIO=13 State=1 Output value=1 287682: EVENT: Ampli#State=1.00 289510: EVENT: Rules#Timer=1 289524: ACT : gpio,13,0 289528: SW : GPIO 13 Set to 0 289608: SW : GPIO=13 State=0 Output value=0 289612: EVENT: Ampli#State=0.00 291510: EVENT: Clock#Time=Fri,12:51 302064: WD : Uptime 5 ConnectFailures 0 FreeMem 11800 WiFiStatus 3 302397: IRSEND,NEC,2FD48B7 302431: EVENT: Receiver#IR=50153655 302447: ACT : gpio,13,1 302451: SW : GPIO 13 Set to 1 302455: ACT : timerSet,1,1 302463: Command: timerset 302477: SW : GPIO=13 State=1 Output value=1 302513: EVENT: Ampli#State=1.00 302534: IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 302568: EVENT: Receiver#IR=4294967295 303510: EVENT: Rules#Timer=1 303525: ACT : gpio,13,0 303529: SW : GPIO 13 Set to 0 303593: SW : GPIO=13 State=0 Output value=0 303628: EVENT: Ampli#State=0.00 306523: IRSEND,RAW2,^2L8614145153516535153614351515335153515353513535^28^2L45,38,107,562 306558: EVENT: Receiver#IR=643437391 317626: IRSEND,RAW2,^5I^1G6B6BJB6BJBKBI3BJB6BJB6BJB6B6BJ96B8C4BJB6BJBJB6BJBJBL7^DS^5DPC,38,52,91 317630: EVENT: Receiver#IR=2399507405 326996: IRSEND,NEC,2FD48B7 327000: EVENT: Receiver#IR=50153655 327016: ACT : gpio,13,1 327020: SW : GPIO 13 Set to 1 327023: ACT : timerSet,1,1 327032: Command: timerset 327045: SW : GPIO=13 State=1 Output value=1 327081: EVENT: Ampli#State=1.00 327101: IRSEND,NEC (Repeat),FFFFFFFFFFFFFFFF 327135: EVENT: Receiver#IR=4294967295 328510: EVENT: Rules#Timer=1 328524: ACT : gpio,13,0 328528: SW : GPIO 13 Set to 0 328593: SW : GPIO=13 State=0 Output value=0 328629: EVENT: Ampli#State=0.00

As you can see (and from field testing) 1 of 10 times the real code (2FD48B7) is received (and the rule fire up, the rule is a simple GPIO state change). Using latest stable mega-20190630 . To be sure that isn't a hardware issue, I did loaded the ESP8066 IR Receive library from https://github.com/crankyoldgit/IRremoteESP8266 and used the DumpV2 that works without a single error (more than 50 tests, long press also) . For not I use that code with some IF to control the GPIO, but it will be very nice to have the IR Decode working on ESPEasy, even if it mean to flash a specific file due to lack of space for other libraries. How to disable IR Send since I do not use it.

Using a Wemos D1, with a TSOP8238 IR Receiver.

Many thanks.