GREE and other protocols reverting to C from F. #1121
Comments
|
Thanks for the report & data. Now, the rest of it. Currently we don't have protocol level support for Fahrenheit for the GREE protocol. That's because no-one until now had supplied any data using the Fahrenheit settings & temps. In order to add native support for it, I'm going to have to work out what bits change between Celsius and Fahrenheit, which I can probably deduce from the hex codes you provided. Plus, I'm going to need to know the minimum & maximum temp values in Fahrenheit the remote can produce, and copies of the corresponding hex codes. Provide those, and I can probably reverse engineer how it works etc. But yes, you've correctly guessed that the library tries to do the right thing for users, it allows users to use F if they want, but converts it to C for A/C units that don't (yet?) support native temps in F. FYI, as an aside. Only 10% or less of the protocols supported currently have native support for Fahrenheit. You North Americans are certainly in the minority! ;-) Also, when it comes to extra precision, don't hold your breath for it. Of the 3 or so protocols that do have native support, we found one that gave the placebo of sending F, but internally still sent it as integer C. The user swore blind that they honestly could feel the difference between the "half degree C" differences, but they too saw the protocol data and realised the remote was giving them a placebo effect. Any way. That's a digression, if your unit displays the set temp in F on it, then it probably does have that level of resolution. To summarise, I'm going to need the min and max codes for F (and a description of what they are) in order in order to add support for it. Waiting on your data/response. |
|
First of all, thank you for dealing with our strange units. I'm sorry. It's terrible. We are more anti-science every day. :( The remote seems to be able to go from 61 to 86F. This dump hopefully provides all of them to you; please let me know if I should capture them some other way? 00:48:48 MQT: tele/tasmota_6A9E68/RESULT = {"IrReceived":{"Protocol":"GREE","Bits":64,"Data":"0x0x09002058002000D0","Repeat":0,"IRHVAC":{"Vendor":"GREE","Model":2,"Power":"On","Mode":"Cool","Celsius":"On","Temp":16,"FanSpeed":"Auto","SwingV":"Auto","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}} |
|
Incidentally, it does look like something is able to decode them because it does seem to be able to correctly turn them into the accurate temp in C. Note in the log it's showing 16c to 30c - hey, look, that's the same as 61f to 86f! |
|
That's because <drumroll> .. the unit really works in Celsius. After looking at it, it has this notion of "half degrees" elsewhere in the code to try to fudge up F. I'm currently trying to map this devices F to C alg. because .. well, it's not the traditional/normal conversion. |
* Add support for setting the A/C using degrees Fahrenheit. * Add unit tests coverage for Fahrenheit. * Clean up existing unit tests style a bit. * Update supported devices. Fixes #1121
|
@3ricj & @s-hadinger I think I've correctly added Fahrenheit support to the Gree IR protocol in PR #1124 (Branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1121) Please download and try it out, and let me know how it goes. @3ricj You're on your own for integrating it with Tasmota. Perhaps @s-hadinger can help you there. Till then, you're probably stuck with the "real world" of Celsius, unless you can Engineer/Science it up a notch! :-P P.S. ProTip: Don't inject or ingest bleach or other disinfectants. Just Sayin'! ;-) |
crankyoldgit
added
Pending Confirmation
|
Thanks David, always super fast. That's not a tiny patch so I'd rather wait for your next release to update Tasmota. @3ricj Can you please confirm this solves your issue? If you want to update the lib in Tasmota, that's super simple. Delete and replace all files in |
|
Wow, amazing. Also, warm tips about bleach. This is the greatest PR ever. I'll compile it tomorrow and give it a shot. Thanks so much for supporting my strange units. @crankyoldgit along the way here I also purchased a "universal AC remote" which claims to support 2000 different models. (but not my other AC unit). It does seem to implement GREE in both units. If this is at all helpful to you I'm happy to mail it to you. ericjohanson atty gmail. https://www.ebay.com/itm/Universal-A-C-Remote-Control-Fits-Samsung-Panasonic-Sanyo-Chigo-Fujitsu-more/221596252074?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 |
I wasn't suggesting otherwise. ;-) |
@3ricj Thanks for the generous offer, but you can hang on to it for now. I'll keep it in mind though. Having the remote is probably three quarters of the battle for adding support, but access to the controlled unit is very important. I could emulate this 2000-in-1 remote, but not know if it really works. i.e. The proof is in how & if it actually controls the A/C correctly. There is no way to know if I'm just emulating a bad implementation without the actual A/C unit. Plus, with the number of A/Cs I've added to this library, it probably supports 2000 models by now already! I've also grown weary of doing full reverse engineering of protocols myself. I now push back onto the person with the remote to do the break-down etc. |
|
Title says "and other protocols" any examples other than Gree? |
|
I think he's referring to the linked Tasmota issue. It was one of the Mitsubishi ones. TL;DR: No way to fix this without adding native Fahrenheit support for every A/C protocol. I would if I had the codes/protocol breakdown, but alas ... we live in reality. ;-) |
* Add support for setting the A/C using degrees Fahrenheit. * Add unit tests coverage for Fahrenheit. * Clean up existing unit tests style a bit. * Update supported devices. X-Ref: arendst/Tasmota#8437 Fixes #1121
Indeed we do |
_v2.7.7 (20200519)_ **[BREAKING CHANGES]** - Fix Symphony protocol. (#1107, #1105) * Now 12 bits and bits are inverted. All previous codes will no longer work. - IRMQTTServer: Better handle power & mode operations for Home Assistant. (#1099, #1092) * When `MQTT_CLIMATE_HA_MODE` is enabled (default) this will break previous operation mode resumption when power is changed. **[Bug Fixes]** - Set correct return type for `.calibrate()` (#1095, #1093) **[Features]** - Add basic support for Carrier 40 & 64 bit protocols. (#1125, @1112, #1127) - Gree: Enable native support for Fahrenheit (#1124, #1121) - Gree: Add option to control display temp source. (#1120, #1118) - Add support for Multibrackets protocol. (#1106, #1103) - Add RawToPronto.py tool & improve `sendPronto()` precision (#1104, #1103) - Add support for `Doshisha` LED light protocol (#1115) - Introduce IRrecvDumpV3 with basic OTA update support (#1111) - Add detailed support for Delonghi A/C (#1098, #1096) - Improved support for SharpAc. (#1094, #1091) - Update auto_analyse to use new decode call structure. (#1102, #1097) - Added Blynk app example (#1090)
_v2.7.7 (20200519)_ **[BREAKING CHANGES]** - Fix Symphony protocol. (#1107, #1105) * Now 12 bits and bits are inverted. All previous codes will no longer work. - IRMQTTServer: Better handle power & mode operations for Home Assistant. (#1099, #1092) * When `MQTT_CLIMATE_HA_MODE` is enabled (default) this will break previous operation mode resumption when power is changed. **[Bug Fixes]** - Set correct return type for `.calibrate()` (#1095, #1093) **[Features]** - Add basic support for Carrier 40 & 64 bit protocols. (#1125, @1112, #1127) - Gree: Enable native support for Fahrenheit (#1124, #1121) - Gree: Add option to control display temp source. (#1120, #1118) - Add support for Multibrackets protocol. (#1106, #1103) - Add RawToPronto.py tool & improve `sendPronto()` precision (#1104, #1103) - Add support for `Doshisha` LED light protocol (#1115) - Introduce IRrecvDumpV3 with basic OTA update support (#1111) - Add detailed support for Delonghi A/C (#1098, #1096) - Improved support for SharpAc. (#1094, #1091) - Update auto_analyse to use new decode call structure. (#1102, #1097) - Added Blynk app example (#1090) **[Misc]** - update auto_analyse script to use new param documentation (#1126) - Improve `raw_to_pronto_code.py` (#1122, #1103) - Use pattern rules in Makefiles to reduce specific rule (#1110) - Update list of supported Daikin models. (#1101)
_v2.7.7 (20200519)_ **[BREAKING CHANGES]** - Fix Symphony protocol. (#1107, #1105) * Now 12 bits and bits are inverted. All previous codes will no longer work. - IRMQTTServer: Better handle power & mode operations for Home Assistant. (#1099, #1092) * When `MQTT_CLIMATE_HA_MODE` is enabled (default) this will break previous operation mode resumption when power is changed. **[Bug Fixes]** - Set correct return type for `.calibrate()` (#1095, #1093) **[Features]** - Add basic support for Carrier 40 & 64 bit protocols. (#1125, #1112, #1127) - Gree: Enable native support for Fahrenheit (#1124, #1121) - Gree: Add option to control display temp source. (#1120, #1118) - Add support for Multibrackets protocol. (#1106, #1103) - Add RawToPronto.py tool & improve `sendPronto()` precision (#1104, #1103) - Add support for `Doshisha` LED light protocol (#1115) - Introduce IRrecvDumpV3 with basic OTA update support (#1111) - Add detailed support for Delonghi A/C (#1098, #1096) - Improved support for SharpAc. (#1094, #1091) - Update auto_analyse to use new decode call structure. (#1102, #1097) - Added Blynk app example (#1090) **[Misc]** - update auto_analyse script to use new param documentation (#1126) - Improve `raw_to_pronto_code.py` (#1122, #1103) - Use pattern rules in Makefiles to reduce specific rule (#1110) - Update list of supported Daikin models. (#1101)
_v2.7.7 (20200519)_ **[BREAKING CHANGES]** - Fix Symphony protocol. (#1107, #1105) * Now 12 bits and bits are inverted. All previous codes will no longer work. - IRMQTTServer: Better handle power & mode operations for Home Assistant. (#1099, #1092) * When `MQTT_CLIMATE_HA_MODE` is enabled (default) this will break previous operation mode resumption when power is changed. **[Bug Fixes]** - Set correct return type for `.calibrate()` (#1095, #1093) **[Features]** - Add basic support for Carrier 40 & 64 bit protocols. (#1125, #1112, #1127) - Gree: Enable native support for Fahrenheit (#1124, #1121) - Gree: Add option to control display temp source. (#1120, #1118) - Add support for Multibrackets protocol. (#1106, #1103) - Add RawToPronto.py tool & improve `sendPronto()` precision (#1104, #1103) - Add support for `Doshisha` LED light protocol (#1115) - Introduce IRrecvDumpV3 with basic OTA update support (#1111) - Add detailed support for Delonghi A/C (#1098, #1096) - Improved support for SharpAc. (#1094, #1091) - Update auto_analyse to use new decode call structure. (#1102, #1097) - Added Blynk app example (#1090) **[Misc]** - update auto_analyse script to use new param documentation (#1126) - Improve `raw_to_pronto_code.py` (#1122, #1103) - Use pattern rules in Makefiles to reduce specific rule (#1110) - Update list of supported Daikin models. (#1101)
|
@3ricj @s-hadinger FYI, the changes mentioned above have now been included in the latest release (v2.7.7) of the library. |
(Please use this template for reporting issues. You can delete what ever is not relevant. Giving us this information will help us help you faster. Please also read the FAQ & Troubleshooting Guide. Your problem may already have an answer there.)
Version/revision of the library used
Typically located in the
library.json&src/IRremoteESP8266.hfiles in the root directory of the library.e.g. v2.0.0, or 'master' as at 1st of June, 2017. etc.
Tasmota 0.8.2 (not sure what specific version they have of this library)
Expected behavior
What steps did you do and what should it have done?
Actual behavior
What steps did you do, and what did or didn't actually happen?
Output of raw data from IRrecvDumpV2.ino (if applicable)
Include some raw dumps of what the device saw.
02:30:09 CMD: Group 0, Index 1, Command "IRHVAC", Data "{"Vendor":"GREE", "Power":"On","Mode":"Hot","FanSpeed":3,"Celsius":"Off","Temp":68}"
02:30:10 MQT: stat/tasmota_6A9E68/RESULT = {"IRHVAC":{"Vendor":"GREE","Model":1,"Power":"On","Mode":"Auto","Celsius":"Off","Temp":68,"FanSpeed":"Medium","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}
02:30:10 MQT: tele/tasmota_6A9E68/RESULT = {"IrReceived":{"Protocol":"GREE","Bits":64,"Data":"0x0x28094050002000D0","Repeat":0,"IRHVAC":{"Vendor":"GREE","Model":1,"Power":"On","Mode":"Auto","Celsius":"On","Temp":25,"FanSpeed":"Medium","SwingV":"Auto","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}
02:30:25 WIF: Checking connection...
Steps to reproduce the behavior
What can we do to (pref. reliably) repeat what is happening?
Example code used
Include all relevant code snippets or links to the actual code files. Tip: How to quote your code so it is still readable.
Circuit diagram and hardware used (if applicable)
Link to an image of the circuit diagram used. Part number of the IR receiver module etc. ESP8266 or ESP32 board type.
nas-ir03w0, using the NAS-IR03W0 IR bridge template, using latest tasomoto-ircustom.bin : https://templates.blakadder.com/neo_coolcam_NAS-IR03W0.html
I have followed the steps in the Troubleshooting Guide & read the FAQ
Yes/No.
Yes.
Has this library/code previously worked as expected for you?
Yes/No. If "Yes", which version last worked for you?
No
Other useful information
More information is always welcome. Be verbose.
It seems the GREE protocol is able to understand F, as when I send commands from my remote in F it does convert them to C in the display:
If I have my remote pointed at the Tasmota device AND my AC unit, and power it on, the AC unit displays 68F, but the tasmota device shows 20c.
18:01:56 MQT: tele/tasmota_6A9E68/RESULT = {"IrReceived":{"Protocol":"GREE","Bits":64,"Data":"0x0x0904205800200010","Repeat":0,"IRHVAC":{"Vendor":"GREE","Model":2,"Power":"On","Mode":"Cool","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Auto","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}
So unexpectedly, it's understanding F well enough to convert it to C... I guess?
This is only really a problem because when the AC receives C, it changes the display, and in addition it's less effective resolution than in F as my unit (and likely the protocol) only supports ints. (specifically, my target temp is 69F, which is 20.5C, but I don't think I can send 20.5C!)
I am able to send IRsend {"Protocol":"GREE","Bits":64,"Data":0x0904205800200010} and have it correctly operate in F, so I do suspect this is an encoding/decoding problem with this library.
68F: IRsend {"Protocol":"GREE","Bits":64,"Data":0x0904205800200010}
69F: IRsend {"Protocol":"GREE","Bits":64,"Data":"0x0905205800200020"}
A unrelated bug (maybe I should file something else on this) but there is some sort of bug in the IRreceived code (note the 0x0x twice)
19:07:55 MQT: tele/tasmota_6A9E68/RESULT = {"IrReceived":{"Protocol":"GREE","Bits":64,"Data":"0x0x4904205001200090","Repeat":0,"IRHVAC":{"Vendor":"GREE","Model":2,"Power":"On","Mode":"Cool","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Auto","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}
See this original bug over here: arendst/Tasmota#8437
The text was updated successfully, but these errors were encountered: