LG AC strange behavior #1298
Comments
|
From a quick read of the LG code it does some mangling of temp when handling power state We might be able to improve this by checking power state when temp is set and keep that in memory until power is set to on, but that code will be a bit of a clunky mess. For reference #1008 (comment) |
LG's A/C power off sets the temp to a special value. So move the `setPower()` call to last in `IRac::lg()` so it happens after any temp changes. Ref: #1298 (comment) Fixes #1298
|
@adrianofoschi Can you please download and test PR #1299 / Branch https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1298 If this works, great, let us know. If it doesn't, let us know, and we'll ask you for more information (or to log an issue with Tasmota) like capturing (via IRrecvDumpV2+) what IR signal/message Tasmota is producing and what your real remote produces in the same setup/settings/conditions/etc. |
|
Initially I used a sonoff receiver with tasmota to capture the code from original remote controller. (I have 2 sonoffs, one receiver and one transmitter :) ) So actually I'm already trying with the code that I catched with "poweroff". The code is:
Sometimes I see some other protocol "unknown" signals.
The behavior is the same that I described in the first post. @crankyoldgit thanks you. Becouse I don't have arduino I should try to include your latest changes inside the tasmota and test again... |
|
I traced the command:
So the code produced by tasmota (88C0051) seems to be right. The important thing is that the problem is not only with the turn off command. But it doesn't work with any command when it is already turned on. |
crankyoldgit
removed
Pending Confirmation
|
Thanks for the extra info. As far as I can tell from looking at the code and the data you have provided, the library (and tasmota) is producing and sending the correct "off" message. If the A/C isn't responding as expected when you send
Can you capture & describe the settings on the real A/C remote for something that is a command when it is already turned on? i.e. How certain are you that it is the |
|
I provide you a full test with all signals catched with tasmota IR receiver from original remote controller step by step.
...I wait for preheating
Now I'm trying to send the same codes from ir transmitter but after step 1 it stops to work. UPDATE |
|
Hi! Regards, |
|
I did another test:
the captured signal is the same:
so the signal in tasmota seems to be right...I finished the ideas... |
|
@adrianofoschi Thanks for all the data. @GiampaMan There should be no difference between sending on an ESP8266 verses a ESP32. @adrianofoschi @GiampaMan I think at this stage I'm going to need the Lines 116 to 118 in ecfc472 I would really prefer the full text output from IRrecvDumpV2 or V3, instead of the raw data captured from Tasmota as I know the it will do a more accurate & complete job for this issue. However, if all you can do is use tasmota to capture the raw output, that will have to do. @adrianofoschi When you are trying to reproduce the message via the Things like that are one of the reasons why we don't like to debug stuff from other projects, and require people to use the native example code etc so we have a better understanding of what is actually going on. |
* Looking at comments for LG2 it seems the repeat is manditory, but we have no proof. So, lets try making it (a minimum of a single repeat for LG2) manditory in most cases. * LG should stay the same with "no repeats" as the default. * Extend existing unit tests to cover these points and to confirm expected operation. This really needs to verified with hard data to be sure. Might fix #1298
|
@adrianofoschi Can you please download and test PR #1300 / Branch https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1298 |
|
@crankyoldgit Thanks you for your support. What I'm going to do today is:
Thanks you again |
The last part of that probably won't work. But it's worth a try. The branch from that PR should address that problem.
There is a way to get Tasmota to report the raw IR data. Others have done it, so you shouldn't need a new board (just yet). Lines 39 to 49 in ecfc472 As for boards, any ESP8266 or ESP32 dev board should suffice. I've personally found the Wemos D1 Mini's to be reliable, cheap, and plentiful. |
|
Hi, To get raw data, use Use this online tool to convert to the old raw format: https://tasmota.hadinger.fr/util Edit: we only set |
So is there no way to specify the number of repeats via the Tasmota interface?
Rather than re-invent the wheel, do you have c++ code for this perchance? I can add it to IRrecvDumpV2+ etc.
No, the timeout I'm referring to is "how long before I give up listening for more pulses in a message?" |
|
Hi, I'm going to post latest test logs, including raw data with 15ms and 50ms timeouts. EDIT Test summary:
TEST 1: catch test using LG original remote controller and tasmota-ir with TIMEOUT 15ms 1.2. wait 5 minutes 1.3. press power to turn off. But it does not turn off, it "beeps" and seems to set again the previous conditions (heat, temp 29, fan max) 1.4. press power again and it turns off 1.5. repeat from (1) then press power to turn on 1.6. wait 5 minutes 1.7. press power to turn off, this time it turns off without press again .... 2.1. send data to turn on from from my transmitter 2.2. wait 5 minutes 2.3. send data to turn off from my transmitter (it does not turn off as expected) ... 3.1. RC: press power to turn on, conditions: heat, temp 29, fan max 3.2. wait 5 minutes 3.3. press power to turn off. But it does not turn off, it "beeps" and seems to set again the previous conditions (heat, temp 29, fan max) 3.4. press power again and it turns off 3.5. repeat from (1) then press power to turn on 3.6. wait 5 minutes 3.7. press power to turn off, this time it turns off without press again ... 4.1. send data to turn on from from my transmitter 4.2. wait 5 minutes 4.3. send data to turn off from my transmitter (it does not turn off as expected) Tell me if you need more data or tests. |
Actually you can use either
Then we're using the default value, and there is no provision to change it via configuration.
Sure. The code to parse it is there: https://github.com/arendst/Tasmota/blob/b48f77104862e9298f3a640fd1bc09d4e42d1475/tasmota/xdrv_05_irremote_full.ino#L649-L681 |
I updated tasmota with IRremoteESP8266 PR #1304 on transmitter and receiver too. Latest logs from my test on PR #1304 power on recorded from remote controller
power off recorded from remote controller
power on recorded from my tasmota transmitter
power off recorded from my tasmota transmitter
I did another interesting test... EDIT: Updated test with raw data Thanks you David |
Clutching at straws now. For #1298
|
FYI, while we are doing this testing/debugging stuff, can you please use the non-compressed raw data output. It means I can actually read it. :) I've pushed another change to that latest branch to change the duty cycle of the IR led from 50% (default) to 33%. Also, please pass on any UNKNOWN messages you get around the time of the message transmissions. They could be something we don't expect. |
Hi David, sorry the latest tasmota use compressed data output Idk if it is disabled. I will convert the output for you with the proper online tool. I edited the latest test adding the uncompressed data. CATCH SIGNAL FROM REMOTE CONTROLLER
CATCH SIGNAL FROM TRASMITTER
Power off test input protocol, irhvac:
Edit: leave only irhvac protocol tests |
|
Thanks for the conversion. As I indicated earlier, using the raw sending method does not allow the duty cycle to be tweaked. You will have to send via the IRHVAC or LG2 protocol methods in the latest updated branch to test it out. |
OK sorry. As you can see I used ALSO irhvac in my latest tests. |
I saw. But it's not clear to me what, if anything, worked or not. The one of the many mysteries here is why the original remote doesn't work all the time either. Dumb question/suggestions: You have checked the batteries in the remote, and there isn't a strong heat source/sunlight in the room etc? |
The actual behavior is the same as when I opened the issue: poweron with The AC starts. From this moment no one command works. I sent the command and it does not beep or react in any way. I could change the battery of the remote controller but how can be this related to the issue? |
|
I recorded a video to clarify the behavior:
The behavior is the same if I try to send any another command at the step 2. |
|
The latest test I did:
and it works....it seems really that the AC expects something different after X seconds from the turn on I am not a technician but seems that there is something similar a "counter" into the original controller. Another possibility is to logs the signal from xiaomi remote controller app for android that works. |
|
Xiaomi remote signals: power on power off (2 signals becouse the first time it doesn't turn off, it beep only) If I send the latest poweroff signal when it is turned off, it turns on ... |
|
Your latest update indicates the Xiaomi remote is sending an NEC code to turn it off. Yet, the data you've reported from the original remote is an LG2 0x88C0051 message. The fact that you both seem to report that it sometimes ignores the actual remote may mean it's some expected behaviour of the A/C. e.g. It wants to avoid being turned off & on etc rapidly. To test your theory of a sequence number in the message etc, try just recording the remote, and see if it sends a different code for powering it off etc. If the code number remains the same every time, then the message should be the same. |
The problem is that any command doesn't work after X seconds, not only the power off.
The turn off code is always the same 0x88C0051. But could be a bug in the receiving? I mean that I see 0x88C0051 but really it is a different code. |
Then it is sounding more and more like its an issue with the A/C unit's design etc.
Extremely unlikely. Especially given the value changes for other messages. |
do you think is not solvable ?
|
|
Hi @adrianofoschi and @crankyoldgit ! Sorry for delays on my response, I was been testing, and unfortunately confirmed that the bug is still there. I had seen @adrianofoschi video with the issue and I think we are experiencing different weird behaviors. I'm waiting a period of time so the bug happens again and I can record a video so you can see what's happening here. I want to let you know that I'm not using Tasmota, I'm using normal Arduino framework with this library. Also I tried to use the last one modification you did, but the same behavior is there (the one on PR #1304 ). I can record a video so you can see the bug and I hope it can help to solve this issue. Have a great day and thanks for all! PD: I will send the video ASAP |
I bought a nodeMCU that will arrive tomorrow. Then I will try again with PR #1304 with Tasmota and Arduino. Thanks you @GiampaMan and @crankyoldgit |
If the actual IR remote can't do it, there is not a lot we can do. All we are doing in re-creating the same message the IR remote is sending. |
For "decoding" an IR message, please use: IRrecvDumpV2 or V3 For "sending", IRMQTTServer is probably the easiest to operate/change etc, but more complex to initially setup. Then there is a middle ground of: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/CommonAcControl/CommonAcControl.ino |
@GiampaMan I admit I am getting confused between the two of you. Can you please re-explain what your issue is and exactly what you're doing that is not behaving as expected? |
* [Bug] Fix LG2 timings and refactor `decodeLG()` * [BUG] LG2 was incorrectly using the Bitmark timings of the LG protocol. - Tweak the timings some more to match reported working LG2 data. * While here, re-write the mess that is `decodeLG()` to use generic routines and clean it up. * Remove all `tick` calculations to simplify things. * Fix a number of style issues. * Misc improvements to Unit tests. * LG2: Try setting a duty cycle of 33% For #1298
|
Hi! I have a good news. Some data: The only difference with sonoff-basic is that the distance. I need to put it nearest the AC. |
Huzzah! That's really good news, because as I said, I was out of ideas. I'm going to close this issue now. @GiampaMan for your problem, can you create a new issue please? |
|
I did more hardware tests and I discover that probably there was not a problem with the sonoff basic but the problem was the resistor value in the circuit. I was using a 100kohm resistor as described in the major irblaster scheme. I replaced it with 10kohm resistor, put the blaster nearest the AC and it works perfectly. |
_v2.7.12 (20201113)_ **[Bug Fixes]** - `defaultBits()` returned incorrect result for `PANASONIC_AC` (#1307 #1314) - Fix LG2 timings and refactor `decodeLG()` (#1298 #1304) **[Features]** - Midea: Add support for "Follow Me"/Sensor, Turbo, Light, & Timers (#1318 #1327) - SharpAc: Add model support for A705 (#1309 #1313) - Add basic support for Panasonic A/C 32bit/16bit protocol. (#1307 #1316) - Add support for Elite Screens protocol. (#1306 #1310) - IRrecvDumpV2+: Add tolerance setting. (#1292) - Add basic support for the Mirage Protocol. (#1289 #1291) - Internationalisation Support - pt-BR: Add Portuguese/Brazilian support. (#1303) - de-DE: Backfill missing strings (#1294) - de-DE: update for recent addition of 'tolerance' (#1293) - de-DE: Translate root README.md into German (#1297) **[Misc]** - refactor ir_LG (#1325) - refactor ir_Kelvinator (#1317) - refactor ir_Hitachi (#1308) - refactor ir_Goodweather (#1295) - refactor ir_Electra (#1290) - refactor ir_Daikin (#1288) - Update Kaysun supported models. (#1322) - fix typos/spelling mistakes (#1301) - Add some missing Doxygen class/data-type descriptions. (#1287)
_v2.7.12 (20201113)_ **[Bug Fixes]** - `defaultBits()` returned incorrect result for `PANASONIC_AC` (#1307 #1314) - Fix `LG2` timings and refactor `decodeLG()` (#1298 #1304) **[Features]** - Midea: Add support for "Follow Me"/Sensor, Turbo, Light, & Timers (#1318 #1327) - SharpAc: Add model support for A705 (#1309 #1313) - Add basic support for Panasonic A/C 32bit/16bit protocol. (#1307 #1316) - Add support for Elite Screens protocol. (#1306 #1310) - IRrecvDumpV2+: Add tolerance setting. (#1292) - Add basic support for the Mirage Protocol. (#1289 #1291) - Internationalisation Support - `pt-BR`: Add Portuguese/Brazilian support. (#1303) - `de-DE`: Backfill missing strings (#1294) - `de-DE`: update for recent addition of 'tolerance' (#1293) - `de-DE`: Translate root README.md into German (#1297) **[Misc]** - refactor ir_LG (#1325) - refactor ir_Kelvinator (#1317) - refactor ir_Hitachi (#1308) - refactor ir_Goodweather (#1295) - refactor ir_Electra (#1290) - refactor ir_Daikin (#1288) - Update Kaysun supported models. (#1322) - fix typos/spelling mistakes (#1301) - Add some missing Doxygen class/data-type descriptions. (#1287)
|
FYI, the changes mentioned above have now been included in the new v2.7.12 release of the library. |
Version/revision of the library used
The version included in the latest tasmota-ircustom.
Expected behavior
I'm trying to use tasmota for my LG Air conditioning (Remote controller model AKB74515420).
An example "cool" command
It starts.
It should stop if I send a power off command.
Actual behavior
My IRblaster works ALWAYS when the AC is turned off and I send a command, but it doesn't work when it is already turned on.
Example:
Example turn off command:
What brand/model IR demodulator are you using?
I built an IR blaster using a SonOFF Basic as there http://www.asknoone.com/ir-blaster-with-tasmota/
Initially I used the receiver to catch the remote ir codes, next I discovered "irhvac" in Tasmota and actually I'm using it to send commands via tasmota transmitter console.
Some important notice:
a) The turn off command works within the first 10/20 seconds after the turn on.
b) The turn off command do "beep" when the climate is already turned off.
c) Sometimes it works unaxpectatly
Conclusion: a command doesn't work 9 times out of 10 if the AC is at full operating speed.
The text was updated successfully, but these errors were encountered: