Supporting Panasonic AC/Heat pump indoor unit CS-E9CKP remote A75C2295

[taxx]

Feature request

Hello and thanks for all the awesome work on this library!

I am trying to control one of my older AC / Heatpumps using this library
(Actually using esphome that uses this library with a custom climate component)

But I fall short on that there is no support for my particular unit in the library.

The heat pump is an CS-E9CKP and the remote is an A75C2295

Browsing though the code here:
https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_Panasonic.cpp
I saw a reference to HeatpumpIR and this code:
https://github.com/ToniA/ESPEasy/blob/HeatpumpIR/lib/HeatpumpIR/PanasonicHeatpumpIR.cpp

Checking that code there seems to be an implementation for the CKP heat pump and the A75C2295 remote.
https://github.com/ToniA/arduino-heatpumpir/blob/master/PanasonicCKPHeatpumpIR.cpp
https://github.com/ToniA/arduino-heatpumpir/blob/master/PanasonicCKPHeatpumpIR.h

I tested a small sample code from HeatpumpIR and the indoor unit reacted to the commands so the needed ir-stuff is in there.

Any possibility of having support for this heat pump in your library?

Best Regards Tobias

[crankyoldgit]

It looks like we already support Panasonic CKP A/Cs.

IRremoteESP8266/src/IRsend.h

Line 147 in 3787433

kPanasonicCkp = 5,

Have you tried setting the model to kPanasonicCkp or 5?
e.g. from one of the example files:

IRremoteESP8266/examples/TurnOnPanasonicAC/TurnOnPanasonicAC.ino

Lines 55 to 61 in 3787433

	ac.setModel(kPanasonicRkr);
	ac.on();
	ac.setFan(kPanasonicAcFanAuto);
	ac.setMode(kPanasonicAcCool);
	ac.setTemp(26);
	ac.setSwingVertical(kPanasonicAcSwingVAuto);
	ac.setSwingHorizontal(kPanasonicAcSwingHAuto);

[taxx]

Yeah, I should have mentioned that in the original post, I've tested all variants of Panasonic in that enum panasonic_ac_remote_model_t, none of them makes the indoor unit react.

But to eliminate any other issues with my previous attempts, I took the sample code and added it to a simple PIO project and tested that again and didn't get any reaction on the heat pump.
(Verifying that I actually saw the IR led blinking looking via the camera in my phone).

There is a lot of listed CKP/5 units with their remotes here:
https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_Panasonic.h
But it do looks like there is a difference between the CKP/5 vs CKP/9 heat pumps and their remotes.

I could try to take a stab at this, but I am afraid it's a little bit over my head.

[NiKiZe]

Can you record your remote with DumpV2+?

[crankyoldgit]

Yeah, I should have mentioned that in the original post, I've tested all variants of Panasonic in that enum panasonic_ac_remote_model_t, none of them makes the indoor unit react.

Thanks for confirming you've tried it.
I've had a quick look at the HeatpumpIR code, while some of it is useful, I don't like how they are doing power on & off. They are setting a on timer one minute before, and wait a minute to turn on the device. Similar for turning it off again.

I'd like to start with you (@taxx) capturing some raw data from the actual remote. e.g. We are going to follow https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol and then https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol

Because of the existing work by the HeatpumpIR code, we can save a lot of reverse engineering effort, but I'd like to collect real data to be able to verify against etc.

So, provide some of that and we can then begin to add support for it.

[taxx]

Thanks!
I'll start capturing some signals from the remote this weekend.

[taxx]

Finally managed to get some data in the serial monitor while sending signals from the remote, using the IRrecvDumpV2 code.
(Had some problems when the receiver was running at 3.3V.)

But I must say I am a bit lost, been reading the details in the links. Especially in regards to "Get basic support for the new IR protocol working first". As panasonicAC is implemented there are probably changes to that needed?

Anyway I started recording with everything set to auto (mode, fan, swings) on the remote and then adjusted the temperature from lowest (16) to highest (30). Took the results and ran the python tool (auto_analyze_raw_data.py).

Not really understanding what I am doing, I went on following the guide to add a protocol. The generated code was referencing a constant called kPanasonicAC2SpaceGap. I understand that it's more to it than these steps, I just wanted to see if I could get anything to compile or to be decoded). (Keep in mind I am out on deep water here))

But when I came to the changes in IRSend.cpp I noticed something that might be a bug in Panasonic AC?
Take a look at IRSend.cpp line 724-727, looks like a copy paste error. I have no idea what the implication are though.

My ugly changes compiles now but I can't see anything fancy in the decode.

Attached temp.txt with the recordings from changing the temperature.

I am obviously lost here :-)

[NiKiZe]

Nice to see some data.
There is parts of your data that is a bit inconsistent, it might be your receiver that is still acting up.
You might want to see https://github.com/crankyoldgit/IRremoteESP8266/wiki/Troubleshooting-Guide#basic-1 and follow up with 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

[taxx]

The problems I had before was that I didn't get any signals at all when I was running my TSOP4838 with 3.3V from the ESP32/ESP8266. I've since switched over to a Wemos D1 mini with the IR receiver powered from 5V.
(But anyway, new TSOP modules in all variations are ordered now)

Good tips in the troubleshooting guide! I was very close last time and using a empty box as a tunnel to shield the receiver from any other signals. I've ran the same sampling as before (16-30 C, all other in auto) all lights turned of and waiting a couple of seconds between each transmission.

Is it better now?
temp-take2.txt

[crankyoldgit]

I've had a detailed look at the signals captured in temp-take2.txt and unfortunately all the ones I tried contain too much noise &/or garbage etc.

You may need to wait to try it against a better hardware IR demodulator.
Also, try recording it at night perhaps, with less sunlight/heat sources etc. Fluorescent lights can also cause havoc too.

As for the issue in defaultBits(). Yes. That's an error. Fix coming shortly.

[taxx]

Can I identify how good the captures are by myself somehow? What are the telltales? (To be able to improve my setup)
For example would a long cardboard tube shielding the receiver and remote from other things help?

[crankyoldgit]

Can I identify how good the captures are by myself somehow? What are the telltales? (To be able to improve my setup)
For example would a long cardboard tube shielding the receiver and remote from other things help?

It's hard to quantify exactly. It's a good signal when the values (depending on their position) are close to one another.
If the signal contains unusually short pulses (e.g. sub-200us) then it's likely a bad signal.
See https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Im_getting_some_random_odd_values__50_usecs_in_my_capture_of_an_IR_message_What_is_up_with_that

BTW, Panasonic uses a frequency of 36.7kHz, most IR demodulators are expecting 38kHz. Depending on the quality of the demodulator, sometimes it works okay-ish, or sometimes (probably yours) it doesn't behave well. It's hit and miss.

I'd suggest getting a demodulator that is specific for the Panasonic protocol/frequencies.

[taxx]

The demodulators arrived today and I've hooked up a 36Khz variant (TSOP4836) to my setup.
Ran the same 16-30 degrees cycle: temp-take3_36khz.txt

I do notice that the number of bits is more static (136 bits) than before.
Still very confused what to make of the rawData, it's like I can't see past the matrix :-)

Took the generated code from the python tool (auto_analyze_raw_data.py) and switched out my attempts on a protocol decoder. Running the commands again against a IRrecvDumpV2, I can't see any apparent differences in the outputs.
(Added it as a "PANASONIC_AC2" to keep it isolated)

[crankyoldgit]

Good news. Those readings are clean/good. I'll take a look at building a basic sender/decoder soon.

[crankyoldgit]

@taxx Can you please download and test branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/PanasonicAC64
Both sending and decoding please.

Hopefully, it should decode and send the messages for your A/C.
e.g.

// # Remote: 17 C, auto mode, auto top swing, auto left/right swing, auto fan
irsend.sendPanasonicAC64(0x0D0DF2F23636FCFC);

