Problems using deCONZ without " --dev=/dev/ttyACM0"

deCONZ Setup Support
1

Hello!

I am using deCONZ inside a LXC privileged container in Proxmox.
I thought I have all the relevant devices inside my container, but it seems deCONZ is not finding the correct device.

This is what I have inside the LXC-container:

lrwxrwxrwx 1 root root 13 28. Mär 14:53 /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2191213-if00 -> ../../ttyACM0

crw-rw-rw- 1 root dialout 166, 0 28. Mär 19:23 /dev/ttyACM0

These are the files inside the host:

lrwxrwxrwx 1 root root 13 Mar 28 14:53 /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2191213-if00 -> ../../ttyACM0

crw-rw-rw- 1 root dialout 166, 0 Mar 28 19:36  /dev/ttyACM0

The file /lib/systemd/system/deconz.service is this:

[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service
StartLimitIntervalSec=0

[Service]
User=1000
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyACM0
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target

The user with the id 1000 is member of the group dialout so he should have rights to access /dev/ttyACM0.

This is working without a problem, until I am running an update of deCONZ like today to 2.26.3.
deCONZ is always deleting the part:

 --dev=/dev/ttyACM0

After that the website looks like this:

Bildschirmfoto 2024-03-28 um 19.28.15

After adding the parameter for the specific device the website looks like this:

Bildschirmfoto 2024-03-28 um 19.30.08

Regardless of adding the dev-parameter to the systemctl-script, gcflasher is always seeing this:

$ GCFFlasher_internal -l
Path              | Serial      | Type
------------------+-------------+---------------
/dev/ttyACM0      | DE2191213   | ConBee_II

So how is deCONZ determining the correct port to speak with ConBee II? Is there any other file that has to be existing to let deCONZ work without this parameter?

Or is it possible that deCONZ is not overwriting the systemctl-script each time an update is taking place?

Is there a solution for this problem?

2

I had the same problem on my RPi4 with both a Z-Wave & Conbee.
You can supply a custom systemd setting that will survive updates:

$ sudo mkdir /etc/systemd/system/deconz.service.d
$ sudo nano /etc/systemd/system/deconz.service.d/custom.conf
$ cat /etc/systemd/system/deconz.service.d/custom.conf
[Service]
ExecStart=
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyACM0
$ sudo /bin/systemctl daemon-reload
$ sudo systemctl restart deconz

This is the standard systemd way of providing default overrides.

3

If I understand you correctly, the [service] part will then executed from the custom.conf file and not from the still existing deconz.service file a folder above. The parts [unit] and [install] will still be used from the deconz.service file a folder above?

4

My understanding is that the existing ‘standard, part of the debian package’ service file is executed first, then it checks deconz.service.d and finds a file there (not overwritten by dpkg) and executes its content.
First ‘ExecStart=’ will delete the previous one, and the next one will take effect instead.

You can check with:

$ sudo systemctl status deconz
● deconz.service - deCONZ: ZigBee gateway -- REST API
     Loaded: loaded (/lib/systemd/system/deconz.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/deconz.service.d
             └─custom.conf
     Active: active (running) since Sat 2024-03-09 15:34:56 CET; 2 weeks 6 days ago
   Main PID: 413 (deCONZ)
      Tasks: 6 (limit: 4470)
        CPU: 6h 14min 22.827s
     CGroup: /system.slice/deconz.service
             └─413 /usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0

They call the file a Drop-In

5

Thank you very much for the explanation!
One step further in knowing Linux better.

The only question ist why deCONZ didn‘t find the correct USB Port on it‘s own.
I had it running on a Pi 4 with Debian 11 before. And there I had the same problem after one system update because the folder serial/by-id wasn‘t there any more. But before it was working fine without the extra parameter.
So there has to be another thing that is missing to let deCONZ choose the correct port.
Strangely the GCFFlasher is finding the correct port.

6

Could be a number of reasons.
One I came across was a system update that broke the USB ‘by-path’ feature of the underlying OS that Deconz relied on. Guess they can’t handle all weird things the host system throws at them?

7

I also have this in my LXC-Container:

lrwxrwxrwx 1 root root 13 28. Mär 14:53 /dev/serial/by-path/pci-0000:00:14.0-usb-0:8:1.0 -> ../../ttyACM0

But it didn’t help.