Add support for newer Ethera devices

[jonasf21]

This pull adds support for newer Ethera devices.

Major changes required are larger buffer size (and timeout for that) since the packets are now >128 bytes big.
Also on temp change it requires field 4 to be set to 02 instead of 00 of the packet. I implented this with a quite dirty hack and
if there is a better way to do it - please change it.
Also changed INIT_END_TIMEOUT and INIT_FAIL_TIMEOUT due to initialization restarts requiring this (or component will fail before restarted init could complete). Needed this since from time to time it would stop at handshake 13 and just hang there.
With this change it will directly restart initialization if it encounters the handshake 13 and in my tests it always succeeds the init after that.

All of these changes should have no impact on other generations of panasonic ACs besides the temp change field "hack". I dont have access to different panasonic equipment so i cant test this and see if others are fine with the change, too.
Maybe some special config flag for the YAML should be added to implent the 02 field for ethera devices to avoid bricking support for other devices.

[DomiStyle]

Doesn't work as is on older devices, the initialization will just get stuck in an endless loop due to restarting at handshake 13.

[jonasf21]

Ok, i assume on older devices it will just continue after the ignored 13/16 handshake while on ethera it will be stuck there.
Do you have a dump of the RX on your device from handshake 13? Maybe its possible to identify the specific handshake ethera sends and only re-start init on that.
This is what i get when the init fails:
5A.0C.10.88.00.08.00.01.30.01.01.02.42.00.83.5A.09.01.09.00.00.93
or
5A.0C.10.88.00.08.00.01.30.01.01.02.42.00.83.5A.22.01.09.00.00.7A
The string changes, however anything upto the "5A" is consistent.

[00:12:26][D][panasonic_ac.dnskp11:595]: Answering handshake [12/16]
[00:12:26][V][panasonic_ac:245]: TX: 5A.0C.10.08.00.09.01.01.30.01.01.02.42.01.42.BE (16)
[00:12:27][V][panasonic_ac:247]: RX: 5A.0C.10.88.00.08.00.01.30.01.01.02.42.00.83.5A.22.01.09.00.00.7A (22)
[00:12:27][D][panasonic_ac.dnskp11:600]: Ignoring handshake [13/16]
[00:12:41][E][component:113]: Component panasonic_ac.climate was marked as failed.

[20:26:54][D][panasonic_ac.dnskp11:595]: Answering handshake [12/16]
[20:26:54][V][panasonic_ac:245]: TX: 5A.0C.10.08.00.09.01.01.30.01.01.02.42.01.42.BE (16)
[20:26:54][V][panasonic_ac:247]: RX: 5A.0C.10.88.00.08.00.01.30.01.01.02.42.00.83.5A.09.01.09.00.00.93 (22)
[20:26:54][D][panasonic_ac.dnskp11:600]: Ignoring handshake [13/16]
[20:27:09][E][component:113]: Component panasonic_ac.climate was marked as failed.

[jonasf21]

I only found one other dump from the handshake 13. It appears the ethera answer to handshake 13 is alot longer than older gen devices and actually the last consistent field (5A) is not present on older gen. I have added a detection for it now. Can you please
try the code on your AC again?

[DomiStyle]

Still gets stuck, here's the full log: https://gist.github.com/DomiStyle/ba7520e98992b5661e9e6a9c4b662908

[DomiStyle]

For reference, this is what a normal handshake looks like: https://gist.github.com/DomiStyle/38ec59ed4d4707f7cc9ec89ad6389abf

[jonasf21]

Apparently the 5A is also sent by your unit. However it seems its possible to match on the 14 and 15th field, that is 83 and 5A - which seems consistent only on etherea.
Can you try the code again please?
Best would be to get a full decode from the handshake on the etherea but i dont have the time to do it right now.

[willie013]

Is this still a thing for newer Etherea devices? How do I know if my Etherea device is still compatible with this PR?