Free manual USB device name for DSMR integration

Feature Requests
1

Could free serial USB port names be allowed for DSMR integration e.g. under “manual”?

If multiple devices are connected to the USB ports of a Raspberry Pi, the automatically assigned USB port number could change after a reboot.
This causes non working integrations, e.g. DSMR and ebusd devices/integrations are swapped after a reboot, e.g. /dev/ttyUSB0" becomes “/dev/ttyUSB2” and vice versa.
This can be avoided with fixed USB port names. For the “external” integrations running in containers this can easily be fixed by using serial USB port names like “/dev/ebuzzz” allocated by udev rules.
However, the DMSR internal integration does not accept free port names (allocated via udev rules) like “/dev/DSMR”.

Kind regard,
Jo.

2

Search for " usb by serial id"

1 Like
3

Hi,

(For some reason I was not notified about this reply, i will have to check my settings).
On my Rpi 3B+ which runs Debian and hosts my HA container, my eBusd container, my Zigbee2MQTT container and a few others this is the result of
ls -al | grep ttyUSB:

lrwxrwxrwx  1 root root           7 Dec 22 12:55 eBuzzz_1 -> ttyUSB2
lrwxrwxrwx  1 root root           7 Dec 22 12:55 P1_DSMR -> ttyUSB1
crw-rw-rw-  1 root dialout 188,   0 Dec 22 12:55 ttyUSB0
crw-rw-rw-  1 root dialout 188,   1 Dec 22 12:55 ttyUSB1
crw-rw-rw-  1 root dialout 188,   2 Dec 22 12:55 ttyUSB2
lrwxrwxrwx  1 root root           7 Dec 22 12:55 ZBDongle-P_1 -> ttyUSB0

As indicated in my request the devices with the names “eBuzzz_1”, “P1_DSMR”, “ZBDongle-P_1” are consistent in their link with the real connected USB interface.
But the devices “ttyUSB?” link to a random real connected USB interface after every reboot.
E.g. in this example the DSMR is on USB1, but after a reboot it can be USB0 or USB2.
That is the reason why I want to be able to enter “/dev/P1_DSMR” for the serial port in the DSMR integration instead of “/dev/USB?” but this is not accepted as a valuable input.

Jo.

4

I tried also
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A176NIN4-if00-port0
which was not accepted either under the manual entry.

Jo.

5

After a new reboot:

ls -al /dev | grep ttyUSB
lrwxrwxrwx  1 root root           7 Dec 22 12:55 eBuzzz_1 -> ttyUSB1
lrwxrwxrwx  1 root root           7 Dec 22 12:55 P1_DSMR -> ttyUSB2
crw-rw-rw-  1 root dialout 188,   0 Dec 22 12:55 ttyUSB0
crw-rw-rw-  1 root dialout 188,   1 Dec 22 12:55 ttyUSB1
crw-rw-rw-  1 root dialout 188,   2 Dec 22 12:55 ttyUSB2
lrwxrwxrwx  1 root root           7 Dec 22 12:55 ZBDongle-P_1 -> ttyUSB0
6

I have finally identified the root cause of the problem and a solution:
When running Home Assistant in a Docker container on systems like a Raspberry Pi, USB device names (e.g., /dev/ttyUSB0, /dev/ttyUSB1) can change after a reboot, making it difficult to maintain a stable connection for integrations like DSMR. A common solution is to use persistent device identifiers, such as the symlinks found in /dev/serial/by-id/, which remain constant across reboots and uniquely identify your USB devices based on their serial number.

However, Docker does not automatically propagate these symlinks (by-id or created by udev) from the host to the container. To make the symlink in /dev/serial/by-id/ available inside the container, you need to use a bind mount in your Docker Compose configuration. This ensures that the symlink is accessible inside the container, providing a stable reference to your device.

Key Concepts:

  • The devices section in the Docker Compose file is used for hardware device mapping. It ensures that physical devices (such as USB ports) on the host are accessible inside the container.
  • The volumes section is used for symlink mapping. This binds the persistent symlinks, such as those in /dev/serial/by-id/ (or such as those created by udev), from the host to the container, ensuring that the device name remains consistent even if the underlying USB device changes.
version: '3'
services:
  home-assistant:
    image: homeassistant/home-assistant:stable
    devices:
      # Hardware device mapping - actual USB ports
      - /dev/ttyUSB0:/dev/ttyUSB0
      - /dev/ttyUSB1:/dev/ttyUSB1
      - /dev/ttyUSB2:/dev/ttyUSB2
    volumes:
      - /path/to/config:/config
      # Symlink mapping - bind-mount the by-id symlink from the host to the container
      - /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A400e8XB-if00:/dev/ttyUSB-DSMR

Explanation:

  • The devices section maps the physical USB devices (/dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2) from the host to the container, making sure Home Assistant has access to the hardware.
  • The volumes section binds the symlink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A400e8XB-if00 from the host to /dev/ttyUSB-DSMR inside the container. This ensures that Home Assistant can consistently access the device using the stable symlink, even if the actual /dev/ttyUSB* names change after a reboot.

By using this method, Home Assistant will always be able to find your device using the stable symlink /dev/ttyUSB-DSMR, ensuring a persistent connection even if the underlying USB port names change after a reboot.