[NASA] Commands not being executed

[asekijima]

Hey @lanwin, just checking if you've seen this before I start to investigate any further.
Sometimes I have to give the command twice so it gets executed.
Like: if AC is off and I want to turn it ti cool mode. I select cool mode, AC beeps but nothing happens, I have to open drawer again and select cool, then magic happens.
It's primarily for mode changes, like turning it on and off.
It's not annoying at all if I am in the room, but it's not good because we have to give the commands twice sometimes, to make sure haha

Either way, it's a great work you did, thanks a lot for that!

[lanwin]

Hi @asekijima can you tell us first if you have a newer NASA based device or a older NonNASA device? You can see it based on the device addresses. 00 are NonNASA 20.00.00 are NASA based devices.

[asekijima]

I’m so sorry, man!
It’s a NASA device. It’s a Windfree Mini split single indoor unit from Brazil.

[lanwin]

Ok then stay tuned. Currently this can happen when the message is sent while other data is incoming. The code currently did not check if a command is executed correctly. But I started to explore how to do that.

[mbo18]

Same here. I've updated my ESP today and now sometimes when changing FAN mode it does not change on my AC

[lanwin]

@mbo18 can you test the fanmode? I think I fixed it a few hours ago.

[atanasenko]

@lanwin I'm also seeing messages sent by esp being ignored by the unit. Did you get a chance to have a look at it? Or maybe have any pointers to share?

[lanwin]

The problem here is that I did not yet found the right timing to send the messages. It happens that "send" runs when its start receiving.

But NASA requests are getting a response message when the command is execrated successfully. So its possible to automatically compensate and resent the when no response is received.

I made some initially tests for that and startet to rewrite the code for that. But its not ready yet.

[mbo18]

@mbo18 can you test the fanmode? I think I fixed it a few hours ago.

Seems ok now

[atanasenko]

@lanwin
I'm also experiencing this problem. While it's not critical for manual manipulation, it could be a problem for automations that just expect the command to go through.

I spent some time the last couple days "looking at the matrix" of data flowing back and forth trying to figure out why commands sometimes fail. I did rewrite a good chunk of the transport code in the process and I think I mostly fixed that.
It's a combination of sending during quiet time, waiting for acks, retrying if needed and also recovering packets that would otherwise be lost (sometimes packets, including acks, come along with invalid stream of data and are discarded).

I will play around with it over the weekend and will submit a pr.

[lanwin]

My plan there was to put all requests in e outgoing log with there timestamp and a retrycount of 3. Then when an Ack happens remove then and then when all packets are processed check if there is something in the list where the timestamp is 2-3 seconds ago. Decrease the retrycount and resend the command.

[atanasenko]

atanasenko@58b1a59
Can you have a look at this? I'm doing that there plus a couple other tweaks, I can later split it into smaller commits.
I went with the timeout approach, not a retry count. But I'm thinking to add at least one retry even if beyond timeout.
I haven't had any issues since I'm running this locally, but I have no way of testing if it broke anything for non-nasa (it most probably did).

[lanwin]

There is nothing yet. I made tests that you can see in the main branch where the Ack message handled. The rest was for now only a plan.

The retrycount is a port of the messsages and the protocol. So it would be good to leverage that to prevent endless loops in case something went wrong.

[matthias882]

For a better overview in the bus traffic i would suggest to extend the debug message log. it would be very helpful to write the time (ms) since the last received message behind the message. So you can see the gaps in the bus-communication and see some regularities

[atanasenko]

@matthias882 @lanwin
I'm actually doing exactly that in my playground here: https://github.com/atanasenko/esphome_samsung_ac/tree/transport
You can also enable VERBOSE log and see traffic that's not handled.

logger:
  level: VERBOSE
  logs:
    component: ERROR
    climate: ERROR
    sensor: ERROR
    switch: ERROR
    json: DEBUG

[leukipp]

@atanasenko
I have a hard time using this integration in Automation's, since some commands (packages) may randomly get lost and ignored. Any news on that draft (#93) ?

[alexanderniebuhr]

I just installed this solution for my 3 indoor, 1 outdoor setup (located in Germany). I'm observing the same behavior, and while I know it doesn't really help to just say this, I would like to offer some debugging capabilities, if needed. I can also help with coding, if someone guides me :)

[atanasenko]

@leukipp not much besides the fact that I'm using that locally without any issues so far. I will need to at least rebase it on top of latest main though, and there are a few changes in protocol code, though mostly relating to non-nasa.

[lanwin]

@atanasenko could you please have a look at the current non nasa protocol impl. @jbekkema added resending support there without exposing it to the "outside". The approach should also work for nasa. I think it should be possible to extract his approach to util class with then can be used by booth protocols. The only problem would be to generalize/adapt the message classes.

[atanasenko]

@lanwin Nasa has acks which makes it much easier.
But another issue I've fixed locally is actually missed acks due to bogus incoming data. I'll try to split these into two.

[vniehues]

@atanasenko which branch of your fork should i use for testing?
I got my AC installed today, handed the installer my little M5STACK and told him what goes where.
Everything is working nicely but the skipped commands really make it awkward to do automations right now :/

Edit: I have a NASA windfree device and would be able to provide feedback / debug logs

[serialx]

Any update on this issue? I'm willing to help in testing NASA devices.

[lanwin]

@serialx not yet. Only to be sure. You mean the problem that command sometimes did not execute on the first try or did you mean every time?

[serialx]

I mean when command sometimes does not execute on the first try. @atanasenko branch seems to be stale, so if theres any updates to the code, I'm willing to test it. If you need it ofc. :)

[htht2001]

Is it not possible according to the confirmation Ack
Check if the package has been received
And if not send it again?

After a long test
Always if it doesn't appear in my diary
Ack message
The command was not received

A log illustrating Ack
The package sent at 22:11:27 was not received

INFO ESPHome 2024.9.2
INFO Reading configuration /config/esphome/samsung-vrf.yaml...
WARNING 'samsung_ac': Using the '_' (underscore) character in the hostname is discouraged as it can cause problems with some DHCP and local name services. For more information, see https://esphome.io/guides/faq.html#why-shouldn-t-i-use-underscores-in-my-device-name
INFO Starting log output from 192.168.85.190 using esphome API
INFO Successfully connected to samsung_ac @ 192.168.85.190 in 0.095s
INFO Successful handshake with samsung_ac @ 192.168.85.190 in 0.076s
[22:11:09][I][app:100]: ESPHome version 2024.9.2 compiled on Oct  7 2024, 21:40:49
[22:11:15][W][samsung_ac:468]: publish packet #Packet Src:80.ff.00 Dst:20.01.0b {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 31}
 > Variable 4201 = 200
[22:11:15][W][samsung_ac:086]: write 32001280ff0020010bc0131f01420100c8fefa34
[22:11:15][W][samsung_ac:816]: found 31
[22:11:15][W][samsung_ac:822]: Ack #Packet Src:20.01.0b Dst:80.ff.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 31}
 s 13
[22:11:21][W][samsung_ac:468]: publish packet #Packet Src:80.ff.00 Dst:20.01.0b {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 32}
 > Variable 4201 = 210
[22:11:21][W][samsung_ac:086]: write 32001280ff0020010bc0132001420100d2a70e34
[22:11:21][W][samsung_ac:816]: found 32
[22:11:21][W][samsung_ac:822]: Ack #Packet Src:20.01.0b Dst:80.ff.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 32}
 s 13
[22:11:27][W][samsung_ac:468]: publish packet #Packet Src:80.ff.00 Dst:20.01.0b {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 33}
 > Variable 4201 = 200
[22:11:27][W][samsung_ac:086]: write 32001280ff0020010bc0132101420100c851d534
[22:40:46][W][samsung_ac:468]: publish packet #Packet Src:80.ff.00 Dst:20.01.0b {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 34}
 > Variable 4201 = 200
[22:40:46][W][samsung_ac:086]: write 32001280ff0020010bc0132201420100c89f3534
[22:40:46][W][samsung_ac:816]: found 34
[22:40:46][W][samsung_ac:822]: Ack #Packet Src:20.01.0b Dst:80.ff.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 34}
 s 14

[lanwin]

Yes that is the plan. Its just a matter of not enough time.

[omerfaruk-aran]

Hi @htht2001,

Thank you for raising this issue and your detailed investigation!

The new commit implements a confirmation check using the acknowledgment (Ack) messages. Now, the system verifies if the sent packet received an Ack, and if not, it attempts to resend the packet. This approach ensures more reliable communication and minimizes potential data loss.

After thorough testing and multiple commits aimed at enhancing stability and clarity in the code, I believe this solution addresses the concern you mentioned.

If you encounter further issues or have additional suggestions, please let me know!

Best,
Ömer Faruk Aran

[htht2001]

@omerfaruk-aran
Thank you for your valuable contributing to a project.

At the moment, I am unable to test if it works because my TTL to RS-485 adapter stopped functioning (#197). When it was working, I had to use this branch: #93, which resolved both the issue of commands not being executed and the ability to send commands to multiple devices simultaneously (#176).

If you've implemented these fixes, as soon as I receive my new adapter, as soon as I get the new adapter I go straight back to the to the main branch.

Have a wonderful day!

[mbo18]

I have loaded the last code to my 3 ESP and the issue is still there : I need to do 2 times the same action for the AC to take it into account. Like if AC are off, I need to click on heat 2 times for the AC to be on. Same to change temperature. It is like the first time it wake the AC from sleep

[omerfaruk-aran]

@omerfaruk-aran

Thank you for your valuable contributing to a project.

At the moment, I am unable to test if it works because my TTL to RS-485 adapter stopped functioning (#197). When it was working, I had to use this branch: #93, which resolved both the issue of commands not being executed and the ability to send commands to multiple devices simultaneously (#176).

If you've implemented these fixes, as soon as I receive my new adapter, as soon as I get the new adapter I go straight back to the to the main branch.

Have a wonderful day!

Hello @htht2001,

Thank you so much for your valuable contributions and feedback!

The PR has not been merged into the main branch yet, but your insights and comments are really appreciated. Once you get your new adapter and have a chance to test, I look forward to hearing your experience with the updated branch.

Wishing you a great day!

Ömer Faruk Aran

[omerfaruk-aran]

I have loaded the last code to my 3 ESP and the issue is still there : I need to do 2 times the same action for the AC to take it into account. Like if AC are off, I need to click on heat 2 times for the AC to be on. Same to change temperature. It is like the first time it wake the AC from sleep

Hello @mbo18,

Thank you for taking the time to test the latest code and sharing your findings. The PR addressing this issue hasn't been merged into the main branch yet, so there could be some pending improvements. Please follow PR #194 for updates. Once it is merged into the main branch, it would be great if you could test it again and provide your feedback.

I appreciate your patience and support in refining the project!

Best regards,
Ömer Faruk Aran