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.
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.
@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.
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
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?
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…
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?
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.
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:
Use --device=/dev/ttyZWave:/dev/ttyACM0 to map the device according to the naming scheme
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.
Since the need for this is not Docker specific, some further clarification here would be helpful…
It may also be helpful to link to this section from the Docker config doc and then provide specific implementation examples. Are the device tags enough, or did you also need to add the enties to EXTRA_JAVA_OPTS?
I also thought about linking to a more detailed document but somehow forgot about that. I will edit my PR.
About the use of EXTRA_JAVA_OPTS:
They are not required at all for the devices to work using Docker (with the described mapping) and I personally also think they are not helpful, see
Also they are separated by “:” which in the context of Docker is used to create mappings. So for the Docker guide I would rather only show the --device way, as this is always working and is the cleaner approach in my opinion. But you can surely try to convince me otherwise
EDIT:
After thinking more about this, I would also add a note in the Serial Port Configuration documentation in case Docker is used and link to the Docker documentation, as the described steps (EXTRA_JAVA_OPTS) are not required.
I very rarely use Docker with OH, so I’m not able to help with that.
You are correct and IMO is a bug that it is missing. You could mention this in your PR and @confectrician will help with it. However, there will be a major overhaul of the docs for OH 3.0.