[Non-NASA] Unable to control AC

[Nanganator]

I have an issues similar to [Non-NASA] Unable to control AC since 7 Feb update #87.

When using Stable, I see the details of all the indoor units perfectly and when using the remote control the updates are seen almost immediately. Only no commands can be sent.

I don't see any cmd:f8 messages in my log, and so there are no write entries when I try change temp etc.
My log from Stable attached.
logs_accontroller_stable.txt
Let me know if changing some logging settings can get a better log output.

If I try main, none of the details of the indoor units comes through any more and I still cannot send commands and the log is just filled with the below on repeat:

[10:11:30][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:30][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:30][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:30][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:30][W][component:204]: Component samsung_ac took a long time for an operation (0.27 s).
[10:11:30][W][component:205]: Components should block for at most 20-30ms.
[10:11:30][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:30][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:30][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:31][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:31][W][component:204]: Component samsung_ac took a long time for an operation (0.28 s).
[10:11:31][W][component:205]: Components should block for at most 20-30ms.
[10:11:31][W][samsung_ac:018]: update
[10:11:31][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:31][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:31][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:31][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[10:11:31][W][component:204]: Component samsung_ac took a long time for an operation (0.27 s).
[10:11:31][W][component:205]: Components should block for at most 20-30ms.

main log for reference:
logs_accontroller_main.txt

[lanwin]

@Nanganator please try main instead, especially in with the non_nasa_keepalive option.

[Nanganator]

No change unfortunately. When using main with the non_nasa_keepalive option set to true I still just get the below on repeat and Home Assistant doesn't show the temp, mode etc. of any of the indoor units.

I had 1 indoor unit running whilst I gathered that log and changed the temp etc.

[17:33:18][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:18][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:18][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:18][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:18][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:18][W][component:204]: Component samsung_ac took a long time for an operation (0.34 s).
[17:33:18][W][component:205]: Components should block for at most 20-30ms.
[17:33:18][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:19][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:19][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:19][W][samsung_ac:080]: write 32d0c8d1d2000000000000001b34
[17:33:19][W][component:204]: Component samsung_ac took a long time for an operation (0.27 s).
[17:33:19][W][component:205]: Components should block for at most 20-30ms.

[Nanganator]

Any ideas @lanwin? Looks like my units simply don't send the cmd:f8 message, so I'm guessing no control messages are ever sent.

The only not answered messages I can see are:
src:c8;dst:f0;cmd:8a
src:c8;dst:ad;cmd:d1

These are sent one after the other and then it loops through again with message and response to and from the 4 indoor units. e.g:
src:c8;dst:00;cmd:c3
src:00;dst:c8;cmd:40
src:c8;dst:01;cmd:80
src:01;dst:c8;cmd:21
src:c8;dst:02;cmd:81
src:02;dst:c8;cmd:21
src:c8;dst:03;cmd:82
src:03;dst:c8;cmd:21

I have nowhere near enough technical knowledge to try anything useful myself! 😂

[lanwin]

@matthias882 did you have time to help here?

[jbekkema]

Stable definitely won't work properly, you can follow the discussion in #102 for how this was resolved. You'll want to use main. Make sure your unit is actually using a fresh build of the main branch: I've noticed ESPHome will cache old repo versions for some time, so you'll want to clear the cache prior to building.

Besides that, looking at the log, it appears it is sending four controller registration requests at a time. This isn't unexpected (as you have four indoor units), and the requests won't clash with each other. But I wonder if it could be causing a clash on the bus: it may be still sending the 3rd or 4th request when the reply to the first request is being sent by the outdoor unit. I don't think anyone has tested with that many indoor units, so it's definitely working fine with 1 indoor unit, and probably working fine with 2, but maybe not 3 or 4.

@Nanganator Try just configuring the yaml with just a single indoor unit, instead of all 4, and see whether it works.

@lanwin This isn't something I considered in my PR and it should be considered a bug. The code should be adjusted to only send registration request messages once each time no matter how many indoor units. The easiest way to do this is to probably just have each indoor device's loop check whether it is the first in the list, and if so it should be the one to send the registration request.

[Nanganator]

Thanks @jbekkema!
I’ve got refresh: 0s under external components already so ideally it should not be using the cache, but I’ll clear the folder anyway just to make sure.

I’ll comment out all but 1 unit as you mentioned and come back with logs/results.

Thanks again for the advice!!

[lanwin]

@jbekkema did you have time to investigate here a little more? @ncapilla #151 and @wifi75 #151 also have the problem that they can not control there devices.

[jbekkema]

@lanwin They have not tried using just a single indoor unit and seeing if it works per my comment above. If it works with just a single unit, then the code needs to be modified as described in the same comment. I'm afraid I only have single indoor unit setups available, so it's not something I can test.

[Nanganator]

Hey guys. I tried it with only 1 indoor unit and got the same behaviour as mentioned above. Tried with both non_nasa_keepalive set and not.

[ncapilla]

Hey @jbekkema

I followed the steps, and I got the same result. I only have one indoor unit and one outdoor unit, so that's the only one configured.

More info in this thread:
#168 (comment)

[jbekkema]

If using a single indoor Non-NASA setup isn't working, then whatever the problem will be something else. I haven't kept up with this project, I'm still using the build from #102 which has been working perfectly in my home and office setups. It's possible something has changed since then.

In regards to SNET Pro not working, I took a look at your YAML file in the linked ticket, and you have both the esphome_samsung_ac and esphome-stream-server components active at the same time. For testing with SNET Pro you should only use the esphome-stream-server component by itself (comment out the esphome_samsung_ac component and associated configuration settings and deploy, reboot the AC unit - likely by power cycling it at your switch box - and then try SNET Pro again). esphome_samsung_ac and SNET Pro will conflict with each other if you don't do this.