How to receive/view UART serial data from ESP32 serial_proxy in Home Assistant?

[thermiek]

Hi everyone,

I’ve set up an ESP32 with ESPHome using the serial_proxy component along with the required Native API and UART components. Here’s my current YAML config:

 

uart:
  id : uartbus
  rx_buffer_size: 1700  
  rx_pin:
    number: 4  
    inverted: false
    mode:
      input: true
      pullup: false
  baud_rate: 115200 

serial_proxy:
  - id: serial_proxy_1
    uart_id: uartbus
    name: My Serial proxy
    port_type: TTL

I’ve flashed it successfully, and the device shows up in Home Assistant via the ESPHome integration. The ESP32 is connected to another serial device that’s sending data over UART.

My question: How can I actually see or receive the serial data in Home Assistant? I expected some kind of entity or log to show the raw bytes/data stream, but I don’t see anything. Do I need:

• A specific sensor/template to parse the data?
• To use the ESPHome API directly (e.g., via Python script)?
• Some HA integration or automation to read the proxied serial stream?
• Logger settings or debug mode to capture it?

What am I missing? Any example configs or tutorials for displaying/using this serial data in dashboards, automations, etc.?

Thanks for your help!

[Edwin_D]

This is new for the 2026.5 release, so you likely need the currently available 2026.5.0b0 beta release or higher of Home Assistent too. And I suspect you’ll need a HA integration that requires a serial interface.

[thermiek]

@Edwin_D

2026.5 release

2026.5 release installed , but i did not found a solution or answer to my problem yet

[Edwin_D]

The release notes explain how it is supposed to work, you need an HA integration that reads the serial data though the proxy.

[nebulous]

If your goal is to connect a Home Assistant integration that expects a serial port (like the Denon RS232 integration), serial_proxy is the right tool — that's exactly what it's designed for.

If what you're after is direct access to the raw serial data over the network — to inspect it, or connect to it from something other than HA — you might have better luck with esphome-uart-link. It exposes the UART as a plain TCP socket instead of going through the ESPHome native API.

Something like:

external_components:
  - source: github://nebulous/esphome-uart-link

uart:
  id: uartbus
  rx_pin: 4
  baud_rate: 115200

uart_tcp_server:
  id: tcp_port
  port: 5000

uart_bridge:
  uart_a: uartbus
  uart_b: tcp_port

Then you can nc <esp-ip> 5000 from any machine on your network and see the data stream directly. Fair warning: it's a newer external component that I threw together for a separate project, but if you just need to get eyes on the serial traffic, it might be a simpler path than trying to make serial_proxy do something it wasn't really built for.

[bmork (Bjørn Mork)]

@nebulous

If what you're after is direct access to the raw serial data over the network — to inspect it, or connect to it from something other than HA — you might have better luck with esphome-uart-link. It exposes the UART as a plain TCP socket instead of going through the ESPHome native API.

Nice! I just tried this for a PoC router console application. Exactly what I wanted. Perfect match with conserver.

[Hannes1 (Hannes)]

Came here just to say thank you, great feature. This is exactly what I need to reverse engineer a device connected to an ESP32 on UART.

[Mahko_Mahko]

@thermiek

Any example configs or tutorials for displaying/using this serial data

This is often a good way to get started.

[How to] UART read without custom component

The UART Bus component provides a write action but no read actions. Typically the UART read is implemented in a custom component that also does the processing. The UART debug sequence can be exploited to act like a call back function whenever there is received data to process. So basically instead of creating a small custom component a large lambda call can be used in the UART debug yaml. This is shared to hopefully help make implementing UART devices a bit easier for average users. It seems t…

Note message inspection and processing happens on the ESPHome side with this approach, so may not meet requirements.