[SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

gregbert · 2024-12-30 20:39:21

Problem - fails to interact with the device via serial port after boot, until the usb device (SLZB-06) is reset

Kernel - 6.6.65-1-lts

Hardware: SLZB-06 zigbee coordinator
Current core firmware version: v2.6.8.dev26
Zigbee coordinator: Revision: 20240710

When I boot, it looks fine:
[ 3.892417] usb 1-4: new full-speed USB device number 2 using xhci_hcd
[ 4.282098] usb 1-4: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[ 4.282102] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.282104] usb 1-4: Product: SMLIGHT SLZB-06
[ 4.282106] usb 1-4: Manufacturer: SMLIGHT
[ 4.282107] usb 1-4: SerialNumber: XYZ
[ 5.810545] usb 1-4: cp210x converter now attached to ttyUSB0

But zigbee2mqtt fails to be able to read it
[2024-12-30 19:53:07] error: z2m: Error: Error: I/O error, cannot open /dev/ttyUSB0

However, if I reset the usb - either physically or using sudo usbrest, it is fine and works until the next reboot

here is my boot log up until target network. https://paste.c-net.org/ReopenedOuter

I hope I have supplied sufficient information. Any ideas why this device would need a reset?

Last edited by gregbert (2025-01-02 00:37:05)

dimich · 2024-12-31 03:14:07

gregbert wrote:

But zigbee2mqtt fails to be able to read it
[2024-12-30 19:53:07] error: z2m: Error: Error: I/O error, cannot open /dev/ttyUSB0

Is this the only error message from the service?

# journalctl -b -u zigbee2mqtt

There are two most likely options:
1. Device node has wrong permissions after boot but correct permissions after reset.
2. zigbee2mqtt starts too early, when device node isn't yet created.

Does device exist in /dev/ after boot? What permissions does it have?

$ ls -l /dev/ttyUSB0

$ udevadm info /dev/ttyUSB0

Do permissions change after device reset?

Does zigbee2mqtt open device successfully if you restart the service instead of device reset?

# systemctl restart zigbee2mqtt

In case (1) we have to figure out why permissions differ.
In case (2) you should start zigbee2mqtt after device added, for example with ENV{SYSTEMD_WANTS} from udev rule (and probably stop it after device removed).

Side note: it is not reliable to refer specific device as /dev/ttyUSB0. If you have other USB-to-UART adapter attached, device names may change and zigbee2mqtt will attempt to open wrong device. Good practice is to create udev rule for specific device by its product string, serial number or other distinctive properties, and/or physical USB port it is attached to. This udev rule should either create a symlink with defined name which zigbee2mqtt will open, or start zigbee2mqtt@ template service with device node as instance name.

gregbert · 2024-12-31 16:57:21

Hi @dimich - thank you very much for your reply.

(1)
zigbee2mqtt is running in a docker container. here are the logs: https://paste.c-net.org/StumbleTaboo
note that I have /dev/ttyUSB0 pointing to the link /dev/serial/by-id/usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0 , which is automatically created by my installation
note that even if re-start the zigbee2mqtt docker container once everything is booted up, it still cannot access the port..
i also tried restarting the docker system (sudo systemctl restart docker), which does not give a different result.
therefore not likely a boot order issue.

(2) permissions

lrwxrwxrwx 1 root root 13 Dec 31 11:42 usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0 -> ../../ttyUSB0
&
crw-rw-rw- 1 root uucp 188, 0 Dec 31 11:42 /dev/ttyUSB0

these permissions are quite inclusive, and unchanged from a sudo usbreset

udevadm before: https://paste.c-net.org/SqueegeeNormally
udevadm after a usbreset and everything is working: https://paste.c-net.org/MarketPinched

any other ideas? I think everything checks out here. also, i was just fine when running with a previous adapter. its only after switching to this SLZB-06, which is supposed to be a far superior adapter, do i have this issue.

ADD: here is a diff between the udevadms's - diff pre-reset post-reset. I am not skilled enough to know what the differences are. but there is clearly a difference.

9,10d8
< S: serial/by-id/usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0
< S: serial/by-path/pci-0000:01:00.0-usb-0:4:1.0-port0
11a10,11
> S: serial/by-path/pci-0000:01:00.0-usb-0:4:1.0-port0
> S: serial/by-id/usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0
17c17
< E: USEC_INITIALIZED=741770508
---
> E: USEC_INITIALIZED=5698227
49c49
< E: DEVLINKS=/dev/serial/by-id/usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0 /dev/serial/by-path/pci-0000:01:00.0-usb-0:4:1.0-port0 /dev/serial/by-path/pci-0000:01:00.0-usbv2-0:4:1.0-port0
---
> E: DEVLINKS=/dev/serial/by-path/pci-0000:01:00.0-usbv2-0:4:1.0-port0 /dev/serial/by-path/pci-0000:01:00.0-usb-0:4:1.0-port0 /dev/serial/by-id/usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0

Last edited by gregbert (2024-12-31 17:03:18)

dimich · 2025-01-01 08:46:37

gregbert wrote:

zigbee2mqtt is running in a docker container.

This looks like a crucial point.

Arch's extra/zigbee2mqtt package doesn't imply docker. Docker image from zigbee2mqtt repository uses Alpine. I don't see how the issue is related to Arch.

gregbert wrote:

here are the logs: https://paste.c-net.org/StumbleTaboo

