ZWave serial port error when using symlink since 2.5.1

openls · April 11, 2020, 9:24am

Platform information:
- Hardware: Synology DiskStation DS218+, Aeotec Z-Stick Gen5
- openHAB version: 2.5.1 or higher in Docker

With openHAB 2.5.1 or higher I get the follow error from the ZWave binding:

Serial Error: Port /dev/ttyZWave does not exist

I run openHAB on a Synology NAS inside a Docker container. Because I use more than one USB-Stick and the port assignment changes after a reboot, I created a rules file in /lib/udev/rules.d/ with the following content:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyZWave", MODE="0777"
SUBSYSTEM=="tty", ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", SYMLINK+="ttyZigbee", MODE="0777"

The container then uses the symlink /dev/ttyZWave instead of /dev/ttyACM0 or /dev/ttyACM1. This has been working perfectly with older versions (and still works) but not with the update to 2.5.1. When I edit the configuration to use the real port (/dev/ttyACM…) openHAB works as expected. I tested this with 2.5.1, 2.5.2 and 2.5.3.

Any help is greatly appreciated as this problem breaks my current setup with multiple USB sticks.

@rlkoshak I am not able to add tags to my topic. When I originally created the topic I got some internal server error and now everytime I try to add tags to my topic I get “Error 500”.

openls · April 11, 2020, 3:46pm

@rlkoshak I am not able to add tags to my topic. When I originally created the topic I got some internal server error and now everytime I try to add tags to my topic I get “Error 500”.

I waited for several hours and now tagging works…

chris · April 11, 2020, 3:48pm

This has been a problem with the forum for many months now. For some reason the zwave tag mostly doesn’t work. Most of the time you can use z-wave instead.

chris · April 11, 2020, 3:53pm

What “older versions” exactly? It helps to know what works - not just what doesn’t.

I assume when you upgraded that you retained any command line parameters to set the ports when starting openHAB?

openls · April 11, 2020, 4:12pm

What “older versions” exactly? It helps to know what works - not just what doesn’t.

Sorry for not being more specific. The latest working version for me is 2.5.0 and that is what I have been using since it was released. I’m not sure if I already had this setup with 2.4 but I tested some milestone builds during the 2.5 development and never had any issues.

I assume when you upgraded that you retained any command line parameters to set the ports when starting openHAB?

Yes, I even created new containers for all version from 2.5.0 onward to see if the problem is specific to one version. For further testing I also did setup all containers in privileged mode so I can rule out any errors passing devices.

So 2.5.0 works and all later stable versions do not work.

chris · April 11, 2020, 4:18pm

Thanks. I just checked, and there have been no changes to the binding since 2.5.0. Well, there were 2 - one to change the license headers to 2020 and one to add a new channel. Neither of these would impact the serial port.

Maybe there were changes elsewhere that could impact this - maybe Docker or Syno repos?

openls · April 11, 2020, 4:28pm

If I’m following the release notes there were some other changes to the binding:

github.com/openhab/org.openhab.binding.zwave

