Error resource temporarily unavailable cannot lock port

• SerialPort Version: 6.0.4

• NodeJS Version: v4.8.2

• Operating System and Hardware Platform: Linux raspberrypi 4.9.59-v7+ Add a bunch of since 5x items #1047

• Have you checked the right version of the api docs?: yes

• Are you having trouble installing and you checked the Installation Special Cases docs?no

• Are you using Electron and have you checked the Electron Docs?:no

Summary of Problem

Hello, I need some help with serialport here. I am building RC CAR for my personal project I am doing testing and got an issue here. When I do «run» function it will write the data but the second time I run it will display this message «Error Resource temporarily unavailable Cannot lock port» and port.isOpen is always says false which is right, but if I use port.close connection everything works correctly, anyway to keep the port open and keep waiting for commands and send them?

Steps and Code to Reproduce the Issue

process.stdin.resume();
process.stdin.setEncoding('utf8');

process.stdin.on('data', function (text) {
  if(text.trim() === 'run'){
        console.log('running commmand');
        sendMessage();
  }
});

function sendMessage(){
        var SerialPort = require('serialport');
        var port = new SerialPort('/dev/ttyS0', {baudRate: 9600 });
        if(!port.isOpen){
                port.on('open', function () {
                        console.log('port opened');
                        port.write('runningn', function(err){
                                if(err){
                                        console.log(err);
                                }else{
                                        console.log('Message sent successfully');
                                }
                                console.log(port.isOpen);
                                // port.close(function () {
                                //      console.log('port Closed.');
                                // });
                        });
                });
        }
}

Most of the time this is caused by Zigbee2MQTT not being able to communicate with your Zigbee adapter.

Error: SRSP - SYS - ping after 6000ms

4 common reasons of this error:

1. The port of your serial adapter changed. Check this to find out the port of your adapter.
2. If you are using a CC2530 or CC2531; it is a common issue for this adapter to crash (due to its outdated hardware). Reflashing the firmware should fix the problem. If it happens often consider flashing the source routing firmwareopen in new window or upgrade to a more powerful adapter.
3. Your adapter requires additional configuration parameters. Check supported Adapters section to find out if your adapter requires extra parameters (eg. ConBee II / RaspBee II).
4. Home Assistant’s «Zigbee Home Automation» (ZHA) integration is enabled. Try to disable the ZHA integration and restart the Zigbee2MQTT add-on.

Verify that you put the correct port in configuration.yaml

Execute the following command to find out the correct path:

pi@raspberry:/ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx. 1 root root 13 Oct 19 19:26 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0018ED3DDF-if00 -> ../../ttyACM0

In this example the correct port would be /dev/ttyACM0.

Which port should I use for Texas Instruments LAUNCHXL-CC26X2R1/CC1352P-2, /dev/ttyACM0 or /dev/ttyACM1?

The Texas Instruments launchpad has a build in debugger. This debugger also registers a port next to the device data port. Of course this is not necessarily number 0 and 1. But normally the lowest number is the device data port and the other the debugger.

To find the correct port, execute:

pi@raspberry:/ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jan  6 19:07 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L1100BTD-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan  6 19:07 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L1100BTD-if03 -> ../../ttyACM1

The device with id ending with if00 is for device data. Use this port in your configuration.

Verify that the user you run Zigbee2MQTT as has write access to the port

This can be tested by executing: test -w [PORT] && echo success || echo failure ( e.g. test -w /dev/ttyACM0 && echo success || echo failure).

If it outputs failure it could mean your user does not have access to the port. To test assign write access by executing: sudo chown [USER] [PORT] (e.g. sudo chown pi /dev/ttyACM0).

if it outputs failure, then you need to permanently give your user permission to the device.

Method 1: Give your user permissions on every reboot.

You can create a ‘udev’ rule to give your user permissions after every reboot:

1. udevadm info -a -n /dev/ttyACM0 | grep 'serial' get the serial to your device YOURSERIAL

2. Create the rule file with: sudo nano /etc/udev/rules.d/99-usb-serial.rules

3. add this line: SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", ATTRS{serial}=="YOURSERIAL", SYMLINK="ttyUSB.CC2531-01", OWNER="pi"

4. modify your Zigbee2MQTT config to adjust new SYMLINK name: nano /opt/zigbee2mqtt/data/configuration.yaml

… serial: port: /dev/ttyUSB.CC2531-01 …

After reboot your device will have the right permissions and always the same name.

Method 2: Add your user to specific groups

As mentioned on https://github.com/esp8266/source-code-examples/issues/26 , depending on your linux installation, various groups could have ownership of the device.

Add your user to the uucp , tty , dialout groups:

sudo usermod -a -G uucp $USER
sudo usermod -a -G tty $USER
sudo usermod -a -G dialout $USER

Reboot your device and now your user should have access to the device.

Error: Coordinator failed to start, probably the panID is already in use, try a different panID or channel

• If you still get this error after increasing the panID (as explained here) and you are using a Raspberry Pi with other USB devices
• In case you are getting this after first starting successfully and pairing a device it might be that the firmware has been flashed incorrectly. Try flashing the stick on a different computer (detailed infoopen in new window). This issue mainly occurs in combination with a Slaesh’s CC2652RB stick.

Error: Resource temporarily unavailable Cannot lock port

This error occurs when another program is already using (and thus locking) the adapter. You can find out which via the following command: ls -l /proc/[0-9]/fd/ |grep /dev/ttyACM0 (replace /dev/ttyACM0 with your adapter port).

Raspberry Pi users: use a good power supply

A bad power supply can make your system and its USB devices unstable. Make sure to use a good power supply.

In case you see message like below when running dmesg -w you are using a bad power supply.

[44870.355590] Under-voltage detected! (0x00050005)
[44874.515618] Voltage normalised (0x00000000)
[44880.755718] Under-voltage detected! (0x00050005)
[44889.075627] Voltage normalised (0x00000000)

When you have a SSD connected to the Pi, try connecting the adapter via a powered USB hub.

Make sure the extension cable works

A bad extension cable can lead to connection issues between the system and the adapter. Symptoms of this are disconnection messages in the dmesg -w log like below.

[44929.156957] usb 1-1.5: USB disconnect, device number 119
[44929.455555] usb 1-1.5: new full-speed USB device number 120 using dwc_otg
[44929.604582] usb 1-1.5: New USB device found, idVendor=0451, idProduct=16a8, bcdDevice= 0.09
[44929.604596] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[44929.604606] usb 1-1.5: Product: TI CC2531 USB CDC
[44929.604615] usb 1-1.5: Manufacturer: Texas Instruments

For Openhab users: disable zwave binding

The Openhab zwave binding interferes with Zigbee2MQTT, click hereopen in new window for more information.

In case of a CC2530 or CC2531 adapter, verify that don’t have a CC2540

The CC2540 can be confused easily with the CC2531 as it looks (almost) exactly the same. However, this device does not support zigbee but bluetooth. This can be verified by looking at the chip.

ModemManageropen in new window is installed

ModemManager, which is default installed on e.g. Ubuntu, is known to cause problems. It can easily be fixed by removing ModemManager through sudo apt-get purge modemmanager.

hciuart is running

hciuart can be disabled by executing: sudo systemctl disable hciuart.

Texas Instruments LAUNCHXL-CC1352P-2/CC26X2R1 only: press the reset button on the device

If Zigbee2MQTT fails to start with a Texas Instruments LAUNCHXL-CC1352P-2/CC26X2R1 with Error: SRSP - SYS - version after 6000ms, you most probably have connected your device to a system that requires pressing the reset button (the one next to the USB connector) momentarily/shortly after connecting the USB cable. This issue has primarily been observed on x86 architectures only ( e.g., Intel NUC, HPE Microserver, i7 laptop), see also #2162open in new window. The procedure has to be repeated every time the adapter is re-connected and it’s not clear yet, whether this can be fixed at all. It does not seem to occur on ARM based boards (Raspberry Pi, ODROID XU4).

Something that can also solve the issue is to replug the USB cable.

CC2531 coordinators only: press the reset button on the device

When you plug the CC2531 in your computer, the green LED should go on. By pressing the reset button on the CC2531 the green LED should go off. The CC2531 has 2 buttons on it, the reset button is the one which is closest to the USB port. Now try starting Zigbee2MQTT again.

Texas Instruments LAUNCHXL-CC26X2R1 coordinator only: verify that you have the correct revision

The revision of your board can be seen in UniFlash by clicking more info in the top, now press Read device info.

The correct revision is: E like shown below.

All earlier version are not supported (these are development boards). Return this board to the seller immediately.

Return to “Interfacing (DSI, CSI, I2C, etc.)”