Hm, unfortunately zigbee2mqtt doesn't print reasonable error message, i.e. 'No such file or directory' or 'Operation not permitted', so not much useful.

gregbert wrote:

note that I have /dev/ttyUSB0 pointing to the link /dev/serial/by-id/usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0

You pass this symlink in --device option to map it to /dev/ttyUSB0 in your docker run, right? What is full docker run command in your case?

gregbert wrote:

note that even if re-start the zigbee2mqtt docker container once everything is booted up, it still cannot access the port..

How do you start container initially? From command line or as a systemd service?

gregbert wrote:

lrwxrwxrwx 1 root root 13 Dec 31 11:42 usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0 -> ../../ttyUSB0
&
crw-rw-rw- 1 root uucp 188, 0 Dec 31 11:42 /dev/ttyUSB0

Those are on your host, right? What permissions for /dev/ttyUSB0 are inside of container?

Can you run a shell in container first, and check /dev/ttyUSB0 accessibility? I.e.

$ docker run --tty --interactive ... koenkk/zigbee2mqtt ls -l /dev/ttyUSB0
$ docker run --tty --interactive ... koenkk/zigbee2mqtt cat /dev/ttyUSB0

You also can pass /bin/sh as container command for further investigation.

gregbert wrote:

udevadm before: https://paste.c-net.org/SqueegeeNormally
udevadm after a usbreset and everything is working: https://paste.c-net.org/MarketPinched

This output is from host, not from container, right?

gregbert wrote:

i was just fine when running with a previous adapter. its only after switching to this SLZB-06, which is supposed to be a far superior adapter, do i have this issue.

It's also possible that this is a particular hardware quirk. As a workaround, you can run usbreset before starting your service.

gregbert wrote:

ADD: here is a diff between the udevadms's - diff pre-reset post-reset. I am not skilled enough to know what the differences are. but there is clearly a difference.

Symlinks order is different. serialport module does some mangling on udevadm info output in linux-list.js. Docker command mounts entire /run/udev volume into container but the only /dev/USB0 device file with no symlinks provided by host's udev. I'm not sure this is relevant since you pass device name explicitly.

I would try with extra/zigbee2mqtt package running natively on Arch, without any containers.

gregbert · 2025-01-01 21:10:26

Many thanks for thinking this through with me.

I run this as a docker-compose.yaml

services:
  zigbee2mqtt:
    container_name: zigbee2mqtt
    image: koenkk/zigbee2mqtt:latest-dev
    volumes:
      - /home/remote_fs_user/conf/zigbee2mqtt:/app/data
    devices:
      - /dev/serial/by-id/usb-SMLIGHT_SMLIGHT_SLZB-06_e8a7a1f91672ef11823343848fcc3fa0-if00-port0:/dev/ttyUSB0
    restart: unless-stopped
    ports:
      - 8880:8080
    environment:
      - PGID=166
      - PUID=1002
      - TZ="America/New_York"

Here are the permissions from within the container

crw-rw-rw-    1 root     987       188,   0 Jan  1 21:00 /dev/ttyUSB0

and

/app # cat /dev/ttyUSB0 (from container)

cat: can't open '/dev/ttyUSB0': I/O error

when i do the same thing from the archlinux host:
cat /dev/ttyUSB0

cat: /dev/ttyUSB0: Input/output error

udevadm was indeed from the host, not the container

NOTE: Once I do the usbreset command, and I do cat /dev/ttyUSB0 - then it just works. It prints the expected gobblygook, but it works

gregbert@Fractal ~ % cat /dev/ttyUSB0


V
FvYvBvBBvBvBvBvFv    B      B
                                                   BÖ
                                                         B

So this makes me think it has nothing to do with the docker container at all. Let me know if you disagree that we've ruled that out and I will go through with the straight install.

dimich · 2025-01-01 21:51:48

gregbert wrote:

when i do the same thing from the archlinux host:
cat /dev/ttyUSB0
cat: /dev/ttyUSB0: Input/output error
So this makes me think it has nothing to do with the docker container at all. Let me know if you disagree that we've ruled that out and I will go through with the straight install.

Yep, now it looks like cp210x issue, not related to docker or zigbee2mqtt at all.

Strange, I have a bunch of devices with cp210x (but not zigbee coordinator) and never seen such error.

Last hope question: do you have Windows installed in parallel?

gregbert · 2025-01-02 00:10:49

I am afraid not! Linux-only machine.

I very much appreciate your troubleshooting help, and not a lazy RTFM response. thank you.

There is one thing I will try, which is to plug it into a different USB port I just thought of that, and will report back if that changes anything

happy 2025

gregbert · 2025-01-02 00:36:11

Bingo. Plugged into a different USB port - one physically attached to the motherboard in the back, rather in the front.

From Bus 001 device 002 --> bus 003 device 002

Now does not require to be reset

Not sure if this is a SOLVE, a work around, or identification of defective hardware.

thanks again

Arch Linux

#1 2024-12-30 20:39:21

[SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

#2 2024-12-31 03:14:07

Re: [SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

#3 2024-12-31 16:57:21

Re: [SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

#4 2025-01-01 08:46:37

Re: [SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

#5 2025-01-01 21:10:26

Re: [SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

#6 2025-01-01 21:51:48

Re: [SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

#7 2025-01-02 00:10:49

Re: [SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

#8 2025-01-02 00:36:11

Re: [SOLVED] Zigbee coordinator requires reset to be accessible - SLZB-06

Board footer