URTSI binding makes it impossible to use other serial ports in other bindings

[gaborherman]

The change 675c67d in the URTSI binding replaces the gnu.io.rxtx.SerialPorts list by the single item configured for the URTSI binding (effectively removing existing items from that list). Instead of this it should add the configured port string to the list. (Note: non-symlinked ports like /dev/ttyUSB* must also be on the list if you want to open them, they are present by default but deleted by this binding)

As a result, any other bindings wanting to use other serial ports will be unable to open them (even if they are non-symlinked ports)

Example reproduction scenario:
-configure /dev/ttyUSB0 for Z-Wave
-configure /dev/ttyUSB1 for URTSI
-start OpenHAB
->Z-Wave binding won't be able to open the configured port!

[RainerBrunold]

I have the same problem and can confirm that this is still a problem in 1.5.1.

More information and debug logs for this problem can be found here:

https://groups.google.com/forum/#!searchin/openhab/collision/openhab/IaS6gHt9h8w/7fXXk-VvwKQJ

Rainer

[RainerBrunold]

Hello,

I have here a method on how to duplicate this issue without having a z-wave and urtsi interface.
I hope this helps a developer to identify the issue more quickly and it can be resolved.

The idea is to create on a linux server virtual serial devices that get linked to the ttyUSBx interfaces and then configure and start openhab with the z-wave and the urtsi addon. This method needs the socat linux executable to be installed.

Then you could see that the z-wave port is reported as not being existent.

simulate urtsi device:

socat -d -d pty,raw,echo=0 pty,raw,echo=0

2014/10/13 17:52:58 socat[7873] N PTY is /dev/pts/4
2014/10/13 17:52:58 socat[7873] N PTY is /dev/pts/5
2014/10/13 17:52:58 socat[7873] N starting data transfer loop with FDs [3,3] and [5,5]

This creates the /dev/pts/4 and /dev/pts/5 device nodes.
From 4 to 5 it looks like a NULL modem cable.
The device numbers vary when you start it, therefor adopt the following commands in that case !

Link one of them to ttyUSB0

ln -s /dev/pts/4 /dev/ttyUSB0

On a new shell connect to the /dev/pts/5 where you would see what is transferred via ttyUSB0

cat < /dev/pts/5

simulate z-wave device:

socat -d -d pty,raw,echo=0 pty,raw,echo=0

2014/10/13 17:54:43 socat[7972] N PTY is /dev/pts/7
2014/10/13 17:54:43 socat[7972] N PTY is /dev/pts/8
2014/10/13 17:54:43 socat[7972] N starting data transfer loop with FDs [3,3] and [5,5]

This creates the /dev/pts/7 and /dev/pts/8 device nodes.
From 7 to 8 it looks like a NULL modem cable.
The device numbers vary when you start it, therefor adopt the following commands in that case !Link one of them to ttyUSB1

ln -s /dev/pts/7 /dev/ttyUSB1

On a new shell connect to the /dev/pts/8 where you would see what is transferred via ttyUSB1

cat < /dev/pts/8

openhab configuration:

1. add the two addons for urtsi and zwave to the addon directory
2. add / adopt the configurations for those two addons on in the openhab.cfg like this

urtsi:beschattung.port=/dev/ttyUSB0
zwave:port=/dev/ttyUSB1

1. configure some Somfy rollershutter to see that the NULL modem cable is working, this is just a sample block from my items files, adopt it to your configuration

Rollershutter Rolladen1Wintergarten "Wintergarten 1" (FF_TV, All) { urtsi="beschattung:1" }
Rollershutter Rolladen2Wintergarten "Wintergarten 2" (FF_TV, All) { urtsi="beschattung:2" }
Rollershutter Rolladen3Wintergarten "Wintergarten 3" (FF_TV, All) { urtsi="beschattung:3" }
Rollershutter Rolladen4Wintergarten "Wintergarten 4" (FF_TV, All) { urtsi="beschattung:4" }

1. start openhab and notice that the z-wave port /dev/ttyUSB1 is reported as not existing
2. issue a up or down command on a rollershutter to see the output on the virtual device
3. shutdown openhab
4. comment out the config line urtsi:beschattung.port=/dev/ttyUSB0 in the openhab.cfg
5. start openhab.cfg once again and notice that the z-wave port is not longer not existing

I hope this helps to identify the problem ...
Thanks to anyone helping with this problem !

Rainer

[maggu2810]

If someone have a look at the relevant commit, it should be clear, that this will break other serial port usage.

Also adding something to a system property will fail (I am not a java guru, but as I know there is the same "logic" as used by other languages [C,C++,...]).
To add something you have to read the system property, add something and set the property.
In a threaded environment this could result in an undefined behavior if this is done by multiple threads at the same time.
A binding could not know if another binding does the same, so changing the system property that one is a bad idea in general.

[maggu2810]

I have a short look at the nrjavaserial code base and asked upstream: NeuronRobotics/nrjavaserial#23

[OLibutzki]

There has to be a thread-safe way to add ports to the system property. Anyway, I will change the URTSI binding in order to add additional ports instead of deleting the old values.

[teichsta]

seem to be fixed through various commits …