Not working on CS-Z35XKEW / probably new protocol/change?

[jonasf21]

I've got a panasonic CS-Z35XKEW (Etherea). It appears its no longer possible to replace the existing DNSK-P11 because the protocol seems to have changed. The module itself now also locks a bit different (different labels/style but still reads DNSK-P11).
I've captured the TX/RX and this is what it does:

[20:36:29][V][panasonic_ac:245]: TX: 5A.09.10.01.00.05.01.30.01.00.01.54 (12)
[20:36:29][V][panasonic_ac:247]: RX: 5A.09.10.81.00.D6.00.01.30.01.00.01.00.01.00.33.00.80.E2.01.00.85.42.04.00.86.62.2E.00.88.62.01.00.A0.E2.01.00.A1.E2.01.00.A4.E2.01.00.A5.E2.01.00.B0.E2.01.00.B2.E2.01.00.BB.42.01.00.BE.42.01.02.20.62.01.02.21.62.01.02.31.E2.01.02.32.62.01.02.33.E2.01.02.34.E2.01.02.35.E2.01.02.36.E2.01.02.42.82.01.02.7D.E2.01.02.7E.42.01.02.7F.42.02.02.80.42.02.02.81.42.02 (120)
[20:36:29][D][panasonic_ac.dnskp11:280]: Dropping invalid packet (checksum)
[20:36:29][V][panasonic_ac:247]: RX: 02.82.42.02.02.83.42.02.02.84.42.02.02.89.C2.0C.02.8A.C2.06.02.8B.C2.06.02.8C.C2.0E.02.91.42.02.02.92.C2.02.02.96.42.02.02.97.42.02.02.98.42.02.02.99.42.02.02.9A.42.02.02.9B.42.02.02.A0.C2.01.02.A1.C2.07.02.A2.C2.02.02.A3.C2.04.02.A4.C2.02.02.A5.C2.02.02.A8.42.02.02.A9.C2.03.02.AA.E2.02.02.FF.42.40.FC (101)
[20:36:29][W][panasonic_ac.dnskp11:249]: Dropping invalid packet (header)
[20:36:29][D][panasonic_ac.dnskp11:721]: Resending previous packet
[20:36:29][V][panasonic_ac:245]: TX: 5A.09.10.01.00.05.01.30.01.00.01.54 (12)
[20:36:30][V][panasonic_ac:247]: RX: 5A.09.10.81.00.D6.00.01.30.01.00.01.00.01.00.33.00.80.E2.01.00.85.42.04.00.86.62.2E.00.88.62.01.00.A0.E2.01.00.A1.E2.01.00.A4.E2.01.00.A5.E2.01.00.B0.E2.01.00.B2.E2.01.00.BB.42.01.00.BE.42.01.02.20.62.01.02.21.62.01.02.31.E2.01.02.32.62.01.02.33.E2.01.02.34.E2.01.02.35.E2.01.02.36.E2.01.02.42.82.01.02.7D.E2.01.02.7E.42.01.02.7F.42.02.02.80.42.02.02.81.42.02 (120)
[20:36:30][D][panasonic_ac.dnskp11:280]: Dropping invalid packet (checksum)
[20:36:30][E][component:113]: Component panasonic_ac.climate was marked as failed.

The RX packets are switching between those with invalid header and invalid checksum. The RX packets do not change (besides those with invalid header vs. those with invalid checksum). So its not noise or interference.

Any ideas?

[DomiStyle]

The handshake is just a 1:1 replay of what my DNSK-P11 sent when I captured it years ago.
I never bothered actually finding out what the fields do.

As a quick test you could try disabling the checksum test to see if the handshake runs through: https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L32

It pretty much does not matter what the AC sends at this point, it just matters that the AC initializes successfully so that it starts accepting commands.

If that does not work, do you have a CNT port as well? You can connect it there as well.

[jonasf21]

Just commected Line 32/33 of esppac_wlan.cpp and recompiled. Now i am getting this:

[22:25:00][V][panasonic_ac:247]: RX: 66.08.00.01.01.F6 (6)
[22:25:00][W][panasonic_ac.dnskp11:613]: Received unknown packet during initialization
[22:25:01][D][panasonic_ac.dnskp11:204]: Starting handshake [1/16]
[22:25:01][V][panasonic_ac:245]: TX: 5A.00.00.06.00.00.A0 (7)
[22:25:01][V][panasonic_ac:245]: TX: 5A.01.00.09.00.00.9C (7)
[22:25:01][V][panasonic_ac:247]: RX: 66.08.00.01.01.F6 (6)
[22:25:01][W][panasonic_ac.dnskp11:613]: Received unknown packet during initialization
[22:25:01][V][panasonic_ac:247]: RX: 66.08.00.01.01.F6 (6)
[22:25:01][W][panasonic_ac.dnskp11:613]: Received unknown packet during initialization
[22:25:02][V][panasonic_ac:247]: RX: 66.08.00.01.01.F6 (6)

Yes, i do have a CNT port but no cable to use it - i've ordered connectors, but it'll take some time to arrive.

EDIT: yay it seems to work now - no idea what happend. Some minutes later it seems to init successfully:

[22:30:31][V][panasonic_ac:247]: RX: 66.08.00.01.01.F6 (6)
[22:30:31][W][panasonic_ac.dnskp11:613]: Received unknown packet during initialization
[22:30:32][V][panasonic_ac:247]: RX: 66.08.00.01.01.F6 (6)
[22:30:32][W][panasonic_ac.dnskp11:613]: Received unknown packet during initialization
[22:30:32][V][panasonic_ac:247]: RX: 66.08.00.01.01.F6 (6)
[22:30:32][W][panasonic_ac.dnskp11:613]: Received unknown packet during initialization
[22:30:33][D][panasonic_ac.dnskp11:204]: Starting handshake [1/16]
[22:30:33][V][panasonic_ac:245]: TX: 5A.00.00.06.00.00.A0 (7)
[22:30:33][V][panasonic_ac:245]: TX: 5A.01.00.09.00.00.9C (7)
[22:30:33][D][panasonic_ac.dnskp11:721]: Resending previous packet
[22:30:33][V][panasonic_ac:245]: TX: 5A.01.00.09.00.00.9C (7)
[22:30:34][V][panasonic_ac:247]: RX: 5A.01.00.89.00.02.00.02.18 (9)
[22:30:34][D][panasonic_ac.dnskp11:555]: Answering handshake [2/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.02.00.0C.00.00.98 (7)
[22:30:34][V][panasonic_ac:247]: RX: 5A.02.00.8C.00.01.00.17 (8)
[22:30:34][D][panasonic_ac.dnskp11:559]: Answering handshake [3/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.03.00.10.00.01.20.72 (8)
[22:30:34][V][panasonic_ac:247]: RX: 5A.03.00.90.00.02.00.20.F1 (9)
[22:30:34][D][panasonic_ac.dnskp11:563]: Answering handshake [4/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.04.00.11.00.02.00.01.8E (9)
[22:30:34][V][panasonic_ac:247]: RX: 5A.04.00.91.00.36.00.00.01.00.01.0A.15.43.53.2D.5A.33.35.58.4B.45.57.2B.34.38.38.36.39.33.34.39.39.36.0B.02.01.2C.0C.14.43.53.2D.32.31.31.00.00.00.00.00.00.00.00.00.00.00.00.00.00.F8 (61)
[22:30:34][D][panasonic_ac.dnskp11:567]: Answering handshake [5/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.05.00.12.00.04.01.10.11.12.57 (11)
[22:30:34][V][panasonic_ac:247]: RX: 5A.05.00.92.00.05.00.01.10.11.12.D6 (12)
[22:30:34][D][panasonic_ac.dnskp11:571]: Answering handshake [6/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.06.00.41.00.00.5F (7)
[22:30:34][V][panasonic_ac:247]: RX: 5A.06.00.C1.00.02.00.01.DC (9)
[22:30:34][D][panasonic_ac.dnskp11:575]: Answering handshake [7/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.07.01.4C.00.00.52 (7)
[22:30:34][V][panasonic_ac:247]: RX: 5A.07.01.CC.00.02.00.01.CF (9)
[22:30:34][D][panasonic_ac.dnskp11:579]: Answering handshake [8/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.08.10.00.00.00.8E (7)
[22:30:34][V][panasonic_ac:247]: RX: 5A.08.10.80.00.05.00.01.01.30.01.D6 (12)
[22:30:34][D][panasonic_ac.dnskp11:583]: Answering handshake [9/16]
[22:30:34][V][panasonic_ac:245]: TX: 5A.09.10.01.00.05.01.30.01.00.01.54 (12)
[22:30:35][V][panasonic_ac:247]: RX: 5A.09.10.81.00.D6.00.01.30.01.00.01.00.01.00.33.00.80.E2.01.00.85.42.04.00.86.62.2E.00.88.62.01.00.A0.E2.01.00.A1.E2.01.00.A4.E2.01.00.A5.E2.01.00.B0.E2.01.00.B2.E2.01.00.BB.42.01.00.BE.42.01.02.20.62.01.02.21.62.01.02.31.E2.01.02.32.62.01.02.33.E2.01.02.34.E2.01.02.35.E2.01.02.36.E2.01.02.42.82.01.02.7D.E2.01.02.7E.42.01.02.7F.42.02.02.80.42.02.02.81.42.02 (120)
[22:30:35][D][panasonic_ac.dnskp11:587]: Answering handshake [10/16]
[22:30:35][V][panasonic_ac:245]: TX: 5A.0A.00.18.00.00.84 (7)
[22:30:35][V][panasonic_ac:247]: RX: 02.82.42.02.02.83.42.02.02.84.42.02.02.89.C2.0C.02.8A.C2.06.02.8B.C2.06.02.8C.C2.0E.02.91.42.02.02.92.C2.02.02.96.42.02.02.97.42.02.02.98.42.02.02.99.42.02.02.9A.42.02.02.9B.42.02.02.A0.C2.01.02.A1.C2.07.02.A2.C2.02.02.A3.C2.04.02.A4.C2.02.02.A5.C2.02.02.A8.42.02.02.A9.C2.03.02.AA.E2.02.02.FF.42.40.FC (101)
[22:30:35][W][panasonic_ac.dnskp11:613]: Received unknown packet during initialization
[22:30:35][V][panasonic_ac:247]: RX: 5A.0A.00.98.00.01.00.03 (8)
[22:30:35][D][panasonic_ac.dnskp11:591]: Answering handshake [11/16]
[22:30:35][V][panasonic_ac:245]: TX: 5A.0B.01.00.00.01.10.89 (8)
[22:30:35][V][panasonic_ac:247]: RX: 5A.00.01.09.00.00.9C (7)
[22:30:35][D][panasonic_ac.dnskp11:604]: Received rx counter [14/16]
[22:30:35][V][panasonic_ac:245]: TX: 5A.00.01.89.00.07.00.B8.B7.F1.9B.4F.A6.25 (14)
[22:30:35][V][panasonic_ac:247]: RX: 5A.0B.01.80.00.01.00.19 (8)
[22:30:35][D][panasonic_ac.dnskp11:595]: Answering handshake [12/16]
[22:30:35][V][panasonic_ac:245]: TX: 5A.0C.10.08.00.09.01.01.30.01.01.02.42.01.42.BE (16)
[22:30:35][V][panasonic_ac:247]: RX: 5A.00.01.09.00.00.9C (7)
[22:30:35][D][panasonic_ac.dnskp11:604]: Received rx counter [14/16]
[22:30:35][V][panasonic_ac:245]: TX: 5A.00.01.89.00.07.00.B8.B7.F1.9B.4F.A6.25 (14)
[22:30:36][V][panasonic_ac:247]: RX: 5A.01.00.20.00.00.85 (7)
[22:30:36][D][panasonic_ac.dnskp11:609]: Answering handshake [15/16]
[22:30:36][V][panasonic_ac:245]: TX: 5A.01.00.A0.00.13.00.08.30.32.2E.30.33.2E.30.30.08.30.31.30.31.30.31.30.33.DB (26)
[22:30:36][D][panasonic_ac.dnskp11:217]: Polling for the first time
[22:30:36][V][panasonic_ac:245]: TX: 5A.0D.10.09.00.38.01.01.30.01.11.00.80.00.00.B0.00.02.31.00.00.A0.00.00.A1.00.00.A5.00.00.A4.00.00.B2.00.02.35.00.02.33.00.02.34.00.02.32.00.00.BB.00.00.BE.00.02.20.00.02.21.00.00.86.00.4B (63)
[22:30:37][V][panasonic_ac:247]: RX: 5A.0D.10.89.00.76.00.01.30.01.11.00.80.01.31.00.B0.01.41.02.31.01.2C.00.A0.01.41.00.A1.01.44.00.A5.01.43.00.A4.01.42.00.B2.01.41.02.35.01.41.02.33.01.42.02.34.01.41.02.32.01.41.00.BB.01.18.00.BE.01.7E.02.20.01.42.02.21.01.41.00.86.2E.2A.00.00.0B.01.01.48.30.30.30.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.3A (125)
[22:30:37][D][panasonic_ac.dnskp11:418]: Received query response
[22:30:37][W][panasonic_ac:064]: Received out of range outside temperature: 126
[22:30:37][D][select:015]: 'Panasonic AC Horizontal Swing Mode': Sending state center (index 3)
[22:30:37][D][select:015]: 'Panasonic AC Vertical Swing Mode': Sending state down (index 6)
[22:30:37][D][switch:055]: 'Panasonic AC NanoeX Switch': Sending state OFF
[22:30:37][D][climate:378]: 'Panasonic AC' - Sending state:
[22:30:37][D][climate:381]: Mode: OFF
[22:30:37][D][climate:389]: Custom Fan Mode: Automatic
[22:30:37][D][climate:395]: Custom Preset: Normal
[22:30:37][D][climate:398]: Swing Mode: HORIZONTAL
[22:30:37][D][climate:401]: Current Temperature: 24.00°C
[22:30:37][D][climate:407]: Target Temperature: 22.00°C
[22:30:37][V][component:204]: Component panasonic_ac.climate took a long time for an operation (0.11 s).
[22:30:37][V][component:205]: Components should block for at most 20-30ms.
[22:30:46][D][panasonic_ac.dnskp11:224]: Finishing handshake [16/16]
[22:30:46][V][panasonic_ac:245]: TX: 5A.0E.01.00.00.01.11.85 (8)
[22:30:46][V][panasonic_ac:247]: RX: 5A.0E.01.80.00.01.00.16 (8)
[22:30:46][I][panasonic_ac.dnskp11:545]: Panasonic AC component v2.3.0 initialized
[22:30:46][V][panasonic_ac:247]: RX: 5A.02.11.01.00.00.92 (7)
[22:30:46][W][panasonic_ac.dnskp11:548]: Received unknown packet
[22:30:47][V][panasonic_ac:247]: RX: 5A.02.11.01.00.00.92 (7)
[22:30:47][W][panasonic_ac.dnskp11:548]: Received unknown packet
[22:31:16][V][panasonic_ac.dnskp11:195]: Polling AC
[22:31:16][V][panasonic_ac:245]: TX: 5A.0F.10.09.00.38.01.01.30.01.11.00.80.00.00.B0.00.02.31.00.00.A0.00.00.A1.00.00.A5.00.00.A4.00.00.B2.00.02.35.00.02.33.00.02.34.00.02.32.00.00.BB.00.00.BE.00.02.20.00.02.21.00.00.86.00.49 (63)
[22:31:17][V][panasonic_ac:247]: RX: 5A.0F.10.89.00.76.00.01.30.01.11.00.80.01.31.00.B0.01.41.02.31.01.2C.00.A0.01.41.00.A1.01.44.00.A5.01.43.00.A4.01.42.00.B2.01.41.02.35.01.41.02.33.01.42.02.34.01.41.02.32.01.41.00.BB.01.18.00.BE.01.7E.02.20.01.42.02.21.01.41.00.86.2E.2A.00.00.0B.01.01.48.30.30.30.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.38 (125)
[22:31:17][D][panasonic_ac.dnskp11:418]: Received query response
[22:31:17][W][panasonic_ac:064]: Received out of range outside temperature: 126
[22:31:17][D][climate:378]: 'Panasonic AC' - Sending state:
[22:31:17][D][climate:381]: Mode: OFF
[22:31:17][D][climate:389]: Custom Fan Mode: Automatic
[22:31:17][D][climate:395]: Custom Preset: Normal
[22:31:17][D][climate:398]: Swing Mode: HORIZONTAL
[22:31:17][D][climate:401]: Current Temperature: 24.00°C
[22:31:17][D][climate:407]: Target Temperature: 22.00°C
[22:31:17][V][component:204]: Component panasonic_ac.climate took a long time for an operation (0.09 s).
[22:31:17][V][component:205]: Components should block for at most 20-30ms.
[22:31:46][V][panasonic_ac.dnskp11:195]: Polling AC
[22:31:46][V][panasonic_ac:245]: TX: 5A.10.10.09.00.38.01.01.30.01.11.00.80.00.00.B0.00.02.31.00.00.A0.00.00.A1.00.00.A5.00.00.A4.00.00.B2.00.02.35.00.02.33.00.02.34.00.02.32.00.00.BB.00.00.BE.00.02.20.00.02.21.00.00.86.00.48 (63)
[22:31:47][V][panasonic_ac:247]: RX: 5A.10.10.89.00.76.00.01.30.01.11.00.80.01.31.00.B0.01.41.02.31.01.2C.00.A0.01.41.00.A1.01.44.00.A5.01.43.00.A4.01.42.00.B2.01.41.02.35.01.41.02.33.01.42.02.34.01.41.02.32.01.41.00.BB.01.18.00.BE.01.7E.02.20.01.42.02.21.01.41.00.86.2E.2A.00.00.0B.01.01.48.30.30.30.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.37 (125)
[22:31:47][D][panasonic_ac.dnskp11:418]: Received query response

[jonasf21]

I've tested some settings and it seems most work (swing mode etc). However and most important temperature change does not work:
[22:40:37][D][climate:010]: 'Panasonic AC' - Setting
[22:40:37][D][climate:039]: Target Temperature: 18.50
[22:40:37][V][panasonic_ac.dnskp11:104]: Requested temperature change
[22:40:37][V][panasonic_ac:245]: TX: 5A.2B.10.08.00.09.01.01.30.01.01.00.31.01.25.CF (16)
[22:40:37][V][panasonic_ac:247]: RX: 5A.2B.10.88.00.09.03.01.30.01.01.00.31.01.25.4D (16)
[22:40:37][V][panasonic_ac.dnskp11:456]: Received command ack

It always reverts back to the previous setting - i cant change the temperature.

[DomiStyle]

Is that with or without checksum enabled?

Try setting the temperature via IR remote and take note of the differences in the packages you receive. The temperature should be in there in hexadecimal, just divide it by 2 and you should get the correct temperature.

All info I collected about the protocol is available in this folder so you can compare: https://github.com/DomiStyle/esphome-panasonic-ac/tree/master/protocol

[jonasf21]

Its without checksum. I changed the temp by IR remote to 21.5:
[22:47:03][V][panasonic_ac:247]: RX: 5A.0D.10.0A.00.19.00.01.30.01.05.00.A1.01.44.00.B0.01.41.02.20.01.43.02.31.01.2B.02.33.01.43.19 (32)

So it should be 21.5x2 = 43 but the field after it is 02, in your doc it says 00 (but n/a, so not sure if that matters).

To be precise, the logs also state this:
[22:47:03][V][panasonic_ac.dnskp11:530]: Received unknown nanoex field

so maybe something related to nanoex changed.

[DomiStyle]

Hmm, looks similar but much longer than a usual response to a temperature change.

Depending on how far you want to go you will probably have to get a packet capture with a logic analyzer from the original wifi module or switch to the CNT port once it arrives. Hopefully nothing changed there.

so maybe something related to nanoex changed.

Definitely, they rebranded and moved this feature around like 5 times already.

[jonasf21]

Sorry, i guess it also changed some other settings as i turned the AC on via HA.
I again changed temp (from previous 21.5 set via infrared) to 21 now:
[23:09:40][V][panasonic_ac:247]: RX: 5A.0E.10.0A.00.09.00.01.30.01.01.02.31.01.2A.E4 (16)

[DomiStyle]

Can you try again if setting the temperature works? That report looks identical to mine.

[jonasf21]

Still doesnt work:

[23:19:55][D][climate:039]: Target Temperature: 19.00
[23:19:55][V][panasonic_ac.dnskp11:104]: Requested temperature change
[23:19:55][V][panasonic_ac:245]: TX: 5A.81.10.08.00.09.01.01.30.01.01.00.31.01.26.78 (16)
[23:19:56][V][panasonic_ac:247]: RX: 5A.81.10.88.00.09.03.01.30.01.01.00.31.01.26.F6 (16)
[23:19:56][V][panasonic_ac.dnskp11:456]: Received command ack

What seems to be different is that the string sent via the IR has a different "30" block. The IR one is
30.01.01.02 while the one from esphome is 30.01.01.00 (so with 00 at the end). From your controller protocol doc it appears you expect this to be always 00...so this might be the cause?

[DomiStyle]

You could try poking around in the code, the function that receives commands from Home Assistant is here: https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L62

The temperature gets set here: https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L105

The set_value function fills a queue made from a key and value. 0x31 is the key for target temperature.

This is the function where the final packet is assembled and sent: https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L621

It just loops through the queue and adds all parameters that were set like this:

KEY 0x01 VALUE 0x00

If you just want to replace the 00 at the end with 02 (whatever that means, I have no idea) you can change this line: https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L640

The function is fairly well documented, at least with what I know.

Also, it should be noted that the syntax between the IR commands and the wifi module commands differs (there are 2 files in the protocol documentation), the key and values are identical but the structure of the packet is different and mostly unknown.

[jonasf21]

Thanks, i'll try and see if that helps.

Since the code does not work with checksumming enabled - how is it calculated? I seem to be unable to find info about that.

[DomiStyle]

The package is verified in this function: https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L231

The checksum is calculated here: https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L273

Essentially it just sums together every byte (including the checksum), if the sum is 0 the checksum is valid.

In the command from above: 5A.81.10.08.00.09.01.01.30.01.01.00.31.01.26.78
If you sum all of them together you get 0x0200, since we're working with a single byte the 0x02 overflows and you are left with 0x00, which means the packet above is valid.

Might also be an idea to create a branch that disable checksumming during initialization and enables it after it bruteforced its way through the initialization, that way you can keep checksumming enabled for regular packets.

[jonasf21]

Ahh thanks for the insight on the checksum, got it now.

As from the first post it appears the checksum is totally of.
5A.09.10.81.00.D6.00.01.30.01.00.01.00.01.00.33.00.80.E2.01.00.85.42.04.00.86.62.2E.00.88.62.01.00.A0.E2.01.00.A1.E2.01.00.A4.E2.01.00.A5.E2.01.00.B0.E2.01.00.B2.E2.01.00.BB.42.01.00.BE.42.01.02.20.62.01.02.21.62.01.02.31.E2.01.02.32.62.01.02.33.E2.01.02.34.E2.01.02.35.E2.01.02.36.E2.01.02.42.82.01.02.7D.E2.01.02.7E.42.01.02.7F.42.02.02.80.42.02.02.81.42.02
actually results in 0x1DF9. No wonder it gets dropped and it doesnt pass init. They must have changed something there.

I'll poke around a bit and see if i can get the temp change working somehow (now that i know its probably not the checksum).

[jonasf21]

I changed 00 to 02 from the "30" and i can set temperature now. However this breaks all other settings, i cant turn off/on the AC etc anymore. So this works just for the temperature.

I made a quick and dirty hack for this:
https://github.com/DomiStyle/esphome-panasonic-ac/blob/master/components/panasonic_ac/esppac_wlan.cpp#L649
I added here:
if (packet[12] == 0x31) {
packet[11] = 0x02;
}

So 02 on the "30" header is only set if the command includes a tempature change. I've verified this works, all settings are fine including temperature - so everything works as intended.
Maybe you can see if this does work with your AC too?

Btw, the wrong checksum packet is being sent at handshake 9. All other handshake packet checksums are good, so its just
this one. So wont need to disable checksumming for the whole init, just for this step (if thats easier).

[00:09:39][D][panasonic_ac.dnskp11:579]: Answering handshake [8/16]
[00:09:39][V][panasonic_ac:245]: TX: 5A.08.10.00.00.00.8E (7)
[00:09:39][V][panasonic_ac:247]: RX: 5A.08.10.80.00.05.00.01.01.30.01.D6 (12)
[00:09:39][D][panasonic_ac.dnskp11:583]: Answering handshake [9/16]
[00:09:39][V][panasonic_ac:245]: TX: 5A.09.10.01.00.05.01.30.01.00.01.54 (12)
[00:09:39][V][panasonic_ac:247]: RX: 5A.09.10.81.00.D6.00.01.30.01.00.01.00.01.00.33.00.80.E2.01.00.85.42.04.00.86.62.2E.00.88.62.01.00.A0.E2.01.00.A1.E2.01.00.A4.E2.01.00.A5.E2.01.00.B0.E2.01.00.B2.E2.01.00.BB.42.01.00.BE.42.01.02.20.62.01.02.21.62.01.02.31.E2.01.02.32.62.01.02.33.E2.01.02.34.E2.01.02.35.E2.01.02.36.E2.01.02.42.82.01.02.7D.E2.01.02.7E.42.01.02.7F.42.02.02.80.42.02.02.81.42.02 (120)
[00:09:39][D][panasonic_ac.dnskp11:587]: Answering handshake [10/16]
[00:09:39][V][panasonic_ac:245]: TX: 5A.0A.00.18.00.00.84 (7)

[jonasf21]

Update:
Actually the answer to the checksum problem is in my first post - yay. The packet is not missing the checksum, its just split in half.
The header states the packet is D6 long, so 214 byte - however the code currently only accepts 128 byte messages (BUFFER_SIZE). I changed the buffer size (esppac.h) to 240 byte and increased the READ_TIMEOUT to 240. I then re-enabled checksumming and its working now! (i tested with read_timeout at 40 & 100 but it didnt work, so i went near the max - maybe there is a better spot).

[JshGrn]

I have these and the CNT port works flawlessly alongside the original WiFi module (so you can keep the app running too).

[jonasf21]

@JshGrn i do not want to use the CNT port - its old and outdated (newer units always use CN-WLAN). I also wanted to replace the DNSPK11 module completly (dont want any foreign/external cloud). So i replaced the DNSPK11 and used its connection (CN-WLAN) - and for this there are changes required.

[JshGrn]

I know, but why does that concern you re it being outdated? There is no functionality that it doesnt provide that the CN-WLAN does...

[jonasf21]

I assume the CN-CNT will be removed from future units since its no longer needed (reason: cost). Also as for feature wise comparision: i am not sure this is true. The etherea device have alot more protocol info than previous gen devices and its not fully decoded - so cant be sure if CN-CNT really would pass all that info. Anyway - the main reason people are doing the change is to remove the panasonic cloud and for that you have to open the unit and remove the DNSPK11 module - while there you can just use the connector there anyway (and dont need to go for CN-CNT).

[JshGrn]

Removing CN-CNT... why is this a concern, are you updating your units every month? I am not sure I agree with your thoughts about them removing it, its there for a reason, its very likely they will keep it.

What features do you think are missing? I currently use this with the Etherea range (3 x same model 1 x 2.5kw) and they all work perfectly. All features from the app work with this except position of vents, not sure that the WIFI version has this either as I think its missing from the package.

I see your logic re removing the wifi module, although I don't understand why you would over using the CN-CNT currently, I'd just turn it off. Its still nice to have the app sometimes.

[jonasf21]

No i dont touch the AC any month but i'd like to keep this project/code up2date, so future users will be able to use it (on either connector).
Afaik the power consumption calculation is different between CN-CNT and CN-WLAN. However its unsupported on CN-WLAN as of now (i might start working on that later).
I dont trust any device i dont have full control of - specially if its connected to some type of cloud. As that the DNSPK11 is unusable for me and has to go.
Lets not try to start a discussion here regarding what connector is better or if panasonic's cloud is trustworthy etc. Everyone can decide that themselves. I just want the code fixed, so people can choose what they prefer - i am adding features not cutting them.

[JshGrn]

I respect that!

For me - I use the CNT, the power consumption isn't something I have paid much attention to.

The cloud solution they offer is terrible and I do suffer from constant disconnects throughout the year, maybe I one day will go to the WLAN port if there is reason for me to do so, right now there is not.

[edalberg]

Very good solution that works perfectly on the older pumps.

I have 3 new pumps and is testing now on a Panasonic CZ25WKE. On this I get error messages such as:

[07:24:47][V][json:038]: Attempting to allocate 512 bytes for JSON serialization
[07:24:47][V][json:058]: Size after shrink 232 bytes

@jonasf21 and @DomiStyle: Could this have something to do with "buffersize" and "read_timeout" in esppac.h?

Here is my entire log:

[07:24:41][W][component:214]: Component panasonic_ac.climate took a long time for an operation (0.10 s).
[07:24:41][W][component:215]: Components should block for at most 20-30ms.
[07:24:42][VV][api.connection:120]: Sending keepalive PING...
[07:24:42][VV][api.service:037]: send_ping_request: PingRequest {}
[07:24:42][VV][api.service:549]: on_ping_response: PingResponse {}
[07:24:46][V][panasonic_ac.cz_tacg1:252]: Polling AC
[07:24:46][V][panasonic_ac:245]: TX: 70.0A.00.00.00.00.00.00.00.00.00.00.86 (13)
[07:24:46][V][panasonic_ac:247]: RX: 70.0A.00.00.00.00.00.00.00.00.00.00.86 (13)
[07:24:46][W][panasonic_ac.cz_tacg1:362]: Received unknown fan speed
[07:24:46][W][panasonic_ac.cz_tacg1:476]: Received unknown mild dry value
[07:24:46][D][climate:380]: 'Warmepumpe-Leiligheta' - Sending state:
[07:24:46][D][climate:383]: Mode: OFF
[07:24:47][D][climate:391]: Custom Fan Mode: Unknown
[07:24:47][D][climate:397]: Custom Preset: Normal
[07:24:47][D][climate:400]: Swing Mode: OFF
[07:24:47][D][climate:403]: Current Temperature: -83.00°C
[07:24:47][D][climate:409]: Target Temperature: 0.00°C
[07:24:47][V][json:038]: Attempting to allocate 512 bytes for JSON serialization
[07:24:47][V][json:058]: Size after shrink 232 bytes
[07:24:47][VV][api.service:242]: send_climate_state_response: ClimateStateResponse {
key: 1694556500
mode: CLIMATE_MODE_OFF
current_temperature: -83
target_temperature: 0
target_temperature_low: 0
target_temperature_high: 0
unused_legacy_away: NO
action: CLIMATE_ACTION_OFF
fan_mode: CLIMATE_FAN_ON
swing_mode: CLIMATE_SWING_OFF
custom_fan_mode: 'Unknown'
preset: CLIMATE_PRESET_NONE
custom_preset: 'Normal'
}
PS uses the CN-CNT interface

Any idea?

[JshGrn]

@edalberg I have this working on the same models (1 2.5kw and 2 3.5kw) as you using the CN-CNT interface without any issues, I haven't seen that error.

[edalberg]

@JshGrn Strange! I have 2 more at the cabin, so I will test them out at the weekend.

[edalberg]

Very good solution that works perfectly on the older pumps.

I have 3 new pumps and is testing now on a Panasonic CZ25WKE. On this I get error messages such as:

[07:24:47][V][json:038]: Attempting to allocate 512 bytes for JSON serialization

[07:24:47][V][json:058]: Size after shrink 232 bytes

@jonasf21 and @DomiStyle: Could this have something to do with "buffersize" and "read_timeout" in esppac.h?

Here is my entire log:

[07:24:41][W][component:214]: Component panasonic_ac.climate took a long time for an operation (0.10 s).

[07:24:41][W][component:215]: Components should block for at most 20-30ms.

[07:24:42][VV][api.connection:120]: Sending keepalive PING...

[07:24:42][VV][api.service:037]: send_ping_request: PingRequest {}

[07:24:42][VV][api.service:549]: on_ping_response: PingResponse {}

[07:24:46][V][panasonic_ac.cz_tacg1:252]: Polling AC

[07:24:46][V][panasonic_ac:245]: TX: 70.0A.00.00.00.00.00.00.00.00.00.00.86 (13)

[07:24:46][V][panasonic_ac:247]: RX: 70.0A.00.00.00.00.00.00.00.00.00.00.86 (13)

[07:24:46][W][panasonic_ac.cz_tacg1:362]: Received unknown fan speed

[07:24:46][W][panasonic_ac.cz_tacg1:476]: Received unknown mild dry value

[07:24:46][D][climate:380]: 'Warmepumpe-Leiligheta' - Sending state:

[07:24:46][D][climate:383]: Mode: OFF

[07:24:47][D][climate:391]: Custom Fan Mode: Unknown

[07:24:47][D][climate:397]: Custom Preset: Normal

[07:24:47][D][climate:400]: Swing Mode: OFF

[07:24:47][D][climate:403]: Current Temperature: -83.00°C

[07:24:47][D][climate:409]: Target Temperature: 0.00°C

[07:24:47][V][json:038]: Attempting to allocate 512 bytes for JSON serialization

[07:24:47][V][json:058]: Size after shrink 232 bytes

[07:24:47][VV][api.service:242]: send_climate_state_response: ClimateStateResponse {

key: 1694556500

mode: CLIMATE_MODE_OFF

current_temperature: -83

target_temperature: 0

target_temperature_low: 0

target_temperature_high: 0

unused_legacy_away: NO

action: CLIMATE_ACTION_OFF

fan_mode: CLIMATE_FAN_ON

swing_mode: CLIMATE_SWING_OFF

custom_fan_mode: 'Unknown'

preset: CLIMATE_PRESET_NONE

custom_preset: 'Normal'

}

PS uses the CN-CNT interface

Any idea?

The problem was a bad soldering!