Hi @tristone-cz that looks wired. The CRC errors are normal. I also have this in my NASA system. I just leave them to have a better understanding how often it happens.

Did you tried to turn on message logging as described in readme?

Hi @lanwin I tried now the logging.

Log number 3 is just basic logging, directives debug_log_ to true.
It is even just upload new FW and ESP restart, no power off of the AC.

Log number 4 is a bit interesting. Slightly different behavior, I saw once already. But not regular.
I turned on the UART debug, deploy FW, restart ESP. No power off.
At 14:50:35 there is an understood message with status of the AC. Since that time the error Unsupported alt_mode 0 is present which is a sign of somehow working communication. But still many of the those registration messages.
At this point it is possible to control the AC and once first command is successfully sent the registration messages stop. At time 14:51:05.
But this behavior is random. I saw it only twice. In other cases no communication.

Log number 5 is with the same debug ar log 4. Just AC was powered off and then on which turns on also the ESP.
And no communication established.

logs_ac-rooms_run_3.txt
logs_ac-rooms_run_4.txt
logs_ac-rooms_logs_5.txt

I managed to handle the delay.
I forked the repo and added delay for first registration. And with the delay it works. Even somehow the registration is not needed, the communication starts sooner then the delay expires.

What I failed is to add a config parameter so I did not create pull request yet. So far no idea what I missed 😢

Code comparison:
main...tristone-cz:esphome_samsung_ac:tristone-cz-patch-1

That code does not take the parameter into account in protocol_non_nasa.cpp

The commented out line work with fixed delay of 1 minute.

	//const long delay_interval = (1 *60 * 1000UL);
	const long delay_interval = (non_nasa_registration_delay_interval * 1000UL);