[REQUEST] Add a port of the new "Serial Proxy" component from ESPHome

[Hedda]

Low-priority idea and perhaps slightly out-of-scope but maybe someday still consider porting and adding the new "Serial Proxy" component from ESPHome to the Linux-Voice-Assistant project to allow it to be used as a HA proxy-server for serial devices over a persistent WebSocket connection (to pipe serial communication over TCP/IP to Home Assistant's integrations from serial devices connected to a remote system running LVA)?

• https://esphome.io/components/serial_proxy/

The new serial_proxy in ESPHome is a new experimental component that proxies UART communication to Home Assistant API clients (i.e. Home Assistant's integrations and apps/addons) over the network (#13944). This experimental component enables remote access to serial devices connected to ESPHome nodes, similar to how the zwave_proxy component bridges Z-Wave modems. Configure a UART bus and expose it as a named serial port with a specified type (TTL, RS232, RS485) in a standardized way that is exposed to Home Assistant integrations or apps/addons.

• https://esphome.io/changelog/2026.3.0/#serial-proxy-experimental

It is a custom TCP connection based on Protocol Buffers (a.k.a. Protobuf, Google's data interchange format for serializing structured data) and from an end-user point-of-view it works kind similar to the Ser2net Linux-deamon serial communication (and serial communication over socat multipurpose relay) but uses ESPHome's native API communication layer so plug-and-play for Home Assistant users, and under the hood ESPHome's serial_proxy component features more advanced processes for Protobuf encoding and Protobuf devirtualization, plus the fact that it has been optimized for performance.

• https://github.com/protocolbuffers/protobuf

Use case is to allow proxying of serial data frames between Serial/UART devices (example product using modbus) via ESPHome’s API over Wi-Fi or Ethernet, for connecting remote to an Home Assistant integration or app/addon. This allows for more flexibility when placing your serial hardware within your home. I think this would be added value to the feature-set if could utilize a Linux-Voice-Assistant installation deployment as a proxy for serial devices too.

• https://www.home-assistant.io/integrations/serial/

Home Assistant's core also migrated to a new "serialx" Python library for synchronous and asynchronous serial communication:

• https://puddly.github.io/serialx/
  • https://github.com/puddly/serialx
    • https://pypi.org/project/serialx/

Again another customized implementation is ESPHome's Z-Wave Proxy component which is available to test to as a "portable Z-Wave experiment" for connecting the ZWA-2 adapter (serial Z-Wave controller) remotley to the Z-Wave JS server addon and seen many oprimization since announced:

• https://www.home-assistant.io/blog/2025/10/13/portable-z-wave-with-wifi-and-poe

PS: Off-topic but FYI for reference, ESPHome also have somewhat related "Bluetooth Proxy" feature for proxying BLE devices (meaning that only supports proxying Bluetooth Low Energy devices such as exampel common Bluetotth temperature sensors like BTHome or BLE Trackers) which broadcast its data then it receieves and automatically aggregates then exposes to Home Assistant's Bluetooth integration:

• https://esphome.io/components/bluetooth_proxy/

[florian-asche]

Cant ser2net be used for that?

[Hedda]

Cant ser2net be used for that?

In theory and on paper yes, however not in practice, at least not for the use cases with very tight integration with Home Assistant as I described above (especially not for sensitive serial devices or Z-Wave Controller and Zigbee Coordinator adapters that have internal USB-to-Serial bridges), as Ser2net is not simply optimized enough. But more importantly I think that adding Ser2net to this project would make it standalone solution and not a user-friendly plug-and-play experience has native support integrated in Home Assistant because it coherently uses the ESPHome native API protocol for most things, with cohesion being a pritority.

Please remember that this Linux-Voice-Assistant uses the ESPHome native API (via the aioesphomeapi Python Client for ESPHome native API) and the original concept from synesthesiam for this Linux-Voice-Assistant project was to no longer having to reinvent the wheel and not to have different solutions that risk failing to keep pace with its ESPHome counterpart. Read:

• https://www.reddit.com/r/homeassistant/comments/1na1chk/new_wyoming_satellite_successor/

and

• Replace Wyoming satellite with Linux Voice Assistant backlog-issues#45

Linux-Voice-Assistant already uses the ESPHome integration in Home Assistant so I do not think it makes as much sence to use other solutions which do not integrate in Home Assistant via the ESPHome protocol. Instead I think it will be best to first try using what the ESPHome protocol already support and if you later want to add features or functions it does not support then it would probably be better so see if could try extend the ESPHome protocol both here and in upstream to make it a unified protocol for both projects.

• https://esphome.io/components/api/

Another benefit with this route means will follow Security Best Practices set for ESPHome to help protect devices and networks:

• https://esphome.io/guides/security_best_practices/

IMHO standartizing to make anything that communicate with Home Assistant's integration to use ESPHome's native API sounds like a smarter and more sustainable path forward, especially if this is to remain an official Open Home Foundation project which has values that stand for both choice AND sustainability as key fundamental principles (other than privacy which is so obvious it really should not need to be mentuioned), then it should have the goal of aligning with the ecosystem that today is built to center around Home Assistant and Music Assistant with a focus on standard and coherent solutions for all platforms.

• https://www.openhomefoundation.org/about/

Regardless, as an OHF project I hope this will align with OHF principles, guidelines and practices.

PS: Speaking of the Open Home Foundation, should this project perhaps be mentioned on their website even if it is experimental?

• https://www.openhomefoundation.org/projects/

[Hedda]

@florian-asche off-topic but FYI, regarding the concept of first try using the ESPHome native API protocol is also relative to a new feature in the upcoming Home Assistant 2026.4 (currently in Beta) which will add "infrared support" in Home Assistant via ESPHome:

• https://www.home-assistant.io/blog/2026/04/01/release-20264/#infrared-becoming-a-first-class-citizen-of-home-assistant

That "Infrared Proxy" feature depends new IR/RF Proxy component in ESPHome on the uses a similar concept to the above described "Serial Proxy" and the popular Bluetooth proxies (via the Bluetooth Proxy component in ESPHome), (so imaging replacing https://home-assistant.io/integrations/infrared/ with https://www.home-assistant.io/integrations/serial/ ).

Meaning that someday users might want Linux-Voice-Assistant satellites to also support "Serial Proxy", "Infrared Proxy", "RF Proxy", "Bluetooth Proxy" because they will have several of them placed around their homes and therefore those multi-purposes ideas makes perfect sence if these too are using the ESPHome native API.

[Hedda]

And all their work for this is part of Open Home Foundation roadmap to make serial proxying a first-class citizen of Home Assistant:

• Have framework for proxying serial connection capabilities established OpenHomeFoundation/roadmap#77

• Improve proxying serial connection capabilities OpenHomeFoundation/roadmap#23

Quote:

If read that then you should understand that there is longterm vision from OHF to make serial proxying become "a first-class citizen".

Goals

Improve serial connection capabilities by having a framework to build with.

This opportunity is important for Home Assistant’s future because:

• It enables a more streamlined way for proxying integrations that rely on serial communication
• It aligns with OHF / Home Assistant’s focus to foster standards and connectivity solutions
• It further broadens the ecosystem

Vision

Serial proxying should become a first class citizen and should feel approachable by integrators to use and build upon in a consistent manner

Scope & Boundaries

In Scope

• Defining a serial (proxy) protocol
• Providing framework for building proxying integrations to build stable serial communication around it

Out of Scope

• Individual Home Assistant integrations
• Instead focus on providing a serial proxying framework

These boundaries are intentionally defined to avoid scope creep while ensuring long-term extensibility.

Further things to consider

One thing to note here is that the RCP protocol used between the Radio and OpenThread is not suited for proxying over network since it is very timing sensitive.

A lot is being done with it, especially with SMLite products. For quite some people it seems to work quite reliable, at least over Ethernet but we need to consider a more holistic architectural view.

Furthermore, recently a new serial protocol which implements the NCP architecture got implemented that moves more OpenThread logic into the radio microcontroller, especially the time sensitive ones. This should be better suited for proxying over network.

Plan

The work will be broken down into high-level epics:

Epic 1: Establish serial proxy protocol

• Define protocol
• Use ESPHome as basis

Epic 2: Introduce integration framework for HA integrations

• Define framework to build (proxying) integrations in HA
• Define discovery and what / how to expose upon connection serial proxying device

Epic 3: Have a Home Assistant Integration

• Have a reference HA integration
• Further scoping tbd

Epic 4: Investigate on a portable ZBT-2 version

• Ideally, re-use approach taken for the portable ZWA-2 (https://www.home-assistant.io/blog/2025/10/13/portable-z-wave-with-wifi-and-poe/)
• Enable proxying a ZBT-2 for indirect connections to HA

Epic 5: Expansion & Iteration

• Incrementally expand supported integrations
• Incorporate community feedback and real-world usage

Prioritization will focus on delivering a usable, end-to-end experience early, then expanding coverage over time.

Related Feature Requests

This opportunity addresses long-standing community interest in improving connectivity through proxying serial communication.

[Hedda]

For reference, the upcoming Home Assistant 2026.5 release (currently in Beta stage) contains have some huge related improvements:

• https://www.home-assistant.io/blog/2026/05/06/release-20265/#serial-ports-over-the-network-with-esphome

Notes cover enhancements that is truley a great beginning for making serial proxying become a first-class citizen of Home Assistant:

Serial ports over the network with ESPHome

We have a bit of a theme going on. Last release, infrared proxying became a first-class citizen of Home Assistant. This release, radio frequency proxying joined the party. And now, there’s another way you can put an ESPHome device somewhere in your home and let Home Assistant talk to things through it: serial ports.

If you’ve ever set up a Bluetooth proxy, the idea will feel familiar. Plenty of smart home gear talks over a serial connection, like energy meters with a P1 port, or that classic Denon receiver with the new Denon RS232 integration shipping in this release. Until now, the device producing those serial signals had to be physically plugged into the same machine running Home Assistant, or wired up over a long, unwieldy cable. Not anymore.

With the new serial proxy support in ESPHome, any serial port plugged into (or built into) an ESPHome device can now be exposed over your network and used by Home Assistant as if it were sitting right next to it. Drop an ESP somewhere convenient, plug your serial device into it, and Home Assistant takes care of the rest.

Screenshot of the new serial port selector in the UI, showing local USB serial ports and remote ESPHome serial proxies side by side.

Where this comes in handy

This is great news if you’ve ever struggled to put a serial-connected device exactly where you wanted it. A few practical examples:

Connect to receivers, projectors, or other AV gear over RS-232 from anywhere on your network.
Read your smart meter’s P1 port from the meter cabinet, even if your Home Assistant server lives upstairs in a closet.
Like our existing Bluetooth, infrared, and radio frequency proxies, this is also a sustainability win. Instead of replacing perfectly good serial-only equipment with newer Wi-Fi versions, you can keep using what you already have. That energy meter, that older AV receiver, that industrial sensor: they all just work, over the network.

Under the hood

Behind the scenes, this release rewires Home Assistant’s serial-port handling top to bottom to make serial proxies a natural part of the system. Some highlights for the curious:

• All of Home Assistant has been migrated to a modern, async-first serial driver called serialx, replacing the older pyserial library that Home Assistant has used for years. It’s designed for the way Home Assistant works today and adds support for new connection types, including ESPHome serial proxies, transparently.

• Integrations that need a serial port now get a brand new, polished serial port selector in the UI. It lists local USB serial ports and remote ESPHome serial proxies side by side, with friendly names. The list even updates live, so a USB device you plug in while the dropdown is open shows up right away.

• Common integrations that talk over serial pick up serial proxies for free. The brand new Denon RS232 integration uses it from day one, and the existing Russound RIO integration has been migrated to serialx as well, so it can now talk to your multi-room audio gear over an ESPHome serial proxy too.

If you’re an integration developer (or maintain a custom component) talking over serial, head over to the migrating from pyserial to serialx developer blog post to read all about how to take advantage of this.

A first step, not the finish line

Let’s be upfront about one thing: getting a serial proxy up and running today is not a one-tap experience yet. To use this in your home, you’ll need to build your own ESPHome device with the serial_proxy component configured for the UART your serial device is wired to. That means writing an ESPHome YAML configuration, flashing the firmware, and connecting the hardware. It’s very doable, but it is on the technical side.

We think that’s okay, because this release is the foundational milestone that makes everything else possible. The plumbing is now in place across Home Assistant, ESPHome, and the integrations that need it. From here, we (and the broader community) can build on top of this with friendlier setup flows, ready-made hardware, and pre-built ESPHome configurations. Just like Bluetooth and infrared proxies before it, the experience will get more approachable release after release.

This work is part of an Open Home Foundation roadmap opportunity to make serial proxying a first-class citizen of Home Assistant. Another roadmap milestone, checked off the list.

[Hedda]

FYI, Paulus (founder of the Open Home Foundation and Home Assistant) did IMHO a great job in the latest Home Assistant release party video at explaining and domo:ing how "Serial Proxies" will play a huge part in OHA goal to include all devices in your home:

• https://www.youtube.com/live/g9F3mn2SYGg?t=920s

Highly recommend that you all watch and listen to his pitch about serial proxying starting from 15 minutes and 20 seconds in video.

Frenck also took the opertunity to post this joke-image showing how older and older devices will be added to Home Assistant! 😜