UART RS485 communication issue

Hello,
I did setup a communication between an ESP32 and a chlorinator. The goal is to read the pH and ORP value out of it and send as sensors to home assitant.
What is weird is that everything works fine when I log the ESP32 wirelessly. ESP32 send the request frame properly, and the chlorinator answer immediately with the desired values.
Then, when I close the log window, the communication stops. Both sending and receiving.
I did add to the code helpers to check if the ESP32 is still alive and it is.

Did somebody have an idea what’s going on?

This is my code:

esphome:
  name: zozo
  platform: ESP32
  board: esp32doit-devkit-v1
  on_boot:
    then:
      - lambda: 'esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);'

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

api:

logger:
  baud_rate: 0  # Disable logging over UART to avoid conflicts
  level: DEBUG
  hardware_uart: UART2

ota:

uart:
  baud_rate: 9600
  tx_pin: GPIO17
  rx_pin: GPIO16
  id: uart_bus
  debug:
    direction: RX
    dummy_receiver: true
    after:
      delimiter: [0x10, 0x03]  # End of message marker
    sequence:
      - lambda: |-
          UARTDebug::log_hex(direction, bytes, ':');
          std::string str(bytes.begin(), bytes.end());
          if (str.size() == 15 && str[0] == 0x10 && str[1] == 0x02 && str[str.size() - 2] == 0x10 && str[str.size() - 1] == 0x03) {
            float ph = float(str[10]) / 10.0;
            float orp = float(str[11]) * 10.0;
            float ph_setpoint = float(str[8]) /10.0;
            float orp_setpoint = float(str[9]) *10.0;
            id(ph_value).publish_state(ph);
            id(orp_value).publish_state(orp);
            id(ph_setpoint_value).publish_state(ph_setpoint);
            id(orp_setpoint_value).publish_state(orp_setpoint);
            // Mise à jour du text_sensor avec l'heure actuelle
            id(esp32_last_received).publish_state("ESP32 received valid response at " + id(sntp_time).now().strftime("%H:%M:%S"));
          }

# Définition de la broche GPIO pour MAX485 RE/DE
switch:
  - platform: gpio
    pin: GPIO5
    id: re_de
    restore_mode: ALWAYS_OFF

button:
  - platform: template
    name: "Send UART Command"
    id: send_uart_command
    on_press:
      - switch.turn_on: re_de
      - delay: 10ms
      - uart.write:
          id: uart_bus
          data: [0x10, 0x02, 0xb0, 0x11, 0x64, 0x37, 0x10, 0x03]
      - delay: 5ms
      - switch.turn_off: re_de


time:
  - platform: sntp
    id: sntp_time

interval:
  - interval: 10s
    then:
      - switch.turn_on: re_de
      - delay: 10ms
      - uart.write:
          id: uart_bus
          data: [0x10, 0x02, 0xb0, 0x11, 0x64, 0x37, 0x10, 0x03]
      - delay: 5ms
      - switch.turn_off: re_de
      - lambda: !lambda |-
          id(esp32_last_sent).publish_state("ESP32 sent request at " + id(sntp_time).now().strftime("%H:%M:%S"));


text_sensor:
  - platform: template
    name: "Last received"
    id: esp32_last_received
  - platform: template
    name: "Last sent"
    id: esp32_last_sent 


sensor:
  - platform: template
    name: "pH Value"
    id: ph_value
    unit_of_measurement: "pH"
    accuracy_decimals: 1

  - platform: template
    name: "ORP Value"
    id: orp_value
    unit_of_measurement: "mV"
    accuracy_decimals: 0

  - platform: template
    name: "pH Set Point"
    id: ph_setpoint_value
    unit_of_measurement: "pH"
    accuracy_decimals: 1

  - platform: template
    name: "ORP Set Point"
    id: orp_setpoint_value
    unit_of_measurement: "mV"
    accuracy_decimals: 0


Hello everyone,

I wanted to follow up on my earlier post.
I’ve discovered the underlying issue and a solution that might help others experiencing similar problems.

It turns out that the logging was inadvertently affecting the timing of the ESP32. When logging was active, it slowed down the ESP32 just enough to allow the transmission process to complete correctly. Once I closed the log window, the ESP32 would run without this slight delay to close the RS485 transmission with GPIO5, causing the transmissions to not be completed.
It’s a matter of ms. (increase to 7ms instead of 5ms the delay).

Next time, I will buy a more expensive RS485 to TTL adapter with automatic flow control.

2 Likes