There is a LOT of duplication in the messages you collected.
e.g.
There are 4 blocks of 32bit data in each message (4 x 32 = 128 bits), however the 1st & 2nd blocks and the 3rd & 4th blocks seem to be a repeat of each other. So, I shrank it down to 64 bits. (128 / 2). (see assumptions below)

It is possible we may be able to shrink it further to 32 bits, because even the resulting code detected seems to have every second 8-bit chunk of data be a repeat of the preceding 8 bits.
e.g.
0x0D0DF2F23636FCFC might become 0x0DF236FC

I need you to play around with your remote to see if some assumptions are correct. e.g.:
a) There is a setting that repeatedly breaks the existing (64bit) decoding. If so, please supply the raw data. e.g. Not just a random-noise effected message. The same setting always is un-decodable. i.e. Maybe need to use 128 bits instead)
b) That byte pattern above no longer stays the same. i.e. Repeating sets of 2 hex digits. (A leading 0 is okay to be missing.) If the pattern holds, we can probably shrink it to 32 bits.

[taxx]

Like magic!
Big thanks for this, I see commands getting decoded now.

I'll see if I can solve the logistics of sending signals to the wall unit this weekend.

Meanwhile, I've started playing around with it and recording things to a spreadsheet.
(Not 100% sure I've understood how to do it)

About the on/off command, I wonder if there is anything with that timer thing from the HeatPumpIR library, the on/off sends the same command: 0x505F5F53636FCFC; (Recorded a couple of different on/off sequences in the spreadsheet)

Noticed that there are some signals that are not being decoded, and shows a different length of 101 bits.
Attaching samplings from those button presses.
swing-horizontal.txt
swing-vertical.txt
quiet-powerful.txt

Again huge thanks for taking a look at this!

About the duplication, could there be some redundancy in how the remote sends the signals to ensure reception?

[crankyoldgit]

Just taking a look at your spreadsheet now.
The output is currently 64 bits. That means there is a even number of hexadecimal digits in the message.
i.e. when you think you've got a single hex digit at the end, you don't. It's really got a leading 0 missing from the front.
e.g.
https://docs.google.com/spreadsheets/d/1V7Z4edgjPXNH9vbu0QUJQzha7eIfboO-I2pNhITKtEQ/edit#gid=0&range=C2
0xD0DF1F13636FCFC; should really be 0x0D0DF1F13636FCFC;
i.e. 0D, 0D, F1, F1, 36, 36, FC, FC
There should always be 16 characters in a 64-bit hexadecimal number. But like decimal, the convention is to not print the leading 0s/zeros.

In other words, your alignment into bytes is wrong: https://docs.google.com/spreadsheets/d/1V7Z4edgjPXNH9vbu0QUJQzha7eIfboO-I2pNhITKtEQ/edit#gid=0&range=D2:K2

[crankyoldgit]

FYI, don't go crazy recording the codes yet. The data you've collected shows it can be compressed further, so the values will change soon.

[crankyoldgit]

I've updated that branch to handle "short" messages (e.g. swing, quiet, & powerful)
Please try it out.

[taxx]

Thanks for your patience with this noob I am :-)
I've adjusted my alignments (happy I used formulas in the sheet).

The shorter commands seems to decode into uit64_t data now, I've updated the sheet with the recordings from those.
But the 32 bit captures doesn't follow the same pattern? i.e the leading zero doesn't seem to be a part of the first byte, or?

[crankyoldgit]

Okay, I've updated the branch again (same name/url) but it's now 32bits/16bits instead of 64/32bits.
See 2a53d72

The codes/values reported from the captures should now be stable. i.e. Go forth onto the analysis phase of
https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#analysing-the-data
FYI, the bit ordering should be correct.

[taxx]

Managed to do some the sendPanasonicAC32 against the actual wall unit. (There are some logistics involved with the wall unit being in a different place than I am normally. Hence the need to control it remotely :-))

