Smarthome: [WARN ] [ysfs.internal.PollingUsbSerialScanner] - A NoSuchFileException prevented a scan for USB serial devices: \sys\class\tty

[PiscisSwimeatus]

Platform information:
OS: Windows 10 Enterprise (64bit)
Java Runtime Environment: Java Runtime Environment Version 8.0 Update 161 (32bit)
openHAB version: 2.3.0 SNAPSHOT 2018-04-23

Start from a clean copy
Add zwave binding
The following warning logs every 5 seconds
Except the warning everything seams to be working ok

openhab.log
events.log

[kaikreuzer]

@hsudbrock Could you have a look at how that can be prevented?
Imho, the bundle should ideally not become active at all on Windows, right?

[hsudbrock]

Thanks for pointing out this issue @PiscisSwimeatus.

@kaikreuzer I agree that the bundle should not become active at all on Windows. I think that, ideally, the bundle should not even be installed on a Windows system. I had hoped that this might be achievable using a requirement in a Karaf feature on the property osgi.os. However, I stumbled upon https://github.com/eclipse/smarthome/issues/1416, where it is stated that this property is not set within Karaf instances.

Hence, I see two points for improvement here:

1. Do net let the DS component SysfsUsbSerialScanner become active on Windows systems (or, more generally, on systems where the sysfs cannot be scanned). In consequence, the 5-second polling of the sysfs will not happen.
2. Move the bundle org.eclipse.smarthome.config.discovery.usbserial.linuxsysfs to its own Karaf feature (currently, it is contained in the Karaf feature that also contains org.eclipse.smarthome.config.discovery.usbserial).

I think that 1. should be implemented (and would also provide a PR for that). I am not yet sure whether, on top of the DS component not being active, the complete bundle should not be active.

When also implementing 2., I think that this would mean that one would have to explicitly install an additional feature for being able to use the USB-Serial discovery on Linux systems. This is why I am not sure whether this should be done (but could also provide a PR, if discussion result here is that we want this).

What do you think?

[kaikreuzer]

I agree that option 2 is not ideal, because it would be the user who'd have to explicitly install that feature.

Ftr, I see the same warning on Mac as well:

20:30:42.609 [WARN ] [ysfs.internal.PollingUsbSerialScanner] - A NoSuchFileException prevented a scan for USB serial devices: /sys/class/tty

It would probably make sense to check for the availability of that file even before scheduling a regular scan - I could imagine that there are even Linux variants that do not have it.
By doing this check and reducing the warning to a debug message, all should be fine, wdyt?

[hsudbrock]

I agree, @kaikreuzer. The plan for my PR is then to check availability of the directories required for scanning, so that periodic scanning will never take place if they are not available, plus adapting the log message level. Thanks for your feedback!

[kaikreuzer]

Thanks for looking into it 😎 .

[sjsf]

fixed by #5521