-
Notifications
You must be signed in to change notification settings - Fork 833
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UNKNOWN Protocols and missing codes when using CommonAcControl in some protocols #1250
Comments
Re: ARGO. It's not the most well supported/tested protocol. IRremoteESP8266/src/ir_Argo.cpp Lines 457 to 458 in ba2d5ca
IIRC someone contributed the send routine and protocol structure/code. I've no ability to verify that actually even works. Can you please supply some raw captures from the actual remote?
That sounds plain weird. Can you provide some sample
Hmmm. Toshiba has an odd-ball power on/off style. Will need to look into your code and how the library reacts further to see what may be going on.
Will need to look into these separately. Possibly separate issues are warranted for each protocol.
|
Um ... for a lot of these |
that is the messages readed from the code stated in the issue only adding delay(5000); after each
Will it's not my code it's yours i guess :), as i said in these errors i used the default CommonAcControl
Will i may not really need all these other protocols so what mainly i would be pleased if you helped me with is the TOSHIBA one and that 5 second delay problem , as of that 5 second delay problem i may be too afraid that i can't rely on the way that the example uses in my main code. |
Will i was trying the strTo**** functions because i will be mainly use it , i don't think it will really affect the output as they already worked with some protocols that i already tested with the same code like SHARP_AC, FUJITSU_AC, SAMSUNG_AC and COOLIX . |
I have a KT-3888 Universal AC Remote which has about 700 AC protocols |
Okay. If you look at the raw data you've provided, you'll see a lot of values that are sub-200 uSeconds. That's a very strong indicator that either a) your IR receiver hardware module is not very good, or b) there is significant IR noise in your environment. See https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Help_Im_getting_very_inconsistent_results_when_capturing_an_IR_message_using_a_VS1838b_IR_demodulator e.g. A sample from your data.
Note the Two ways to fix a lot of the problems you are having with your sensor/environmental issues is to set max_skip to 2-4 etc. Or adjust the IRremoteESP8266/examples/IRrecvDumpV3/IRrecvDumpV3.ino Lines 74 to 81 in ba2d5ca
Due to how the micro controllers work on normal IR devices, a sent signal from the library will probably be understood better than the super-generic-try-to-do-everything
Thanks for the offer. We prefer data from OEM remotes so we know we are not re-implementing/reverse-engineering someone else's potentially dodgy implementation. |
I'am Really thankful for all your time and answers that's very kind of you , but one last thing I'am sorry i tried and i need your help in it
Also the problem i did stated about the TOSHIBA Protocol , keeping in mind that I'am using the default example and the power is not shifting. |
You don't need to do anything special other than change the value of
The Hopefully comment is because there is no way the library can know the initial/actual power state of the Airwell A/C. You'd need to get them in sync. |
I haven't forgotten. I'm looking into that now. |
* setPower() needs to happen after other functions that can change the operation mode. * Unit tests added to help debug/confirm the issue has been fixed successfully. Fixes #1250
I found the bug with Toshiba a/c, it will be fixed with PR #1251 |
Oh i get it, Thanks for your great help and this great library, hope you get the bug fixed easily :) |
Already fixed in the |
_v2.7.10 (20200831)_ **[BREAKING CHANGES]** - move SPIFFS to LittleFS for ESP8266 (#1182 #1226) - Daikin176: Change & increase operating mode values. (#1233 #1235) **[Bug Fixes]** - TOSHIBA_AC: not turning off when using `IRac` class. (#1250 #1251) - Haier: change position of Fan speed bits. (#1246 #1247) **[Features]** - Voltas: Add detailed support for Voltas A/Cs (#1238 #1248) - Add support for Metz protocol. (#1241 #1242) - Basic support for Voltas A/C protocol (#1238 #1243) - Add low level bit formatting sanity checks. (#1232) **[Misc]** - Rewrite Airwell by using bit fields (#1254) - Rewrite Haier YRW02 using bit fields (#1253) - rewrite Haier HSU07-HEA03 (#1246 #1247) - rewrite ir_Gree & ir_Midea by using bit field (#1240) - Incorrect usage of `assert()` (#1244 #1245 #1232) - rewrite Gree (#1210)
## v2.7.10 release _v2.7.10 (20200831)_ **[BREAKING CHANGES]** - move SPIFFS to LittleFS for ESP8266 (#1182 #1226) - Daikin176: Change & increase operating mode values. (#1233 #1235) **[Bug Fixes]** - TOSHIBA_AC: not turning off when using `IRac` class. (#1250 #1251) - Haier: change position of Fan speed bits. (#1246 #1247) **[Features]** - Voltas: Add detailed support for Voltas A/Cs (#1238 #1248) - Add support for Metz protocol. (#1241 #1242) - Basic support for Voltas A/C protocol (#1238 #1243) - Add low level bit formatting sanity checks. (#1232) **[Misc]** - Rewrite Airwell by using bit fields (#1254) - Rewrite Haier YRW02 using bit fields (#1253) - rewrite Haier HSU07-HEA03 (#1246 #1247) - rewrite ir_Gree & ir_Midea by using bit field (#1240) - Incorrect usage of `assert()` (#1244 #1245 #1232) - rewrite Gree (#1210)
The code changes (Toshiba) mention have now been included in the newly released v2.7.10 of the library. |
Library : v2.7.9
Expected behavior
What steps did you do and what should it have done?
e.g.
Actual behavior
What steps did you do, and what did or didn't actually happen?
Output of raw data from IRrecvDumpV3.ino
Timestamp : 000315.414
Library : v2.7.9
And Loop Goes on the exactly same with the exactly same UNKNOWN protocol raw code
Example code used
Additional info
When i tried to put a delay of 5 seconds between protocols (i.e, just before
//----------------
line) i got nothing but a stream of unknown signals with of course their delays , so can someone explain why dose that occur!?, because in my code i want to use any AC signal that come from the user at any time during the loop ..One last Important thing is when i tried to work with the code as it is (i.e, default example of CommonAcControl) it all works so fine except of the following errors:
Note: All reads are gotten from the another device as stated before.
IMPORTANT NOTE: the past errors listed from the default CommonAcControl is gathered from 6 repeats of the code loop and they are all the same (i.e, made sure that these are not just random IR signals,, they are repeated 6 times.)
Circuit diagram and hardware used (if applicable)
The sender one is ESP8266-12E and the RX one is NodeMCU
Has this library/code previously worked as expected for you?
No
The text was updated successfully, but these errors were encountered: