I can select ttyS0, ttyS1, ttyS2 and ttyS3 in the configuration but if i try to specify it the way it is listed in the machine hardware “/dev/bus/usb/002/004” I get this error:
“Kunne ikke lagre tilleggskonfigurasjonen, Device ‘/dev/bus/usb/002/004’ does not exist in Z-Wave JS (core_zwave_js). Got {‘device’: ‘/dev/bus/usb/002/004’, ‘log_level’: ‘info’, ‘log_to_file’: False, ‘log_max_files’: 7, ‘soft_reset’: ‘Automatic’,…”
If i run lsusb i can see that the zwave stick is recognized on the host, here is the result:
---
name@debian-ha:/$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 002 Device 003: ID 0b05:190e ASUSTek Computer, Inc. ASUS USB-BT500
Bus 002 Device 002: ID 413c:2106 Dell Computer Corp. QuietKey Keyboard
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
---
In HA under hardware the device is listed with this information:
Those are more like “system” files that provide information about the physical device and its location within the system, so you can’t use those for read/write operations to the serial port.
In your case for the Silicon Labs CP210x, the system should be assigning it to something like /dev/ttyUSBn (n is a number 0,1,etc). The system should also create a linked file with a name something like: /dev/serial/by-id/usbSilicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_blah-blah-if00-port0.
The “best practice” is to use the /dev/serial/by-id/xxx file in your configuration.
I seems like Debian does not link my zwave stick to any /dev/ttyUSBn or similar. I attached a screenshot, is there any of those devices that could be my zwave stick?
I doubt it is any of those, but one thing to check is to unplug the ZStick and then plug it back in, and then do sudo dmesg | less and go to the bottom of the file (hit G), and see what the events are.
[ 128.066544] hassio: port 7(vethed595e7) entered forwarding state
[ 129.808918] perf: interrupt took too long (2504 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
[ 152.242804] perf: interrupt took too long (3132 > 3130), lowering kernel.perf_event_max_sample_rate to 63750
[ 177.794111] perf: interrupt took too long (3956 > 3915), lowering kernel.perf_event_max_sample_rate to 50500
[ 250.383483] perf: interrupt took too long (4946 > 4945), lowering kernel.perf_event_max_sample_rate to 40250
[ 320.723701] hassio: port 8(veth3b4794f) entered blocking state
[ 320.723727] hassio: port 8(veth3b4794f) entered disabled state
[ 320.725039] device veth3b4794f entered promiscuous mode
[ 322.961123] eth0: renamed from vethfa22635
[ 322.981645] IPv6: ADDRCONF(NETDEV_CHANGE): veth3b4794f: link becomes ready
[ 322.981845] hassio: port 8(veth3b4794f) entered blocking state
[ 322.981865] hassio: port 8(veth3b4794f) entered forwarding state
[ 337.946686] hassio: port 9(veth5d833b4) entered blocking state
[ 337.946709] hassio: port 9(veth5d833b4) entered disabled state
[ 337.951514] device veth5d833b4 entered promiscuous mode
[ 341.141250] eth0: renamed from veth8fd15c8
[ 341.166726] IPv6: ADDRCONF(NETDEV_CHANGE): veth5d833b4: link becomes ready
[ 341.166930] hassio: port 9(veth5d833b4) entered blocking state
[ 341.166951] hassio: port 9(veth5d833b4) entered forwarding state
[ 356.388303] perf: interrupt took too long (6198 > 6182), lowering kernel.perf_event_max_sample_rate to 32250
[ 1378.740918] perf: interrupt took too long (7766 > 7747), lowering kernel.perf_event_max_sample_rate to 25750
[ 1963.158343] systemd-journald[235]: Data hash table of /var/log/journal/ba773a88de384616a11faca0605d2f05/system.journal has a fill level at 75.0 (174763 of 233016 items, 58720256 file size, 335 bytes per hash table item), suggesting rotation.
[ 1963.158376] systemd-journald[235]: /var/log/journal/ba773a88de384616a11faca0605d2f05/system.journal: Journal header limits reached or header out-of-date, rotating.
[ 3353.628126] ath5k: ath5k_hw_get_isr: ISR: 0x00040001 IMR: 0x00000000
When runnning “sudo dmesg | grep Silicon” I get this:
I suspect you didn’t unplug and replug the Z-Stick otherwise there should be some usb events at the end, but anyway what I am looking for is something like: usb 1-1.5: cp210x converter now attached to ttyUSB0
[118833.921549] usb 2-6: USB disconnect, device number 4
[118856.183819] usb 2-6: new full-speed USB device number 5 using ohci-pci
[118856.427968] usb 2-6: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[118856.427987] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[118856.427994] usb 2-6: Product: CP2102N USB to UART Bridge Controller
[118856.428000] usb 2-6: Manufacturer: Silicon Labs
[118856.428005] usb 2-6: SerialNumber: c299ac086725ed11be4d68c2f9a97352
[118856.432234] cp210x 2-6:1.0: cp210x converter detected
[118856.445088] usb 2-6: cp210x converter now attached to ttyUSB0
[118858.128985] usb 2-6: usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1
[118858.132920] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[118858.148082] cp210x 2-6:1.0: device disconnected
Seems like it is connected to ttyUSB0 for a while and then disconnected somehow but it is still plugged in.
Doing a little research, it looks like there is a daemon called brltty that sees the stick getting plugged in and grabs it for its own purposes. Here is some info on brltty.
Here is a thread I found on this problem that seems to have a solution (assuming you don’t need brltty).