Как правильно задавать вопросы

Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Для начала воспользуйтесь поиском форума. 2. Укажите версию ОС вместе с разрядностью. Пример: LM 19.3 x64, LM Sarah x32 3. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 4. Какое железо. (достаточно вывод inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот

Okay, that looks like wild copy & paste from different sources in order to get it working.

Please post also the output of ls -l /dev/tty* from the PVE host in order to see the actual TTY devices.

root@pve:~# ls -l /dev/tty*
crw-rw-rw- 1 root tty 5, 0 Dec 18 01:32 /dev/tty
crw—w—- 1 root tty 4, 0 Dec 18 01:32 /dev/tty0
crw—w—- 1 root tty 4, 1 Dec 18 01:32 /dev/tty1
crw—w—- 1 root tty 4, 10 Dec 18 01:32 /dev/tty10
crw—w—- 1 root tty 4, 11 Dec 18 01:32 /dev/tty11
crw—w—- 1 root tty 4, 12 Dec 18 01:32 /dev/tty12
crw—w—- 1 root tty 4, 13 Dec 18 01:32 /dev/tty13
crw—w—- 1 root tty 4, 14 Dec 18 01:32 /dev/tty14
crw—w—- 1 root tty 4, 15 Dec 18 01:32 /dev/tty15
crw—w—- 1 root tty 4, 16 Dec 18 01:32 /dev/tty16
crw—w—- 1 root tty 4, 17 Dec 18 01:32 /dev/tty17
crw—w—- 1 root tty 4, 18 Dec 18 01:32 /dev/tty18
crw—w—- 1 root tty 4, 19 Dec 18 01:32 /dev/tty19
crw—w—- 1 root tty 4, 2 Dec 18 01:32 /dev/tty2
crw—w—- 1 root tty 4, 20 Dec 18 01:32 /dev/tty20
crw—w—- 1 root tty 4, 21 Dec 18 01:32 /dev/tty21
crw—w—- 1 root tty 4, 22 Dec 18 01:32 /dev/tty22
crw—w—- 1 root tty 4, 23 Dec 18 01:32 /dev/tty23
crw—w—- 1 root tty 4, 24 Dec 18 01:32 /dev/tty24
crw—w—- 1 root tty 4, 25 Dec 18 01:32 /dev/tty25
crw—w—- 1 root tty 4, 26 Dec 18 01:32 /dev/tty26
crw—w—- 1 root tty 4, 27 Dec 18 01:32 /dev/tty27
crw—w—- 1 root tty 4, 28 Dec 18 01:32 /dev/tty28
crw—w—- 1 root tty 4, 29 Dec 18 01:32 /dev/tty29
crw—w—- 1 root tty 4, 3 Dec 18 01:32 /dev/tty3
crw—w—- 1 root tty 4, 30 Dec 18 01:32 /dev/tty30
crw—w—- 1 root tty 4, 31 Dec 18 01:32 /dev/tty31
crw—w—- 1 root tty 4, 32 Dec 18 01:32 /dev/tty32
crw—w—- 1 root tty 4, 33 Dec 18 01:32 /dev/tty33
crw—w—- 1 root tty 4, 34 Dec 18 01:32 /dev/tty34
crw—w—- 1 root tty 4, 35 Dec 18 01:32 /dev/tty35
crw—w—- 1 root tty 4, 36 Dec 18 01:32 /dev/tty36
crw—w—- 1 root tty 4, 37 Dec 18 01:32 /dev/tty37
crw—w—- 1 root tty 4, 38 Dec 18 01:32 /dev/tty38
crw—w—- 1 root tty 4, 39 Dec 18 01:32 /dev/tty39
crw—w—- 1 root tty 4, 4 Dec 18 01:32 /dev/tty4
crw—w—- 1 root tty 4, 40 Dec 18 01:32 /dev/tty40
crw—w—- 1 root tty 4, 41 Dec 18 01:32 /dev/tty41
crw—w—- 1 root tty 4, 42 Dec 18 01:32 /dev/tty42
crw—w—- 1 root tty 4, 43 Dec 18 01:32 /dev/tty43
crw—w—- 1 root tty 4, 44 Dec 18 01:32 /dev/tty44
crw—w—- 1 root tty 4, 45 Dec 18 01:32 /dev/tty45
crw—w—- 1 root tty 4, 46 Dec 18 01:32 /dev/tty46
crw—w—- 1 root tty 4, 47 Dec 18 01:32 /dev/tty47
crw—w—- 1 root tty 4, 48 Dec 18 01:32 /dev/tty48
crw—w—- 1 root tty 4, 49 Dec 18 01:32 /dev/tty49
crw—w—- 1 root tty 4, 5 Dec 18 01:32 /dev/tty5
crw—w—- 1 root tty 4, 50 Dec 18 01:32 /dev/tty50
crw—w—- 1 root tty 4, 51 Dec 18 01:32 /dev/tty51
crw—w—- 1 root tty 4, 52 Dec 18 01:32 /dev/tty52
crw—w—- 1 root tty 4, 53 Dec 18 01:32 /dev/tty53
crw—w—- 1 root tty 4, 54 Dec 18 01:32 /dev/tty54
crw—w—- 1 root tty 4, 55 Dec 18 01:32 /dev/tty55
crw—w—- 1 root tty 4, 56 Dec 18 01:32 /dev/tty56
crw—w—- 1 root tty 4, 57 Dec 18 01:32 /dev/tty57
crw—w—- 1 root tty 4, 58 Dec 18 01:32 /dev/tty58
crw—w—- 1 root tty 4, 59 Dec 18 01:32 /dev/tty59
crw—w—- 1 root tty 4, 6 Dec 18 01:32 /dev/tty6
crw—w—- 1 root tty 4, 60 Dec 18 01:32 /dev/tty60
crw—w—- 1 root tty 4, 61 Dec 18 01:32 /dev/tty61
crw—w—- 1 root tty 4, 62 Dec 18 01:32 /dev/tty62
crw—w—- 1 root tty 4, 63 Dec 18 01:32 /dev/tty63
crw—w—- 1 root tty 4, 7 Dec 18 01:32 /dev/tty7
crw—w—- 1 root tty 4, 8 Dec 18 01:32 /dev/tty8
crw—w—- 1 root tty 4, 9 Dec 18 01:32 /dev/tty9
crw——- 1 root root 5, 3 Dec 18 01:32 /dev/ttyprintk
crw-rw—- 1 root dialout 4, 64 Dec 18 01:32 /dev/ttyS0
crw-rw—- 1 root dialout 4, 65 Dec 18 01:32 /dev/ttyS1
crw-rw—- 1 root dialout 4, 74 Dec 18 01:32 /dev/ttyS10
crw-rw—- 1 root dialout 4, 75 Dec 18 01:32 /dev/ttyS11
crw-rw—- 1 root dialout 4, 76 Dec 18 01:32 /dev/ttyS12
crw-rw—- 1 root dialout 4, 77 Dec 18 01:32 /dev/ttyS13
crw-rw—- 1 root dialout 4, 78 Dec 18 01:32 /dev/ttyS14
crw-rw—- 1 root dialout 4, 79 Dec 18 01:32 /dev/ttyS15
crw-rw—- 1 root dialout 4, 80 Dec 18 01:32 /dev/ttyS16
crw-rw—- 1 root dialout 4, 81 Dec 18 01:32 /dev/ttyS17
crw-rw—- 1 root dialout 4, 82 Dec 18 01:32 /dev/ttyS18
crw-rw—- 1 root dialout 4, 83 Dec 18 01:32 /dev/ttyS19
crw-rw—- 1 root dialout 4, 66 Dec 18 01:32 /dev/ttyS2
crw-rw—- 1 root dialout 4, 84 Dec 18 01:32 /dev/ttyS20
crw-rw—- 1 root dialout 4, 85 Dec 18 01:32 /dev/ttyS21
crw-rw—- 1 root dialout 4, 86 Dec 18 01:32 /dev/ttyS22
crw-rw—- 1 root dialout 4, 87 Dec 18 01:32 /dev/ttyS23
crw-rw—- 1 root dialout 4, 88 Dec 18 01:32 /dev/ttyS24
crw-rw—- 1 root dialout 4, 89 Dec 18 01:32 /dev/ttyS25
crw-rw—- 1 root dialout 4, 90 Dec 18 01:32 /dev/ttyS26
crw-rw—- 1 root dialout 4, 91 Dec 18 01:32 /dev/ttyS27
crw-rw—- 1 root dialout 4, 92 Dec 18 01:32 /dev/ttyS28
crw-rw—- 1 root dialout 4, 93 Dec 18 01:32 /dev/ttyS29
crw-rw—- 1 root dialout 4, 67 Dec 18 01:32 /dev/ttyS3
crw-rw—- 1 root dialout 4, 94 Dec 18 01:32 /dev/ttyS30
crw-rw—- 1 root dialout 4, 95 Dec 18 01:32 /dev/ttyS31
crw-rw—- 1 root dialout 4, 68 Dec 18 01:32 /dev/ttyS4
crw-rw—- 1 root dialout 4, 69 Dec 18 01:32 /dev/ttyS5
crw-rw—- 1 root dialout 4, 70 Dec 18 01:32 /dev/ttyS6
crw-rw—- 1 root dialout 4, 71 Dec 18 01:32 /dev/ttyS7
crw-rw—- 1 root dialout 4, 72 Dec 18 01:32 /dev/ttyS8
crw-rw—- 1 root dialout 4, 73 Dec 18 01:32 /dev/ttyS9