Repository navigation
Workaround causes serial port discovery issues #577
Description
Activity
The crash/exit can also be reproduced with other USB devices and will probably be resolved when NeuronRobotics/nrjavaserial#180 is fixed.
- added a commit that references this issue
on May 27, 2020 - added a commit that references this issue
on May 27, 2020 The workaround can be removed in OH3 because nrjavaserial 5.2.1 no longer exits the JVM in certain scenarios when ports are closed/reopened.
nrjavaserial 5.2.1 no longer exits the JVM
Unfortunately that's not true on a Mac at least.
This issue has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/success-with-sonoff-zigbee-bridge-and-zigbee-binding/104985/81
This issue has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/oh3-zigbee-binding-not-working-with-rfc2217-port/115711/2
It would be good if this can be fixed. Sonoff ZBBridge can be used with zigbee binding, but only with socat because RFC2217 does not work.
Unfortunately that's not true on a Mac at least.
Hopefully your Mac issue will be fixed by NeuronRobotics/nrjavaserial#211
- added a commit that references this issue
on Jul 11, 2023 Is this issue still open because #661 didn't actually fix the problem?
I've a new Z-Net Pro with Zwave and an ember Zigbee coordinator but these are only available over the network. rfc2217 worked like a champ for Zwave, but it's failing to work for Zigbee. I'm trying to determine if it's supposed to work or was never made to work.
The binding currently uses serialPortManager.getIdentifiers() to see if there are any
SerialPortIdentifiers.This workaround was added in #335 by @triller-telekom.
The workaround causes serial port detection issues because the
getIdentifiers()method will only return discovered ports.As a result:
gnu.io.rxtx.SerialPortsso they can be used without users having to configure thisWe've upgraded nrjavaserial in OH3 so we should retest if this is still an issue.
We should also test if it is fixed with nrjavaserial 5.1.0+ because it contains fixes for hardware that gets removed.
If this is no longer an issue we should remove the workaround by instead detecting that a controller is disconnected by just opening the port and handling any resulting exceptions.
If it is still an issue, we should create an issue for it in the nrjavaserial issue tracker with a reproduction scenario. That way we can fix the root cause and don't need to add such workarounds (causing discovery issues) to other add-ons.
Related to: