UART Bus¶

Configuration variables:¶

• baud_rate (Required, int): The baud rate of the UART bus.

• tx_pin (Optional, Pin): The pin to send data to from the ESP’s perspective. Use the full pin schema and set inverted: true to invert logic levels. Not supported by host platform.

• rx_pin (Optional, Pin): The pin to receive data on from the ESP’s perspective. Use the full pin schema and set inverted: true to invert logic levels. Not supported by host platform.

• port (Optional, string): Host platform only. Unix style name of the port to use.

• rx_buffer_size (Optional, int): The size of the buffer used for receiving UART messages. Increase if you use an integration that needs to read big payloads from UART. Defaults to 256.

• data_bits (Optional, int): The number of data bits used on the UART bus. Options: 5 to 8. Defaults to 8.

• parity (Optional): The parity used on the UART bus. Options: NONE, EVEN, ODD. Defaults to NONE.

• stop_bits (Optional, int): The number of stop bits to send. Options: 1, 2. Defaults to 1.

• id (Optional, ID): Manually specify the ID for this UART hub if you need multiple UART hubs.

• debug (Optional, mapping): Options for debugging communication on the UART hub, see Debugging.

Hardware UARTs¶

Whenever possible, ESPHome will use the hardware UART unit on the ESP8266 for fast and accurate communication. When the hardware UARTs are all occupied, ESPHome will fall back to a software implementation that may not be accurate at higher baud rates.

UART0 is (by default) used by the logger component, using tx_pin: GPIO1 and rx_pin: GPIO3. If you configure a UART that overlaps with these pins, you can share the hardware with the logger and leave others available. If you have configured the logger to use a different hardware UART, the pins used for hardware sharing change accordingly.

The ESP32 has three UARTs. ESP32 lite variant chips (ESP32-S3, ESP32-C3, ESP32-S2, etc) may have fewer UARTs (usually two). Any pair of GPIO pins can be used, as long as they support the proper output/input modes.

The ESP8266 has two UARTs; the second of which is TX-only. Only a limited set of pins can be used. UART0 may use either tx_pin: GPIO1 and rx_pin: GPIO3, or tx_pin: GPIO15 and rx_pin: GPIO13. UART1 must use tx_pin: GPIO2. Any other combination of pins will result in use of a software UART.

uart.write Action¶

This Action sends a defined UART signal to the given UART bus.

on_...:
  - uart.write: 'Hello World'

  # For escape characters, you must use double quotes!
  - uart.write: "Hello World\r\n"

  # Raw data
  - uart.write: [0x00, 0x20, 0x42]

  # Templated, return type is std::vector<uint8_t>
  - uart.write: !lambda
      return {0x00, 0x20, 0x42};

  # in case you need to specify the uart id
  - uart.write:
      id: my_second_uart
      data: 'other data'

Debugging¶

If you need insight in the communication that is being sent and/or received over a UART bus, then you can make use of the debugging feature.

# Example configuration entry
uart:
  baud_rate: 115200
  debug:
    direction: BOTH
    dummy_receiver: false
    after:
      delimiter: "\n"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

# Minimal configuration example, logs hex strings by default
uart:
  baud_rate: 9600
  debug:

• direction (Optional, enum): The direction of communication to debug, one of: “RX” (receive, incoming), “TX” (send, outgoing) or “BOTH”. Defaults to “BOTH”.

• dummy_receiver (Optional, boolean): Whether or not to enable the dummy receiver feature. The debugger will only accumulate bytes that are actually read or sent by a UART device component. This feature is useful when you want to debug all incoming communication, while no UART device component is configured for the UART bus (yet). This is especially useful for developers. Normally you’d want to leave this option disabled. Defaults to false.

• after (Optional, mapping): The debugger accumulates bytes of communication. This option defines when to trigger publishing the accumulated bytes. The possible options are:

  • bytes (Optional, int): Trigger after accumulating the specified number of bytes. Defaults to 150.

  • timeout (Optional, Time): Trigger after no communication has been seen during the specified timeout, while one or more bytes have been accumulated. Defaults to 100ms.

  • delimiter (Optional, string or list of bytes): Trigger after the specified sequence of bytes is detected in the communication.

• sequence (Optional, Action): Action(s) to perform for publishing debugging data. Defaults to an action that logs the bytes in hex format. The actions can make use of the following variables:

  • direction: uart::UART_DIRECTION_RX or uart::UART_DIRECTION_TX

  • bytes: std::vector<uint8_t> containing the accumulated bytes

Helper functions for logging

Helper functions are provided to make logging of debug data in various formats easy:

• UARTDebug::log_hex(direction, bytes, char separator) Log the bytes as hex values, separated by the provided separator character.

• UARTDebug::log_string(direction, bytes) Log the bytes as string values, escaping unprintable characters.

• UARTDebug::log_int(direction, bytes, char separator) Log the bytes as integer values, separated by the provided separator character.

• UARTDebug::log_binary(direction, bytes, char separator) Log the bytes as <binary> (<hex>) values, separated by the provided separator character.

Logger buffer size

Beware that the logger component uses a limited buffer size of 512 bytes by default. If the UART debugger log lines become too long, then you will notice that they end up truncated in the log output.

In that case, either make sure that the debugger outputs less data per log line (e.g. by setting the after.bytes option to a lower value) or increase the logger buffer size using the logger tx_buffer_size option.

Changing at runtime¶

There are scenarios where you might need to adjust UART parameters during runtime to enhance communication efficiency and adapt to varying operational conditions. ESPHome facilitates this through lambda calls. Below are the methods to read current settings and modify them dynamically:

• Reading Current Settings: Access UART’s current configuration using these read-only attributes:

  // RX buffer size
  id(my_uart).get_rx_buffer_size();
  // Stop bits
  id(my_uart).get_stop_bits();
  // Data bits
  id(my_uart).get_data_bits();
  // Parity
  id(my_uart).get_parity();
  // Baud rate
  id(my_uart).get_baud_rate();
  

• Modifying Settings at Runtime: You can change certain UART parameters during runtime. After setting new values, invoke load_settings() (ESP only) to apply these changes:

  select:
    - id: change_baud_rate
      name: Baud rate
      platform: template
      options:
        - "2400"
        - "9600"
        - "38400"
        - "57600"
        - "115200"
        - "256000"
        - "512000"
        - "921600"
      initial_option: "115200"
      optimistic: true
      restore_value: True
      internal: false
      entity_category: config
      icon: mdi:swap-horizontal
      set_action:
        - lambda: |-
            id(my_uart).flush();
            uint32_t new_baud_rate = stoi(x);
            ESP_LOGD("change_baud_rate", "Changing baud rate from %i to %i",id(my_uart).get_baud_rate(), new_baud_rate);
            if (id(my_uart).get_baud_rate() != new_baud_rate) {
              id(my_uart).set_baud_rate(new_baud_rate);
              id(my_uart).load_settings();
            }
  

  Available methods for runtime changes:

  // Set TX/RX pins
  id(my_uart).set_tx_pin(InternalGPIOPin *tx_pin);
  id(my_uart).set_rx_pin(InternalGPIOPin *rx_pin);
  // RX buffer size
  id(my_uart).set_rx_buffer_size(size_t rx_buffer_size);
  // Stop bits
  id(my_uart).set_stop_bits(uint8_t stop_bits);
  // Data bits
  id(my_uart).set_data_bits(uint8_t data_bits);
  // Parity
  id(my_uart).set_parity(UARTParityOptions parity);
  // Baud rate
  id(my_uart).set_baud_rate(uint32_t baud_rate);
  

This flexibility allows for dynamic adaptation to different communication requirements, enhancing the versatility of your ESPHome setup.

UART component with the host platform¶

Since the host platform does not have physical UART pins, the UART component is implemented using Unix-style ports. Instead of using pins, you can specify the port name to use. This implementation also supports components that have require_tx and require_rx options such as smt100 etc.

# Example configuration entry for host platform
uart:
  baud_rate: 9600
  port: "/dev/ttyUSB0"

See Also¶

• Logger Component

• API Reference

• Edit this page on GitHub