Closed shyne99 closed 6 years ago
Hey @shyne99 Thanks for the detailed report!
I've done some tests and modification to get it to detect it okay (not perfect). Most of the changes thus far have been to increase the tolerances for the pulse/gap lengths. They were far more out of "spec" than normal. e.g. Normally we allow a +/- 25% error margin. For the message you posted, it required a +/-40% margin to pass.
Question: Is that message you captured from the actual remote, or generated by an esp/arduino running that heatpump library?
If it's from the real remote, I've got no qualms tweaking the values etc. If it is from a simulated/artificial source, then I may be allowing more slop than I should be for detecting it.
Anyway, I'll upload the code in a minute or two. It works, except the model detection isn't working. My guess is it is an LKE (which allows horizontal and vertical swing). Can you please include as much information about the A/C unit etc as possible so I can see if it is supposed to be an LKE series (I've got no idea how to confirm that yet ;-) or if it is something new. e.g. Model Number of head unit/main unit, rough year of manufacture, link to manual if possible, etc etc etc.
@shyne99 Can you please try out the code in this branch to see how it goes: https://github.com/markszabo/IRremoteESP8266/tree/issue_540
@crankyoldgit , The reading comes directly from the remote control, not from the ESP code. I use the DKE part of the code to make it works Here is the label's picture of the label of the AC unit : https://imgur.com/a/9QBPtWO And a picture of the remote control : https://www.panaservicio.es/images/products/cwa75c3704-mando-original-panasonic.jpg
I'll give a try tonight to the code on this branch, and update the issue accordingly.
I'll also capture a lot of On/Off sequence and post them to pastebin, to see if the error margin is constant or if it is just an issue with this one reading.
@shyne99 Cool. Thanks for confirming it came from a real remote. I've merged that PR, so you can just download/clone/pull the master
branch.
Let us know how it goes with the other codes/messages.
Okay so, it seems that this is the MKE type (apparently it is simply written in the Pn of the indoor unit). Detection works great for simple command, but fail if I try those command
Also, those command are just send to the unit and not stored inside the controller. To be clear, if I activate EcoNavi mode the Unit light the econavi light. Then I switch the unit off, and on again, the EcoNavi light is Off. So detection only fails If i press one of those special button.
As a user, those feature are not useful, and I never use them so it is not blocking at all for me, but it may not be the same for orhers, so I'll try to help in making them customizable.
I'll try to pinpoint the byte modified by each one
But those command seems to be specific to MKE models.
On the other hand, I was not able to send data back to the unit at all (even in 2.5.1), I have looked inside the code the send method seems to be missing, and fails at compile time. I try to implement it but I have issue implementing the checksum part)...
I'll try to pinpoint the byte modified by each one
If you could, that would be great. Can you also provide some rawData[]
& state[]
captures/lines for those messages too. That will help me build test cases for it.
But those command seems to be specific to MKE models.
I suspected as much (not one of the supported models) based on a quick glance at the state[]
codes as there seemed to be bits changed I wasn't familiar with. Hopefully I can work out a signature to tell the difference.
I have looked inside the code the send method seems to be missing, and fails at compile time.
Eek. You are right. I missed it. I'll create a PR for it shortly.
If you care to try branchissue_540
it should contain the missing send()
class method. https://github.com/markszabo/IRremoteESP8266/tree/issue_540
See PR #545 for the changes.
The send fix should now be in the master
branch.
@crankyoldgit Okay so just to let You know that I have tested that
/* Copyright 2017 crankyoldgit
* An IR LED circuit *MUST* be connected to the ESP8266 on a pin
* as specified by kIrLed below.
*
* TL;DR: The IR LED needs to be driven by a transistor for a good result.
*
* Suggested circuit:
* https://github.com/markszabo/IRremoteESP8266/wiki#ir-sending
*
* Common mistakes & tips:
* * Don't just connect the IR LED directly to the pin, it won't
* have enough current to drive the IR LED effectively.
* * Make sure you have the IR LED polarity correct.
* See: https://learn.sparkfun.com/tutorials/polarity/diode-and-led-polarity
* * Typical digital camera/phones can be used to see if the IR LED is flashed.
* Replace the IR LED with a normal LED if you don't have a digital camera
* when debugging.
* * Avoid using the following pins unless you really know what you are doing:
* * Pin 0/D3: Can interfere with the boot/program mode & support circuits.
* * Pin 1/TX/TXD0: Any serial transmissions from the ESP8266 will interfere.
* * Pin 3/RX/RXD0: Any serial transmissions to the ESP8266 will interfere.
* * ESP-01 modules are tricky. We suggest you use a module with more GPIOs
* for your first time. e.g. ESP-12 etc.
*/
#ifndef UNIT_TEST
#include <Arduino.h>
#endif
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Panasonic.h>
const uint16_t kIrLed = D1; // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRPanasonicAc panair(kIrLed); // Set the GPIO to be used to sending the message.
void setup() {
panair.begin();
Serial.begin(115200);
}
void loop() {
Serial.println("Sending...");
// Set up what we want to send. See ir_Argo.cpp for all the options.
panair.stateReset();
panair.setModel(kPanasonicDke);
panair.setPower(true);
panair.setFan(kPanasonicAcFanAuto);
panair.setMode(kPanasonicAcCool);
panair.setTemp(25);
#if SEND_PANASONIC
// Now send the IR signal.
panair.send();
#else // SEND_PANASONIC
Serial.println("Can't send because SEND_PANASONIC has been disabled.");
#endif // SEND_PANASONIC
delay(5000);
}
and it works like a charm for the simple commands. I'll gather missing information and share them with you guys. Amazing.
Okay so I think I have gathered missing info. It seems that those extra features send a smaller payload to the unit, and always the same one. (Patrol/e-ion for example just send the same payload if I press the key on my remote). It looks like this is a toggle command that is sent and I have nothing on the small screen that indicates that the feature is On or Off, which correlate with the fact that everything this is a constant payload that need to be sent to toggle the feature.
I have gathered a lot of commands from my remote with AnalyzIR, I'll let you check that everything looks normal for the commited code, and to work with this.
If you need more intel, just ask, and I'll see what I can do 👍
https://imgur.com/gallery/UeVnYdh
please read them from bottom to top.
Those 128 bits payload is what I was talking about, when I press the special keys that have no feedback in the remote control.
EDIT : did not managed to keep styling of the report, but here is a version where you can copy paste data from it, rather than from a picture
# | Key | Hex | # Bits | ||
1 | ON/27°C/ALL AUTO/MODE COOL | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 0D 00 0E E0 00 00 81 00 00 20 | 216 | ||
2 | horizontal left | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 0C 00 0E E0 00 00 81 00 00 1F | 216 | ||
3 | horizontal middle right | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 0A 00 0E E0 00 00 81 00 00 1D | 216 | ||
4 | horizontal right | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 09 00 0E E0 00 00 81 00 00 1C | 216 | ||
5 | horizontal 1 press | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 06 00 0E E0 00 00 81 00 00 19 | 216 | ||
6 | ON/27°C/ALL AUTO/MODE COOL | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 0D 00 0E E0 00 00 81 00 00 20 | 216 | ||
7 | vertical swing to pos 5 (lowest position) | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 A5 0D 00 0E E0 00 00 81 00 00 16 | 216 | ||
8 | vertical swing to position 3 (middle position) | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 A3 0D 00 0E E0 00 00 81 00 00 14 | 216 | ||
9 | vertical swing higher position | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 A1 0D 00 0E E0 00 00 81 00 00 12 | 216 | ||
10 | ON/27°C/ALL AUTO/MODE COOL | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 0D 00 0E E0 00 00 81 00 00 20 | 216 | ||
11 | fan speed 5 | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 7F 0D 00 0E E0 00 00 81 00 00 F0 | 216 | ||
12 | fan speed 3 | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 5F 0D 00 0E E0 00 00 81 00 00 D0 | 216 | ||
13 | fan min | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 3F 0D 00 0E E0 00 00 81 00 00 B0 | 216 | ||
14 | ON/27°C/ALL AUTO/MODE COOL | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 0D 00 0E E0 00 00 81 00 00 20 | 216 | ||
15 | Powerfull/quiet pressed | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 9C 32 54 | 128 | ||
16 | Powerfull/quiet pressed | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 9C 32 54 | 128 | ||
17 | Powerfull/quiet pressed | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 9C 32 54 | 128 | ||
18 | Patrol pressed | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 66 33 1F | 128 | ||
19 | Patrol pressed | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 66 33 1F | 128 | ||
20 | Patrol pressed | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 66 33 1F | 128 | ||
21 | Comfort Off | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 52 33 0B | 128 | ||
22 | Comfort On | 02 20 E0 04 00 00 00 06 02 20 E0 04 80 69 F2 E1 | 128 | ||
23 | DRY - switch auto to 24 °C | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 29 30 80 AF 0D 00 0E E0 00 00 81 00 00 0A | 216 | ||
24 | 27°C | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 36 80 AF 0D 00 0E E0 00 00 81 00 00 20 | 216 | ||
25 | 26°C | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 34 80 AF 0D 00 0E E0 00 00 81 00 00 1E | 216 | ||
26 | ON/25°C/ALL AUTO/ MODE | 02 20 E0 04 00 00 00 06 02 20 E0 04 00 39 32 80 AF 0D 00 0E E0 00 00 81 00 00 1C | 216 |
Thanks for that. Top work.
Can you please capture some of those "short" 128bit messages with IRrecvDumpV2
please?
I want to make sure of the underlying structure of those messages. i.e. The rawData[] lines.
In order to send those short(er) messages, I'll need to make some changes to sendPanasonicAC()
and that data will help.
What I think I'll need to do at least is:
Change the line in ir_Panasonic.cpp
from:
if (nbytes < kPanasonicAcStateLength) return;
to:
if (nbytes < kPanasonicAcSection1Length) return;
and after that maybe you can send via:
uint8_t patrol[16] = (0x02, 0x20, 0xE0, 0x04, 0x00, 0x00, 0x00, 0x06, 0x02, 0x20, 0xE0, 0x04, 0x80, 0x66, 0x33, 0x1F};
irsend.sendPanasonicAC(patrol, 16);
try it and let me know how it goes.
I've gotten a "raw" copy of one of the short Panasonic a/c messages. The changes I've merged in to the master
branch supports sending and basic decoding of these. It will be in the next release of the library.
The short messages are not deep decoded into specific functions etc, but it will give you the state and size to send with so you can use it.
Marking this closed for now.
This is now live in the new v2.5.2 release of the library.
Version/revison of the library used
2.5.1
Output of raw data from IRrecvDumpV2.ino (if applicable)
Example code used
https://github.com/ToniA/arduino-panasonic-heatpump-controller/blob/master/PanasonicHeatpumpController.ino
Hello guys. I am here because I saw your amazing work on Panasonic A/C. I just wanted to share with you my testing. So basically, I am using the code aboce (github link) to control my AC unit. The controller is A75C3704, and it works well. But, as you can see IRRemoteESP can't decode it. So as the code is working above, and that I am willing to do all the testing necessary on my unit, I thought I could share with people more familiar with developping on IRRemote than me.
The above code represent this state on the controller : Status : ON, Mode Cool, Fanspeed Auto, Swing auto (both V and H), temp 26 Celsius
I hope it could help you to extend compatibility with this unit. Again, I am willing to help you share code and test sendings on my unit at home.
Thank you