[NonNASA] I cannot control device from HA but it's receiving data

[ncapilla]

Hey @lanwin!

First of all, great work. Thank you so much for sharing it with the community!

I found this project and used it to integrate my old Samsung AC into Home Assistant. The AC unit's readings are working correctly, but I cannot set climate control values through HA.

A little bit of background here:

• My AC unit model is Samsung NS100SDXEA; because of the discovered address, I can say it is a NonNASA unit.
• I'm using the M5STACK ATOM Lite + M5STACK ATOM RS-485 Base to connect HA with the AC unit.

This is the AC unit wiring schema. As mentioned in the documentation, I've used the F1, F2, V1, and V2 ports.

Here it is my configuration yaml

esphome:
  name: samsung-ac
  friendly_name: Samsung AC

esp32:
  board: m5stack-atom

# Enable logging
logger:
  level: DEBUG
  logs:
    component: ERROR # Remove the "Your component takes to long to respond warning"

# Enable Home Assistant API
api:
  encryption:
    key: "XXXXXXX"

ota:
  - platform: esphome
    password: "XXXXXXX"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Samsung-Ac Fallback Hotspot"
    password: "XXXXXX"

captive_portal:

# Specify pins used by the board to comunicate with RS485 board - in this case M5STACK
uart:
  tx_pin: GPIO19
  rx_pin: GPIO22
  # For older devices it could also be 2400. But you should start with 9600.
  baud_rate: 9600
  parity: EVEN

## SAMSUNG AC CONFIGURATION

# Import custom component from GitHub
external_components:
  - source: github://lanwin/esphome_samsung_ac@stable
    components: [samsung_ac]

# Configuration of AC component
# Configuration of AC component
samsung_ac:
  # Prints the parsed message data to the log
  debug_log_messages: true
  # Prints the binary message data (HEX encoded) to the log
  debug_log_messages_raw: true

  devices:
    # For NonNASA devices it looks like this (with 2 indoor devices): 
    #   Indoor:  00, 01
    # You need this addresses for the the sections below. If you see only a "-" then you should visit the troubleshooting section in the readme. 

    # Repeat everything below for each indoor device address you see in your logs
    - address: "00" # Indoor device address 
      # Each property below is optional (climate, room_temperature etc.) - you can delete those which you dont need.
      # For the names I suggest to choose a combination of room name and the thing it controls. 
            
      # Creates climate control in Home Assistant. A climate control combines multiple of the controls below (like temperature, mode etc.)
      climate:
        name: "Aire acondicionado"

      # The controls directly below are all included in the climate control. Its adviced to only add the climate control and skip the extra controls.
      #room_temperature:
      #  name: "Temperatura salón"
      #target_temperature:
      #  name: "Temperatura objetivo"
      #power:
      #  name: "Potencia"
      #mode:
      #  name: "Modo"

This is a DEBUG log in which I deploy the config and try to turn on the AC from HA.
logs_samsung-ac_run.txt

What I've tried so far (with no luck):

• Check the wiring -> It's ok
• Change baud_rate from 9600 to 2400 (some older hardware uses a lower baud rate) -> It stops reading data.
• add baud_rate: 0 to the logger section -> Nothing happens

I see no errors in the log, just some Warnings.
[12:41:50][W][samsung_ac:171]: NonNASA: invalid crc - got 9 but should be 141: 32c800f8030934

I'm happy to test anything. Do a fork, create a dev version and deploy it to the atom board and then create a PR to your repository.

I'm seeking guidance on where to start looking, file/function/method. Maybe I just misconfigured something, and you could point me to the error.

[Nanganator]

Sounds like the issue I have in #127. Seems like currently there is no fix.

[lanwin]

Hi @Nanganator, when you can see the correct readings, then the boud_rate and message system works.

We currently have the problem that it seems there are different ways to be able to send the old AC specific messages before it accepts commands.

Can you try enable non_nasa_keepalive and maybe switch to #stable branch und try that?

[Nanganator]

Hey @lanwin, I tried that in #127 but lost the ability to see the AC states in HA and just got the below on repeat endlessly in the logs of the ESP:

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

I didn’t end up following up on #127 yet as I went travelling and have only just recently returned. Getting through my backlog of projects 😂

Don’t want to threadjack though as for all I know what ncapilla is experiencing could be a totally unrelated issue just with the same result. You guys just already commented a bunch of stuff to try so was adding my thread in here as a reference for him 😊

[lanwin]

Can you please try that #66 and check if you are able to control your AC via the non NASA Version of SNET?

And please check if you can control the device from this component right after you controlled it via SNET.

[Nanganator]

Can you please try that #66 and check if you are able to control your AC via the non NASA Version of SNET?

And please check if you can control the device from this component right after you controlled it via SNET.

Sure. Will try give it a shot tonight.

[ncapilla]

Ok, I've changed this in the configuration. main branch and the keepalive

external_components:
  - source: github://lanwin/esphome_samsung_ac@main
    components: [samsung_ac]

# Configuration of AC component
# Configuration of AC component
samsung_ac:
  # For NonNASA devices the following option can be enabled to prevent the device from sleeping when idle. This allows
  # values like internal and external temperature to continue to be tracked when the device isn't in use.
  non_nasa_keepalive: true

There it is the log file.
logs_samsung-ac_run (1).txt

I've tried to turn it off

[15:15:21][D][climate:011]: 'Aire acondicionado' - Setting
[15:15:21][D][climate:015]:   Mode: OFF

I took a look at that SNET-Pro program but unfortunately I only have linux and mac machines at home. I will ask someone a windows machine to try it out.

[ncapilla]

TBH @lanwin, not sure if that's all or I missed something in your conversation with @Nanganator.

Cross conversations makes things really difficult 😓

[ncapilla]

Hey @lanwin

I've tried this #66

I successfully connected to the indoor unit and was able to read the data, but I couldn't control it. Could it be a wiring problem? If I'm reading the data correctly, I suppose the F1/F2 wires are appropriately positioned. One of them may not be connected correctly.

Here are some pictures of the SNET software

[lanwin]

Hu, that is strange. Most of the time when reading worked, writing also works. But maybe you check that again. And non of the buttons does anything?

Can you please also check the "Disable Individal Control" checkbox. But I am not sure that helps.

And If you change the AC via remote, did the values here also change?

[ncapilla]

Hey @lanwin

• I tried to check the "Disable Individual Control" checkbox, same result.
• I did change some values from my AC controller and the information didn't update in the S-NET software until I disconnected and connected again. The info is refreshing on the ESPHome.

Let me recap with all the info 👇🏻

Up-to-date ESPHome logs of the test
S-NET Software recording of the test

This is my current configuration:

esphome:
  name: samsung-ac
  friendly_name: Samsung AC

esp32:
  board: m5stack-atom

# Enable logging
logger:
  level: DEBUG
  logs:
    component: ERROR # Remove the "Your component takes to long to respond warning"

# Enable Home Assistant API
api:
  encryption:
    key: "XXXXXXX"

ota:
  - platform: esphome
    password: "XXXXXXX"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Samsung-Ac Fallback Hotspot"
    password: "XXXXXXX"

captive_portal:

# Specify pins used by the board to comunicate with RS485 board - in this case M5STACK
uart:
  tx_pin: GPIO19
  rx_pin: GPIO22
  # For older devices it could also be 2400. But you should start with 9600.
  baud_rate: 9600
  parity: EVEN

## SAMSUNG AC CONFIGURATION

# Import custom component from GitHub
external_components:
  - source: github://lanwin/esphome_samsung_ac@main
    components: [samsung_ac]
  - source: github://oxan/esphome-stream-server

stream_server:

# Configuration of AC component
# Configuration of AC component
samsung_ac:
  # For NonNASA devices the following option can be enabled to prevent the device from sleeping when idle. This allows
  # values like internal and external temperature to continue to be tracked when the device isn't in use.
  non_nasa_keepalive: true
  # Prints the parsed message data to the log
  debug_log_messages: true
  # Prints the binary message data (HEX encoded) to the log
  debug_log_messages_raw: true

  devices:
    # For NonNASA devices it looks like this (with 2 indoor devices): 
    #   Indoor:  00, 01
    # You need this addresses for the the sections below. If you see only a "-" then you should visit the troubleshooting section in the readme. 

    # Repeat everything below for each indoor device address you see in your logs
    - address: "00" # Indoor device address 
      # Each property below is optional (climate, room_temperature etc.) - you can delete those which you dont need.
      # For the names I suggest to choose a combination of room name and the thing it controls. 
            
      # Creates climate control in Home Assistant. A climate control combines multiple of the controls below (like temperature, mode etc.)
      climate:
        name: "Aire acondicionado"

      # The controls directly below are all included in the climate control. Its adviced to only add the climate control and skip the extra controls.
      #room_temperature:
      #  name: "Temperatura salón"
      #target_temperature:
      #  name: "Temperatura objetivo"
      #power:
      #  name: "Potencia"
      #mode:
      #  name: "Modo"

What I've tried so far (with no luck):

• Check the wiring -> It's ok
• Change baud_rate from 9600 to 2400 (some older hardware uses a lower baud rate) -> It stops reading data.
• add baud_rate: 0 to the logger section -> Nothing happens
• [S-NET PRO] Try to control the indoor unit using S-NET PRO (Non-Nasa) How to: Use esphome as RS485 to Wifi bridge #66 -> I can read the data but I cannot control the unit.
• [S-NET PRO] I tried to check the "Disable Individual Control" checkbox, same result.
• [S-NET PRO] I did change some values from my AC controller and the information didn't update in the S-NET software until I disconnected and connected again. The info is refreshing on the ESPHome.

[ncapilla]

Hi @lanwin,

I've made some additional attempts to troubleshoot the issue, and I'd like to provide an update.

First, I removed the samsung_ac plugin from my configuration and left only the stream_server plugin for testing purposes. This seemed to provide more stability during my tests with the SNET-PRO software.

I tried using the SNET-PRO software from Samsung to control the air conditioning unit. I tested every AC model available in the application, and while I could receive data and see the information update for most models, I was unable to control the unit.

I inspected the wiring and noticed that the wired controller for my AC unit had thinner cables. To rule out any potential interference issues, I decided to replace those cables, but the result remained the same.

During the wiring inspection, I noticed that my home controller is connected to the F3, F4, V1, and V2 ports, so I tried connecting to those ports as well. When attempting to connect with SNET-PRO on those ports, the only change was that I could only read information by selecting a specific model from the list, which I assume is the correct model. However, I still couldn't control the unit.

After that, I tried alternating the connections between F3 and F4, as well as F1 and F2, but that only resulted in everything stopping to work.

I'm honestly out of ideas on what else to try. If I can't manage to control the unit from the SNET-PRO software, I don't think we'll be able to make progress with the plugin either.

I would greatly appreciate any additional suggestions or guidance you might have. Please let me know if you need any further information or logs from my end.

[lanwin]

Wall that is sad. This makes it a lot more difficult. Maybe you could connect to F3,F4 and turn on debug message logging and capture the logs right from the second you changed one value on your home controller.

From what I know is that F3,F4 works the same but the messages could be different. But be aware that F3,F4 uses a different baud rate (as far as I know).

[lanwin]

From what I know. As far as you can read data, there wiring is ok. Otherwise you would get no data.

[ncapilla]

Wall that is sad. This makes it a lot more difficult. Maybe you could connect to F3,F4 and turn on debug message logging and capture the logs right from the second you changed one value on your home controller.

From what I know is that F3,F4 works the same but the messages could be different. But be aware that F3,F4 uses a different baud rate (as far as I know).

I'll try that. I'm open to anything, hehe. I'll let you know the results.

Thanks!!