Serial devices appear to use the same lock file

[kolaf]

I'm running three bindings that connect through emulated USB serial ports (I believe in different fashions): zwave (the latest unofficial release for OH2), mysensors, and rfxcom. I'm running as root (only way I have found to get full access to the serial ports) under ubuntu 14.something.

Initialising the first device (mysensors) went smoothly after installing the prerequisite serial bundle: feature:install openhab-transport-serial. Next, initialising the zwave bundle failed with a message something like this (this is not entirely correct I lost the log from that issue):

RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine

@L" testRead() Lock file failed

The message was slightly different, but it referenced the lock file for the mysensorsUSB device, not for zwave. Rebooting OH2 made things work.

Finally, failing to automatically discover the rfxcom device because of the Linux FTDI driver issue, I set up the bridge manually. This resulted in the following error message:

 Loading model 'rfxcom.things'
13:13:33.178 [INFO ] [smarthome.event.ThingAddedEvent     ] - Thing 'rfxcom:bridge:rfxtrx' has been added.
13:13:33.195 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed     from UNINITIALIZED to INITIALIZING
13:13:33.198 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from INITIALIZING to OFFLINE
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine

@L" testRead() Lock file failed
13:13:33.204 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: null
13:13:33.207 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'rfxcom.things'

Restarting OH2 does not seem to resolve this, so I am unable to use both mysensors and rfxcom at the same time. Unloading the FTDI driver is not an option, because this makes the mysernsors device unavailable.

[cdjackson]

If I remember correctly, the lock file is handled by the serial driver (well, everything to do with the actual serial port is handled by the driver).

https://github.com/NeuronRobotics/nrjavaserial

There is also an open issue associated with lock files that came out of the zwave binding - you might be interested in taking a look and adding to their discussion? NeuronRobotics/nrjavaserial#60

[kolaf]

It looks like that issue was closed, without me getting any wiser on how or why. Not sure I can contribute any more than reporting what I saw :/

[cdjackson]

The issue I referenced is still open NeuronRobotics/nrjavaserial#60 NeuronRobotics/nrjavaserial#60

[kolaf]

Sorry, I misread the labels on the final post. I get the same issue when reconnecting the zwave dongle. I can give them the same log as I posted here and see what they say.

[mnlipp]

Your lock file has a rather strange name. Usually, lock files have names such as LCK..<dev> with <dev> being something like ttyUSB0 or ttyACM3. You mentioned that you use "emulated USB serial ports". Could you elaborate a bit on that? From the look of your lock file, you should have a "/dev/mysensorsUSB". How can you get such a thing?

[kolaf]

/dev/mysensorsUSB is a symlink to /dev/ttyUSB1 which is created automatically whenever the device is plugged in as per a recipe in the openhab wiki somewhere. It is to ensure that it has the same name after every boot and plug in/plug out.

By emulated USB serial ports I simply mean generic FTDI devices, devices you plug into the USB port but act as serial ports, as they typically do. Nothing special there, just me not phrasing myself correctly :-)

[mnlipp]

Okay, so /dev/mysensorsUSB -> /dev/ttyUSB1 works. The problem occurs when you try to connect your second USB device (zwave). From the error message (/var/lock/LCK..mysensorsUSB: File exists.) it appears that you configured the zwave component to use the same USB device, hence the message.

I'd suggest to try three configurations each using only one of the USB devices one after the other. When they run, have a look at what files are created in /var/lock. Should be different files in all cases.

[kolaf]

They are not using the same USB device, zwave is connected through /dev/ttyACM0. But sure, I'll disable all three bindings and go through them one by one.

[kolaf]

I've tested initialising the services in different orders and this is what I have found:

It appears that everything is related to the RFXCOM binding. It never works regardless of which order I configure things, and the two other bindings always work. One point that might be interesting finding the issue with the rfxcom binding is that when I initialising as the first binding I get the simple error message:

15:59:14.740 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Checking RFXCOM transceiver connection, thing status = OFFLINE
15:59:14.741 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Connecting to RFXCOM transceiver
15:59:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Disconnecting
15:59:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Closed
15:59:14.777 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: null

However, as soon as I install the mysensor binding the error changes to this:

16:00:11.205 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mysensors.things'
16:00:11.232 [INFO ] [smarthome.event.ThingAddedEvent     ] - Thing 'mysensors:bridge-ser:gateway' has been added.
16:00:11.256 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from UNINITIALIZED to INITIALIZING
16:00:11.294 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from INITIALIZING to ONLINE
16:00:11.295 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'mysensors.things'
16:00:13.637 [WARN ] [essage.ApplicationUpdateMessageClass] - Got ApplicationUpdateMessage without request, ignoring. Last message was SendData.
16:00:14.740 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Checking RFXCOM transceiver connection, thing status = OFFLINE
16:00:14.740 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Connecting to RFXCOM transceiver
16:00:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Disconnecting
16:00:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Closed
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine

eP$ testRead() Lock file failed
16:00:14.742 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: null

This is regardless of what I do with the zwave controller. I will point the rfxcom guys to this issue for details.

[mnlipp]

I think something goes wrong here (obviously), but it is not related to the serial driver's locking. The root course is that your RFXCOM connection isn't working. I think you should get that working first in a configuration without the other components.

Looking at the source code (e.g. https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.rfxcom/src/main/java/org/openhab/binding/rfxcom/handler/RFXComBridgeHandler.java) I see quite proper usage of debug logging. Try to run your configuration with log level debug. That should provide more hints.

[dennisausbremen]

Did anyone actually had success building a working org.openhab.io.transport.serial for the OH2 Beta2 with the prerelease from https://github.com/NeuronRobotics/nrjavaserial/releases/tag/3.12.0?

[mnlipp]

Pre-release doesn't work, looking into it...

[mnlipp]

It doesn't work because most native libraries haven't been recompiled, and those that have been recompiled aren't used ;-) (see NeuronRobotics/nrjavaserial#60).

[dennisausbremen]

As you stated in NeuronRobotics/nrjavaserial#60, do you have a version of org.openhab.io.transport.serial.jar for us we can test?

[mnlipp]

What version should I give it in order to not produce something that "gets around" and causes confusion?

[dennisausbremen]

Some "-pre" or "-test"?

[mnlipp]

Are you sure that this complies with OSGi rules?

[dennisausbremen]

No I'm not. But I saw some forks of OH with tagged prereleases for testing, or simply direct links.

[mnlipp]

I'm going to try to package something. I had uses a hacked 1.7.1 for my tests (simply replaced the nrserial jar), but I don't want to publish that.

[mnlipp]

How do I properly replace a jar with a newer version for testing? I have removed org.openhab.io.transport.serial-1.7.1.jar from server/plugins and put my org.openhab.io.transport.serial-1.8.0-test.jar there. But it doesn't seem to be used (no "auto-deploy"). Do I have to change some configuration file?

(Probably a silly question, if you know about OSGi, but I was trying to learn how OSGi works by taking OpenHAB as an example when I found that I couldn't get my RXComm working which led me to nrjavaserial which led me to the lockdir problem which led me to how to cross-compile the native libraries... So I still don't know a lot about OSGi.)

[watou]

I have removed org.openhab.io.transport.serial-1.7.1.jar from server/plugins and put my org.openhab.io.transport.serial-1.8.0-test.jar there.

It's not intuitive, but remove the old one from server/plugins, but put the new one in addons. This is more of an openHAB thing than a generic OSGi thing. 😄

[mnlipp]

There seem to be some restrictions on the version number patterns, so my initial attempt with 1.8.0-test failed. Since openhab doesn't actually add any value to the library expect for packaging it as an OSGi component, I decided to use the nrjavaserial number for versioning, so 3.12.0.a1 in this case.

Deployment as described by @watou didn't work either. Since I tried several things, I cannot be perfectly sure, but I think you have to replace the jar in server/plugins and issue an update file:/... command in the console. (I strongly suspect that the location of the jar doesn't matter at all, and that server/plugins is only used for the initial population of the server. Hopefully I'll have some time now to have a closer look at that OSGi stuff.)

You can download the bundle from https://github.com/mnlipp/nrjavaserial/releases. It successfully connects my RFXComm with openhab on my Raspberry Pi 2 running Arch Linux, using locking as it should. You can find an enumeration of the environments where it should work in the release notes. Make sure to install the package that provides liblockdev on your system.

[paulianttila]

Should we update nrjavaserial to version 3.12.0. It still seems to be pre-release, but nothing has happen since 20th of feb.

[kaikreuzer]

NeuronRobotics/nrjavaserial#44 is still a blocker for me. If the project is dead, we can discuss to fork it and take over - but we would need someone willing helping to maintain it.

[kaikreuzer]

FTR, we meanwhile use version 3.14.0, but NeuronRobotics/nrjavaserial#60 is still open, so the locking issue continues to exist.

[wborn]

The current status (20-12-2018) is that:

• The official nrjavaserial releases are still build with liblockdev causing issues on some distributions (Use proper lock directory NeuronRobotics/nrjavaserial#60)
• After having used the official nrjavaserial 3.14.0 release we ran into these locking issues again (see community thread)
• We now cross compile an openHAB nrjavaserial JAR using the official sources while disabling liblockdev (nrjavaserial-builder)

[davidgraeff]

We now cross compile an openHAB nrjavaserial JAR using the official sources while disabling liblockdev

I'm closing this then :)