WTH can remote serial devices not be easily mounted as /dev/tty virtual devices?

Why is it cumbersome to mount remote serial devices as /dev/tty virtual devices, especially for those who aren’t as technical? Adding a native HA feature would allow EASILY using remote serial devices that are not physically connected to the same device that runs HA with any of the existing HA integrations. Basically a feature, exposed through HA UI, to use socat to mount virtual /dev/tty devices, which then ANY integration could access these remote serial devices.

This could be limited to support pseudo-terminal (pty) devices only:

  • the goal was to expose virtual tty devices to HA components that rely on reading/writing to local /dev/tty* for communicating with devices
  • for security reasons (e.g. no ability to start listeners or interact with the local filesystem on a Home Assistant instance)

Example remote serial connections:

  • communicating to RS232 serial devices using the IP2SL remote serial connection protocol (e.g. using IP2SL hardware devices or Virtual IP2SL)
  • communicating to hardware devices exposed via ser2net

Example of what configuration could look like:

remote_tty:
  - dev: marantz-stereo
    remote_address: "tcp:10.10.1.33:4999"
  - dev: pool-controller
    remote_address: "tcp:10.10.1.12:5002"
    pty_options: "waitslave"
  - dev: monoprice
    remote_address: "tcp:10.10.1.12:4999"

The remote_address option is the second address argument passed into socat.

See additional threads and details on this:

What are the shortcomings of the Serial integration compared to your proposal?

It looks like the serial integration relies on having a serial device (whether local or remote) at somewhere like /dev/TTYACM0.

The issue that @ryans raised means it’s not possible to get a remote device linked to a local HASS instance.

3 Likes

The Serial integration’s documentation indicates it works with ser2net and socat.

I have no practical experience with any of the above but, taking a guess, what might be the hurdle here is that (possibly) socat is not included in Home Assistant OS. That’s the version that comes with its own (restricted) hypervisor.

In contrast, Home Assistant Supervisor, Home Assistant Container, and Home Assistant Core, run on a Linux distro which typically includes socat.

EDIT

Confirmed; there’s no socat included with the hypervisor in Home Assistant OS. However it is included in the homeassistant container.

@infocus13 is correct! This is NOT specific to the Serial integration. The goal would be to to allow ALL integrations that rely on directly reading/writing /dev/tty* devices to be able to interact with remote serial devices. Basically, every integration that interacts over RS232/RS485/etc should be able to easily communicate with the device whether it is locally attached OR remotely attached via a common serial-over-IP protocol. socat is one way to achieve this (and probably the simplest to leverage) as it is commonly used for this.

For example, the following core integrations are impossible to use with a remote tty natively from Home Assistant, without installing socat package and hand configuring mounts:



Similarly, there are many custom components that also communicate via serial communication…ALL of these would benefit. This is especially useful for many home audio receivers/amplifiers, which often provide RS232 control, but no network accessible API.

With addition of socat and some minor UI addition (or yaml configuration), ALL integrations would be able to remotely interact with serial devices connected over IP.

1 Like

Did anything come from this? I’m thinking of virtualize going for redundancy after continual NUC failures and this will be a hurdle.

@darrylb I don’t think anyone is working on this yet, but hopefully someone picks this up and runs with it!

2 Likes

I am kinda gobsmacked this is not already available. I have many serial devices that are only accessible over GlobalCache or other ser2net gateways.

Given I’m new to HA I’d love to stick with the simplicity of hassos - I’m guessing right now the next best option is to build my own container stack? I’m worried about the future upgrade burden this puts on the system as I may drift further from the “supported” platform.

I was under the impression that was already working, f.e. with zigbee i can choose to use serial or tcp

Just wondering how this related to this topic :thinking: