Arilux LC03 IR receives garbage on 6.5.0 #5853
Comments
|
Hi, Please, can you share the correct codes you receive using 6.4.1 and the status 0 of that? Thanks |
|
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: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}} Thank you. |
|
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 Perhaps this was always happening but 6.2.1 does not report a tele/RESULT for the garbage, but 6.5.0 does? |
|
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:
|
arendst
added
question
|
+1 for Talking Heads reference :) |
|
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? |
|
I'll look in to the possibility of changing sensitivity online. It depends on the flexibility of the library. Investigating. |
6.5.0.13 20190527 * Add command SetOption38 6..255 to set IRReceive protocol detection sensitivity mimizing UNKNOWN protocols (#5853)
|
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: 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. |
|
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 😉 |
|
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. |
|
"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 Cheers! |
arendst
added
the
awaiting feedback
|
Hi, have you tried latest fixes? Your issue is solved? |
ascillato2
added
bug
|
Closing this issue as there is no feedback |
|
Will get time to test new firmware next week probably, will let you know. |
As the owner of said IR library. I second the comments by @arendst. |
|
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 |
|
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. |
|
So, manually edit lib/IRremoteESP8266-2.6.0; yes? This seems like all that needs to be included in addition: |
|
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. |
|
@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? |
|
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. |
@arendst If it would help, I could make the library support external defines. e.g. compile-time flag
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. |
|
Thx David for your support. Alas we didn't manage to make Once I decide to abandon support for Arduino IDE then your suggestion makes sense as pio should handle global defines just fine. |
Egads! That's disgusting and disappointing. :-( I wonder if you could cheese it by having the most minimal code in the Let me know in the future if you want it anyway. I may just add it before then. Who knows. ;-) |
|
@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. |
|
@arendst Just be aware that there are some You are absolutely correct about the That said, I'm happy to trial anything you can think of to make them selective via |
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
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"}}
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
The text was updated successfully, but these errors were encountered: