Bug [Samsung_HVAC]: commands are not executed

[htht2001]

The problem

that I give orders to several air conditioners at the same time
every time Some air conditioners do not accept the command
(different air conditioners each time)
When a command fails, it creates endless messages of
[21:32:01][W][samsung_ac:902]: Packet 54 failed after 3 attempts.
[21:32:01][W][samsung_ac:902]: Packet 55 failed after 3 attempts.
[21:32:01][W][samsung_ac:902]: Packet 6 failed after 3 attempts.
[21:32:01][W][samsung_ac:902]: Packet 26 failed after 3 attempts.
[21:32:01][W][samsung_ac:902]: Packet 28 failed after 3 attempts.
But apparently he doesn't really send a command again
Because if I give them command separately, The air conditioners do carry out the orders

The situation has significantly improved since the merge of Pull Request #206
Only further improvement to the mechanism is required

It should be noted that when using the fork of atanasenko, The commands work fine
If you need further tests I am so for you

Thank you for your work for the project

ESPHome Version

2024.11.2

Samsung HVAC Component Version

30/11/2024

Home Assistant Version

2024.11.3

AC Type

NASA

Indoor AC Unit Model

Global Mini4Way, 360CST, Fresh Ouct

Outdoor AC Unit Model

unknown

ESP Device Model

WT32-ETH01 + Grove-RS485

Connection Points

F1/F2

ESPHome Logs

logs_1_logs.txt
logs_1_logs (1).txt

Samsung AC Logs

No response

YAML Configuration

## BASIC CONFIGURATION
esphome:
  name: samsung_ac
  friendly_name: Climate

esp32:
  board: 'wt32-eth01'
  framework:
    type: arduino
  
ethernet:
  type: 'LAN8720'
  mdc_pin: 'GPIO23'
  mdio_pin: 'GPIO18'
  clk_mode: 'GPIO0_IN'
  phy_addr: 1
  power_pin: 'GPIO16'
  
web_server:
  port: 80

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

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

ota:
  - platform: esphome

# Specify pins used by the board to comunicate with RS485 board - in this case M5STACK
uart:
  id: uart_bus
  tx_pin: GPIO17   # Use GPIO26 for ATOM Tail485 
  rx_pin: GPIO5   # Use GPIO32 for ATOM Tail485
  # For older devices it could also be 2400. But you should start with 9600.
  baud_rate: 9600
  parity: EVEN

# Example configuration entry
button:
  - platform: factory_reset
    name: Restart with Factory Default Settings

## SAMSUNG AC CONFIGURATION

# Import custom component from GitHub
external_components:
  - source: github://omerfaruk-aran/esphome_samsung_hvac_bus@main # use @main if you want the latest development (possibly unstable?)
    components: [samsung_ac]

# 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
  
  # When enabled (set to true), this option will log the messages associated with undefined codes on the device. This is useful for debugging and identifying any unexpected or unknown codes that the device may receive during operation.
  debug_log_undefined_messages: false
  
  # When enabled (set to true), this option logs messages associated with defined codes on the device. This helps in monitoring the behavior of the device by recording the activity related to known, expected codes.
  debug_log_messages: false

  # Capabilities configure the features that all devices of your AC system have (all parts of this section are optional). 
  # All capabilities are off by default, you need to enable only those your devices have.
  # You can override or configure them also on a per-device basis (look below for that).
  capabilities: 
    vertical_swing: true
    horizontal_swing: true
    # Presets define special AC modes like Windfree, Eco, and so on. 
    # The following modes are available: sleep, quiet, fast, longreach, windfree, eco.
    presets: 
      # Short version - a quick and simple way to enable presets.
      quiet: true
      # Long version - allows customization, including localized names and control over enabling the presets.
      fast:
        name: "Fast cooling"
        enabled: true

  devices:

  - address: "20.01.00" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "L3"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "L3 Error Code"

  - address: "20.01.01" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "R4"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "R4 Error Code"

  - address: "20.01.02" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "L4"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "L4 Error Code"

  - address: "20.01.03" # Indoor device address 
    climate:
      name: "mid 3"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "mid 3 Error Code"

  - address: "20.01.04" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "R1"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "R1 Error Code"

  - address: "20.01.05" # Indoor device address 
    climate:
      name: "mid 4"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "mid 4 Error Code"

  - address: "20.01.06" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "L1"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "L1 Error Code"

  - address: "20.01.07" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "R3"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "R3 Error Code"

  - address: "20.01.08" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "R2"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "R2 Error Code"

  - address: "20.01.09" # Indoor device address 
    capabilities:
      horizontal_swing: true
    climate:
      name: "L2"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "L2 Error Code"

  - address: "20.01.0a" # Indoor device address 
    climate:
      name: "mid 2"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "mid 2 Error Code"

  - address: "20.01.0b" # Indoor device address 
    climate:
      name: "mid 1"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "mid 1 Error Code"

  - address: "20.01.0c" # Indoor device address 
    capabilities:
      horizontal_swing: false
      vertical_swing: false
    climate:
      name: "avir"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "avir Error Code"

  - address: "20.01.0d" # Indoor device address 
    climate:
      name: "1"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "1 Error Code"

  - address: "20.01.0e" # Indoor device address 
    climate:
      name: "bl"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "7bl Error Code"

  - address: "20.01.0f" # Indoor device address 
    climate:
      name: "fl"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "fl Error Code"

  - address: "20.01.10" # Indoor device address 
    climate:
      name: "br"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "8br Error Code"

  - address: "20.01.11" # Indoor device address 
    climate:
      name: "fr"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "16fr Error Code"

  - address: "20.01.12" # Indoor device address 
    climate:
      name: "3"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "3 Error Code"

  - address: "20.01.13" # Indoor device address 
    climate:
      name: "2"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "2 Error Code"

  - address: "20.01.14" # Indoor device address 
    climate:
      name: "4"
      visual:
       min_temperature: 18
       temperature_step: 0.5
    error_code:
      name: "4 Error Code"

  - address: "10.01.00" # Outdoor device address as the following components are dependent on an outdoor unit.
    error_code:
      name: error_code_00

    outdoor_instantaneous_power:
      name: "Outdoor Instantaneous Power 00"

    outdoor_cumulative_energy:
      name: "Outdoor Cumulative Energy 00"

    outdoor_current:
      name: "Outdoor Current 00"

    outdoor_voltage:
      name: "Outdoor Voltage 00"

  - address: "10.01.01" # Outdoor device address as the following components are dependent on an outdoor unit.
    error_code:
      name: error_code_01

    outdoor_instantaneous_power:
      name: "Outdoor Instantaneous Power 01"

    outdoor_cumulative_energy:
      name: "Outdoor Cumulative Energy 01"

    outdoor_current:
      name: "Outdoor Current 01"

    outdoor_voltage:
      name: "Outdoor Voltage 01"

Additional Details

No response

[htht2001]

Hi @omerfaruk-aran,

I figured out the issue with the code in #206 and managed to resolve it. However, I’m hesitant to continue down that path because I believe @atanasenko's approach in #93 is far superior.

The strategy of creating a packet queue, sending each packet only after receiving an acknowledgment (with retries as needed), and transmitting only during quiet periods is far more effective. It’s incomparable—commands never fail, and the air conditioners respond much faster, with minimal need for retries.

Unfortunately, I don’t have programming experience, so I’m unable to help resolve the merge conflicts in #93 or reapply the changes.

I’m awaiting your your answer on how we should proceed from here.

Thank you for your contributions to the project!
😉 We want to see you here with us

[Beormund]

I have the same issue with commands not being ackd. I tried to resolve the merge conflicts in #93, but I think too many commits have been made since this pull request was made

[omerfaruk-aran]

Hi,

Thank you for bringing up the issue and for the references to PR #93. It seems that the code in PR #93 was implemented in a way that bypasses ESPHome and directly uses a custom implementation. While this may work for specific use cases, integrating such code directly into the main project would leave many users unable to benefit, especially those relying on ESPHome’s standard structure and support.

To address this issue, I plan to create a new implementation based on the ideas and requirements outlined in PR #93 but fully integrated into the ESPHome framework. This way, the functionality can be standardized, tested, and made accessible to all users without compromising the project’s compatibility.

Once I have a working solution, I’ll update this issue and open a PR for review. In the meantime, if you have any additional insights or requirements, feel free to share them here.

Thank you for your patience and for contributing to improving the project!

Best regards,
Ömer Faruk ARAN

[Beormund]

@omerfaruk-aran - this sounds great and I am more than happy to test on my heat pump. I have the MIM-H04EN Wifi Receiver connected so am able to see the modbus payloads being sent from anything I can control/read via SmartThings. I am currently using the LILYGO® T-RSS3 ESP32-S3 development board which has dual RS232 and RS485 capability with 5V/12V DC input - perfect for this project.

I couldn't figure out the YAML to switch heating & hot water on/off using codes 4000 & 4065 or other control commands so hence my trying out @brazoayeye's fork but would prefer to use the original repo. If I can configure the correct sensors and switches with the NASA codes my heat pump uses then I can configure a standard ESPHome climate control rather than have to use a custom climate config. But there is no example of how to do this in the example.yaml. Here's what I see in the logs when I use SmartThings:

Heating Zone Off:

[14:13:51][W][samsung_ac:857]: Request #Packet Src:62.00.6e Dst:20.00.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 237}
 > Enum 4000 = 0
[14:13:51][W][samsung_ac:848]: Ack not found for packet number 237
[14:13:51][W][samsung_ac:851]: Ack #Packet Src:20.00.00 Dst:62.00.6e {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 237}
 sent_packets size: 0

Heating Zone On:

[14:14:26][W][samsung_ac:857]: Request #Packet Src:62.00.6e Dst:20.00.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 245}
 > Enum 4000 = 1
[14:14:26][W][samsung_ac:848]: Ack not found for packet number 245
[14:14:26][W][samsung_ac:851]: Ack #Packet Src:20.00.00 Dst:62.00.6e {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 245}
 sent_packets size: 0

DHW On:

[14:18:19][W][samsung_ac:857]: Request #Packet Src:62.00.6e Dst:20.00.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 40}
 > Enum 4065 = 1
[14:18:19][W][samsung_ac:848]: Ack not found for packet number 40
[14:18:19][W][samsung_ac:851]: Ack #Packet Src:20.00.00 Dst:62.00.6e {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 40}
 sent_packets size: 0

DHW Temp Down to 49C:

[14:20:18][W][samsung_ac:857]: Request #Packet Src:62.00.6e Dst:20.00.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 66}
 > Variable 4235 = 490
[14:20:18][W][samsung_ac:848]: Ack not found for packet number 66
[14:20:18][W][samsung_ac:851]: Ack #Packet Src:20.00.00 Dst:62.00.6e {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 66}
 sent_packets size: 0

DHW Temp Up to 50C:

[14:23:10][W][samsung_ac:857]: Request #Packet Src:62.00.6e Dst:20.00.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 103}
 > Variable 4235 = 500
[14:23:11][W][samsung_ac:848]: Ack not found for packet number 103
[14:23:11][W][samsung_ac:851]: Ack #Packet Src:20.00.00 Dst:62.00.6e {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 103}
 sent_packets size: 0

DHW Off:

[14:23:51][W][samsung_ac:857]: Request #Packet Src:62.00.6e Dst:20.00.00 {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 3;PacketNumber: 112}
 > Enum 4065 = 0
[14:23:52][W][samsung_ac:848]: Ack not found for packet number 112
[14:23:52][W][samsung_ac:851]: Ack #Packet Src:20.00.00 Dst:62.00.6e {PacketInformation: 1;ProtocolVersion: 2;RetryCount: 0;PacketType: 1;DataType: 6;PacketNumber: 112}
 sent_packets size: 0

Cheers

[omerfaruk-aran]

🚧 Community Feedback Requested on PR #242 🚧

Dear community members,

Thank you for your continued support and contributions to this project. In response to Issue #229, PR #242 has been created to address the retry mechanism concerns.

We would greatly appreciate your help in testing the proposed changes in PR #242. Here's how you can assist:

1. Test the Changes

   • Pull the branch associated with PR Bug [Samsung_HVAC]: Does not compile with ESPHome 2024.12.x And esp-idf framework #242.
   • Update your system and test the retry mechanism under real-world conditions.

2. What to Look For

   • Verify if retry attempts are functioning as expected.
   • Check if packets are being handled and removed correctly after reaching the retry limit.
   • Ensure system stability during retries.

3. Share Your Results

   • Provide feedback on your testing experience.
   • Include any relevant logs, observations, or issues encountered.

Your feedback will play a crucial role in determining if the changes in PR #242 can be safely merged into the main branch. Thank you for your valuable contributions! 🙌

[htht2001]

Hi @omerfaruk-aran
The TTL-RS485 adapters
don’t last more than a month for me.
I don’t have an oscilloscope to check what’s happening on the RS-485 line that causes my converters to fail.

The converters that worked for me until they broke:
Atomic RS485 Base-m5stack
Grove RS485-Seeed Studio
And a simple converter from AliExpress

These two didn’t work straight out of the box:
Multibus Converter-waveshare
Isolated RS485 Unit-m5stack

Now I’m waiting for more simple converters to arrive from AliExpress,
so I can test the new changes.

If anyone knows of a good, durable converter, I’d love to hear about it.

Thank you for all the effort and help!

[omerfaruk-aran]

Hello, it is not normal for it to break down once a month. I have been using the ATOMIC RS485 in the link for more than 1 year and I have never had any problems.

Atomic RS485

[htht2001]

The first one I had was ATOMIC RS485, and after a month it broke.

[omerfaruk-aran]

Hello, the frequent failure of your RS-485 adapters is quite unusual. The issue might not be with the RS-485 adapters themselves but possibly with the M5Stack ATOM Lite ESP32 device you are using. If there is a hardware issue with the M5Stack device, it could cause the connected RS-485 adapters to fail over time.

To verify this, I recommend the following steps:

1. Try another ESP32 device: Replace the M5Stack ATOM Lite with a different ESP32 module or board to see if the issue persists. This can help identify if the M5Stack device is the root cause.
2. Test the RS-485 adapter independently: Connect the RS-485 adapter to another device (such as a computer or a different UART converter) and test it separately. This will help determine whether the problem lies in the adapter or the M5Stack.
3. Inspect the M5Stack device: Check the M5Stack device for any issues, such as a short circuit or voltage irregularities on the 5V power line or UART pins.

After performing these tests, we can better identify the root cause and look for a more specific solution. I hope these suggestions are helpful!

[htht2001]

Thank you for your help!

I forgot to mention that when my RS-485 to TTL converters malfunctioned, they didn’t completely stop working. They were still able to read data from the air conditioners but could no longer send data.

However, in a lab environment, when I connected a USB-to-RS-485 converter to the TTL-to-RS-485 converter, I found that it could both send and receive data without any issues.

I also tried using the WT32-ETH01, but the same problem persisted.

When I connected the converters to a computer using a TTL-to-USB converter and used S-NET, I was again only able to read data, not send it.

[htht2001]

Do you know where the problem could be?