ZWave serial port error when using symlink since 2.5.1

Yes. What I meant is that the communication with the serial port is done through the openhab serial port classes. The binding doesn’t have a lot to do with this - it just passes the data to the driver.

I dont have any time to look at this at the moment - sorry.

No problem. I guess I just have to figure it out myself.

Btw I think this is basically the same problem so I might not be the only one:

Sorry - I just don’t have the time to look at minor issues like this (I know it’s not minor to you, but one person with such an issue in 4 months is still minor and I’ve a lot of other things to work in - sorry).

1 Like

I took the time to setup a dev environment for openHAB and compiled my own version of the ZWave binding. I didn’t get remote debugging to work so I had to work with log output, which was rather painful, but I got the result I expected.

The changes in the reconnection merge request lead to the problem. The problem is not the change itself but rather the implementation of SerialPortManager. The changes were made because:

Workaround for getIdentifier in SerialPortManager class, because it doesn’t detected correctly that the device is unplugged.

Using getIdentifiers instead now breaks support for symlinks at least in my case. Most of the time getIdentifiers returns no port for me. Strangely sometimes it does but not during execution. So either it always returns the port correctly or it never returns the port. I guess this depends on SerialPortRegistry and if it is filled correctly. I didn’t have the same to dive deeper into the code.

So instead of trying different workarounds in the binding I think it would be best to take a closer look at SerialPortManager and the underlying classes and fix the initial problem. As you have no time, maybe you can point me in the direction of someone who might be able to help me further investigate this issue.

If there is no such person, I’m fine with using my own patched version of the binding. As you mentioned the problem does not seem to affect many people and as for me I’d rather have a working port detection than support for stick reconnection during runtime.

PS Happy Easter :rabbit:

3 Likes

Thanks for investigating.

This is what I was getting at earlier - the binding doesn’t directly do a lot with the serial port. Can I suggest to raise this as an issue on the issue tracker so at least someone tracks it.

Even if I had time, I have no knowledge of this code as I’ve never worked on it. I think it came from ESH. As above, I’d suggest to raise this as an issue on the OH core issue tracker.

Possibly related

1 Like

Thanks. I found even more related issues.

@5iver You mentioned something about a naming scheme in the Github issue. Could you please give me a little bit more information about that? I’m using the name “/dev/ttyZWave” and getIdentifier in SerialPortManager has no problems with this. getIdentifiers on the other hand almost never returns the port. But if this was due to the name of the port, I would expect it to not work at all and not sometimes.

Have you added all of the serial ports to EXTRA_JAVA_OPTS? If you have, then you can use any name you want. If for some reason you do not want to add the ports to EXTRA_JAVA_OPTS, then read the note at the bottom of… https://github.com/openhab/openhab1-addons/wiki/symlinks. I remember also finding more details on the Internet when I was looking into this.

Here is a PR that helped to resolve some issues I had seen with serial prior to 2.5M2.

2 Likes

Thank you very much, this is interesting. I did not know this and several things come to my mind.

I use Docker and add devices like this: --device=/dev/ttyZWave, so I do not use EXTRA_JAVA_OPTS. Also this not mentioned anywhere in the Docker description for openHAB. I did not have problems with this until the code (of the ZWave binding) changed in 2.5.1. Actually the old code still works without any errors when

serialPortManager.getIdentifier(name);

is used. But this was changed to

serialPortManager.getIdentifiers().filter(id -> id.getName().equals(name)).findFirst();

and the funny thing is, that this does not work most of the time, but sometimes (just restarting the container again and again…) it works. I would image that if EXTRA_JAVA_OPTS are required, the code would not work at all.

@wborn As you seem to have worked on this topic, could you please just have a quick look at my findings and give a comment if this could still be a bug?

:frowning: One of the first things I asked you is if you retained the command line parameters to configure the ports… You said yes.

I seem to remember in the past there was an issue where these options were required which is why I asked this. I guess I should have been a bit more specific, but I’m not sure what parameters you thought I meant if it wasn’t these…

The command line parameters which are needed to start the docker container and are described in the documentation:


Ok, I guess there’s too many ways to start OH and that adds to the confusion, but as we were talking about serial ports this is what I had meant.

So are EXTRA_JAVA_OPTS required for working with usb devices in Docker? I never used those and they are not mentioned anywhere regarding devices in

https://hub.docker.com/r/openhab/openhab/

:frowning:

I’m not very familiar with Docker, but these options are related to Java, so I would expect that it is needed for ALL installations (or at least recommended). These options help pass on system information to the Java classes that have to try and find serial ports.

I’d recommend having a read of the serial port configuration section - it’s applicable for all installations and fundamentally I assume the Docker installation is basically a Linux install inside the container?

https://www.openhab.org/docs/administration/serial.html#serial-port-configuration

Hmm I will do some tests with EXTRA_JAVA_OPTS. There is even a trouble shooting area in the docker guides about USB sticks and also no mention of this. Let me get back with some more test results.

For sure, there is always room to improve the docs, so if you find shortfalls, please feel free to provide a PR to help the community.

Okay after further testing I can confirm that this is true:

Have you added all of the serial ports to EXTRA_JAVA_OPTS? If you have, then you can use any name you want. If for some reason you do not want to add the ports to EXTRA_JAVA_OPTS, then read the note at the bottom of… symlinks · openhab/openhab1-addons Wiki · GitHub. I remember also finding more details on the Internet when I was looking into this.

@5iver Thank you again, this was really helpful and also @rossko57

So basically two options work:

  1. Use --device=/dev/ttyZWave:/dev/ttyACM0 to map the device according to the naming scheme
  2. Use EXTRA_JAVA_OPTS=“-Dgnu.io.rxtx.SerialPorts=/dev/ttyZWave”

So this should really be mentioned somewhere in the Docker installation guide. I have no account to start a PR, but if no one else can do this quickly, I will do it if I have some more time.

The last question for me is: Why is this even required? Some functions of SerialPortManager work perfectly fine without any of these workarounds while others don’t.

But I can live with solution 1 :slight_smile:

Great - glad it’s working :slight_smile:

I guess we can expect some updates to the docs? :sunglasses:

Note that it’s free and simple to get one. You can quickly register on GitHub and it would allow you to make a contribution back to the community.

1 Like
2 Likes