Things look good overall on the 32/16 bit protocol, but there are some oddities.
In relation to the Quiet/Powerful/previously 32 bit commands (from when it decoded 32/64bit). For example when sending Quiet ; 0x3381 it turns off the wall unit and sending it again turns it back on. (converted manually, though, not recorder).

  // Quiet declared as:  const uint32_t Quiet = 0x3381;

  // From the loop() part
  irsend.sendPanasonicAC32(Quiet);
  // Wall unit turns off if it was on
  delay(10000);

  irsend.sendPanasonicAC32(Quiet);
  // Wall unit turns on if it was off
  delay(10000);

I'll do some more hands-on later today when I am actually in front of the wall unit.

[crankyoldgit]

If it is a 16bit code, you'll need to tell sendPanasonicAC32() to use 16 bits. It uses 32 bits by default.
E.g. irsend.sendPanasonicAC32(Quiet, 16);

[taxx]

Great now it works to send those codes!

[taxx]

Running the IRrecvDumpV2 now I get this decoded

Protocol  : PANASONIC_AC64
Code      : 0xE0EF7F73636FCFC (64 Bits)
uint64_t data = 0xE0EF7F73636FCFC;

(Temp: 22 C, Mode: Auto, Fan: Auto, H swing: Auto, V swing: Auto, Clock: Blinking)

Should I be getting something like PANASONIC_AC32 with 32bit data?

[crankyoldgit]

You need to rebuild & upload using the latest commits in that branch, it should be reporting as 32

[taxx]

Started recording data to the spreadsheet, starting to see some patterns, I think.

I did however encounter "commands" related to timer logic that isn't being decoded, 210 bit length messages. Attached a sampling of those messages below. From my point of view it's nothing I intend to use though, but I can of course try to decode them as well.

Timer-Stuff.txt

[crankyoldgit]

I did however encounter "commands" related to timer logic that isn't being decoded, 210 bit length messages. Attached a sampling of those messages below. From my point of view it's nothing I intend to use though, but I can of course try to decode them as well.

Timer-Stuff.txt

Sigh. This is information I wish I had had much sooner. I can't fit that into the way I've currently designed the code for this protocol. In short, it boils down to 96 bits of information. i.e. Larger than 64 bits. To support those messages natively, it would require a major redesign & rewrite of the code. That's not something I want to do for a feature that probably won't get used much. (i.e. Timers)

So, I'm going to say, lets forget about timers. :-/

[taxx]

Any tips on how to implement code changes to the ir_Panasonic.* files for this remote ?
For example the enum: panasonic_ac_remote_model_t contains a "ckp" unit that doesn't work with this E9CKP unit I am having. (Perhaps a switch to using the remote name?)

I also need some eyes on my spreadsheet to get feedback if I am on the right track or not.
The mode = auto and temperature sweep from 16 C - 30 C confuses me a bit, looks like what I think is the mode changes dependent on the temperature.

[crankyoldgit]

Any tips on how to implement code changes to the ir_Panasonic.* files for this remote ?

You can leave that to us, once you've got a firmer understanding of what bits control what etc.

For example the enum: panasonic_ac_remote_model_t contains a "ckp" unit that doesn't work with this E9CKP unit I am having. (Perhaps a switch to using the remote name?)

For example the enum: panasonic_ac_remote_model_t contains a "ckp" unit that doesn't work with this E9CKP unit I am having. (Perhaps a switch to using the remote name?)

You can ignore that. This "protocol" won't use the same PANASONIC_AC protocol as that (panasonic_ac_remote_model_t, it will use PANASONIC_AC32 and most likely not have per model options.

I also need some eyes on my spreadsheet to get feedback if I am on the right track or not.

To me it seems you're on the right track so far.

The mode = auto and temperature sweep from 16 C - 30 C confuses me a bit, looks like what I think is the mode changes dependent on the temperature.

