[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]

https://github.com/atanasenko/esphome_samsung_ac/commit/58b1a59db719b0d53434155c657e7bcd5cfc7a0c 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.