Tasmota: Arilux LC03 IR receives garbage on 6.5.0

[r31337]

BUG DESCRIPTION

Arilux LC03 RGB driver with IR Receiver generates constant IR command garbage and no longer receives NEC codes correctly on 6.5.0 release and latest development release (6.5.0.12 from thehackbox ). All using 2.3.0 core. Confirmed working normally in 6.4.1 and prior releases.

REQUESTED INFORMATION

• [x] Read the Contributing Guide and Policy and the Code of Conduct
• [x] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
• [x] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
• [x] Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers)
• [x] Searched the problem in the chat (https://discord.gg/Ks2Kzd4)
• [x] Device used (i.e. Sonoff Basic) : Arilux LC03
• [x] Tasmota binary firmware version number used : 6.5.0 & 6.5.0.12 / (pre-compiled)
• [x] Development IDE - Compiler / Upload tools used : N/A / OTA
• [x] Provide the output of command status 0 :

STATUS 0 OUTPUT HERE:
15:04:48 MQT: stat/TV-LED-1/STATUS = {"Status":{"Module":18,"FriendlyName":["TV-LED-1"],"Topic":"TV-LED-1","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
15:04:48 MQT: stat/TV-LED-1/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/020300/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T00:00:22","StartupUTC":"2019-05-23T14:04:26","Sleep":50,"CfgHolder":4617,"BootCount":52,"SaveCount":1099,"SaveAddress":"FA000"}}
15:04:48 MQT: stat/TV-LED-1/STATUS2 = {"StatusFWR":{"Version":"6.5.0.12(644d89c-sonoff)","BuildDateTime":"2019-05-23T13:01:38","Boot":7,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
15:04:49 MQT: stat/TV-LED-1/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["nope","nope1"],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00028009","280500000100000000000000000000000000","00000001"]}}
15:04:49 MQT: stat/TV-LED-1/STATUS4 = {"StatusMEM":{"ProgramSize":523,"Free":480,"Heap":13,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","0FDAE394","001783A0","23B617CC","01003BC0"]}}
15:04:49 MQT: stat/TV-LED-1/STATUS5 = {"StatusNET":{"Hostname":"TV-LED-1-2733","IPAddress":"192.168.1.26","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"60:01:94:96:8A:AD","Webserver":2,"WifiConfig":4}}
15:04:49 MQT: stat/TV-LED-1/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.200","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_968AAD","MqttUser":"DVES_USER","MqttCount":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
15:04:49 MQT: stat/TV-LED-1/STATUS7 = {"StatusTIM":{"UTC":"Thu May 23 14:04:49 2019","Local":"Thu May 23 15:04:49 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"04:59","Sunset":"20:34"}}
15:04:49 MQT: stat/TV-LED-1/STATUS10 = {"StatusSNS":{"Time":"2019-05-23T15:04:49"}}
15:04:49 MQT: stat/TV-LED-1/STATUS11 = {"StatusSTS":{"Time":"2019-05-23T15:04:49","Uptime":"0T00:00:23","SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"OFF","Dimmer":20,"Color":"51,0,0","HSBColor":"0,100,20","Channel":[20,0,0],"Scheme":0,"Fade":"ON","Speed":6,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"nope","BSSId":"edit","Channel":6,"RSSI":76,"LinkCount":1,"Downtime":"0T00:00:06"}}}
15:04:49 MQT: tele/TV-LED-1/RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":3,"Data":"0x0CAF41CA"}}

• [x] Provide the output of console when you experience your issue if apply :

CONSOLE OUTPUT HERE:
15:14:22 MQT: tele/TV-LED-1/RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":3,"Data":"0x25AE7EE0"}}
15:14:23 IRR: Echo 0, RawLen 8, Overflow 0, Bits 4, Value 0xE7E70B67, Decode -1
15:14:23 MQT: tele/TV-LED-1/RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":4,"Data":"0xE7E70B67"}}
15:14:24 IRR: Echo 0, RawLen 6, Overflow 0, Bits 3, Value 0x24AE7D4F, Decode -1
15:14:24 MQT: tele/TV-LED-1/RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":3,"Data":"0x24AE7D4F"}}

TO REPRODUCE

Flash release newer than 6.4.1. Set Generic module. GPIO4 set to IRRecv.

EXPECTED BEHAVIOUR

No garbage IR and normal reception of NEC codes as per 6.4.1 release.

SCREENSHOTS

N/A

ADDITIONAL CONTEXT

N/A

[ascillato2]

Hi,

Please, can you share the correct codes you receive using 6.4.1 and the status 0 of that? Thanks

[r31337]

Hi Adrian,

I was premature in saying 6.4.1 was OK, I noticed some strange behaviour and then saw the garbage IR in the console as per 6.5.0. I'm not sure why this was not immediately obvious as it was with 6.5.0.

I should also be clear and say the garbage IR is received to console without any IR transmission. It is just a constant flow of messages, I am not sending from any other device.

I have reverted back to 6.2.1 which was working well for > 1 month without issue. Again there is no garbage messages and everything works well now. Example below is from 6.2.1.

17:27:23 MQT: tele/TV-LED-1/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"F7A05F"}}
17:27:28 MQT: tele/TV-LED-1/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"F7609F"}}
17:27:32 MQT: tele/TV-LED-1/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"F740BF"}}

17:28:50 MQT: stat/TV-LED-1/STATUS = {"Status":{"Module":18,"FriendlyName":["TV-LED-1"],"Topic":"TV-LED-1","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}}
17:28:50 MQT: stat/TV-LED-1/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/020300/sonoff.bin","RestartReason":"Software/System restart","Uptime":"1T01:43:15","StartupUTC":"2019-05-25T14:45:35","Sleep":50,"BootCount":56,"SaveCount":1124,"SaveAddress":"FA000"}}
17:28:50 MQT: stat/TV-LED-1/STATUS2 = {"StatusFWR":{"Version":"6.2.1","BuildDateTime":"2018-09-09T16:50:26","Boot":7,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
17:28:50 MQT: stat/TV-LED-1/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["nope","nope1"],"TelePeriod":300,"SetOption":["00028009","558180C0","00000001"]}}
17:28:50 MQT: stat/TV-LED-1/STATUS4 = {"StatusMEM":{"ProgramSize":471,"Free":532,"Heap":15,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3,"Features":["00000809","0FDAE794","000003A0","23B617CE","00000000"]}}
17:28:50 MQT: stat/TV-LED-1/STATUS5 = {"StatusNET":{"Hostname":"TV-LED-1-2733","IPAddress":"192.168.1.26","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"edit","Webserver":2,"WifiConfig":4}}
17:28:50 MQT: stat/TV-LED-1/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.200","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_968AAD","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
17:28:50 MQT: stat/TV-LED-1/STATUS7 = {"StatusTIM":{"UTC":"Sun May 26 16:28:50 2019","Local":"Sun May 26 17:28:50 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":1,"Sunrise":"04:56","Sunset":"20:38"}}
17:28:51 MQT: stat/TV-LED-1/STATUS10 = {"StatusSNS":{"Time":"2019-05-26T17:28:50"}}
17:28:51 MQT: stat/TV-LED-1/STATUS11 = {"StatusSTS":{"Time":"2019-05-26T17:28:51","Uptime":"1T01:43:16","Vcc":2.756,"POWER":"OFF","Dimmer":20,"Color":"0,0,51","HSBColor":"240,100,20","Channel":[0,0,20],"Scheme":0,"Fade":"ON","Speed":6,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"nope","RSSI":66,"APMac":"edit"}}}

Thank you.

[r31337]

I just set on weblog 4 on 6.2.1 and realised it too is receiving a lot of ghost transmissions? Example:

17:40:12 IRR: RawLen 10, Bits 5, Value 3FFF6854, Decode 1962822248
17:40:12 IRR: RawLen 6, Bits 3, Value 3FFF6854, Decode 581859881
17:40:13 IRR: RawLen 8, Bits 4, Value 3FFF6854, Decode 1780065488
17:40:14 IRR: RawLen 9, Bits 4, Value 3FFF6854, Decode -1663734476
17:40:17 IRR: RawLen 16, Bits 8, Value 3FFF6854, Decode 354735182
17:40:17 IRR: RawLen 6, Bits 3, Value 3FFF6854, Decode 1253111733

Perhaps this was always happening but 6.2.1 does not report a tele/RESULT for the garbage, but 6.5.0 does?

[arendst]

Refering to "The Talking Heads": "You may ask yourselfs where does the garbage come from."

IR is a communication means using LIGHT. As such it is sensitive to any light it receives. From this light it has to decide if it is a communication message or just light...

On request of other users the IR receive handler has been made more responsive to more protocols. Any additional protocol makes decoding more of a problem. The advantage to this request is that you now have full compile control over it's sensitivity.

So what you should do is:
1) detect when the garbage is received. During day and/or night? Are there any lights on when the garbage occurs (There are AriLux controllers using RF for a reason you know).
2) if so, move the receiver away from the light and see what happens.
3) as you want to receive NEC codes (32-bits), change the receive sensitivity by updating define IR_RCV_MIN_UNKNOWN_SIZE from current 6 to at least 24. This will discard any message with a decoded length of 24 bits and should stop your garbage as it seems to be smaller that 16 bits (RawLen).

[joba-1]

+1 for Talking Heads reference :)

[r31337]

Thanks Theo.

1&2 - Makes sense. I expect that the lack of garbage reported when briefly testing 6.4.1 was due to being night-time and perhaps not having the LEDs powered on at the time of checking. I will move the IR receiver further from the LEDs.

3 - Excellent, that sounds like a good workaround, thank you.

I understand it is not really a bug but an issue with interference in my setup, but there is still the point that reception of NEC worked well in 6.2.1 despite the noisy environment, but not well in 6.5.0 due to the sensitivity changes.

Perhaps this needs some consideration? Can the receive sensitivity config be broken out into a command instead of define?

[arendst]

I'll look in to the possibility of changing sensitivity online. It depends on the flexibility of the library.

Investigating.

[arendst]

With the latest release command SetOption38 6..255 is provided. Changing the default value of 6 to 100 will increase protocol detection sensitivity while decreasing the amount of UNKNOWN's.

Example:

11:50:29 IRR: Echo 0, RawLen 38, Overflow 0, Bits 19, Value 0xBEC4D6E3, Decode -1
11:50:29 MQT: tele/bridgeir/RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":19,"Data":"0xBEC4D6E3","RawData":[306,72,374,946,1636,1868,188,108,730,74,432,102,118,944,240,2378,1478,118,136,988,606,142,106,1068,90,60,394,1370,96,58,418,900,660,2022,692,350,652],"RawDataInfo":[37,37,0]}}
11:50:37 IRR: Echo 0, RawLen 52, Overflow 0, Bits 26, Value 0xAAF0D6FF, Decode -1
11:50:37 MQT: tele/bridgeir/RESULT = {"IrReceived":{"Protocol":"UNKNOWN","Bits":26,"Data":"0xAAF0D6FF","RawData":[608,1138,436,146,102,1018,214,428,130,918,294,240,80,72,500,2176,80,1868,666,152,182,330,314,1074,290,108,290,1460,118,214,80,992,384,174,96,70,102,900,292,82,252,62,134,1172,76,192,274,1926,290,62,384],"RawDataInfo":[51,51,0]}}
11:50:37 IRR: Echo 0, RawLen 44, Overflow 0, Bits 22, Value 0xA41D1FE, Decode -1
11:50:50 CMD: setoption38 100
11:50:50 SRC: WebConsole from 192.168.2.1
11:50:50 RSL: Group 0, Index 38, Command SETOPTION, Data 100
11:50:50 MQT: stat/bridgeir/RESULT = {"SetOption38":"100"}
11:50:50 CFG: Saved to flash at F4, Count 328, Bytes 3584
11:51:10 IRR: Echo 0, RawLen 20, Overflow 0, Bits 12, Value 0x486, Decode 1
11:51:10 MQT: tele/bridgeir/RESULT = {"IrReceived":{"Protocol":"RC5","Bits":12,"Data":"0x486","RawData":[896,874,1764,1778,1790,874,872,1810,1736,948,882,870,890,916,896,1770,924,864,1736],"RawDataInfo":[19,19,0]}}
11:51:10 IRR: Echo 0, RawLen 20, Overflow 0, Bits 12, Value 0x486, Decode 1

Here UNKNOWN's were received using the default setting of 6. Changing it to 100 discards UNKNOWN's but will still allow reception of KNOWN protocols.

[meingraham]

Not having looked at the code, apologies in advance if this suggestion is completely whacked.

Since supporting additional protocols makes the detection of real data vs garbage more prone sensitive to misdetection due to having to open up the "scanning" window to detect from the many possible data pattern for all the protocols possible... could selection of protocols be subsetted by the user? The user would select only the protocols that at relevant in their environment. This way the code gets "honed" to consider only a smaller set of protocols as valid... so better garbage detection. Ideally the selection of valid protocols would be a runtime configuration, but if that isn't possible, a set of #defines for protocols to compile in.

I really don't have a horse in this race as I am not currently using any IR in my home automation. I just wanted to share a possible alternative in the event that sensitivity algorithms are not available or feasible.

Who knows, I may find a need to implement IR automation down the road.

Cheers!

Mike

P.S. No need to respond to explain if my concept is whacked 😉

[arendst]

Mike, you're opening a can of IR worms here. I already made a minor selection of protocols out of the abundance of supported protocols by the IRRemote library. You might have seen requests for protocols not default in Tasmota too.

To provide this functionality users will need to re-compile as online enabling/disabling protocols is not possible while adding all protocols to Tasmota also is a no-go due to size. So likely they will need to re-compile as their protocol just wasn't in the default set. I don't like that as I prefer online tweaks over re-compilation.

[meingraham]

"online enabling/disabling protocols is not possible while adding all protocols to Tasmota also is a no-go due to size" - I suspected it might not be feasible due to program size considerations. One could always disable Domoticz to make room (that's a joke) ;-)

"I prefer online tweaks over re-compilation" - my preference as well.

I hadn't seen your SetOption38 response when I was replying. That probably addresses most issues... and if not, folks can disable unneeded protocols and re-compile.

Cheers!

[ascillato2]

@r31337

Hi, have you tried latest fixes? Your issue is solved?

[ascillato2]

Closing this issue as there is no feedback

[r31337]

Will get time to test new firmware next week probably, will let you know.

[crankyoldgit]

To provide this functionality users will need to re-compile as online enabling/disabling protocols is not possible while adding all protocols to Tasmota also is a no-go due to size. So likely they will need to re-compile as their protocol just wasn't in the default set. I don't like that as I prefer online tweaks over re-compilation.

As the owner of said IR library. I second the comments by @arendst.
I'm adding an IR protocol about every two+ weeks it seems. Even our example code just doing every IR protocol supported + MQTT has trouble fitting into 500k. Sadly there is no option but to exclude at compile time to fit it into the smaller ESP8266's.

[meingraham]

@arendst @crankyoldgit

This had slipped my mind. I'd meant to follow up to ask how protocols would be selected/ignored at compile time. I'm inquiring so that I may update the recommendation and procedure to the wiki.

Mike

[crankyoldgit]

See: https://github.com/arendst/Sonoff-Tasmota/blob/development/lib/IRremoteESP8266-2.6.0/src/IRremoteESP8266.h#L55 & https://github.com/arendst/Sonoff-Tasmota/blob/development/lib/IRremoteESP8266-2.6.0/src/IRremoteESP8266.h#L230 for at least part of it. There is probably more to it than that (i.e. the Tasmota side), but that's the part I know/am intimately familiar with.

[meingraham]

So, manually edit lib/IRremoteESP8266-2.6.0; yes?

This seems like all that needs to be included in addition:

// Each protocol you include costs memory and, during decode, costs time
// Disable (set to false) all the protocols you do not need/want!
// The Air Conditioner protocols are the most expensive memory-wise.

[meingraham]

https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#irremote

[crankyoldgit]

Specifying the IRremoteESP8266 directory with the version number in it is going to be obsolete with any version update. I'd suggest something more general/future proof.

As I said, I also think that's part of the problem/solution for enabling them in Tasmota. That part as you've added is just enabling/disabling them in the IRremoteESP8266 library. There is still the whole other part of the parser and calling of the API in/from Tasmota. I can't speak to that part.

[meingraham]

@crankyoldgit OK, I'll make it a bit more generic. I just wanted to make sure I had the "sentiment" right.

@arendst - Can you comment on the Tasmota side of this topic?

[arendst]

As @crankyoldgit David noted too enabling all protocols makes Tasmota unusable.

What I and Heiko (the original implementer of IRRemote in Tasmota) did was selecting only a few protocols which we then thought were useful to most users. Every protocol needs code space. Enabling/Disabling protocols is done in file IRremoteESP8266.h where I inserted a Tasmota section starting at line 230. Every enabled protocol needs a frontend where user interaction is translated in a IRremote library call. This is done in xdrv_05_irremote.ino starting from line 674.

At that time HVac was only supported on two protocols needing a lot of extra code too.

Enabling/Disabling features in libraries using Arduino IDE could/can only be done by editing defines in the library itself as Arduino IDE did/does not support global define control. This makes selecting features messy for users as they would need to change defines in two seperate locations.

So having users select protocols at will needs knowledgeable users and for me a whole lot of optional additions to tasmota to provide user interfaces.

As always, it could be done but as new protocols appear weekly would need a dedicated maintainer to provide optional Tasmota interfaces while keeping the code as small as possible as being my goal.

[crankyoldgit]

Enabling/Disabling features in libraries using Arduino IDE could/can only be done by editing defines in the library itself as Arduino IDE did/does not support global define control.

@arendst If it would help, I could make the library support external defines. e.g. compile-time flag -DSEND_NEC etc. or nested etc.
e.g.

#ifndef SEND_NEC
#define SEND_NEC true
#endif

As always, it could be done but as new protocols appear weekly would need a dedicated maintainer to provide optional Tasmota interfaces while keeping the code as small as possible as being my goal.

Agreed. I'd recommend only the most common/prolific protocols be included in Tasmota by default, and either/or of the Generic formats. e.g. Pronto & GlobalCache. As they can produce almost any _simple_ protocol at the cost of message size. Similar to Raw etc. Plus there are plenty of resources for people to look up button mappings for their remotes in those formats.

[arendst]

Thx David for your support.

Alas we didn't manage to make #ifndef #endif sequence work with Arduino IDE either. It is implemented in the PubSubClient library and it never worked as expected. See this https://community.platformio.org/t/warning-symbol-redefined-probably-because-of-fpreprocessed/6362 for a reasonable explanation.

Once I decide to abandon support for Arduino IDE then your suggestion makes sense as pio should handle global defines just fine.

[crankyoldgit]

See this https://community.platformio.org/t/warning-symbol-redefined-probably-because-of-fpreprocessed/6362 for a reasonable explanation.

Egads! That's disgusting and disappointing. :-( I wonder if you could cheese it by having the most minimal code in the .ino file, and have everything else in .h and .cpp files and let the linker sort it out.

Let me know in the future if you want it anyway. I may just add it before then. Who knows. ;-)

[arendst]

@crankyoldgit David, just noticed that regarding IRsend it makes no difference if I set SEND_XXX to false or true; as long as I do not call the specific protocol send function the code is not linked in and the resulting total code size does not grow!

That's just what I wanted with regard to control over IRsend protocol selection. So I will set all SEND_XXX protocols to true (in IRremoteESP8266.h) and for front-ends I wrote let users select IRsend protocols at compile time in my_user_cfg.h. Wonderfull.

For IRreceive (DECODE_XXX) it's different and I won't change the false for now.

[crankyoldgit]

@arendst Just be aware that there are some IRsend class methods that will pull all of the protocols into the binary. e.g. The generalised IRsend::send() methods. But yes, g++ and the linker are pretty intelligent about including only the bits needed.

You are absolutely correct about the IRrecv/decode parts though. There is very little I can do to control program size other than by #ifdefs etc. I could add run-time selective decoding, but it would still have the prog space overhead of including every decoder etc.

That said, I'm happy to trial anything you can think of to make them selective via #defines under your control/source space.