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

[ryans]

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.

[ryans]

See additional threads and details on this:

Missing command like socat on hassio

No ideas yet but i intend to use rfxtrx on Home Assistant via network… any suggestions welcome. I already use rflink and dsmr via network using ser2net on a Pi, works fine. But those already support network in the yaml config out of the box. I now see three approaches to this: run socat on hassio to make HA think its a local device. (this topic) use node-red to connect rfxcom I suppose thats https://flows.nodered.org/node/node-red-contrib-rfxcom and HA must use mqtt to talk to it. (so…

Hass.io remote z-wave module with socat/ser2net?

Long story short, I am moving from the far less reliable Rasberry Pi build to a VM on enterprise grade hardware. The only problem with this is I bought a RaZberry Z-Wave module back when I was running HASS on the Pi. Now, I can get the remote Z-Wave module to work within the VM using socat. However, the “factory” HassIO docker container doesn’t want to connect to the remote Z-Wave. This is because the socat virtual device isn’t in udev (CentOS docker host) and it seems the pre-built docker cont…

Is it possible to get USBIP or socat on HASSOS?

Hey folks I feel like I’m so close to running a high-availability Home Assistant setup with a USB Z-Wave stick but there’s just one problem. I have a Proxmox cluster with HASSOS running on one of the nodes. I also have a Raspberry Pi which has been setup to serve my Z-Wave USB stick over ser2net. So far, so good. My issue is that my HASSOS install seems to be extremely locked down and appliance-like (which is the idea I guess) but that means that I cannot get something like usbip or socat ins…

[123 (Taras)]

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

Serial

[infocus13 (Dimitry Katchalov)]

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.

[123 (Taras)]

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.

[ryans]

@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:

Monoprice 6-Zone Amplifier

Serial Particulate Matter

Elk-M1 Control

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.

[darrylb (Darryl)]

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

[ryans]

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

[beerygaz (Gavin Hill)]

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.

[aceindy]

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

@aceindy

serial:
  port: 'tcp://192.168.1.22:5656'

Just wondering how this related to this topic