I concur. The remote might have a temperature sensor in it and tell the A/C what "auto" mode to be in. Try putting the remote in the refrigerator or neat a heater to see if the values change based on the temp the remote thinks it is.

If not, we can construct a table or the needed logic to work out what "auto" value to use based on the requested temp.

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.7.12 release of the library.

[crankyoldgit]

I'm going to close this issue. When you've finished your analysis/breakdown of the message bits, please create a new issue and reference this old one.

[Fettkeewl]

Any tips on how to implement code changes to the ir_Panasonic.* files for this remote ?
For example the enum: panasonic_ac_remote_model_t contains a "ckp" unit that doesn't work with this E9CKP unit I am having. (Perhaps a switch to using the remote name?)

I also need some eyes on my spreadsheet to get feedback if I am on the right track or not.
The mode = auto and temperature sweep from 16 C - 30 C confuses me a bit, looks like what I think is the mode changes dependent on the temperature.

Any progress on this? I've got the same setup at home can't wait to be able to control it :P

[crankyoldgit]

@Fettkeewl I'm sure @taxx would like some extra eyes & effort to help on the analysis of the bits in the message.

See the wiki about how to do it for aircons.

[Fettkeewl]

@crankyoldgit I'm sorry but such analysis is beyond my knowledge, I struggle with understanding bits and bytes specially with RF/IR. I've tried a couple of times, without the proper education it's just to hard to follow 😛

However: if it's any help in making some progress I found this lib on github
https://github.com/ToniA/arduino-heatpumpir/blob/43fd054bdffbba588c31faaf44522c8b7a31e573/PanasonicCKPHeatpumpIR.h
Can this be of any help to you guys @crankyoldgit @taxx , it is the same remote we both have (me and @taxx )

// Panasonic CKP timing constants (remote control P/N A75C2295)
#define PANASONIC_AIRCON1_HDR_MARK   3400
#define PANASONIC_AIRCON1_HDR_SPACE  3500
#define PANASONIC_AIRCON1_BIT_MARK   800
#define PANASONIC_AIRCON1_ONE_SPACE  2700
#define PANASONIC_AIRCON1_ZERO_SPACE 1000
#define PANASONIC_AIRCON1_MSG_SPACE  14000

// Panasonic CKP codes
#define PANASONIC_AIRCON1_MODE_AUTO  0x06 // Operating mode
#define PANASONIC_AIRCON1_MODE_HEAT  0x04
#define PANASONIC_AIRCON1_MODE_COOL  0x02
#define PANASONIC_AIRCON1_MODE_DRY   0x03
#define PANASONIC_AIRCON1_MODE_FAN   0x01
#define PANASONIC_AIRCON1_MODE_ONOFF 0x00 // Toggle ON/OFF
#define PANASONIC_AIRCON1_MODE_KEEP  0x08 // Do not toggle ON/OFF
#define PANASONIC_AIRCON1_FAN_AUTO   0xF0 // Fan speed
#define PANASONIC_AIRCON1_FAN1       0x20
#define PANASONIC_AIRCON1_FAN2       0x30
#define PANASONIC_AIRCON1_FAN3       0x40
#define PANASONIC_AIRCON1_FAN4       0x50
#define PANASONIC_AIRCON1_FAN5       0x60
#define PANASONIC_AIRCON1_VS_SWING   0xF0 // Vertical swing
#define PANASONIC_AIRCON1_VS_UP      0x90
#define PANASONIC_AIRCON1_VS_MUP     0xA0
#define PANASONIC_AIRCON1_VS_MIDDLE  0xB0
#define PANASONIC_AIRCON1_VS_MDOWN   0xC0
#define PANASONIC_AIRCON1_VS_DOWN    0xD0
#define PANASONIC_AIRCON1_HS_SWING   0x08 // Horizontal swing
#define PANASONIC_AIRCON1_HS_MANUAL  0x00

[crankyoldgit]

@Fettkeewl That code might work. I can't tell, as I don't have access to a CKP AC device.
Why don't you try that software and see if it works.

[Fettkeewl]

@Fettkeewl That code might work. I can't tell, as I don't have access to a CKP AC device.
Why don't you try that software and see if it works.

Aright, having tried it out I can confirm that

1. The library covering Panasonic CKP heatpumps with remote A75C2295 works.
2. There is a weird workaround for some reason using timers to control on/off state of the heatpump.
   Why I do not know, there is a dedicated on/off button on the remote.
3. library uses 38 kHz frequency for sending and not what you wrote (far above, panasonic using 36,7 kHz)

BTW, Panasonic uses a frequency of 36.7kHz, most IR demodulators are expecting 38kHz.

4. Cant set freq to 36.7 kHz due to lib using int as argument, tried with 37. Worked all the same.
5. I used the example code and only modified row 22 to be (IRSenderESP8266)
6. My original remote sends signals at 4-5 meters distance without issue, my IR blaster can only send from 10 cm @ 3.3v and rougly 30-40 cm distance @ 5v ( maybe something with the frequency here, beyond me)

Now what @crankyoldgit :) How do we get this in to IRremoteESP8266?
Oh and btw under step 5 above, I tried ToniA's implementation of your library aswell using (IRSenderIRremoteESP8266 instead)
and it worked aswell.

#include <Arduino.h>

#include <PanasonicCKPHeatpumpIR.h>
#include <Timer.h> // https://github.com/JChristensen/Timer

/*
    This schema demonstrates how to control the Panasonic CKP power state change. The CKP does not have discrete
    'ON' and 'OFF' commands, but only a state switch. So, if the initial power state is now known, switching the
    state does not help much.
    
    Luckily this can be implemented by using the timer:
    * The 'send' command will send all the settings AND program the timer so that the pump will turn ON in a minute
    * The 'sendPanasonicCKPCancelTimer' will cancel the timer
    
    The 'turn OFF' must be implemented the same way.
    
    Of course you can choose to not turn off the timer, but that means that the heatpump will attempt to switch ON
    (or OFF) every day at the same time, as the timer will still be active.
*/


IRSenderESP8266Alt irSender(4);     // IR led on Duemilanove digital pin 3, using Arduino PWM
//IRSenderBlaster irSender(3); // IR led on Duemilanove digital pin 3, using IR Blaster (generates the 38 kHz carrier)

PanasonicCKPHeatpumpIR *heatpumpIR;

Timer timer;

void setup()
{
  Serial.begin(115200);
  delay(500);

  heatpumpIR = new PanasonicCKPHeatpumpIR();

  Serial.println("Turning the Panasonic CKP heatpump ON by using the timer");
  heatpumpIR->send(irSender, POWER_ON, MODE_HEAT, FAN_2, 24, VDIR_UP, HDIR_AUTO);
  Serial.println("The heatpump should have beeped, and the TIMER led should be ON");

  timer.after(60000, panasonicIsOn); // Called after 1 minute
  timer.after(120000, panasonicCancelTimer); // Called after 2 minutes

}

void loop()
{
  timer.update();
}

void panasonicIsOn()
{
  Serial.println("The heatpump should should turn ON by now, the TIMER led is still ON");
}

void panasonicCancelTimer()
{
  heatpumpIR->sendPanasonicCKPCancelTimer(irSender);
  Serial.println("The TIMER led should now be OFF");
}

[crankyoldgit]

BTW, Panasonic uses a frequency of 36.7kHz, most IR demodulators are expecting 38kHz.

1. Cant set freq to 36.7 kHz due to lib using int as argument, tried with 37. Worked all the same.

FYI see https://crankyoldgit.github.io/IRremoteESP8266/doxygen/html/classIRsend.html#ab3b6d36c9b5d26c400526717d433ed2d
Our library can use enableIROut(36700);

Thanks for confirming that code works. I'll look at re-working it into our framework.

Are you able to capture the on/off messages? If so, please provide them.