Add serial port reconnection logic (Closes #1213)

openhab:2.5.x ← bodiroga:serial-reconnection

opened 01:08AM - 14 Aug 19 UTC

bodiroga

+292 -71

Hi @cdjackson! Let's see what you think about the implementation, fingers cro…ssed :crossed_fingers: Some parts of the code are taken from the great work done by @Hilbrand on #1210, so thanks Hilbrand for your job! A couple of important notes: - I have set the "notifyOnDataAvailable" flag to false because we are not using the serialEvent callback of the SerialPortEventListener interface to check for new data, as we are reading the serial port in a while loop. The "forever" sleep (```Thread.sleep(Long.MAX_VALUE);```) in serialEvent causes a 100% CPU load when the USB stick is removed, because the sleep thread continues to be alive even after interrupting and setting the receiveThread object to null. I don't know why, but I made some test setting the sleep to something like 300 seconds and logging a message after the sleep line, and after calling the onSerialPortError, when everything should be closed, the message was logged after 5 minutes. Adding the "```notifyOnDataAvailable(false)```" line has fixed the CPU load problem. - Yes, I know that the "getSerialPortIdentifier" function is very awkward, because it's the same as the one defined in the serialPortManager interface, but using the already defined "getIdentifier" function I was not able to detect that the USB controller was unplugged. In my case the function does not return null if the stick was previously connected. It would be really helpful if you could make some tests overwriting the getSerialPortidentifier code with a simple ```return serialPortManager.getIdentifier(portId)```. Does the function return null when you remove the stick from the USB port? Otherwise, the code is working flawlessly here and I have re-plugged the stick many times, trying to be a bad guy (when the network was initializing and the controller was sending a lot of messages), but everything restarts correctly. I also made the test of unplugging the controller, adding a new Z-Wave manually (with the sticks button) and plugging it back, and the new discovery result appeared in the inbox :+1: Thank you for having a look at it and looking forward to your comments. Best regards, Aitor Closes #1213 Signed-off-by: Aitor Iturrioz <riturrioz@gmail.com>

Another thing which comes to my mind is that I somehow remember reading about a change in the underlying Serial Port implementation (a different one) being used but I’m not sure if remember that correctly and if that applies to the new releases. I was a passive follower of openHAB for a long time

Maybe there were changes elsewhere that could impact this - maybe Docker or Syno repos?

Sadly no. I created all containers again from scratch yesterday without restarting or changing versions of Docker or DSM. So I can create a new 2.5.0 container now and it works, whereas 2.5.1 etc. do not work.

chris · April 11, 2020, 4:33pm

The serial reconnect logic was well before 2.5 was released. That is dated August, while 2.5.0 was released in mid December.

I’m not sure why the other ones aren’t showing up in the history - I’ll take a look.

Yes, but this was maybe a year ago - again, well before 2.5.0 was released.

openls · April 11, 2020, 4:37pm

I might be stupid but the merge request was created in August. The actual changes were merged by you in January.

chris · April 11, 2020, 4:38pm

Below is the full list of changes since 2.5.0. Many of these were not merged and some were merged into a branch not related to 2.5. In any case I don’t see any that should impact the serial port, and in general, the serial port is not managed by the binding anyway.

chris · April 11, 2020, 4:39pm

Fair point. I don’t think that PR would change anything though. As mentioned, the binding doesn’t directly link to the serial port - it’s all done externally.

openls · April 11, 2020, 4:43pm

Is there an easy way to use the old 2.5.0 binding with the 2.5.3 release? I guess that would be a quick way of seeing if the error lies within the binding or somewhere else.

chris · April 11, 2020, 4:44pm

Yes, you can run the 2.5 binding with the 2.5.3 runtime - the runtime is as far as I know the same.

openls · April 11, 2020, 4:47pm

Can I just uninstall the binding in 2.5.3 and then put a jar of the 2.5.0 version in the Addons folder or do I have to do this another way? Sorry for bothering you this much.

openls · April 11, 2020, 5:00pm

Fair point. I don’t think that PR would change anything though. As mentioned, the binding doesn’t directly link to the serial port - it’s all done externally.

Sorry for being stubborn but by looking at the changes in the MR I beg to differ.

I’m not familiar with the openHAB source code but is this really not related to my problem? It looks like the implementation of how the serial port is identified changed.

chris · April 11, 2020, 5:09pm

Please feel free to try and debug the issue then - I didn’t work on this code and there have been no other reports of such issues in the past 4 months, but you’re welcome to try and work through the issue of course.

openls · April 11, 2020, 7:57pm

I took me a while but I tested some more configurations. I created a new container with empty folders except for the zwave.things file which contains only the controller.

2.5.0 with ZWave binding from Paper UI → everything works
2.5.1 with ZWave binding from Paper UI → Serial Error: Port /dev/ttyZWave does not exist
2.5.1 with “org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar” → everything works

So it seems the problem lies within the binding and the only changes related to serial ports is the merge request I mentioned earlier. As far as I can see these changes might even be the only real code changes since 2.5.0.

Please feel free to try and debug the issue then

I’m no Java developer and I have no experience with the openHAB source code at all, but if that’s what you think is best, I will gladly try to resolve the issue myself. But before I do that I want to be sure to not waste time debugging this code if you think it is not related to my problem.

As mentioned, the binding doesn’t directly link to the serial port - it’s all done externally.

I’m not sure I understand you. Could you please explain to me what you mean by that? Just from looking at the code I got the impression that the shown part is directly responsible for generating the error message I’m seeing and the way to identify the serial port after initialization, which leads to that error, was changed in 2.5.1 in that merge request. Again, I might be wrong and please do not feel offended by my questions

chris · April 11, 2020, 8:00pm

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.

openls · April 11, 2020, 8:19pm

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:

chris · April 11, 2020, 8:21pm

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).