ESPEasy 🚀 - IR RX hardly usable in latest releases

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?

TD-er on 4 Apr 2019

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.

ghtester on 4 Apr 2019

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.

jimmys01 on 4 Apr 2019

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
<<

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
...
...

ghtester on 5 Apr 2019

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

jimmys01 on 5 Apr 2019

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.

ghtester on 5 Apr 2019

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
:-)

jimmys01 on 5 Apr 2019

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.

ghtester on 5 Apr 2019

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

jimmys01 on 6 Apr 2019

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.

ghtester on 8 Apr 2019

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.

jimmys01 on 9 Apr 2019

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.

ghtester on 10 Apr 2019

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)

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.

TD-er on 10 Apr 2019

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

jimmys01 on 10 Apr 2019

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.

ghtester on 10 Apr 2019

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);

crankyoldgit on 10 Apr 2019

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

jimmys01 on 10 Apr 2019

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,

crankyoldgit on 10 Apr 2019

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

jimmys01 on 10 Apr 2019

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 on 10 Apr 2019

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

I gathered. Hence the curiosity.

crankyoldgit on 10 Apr 2019

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.

crankyoldgit on 10 Apr 2019

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

ghtester on 10 Apr 2019

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

TD-er on 10 Apr 2019

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 on 11 Apr 2019

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

Happy to help if @ summoned. :-)

crankyoldgit on 11 Apr 2019

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.

ghtester on 11 Apr 2019

@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. ;-)

crankyoldgit on 11 Apr 2019

👍1

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...

ghtester on 11 Apr 2019

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

jimmys01 on 11 Apr 2019

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

ghtester on 11 Apr 2019

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 on 11 Apr 2019

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

jimmys01 on 11 Apr 2019

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 on 11 Apr 2019

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...

ghtester on 11 Apr 2019

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)

crankyoldgit on 11 Apr 2019

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

jimmys01 on 11 Apr 2019

👍1

@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...

ghtester on 11 Apr 2019

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 on 11 Apr 2019

@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.

crankyoldgit on 11 Apr 2019

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. ;-)

ghtester on 11 Apr 2019

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.

crankyoldgit on 12 Apr 2019

@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.)

TD-er on 12 Apr 2019

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.

crankyoldgit on 12 Apr 2019

👍1

@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.

ghtester on 12 Apr 2019

@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.

TD-er on 12 Apr 2019

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.

crankyoldgit on 12 Apr 2019

👍1

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
<<

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
<<

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
...
...

ghtester on 13 Apr 2019

Yep, looks like a memory allocation error.

TD-er on 13 Apr 2019

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.

rivman on 29 Jul 2019

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?

jimmys01 on 29 Jul 2019

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

ghtester on 29 Jul 2019

👍1

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)

crankyoldgit on 30 Jul 2019

👍3 🚀1

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.

ghtester on 1 Oct 2019

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?

TD-er on 6 Oct 2019

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

crankyoldgit on 6 Oct 2019

👍1

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.

jimmys01 on 6 Oct 2019

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! :-)

ghtester on 7 Oct 2019

Espeasy: IR RX hardly usable in latest releases

Most helpful comment

All 58 comments

Related issues