So below is the Full Debug-log (docker-run parameter -e DEBUG=zigbee-herdsman*)
if anyone can do something with it (wait, till the blue led turns off, after that, stopping the Container, same as the first debug log from my previous post) :
so now i have written enough for the first 
I just want to tag on to this as I also replaced my CC2531 Zigbee coordinator with a CC2652RB model and I am experiencing exactly the same. The openHAB zwave stack somehow blocks access to ttyUSB0, even though the zwave-stick is on port ttyACM1.
What Zigbee binding are you using? I expect many people are successfully using the Zigbee & Z-Wave bindings together. @chris can verify if he knows of users using the CC2652RB successfully.
That would indicate an issue with zigbee2mqtt binding or the flashed firmware.
Plug in a USB memmory stick to the port you usally use for z-wave. Is it usable? If you then plug in z-wave, (sho ls -l /dev/ttyUSB* /dev/ttyA*): does it work?
Just to proof, it’s not a “blocking /dev/ttyUSB*” issue but zigbe(2mqtt) using CC2652RB flashed with whatever vs z-wave using whatever controller.
No zigbee-binding at all, I use zigbee2mqtt.
Your comment about “many people” may be correct, assuming that “many people” use the (cheap but weak) CC2531-USB-stick. I also have one of those, and with that it works flawlessly.
However, the CC2531 uses a ttyACM-port, while the CC2652RB, which does NOT work with the zwave binding, uses a ttyUSB-port. Which the zwave-framework of openHAB seems to block, even though it shouldn’t even touch it.
For clarification, my /etc/default/openhab2 contains:
EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyACM1"
(which is the port my zwave-stick uses).
Well - as you might know, setting it like this, the only port seen by openHAB (no to say JAVA apps) is /dev/ttyACM1. Don’t know what that means for the zigbee2mqtt usage though.
Are you using a docker imager like @bifi2090?
@yab:
It is sufficient to temporariliy disable the zwave-controller “thing” in PaperUI to make the zigbee-stick work as intended. So sure, unplugging the zwave-stick has the same effect. Re-enabling the thing knocks the zigbee-stick out again.
Is that what you meant?
And yes, the USB-ports themselves work fine, it does not matter where which stick is inserted (and shouldn’t).
That is intentional. openHAB should only see the port the binding uses for zwave, nothing else. I do not have any other JAVA apps accessing USB, so that’s fine for me.
And no, no docker image, pure Debian system.
Although i am not really able to find the solution as i stated above, i try to analyse the problem - hoping this might be helpful for someone knowledgable.
Is z-wave really blocking /dev/ttyUSB0? To proof this, check usage of an USB-Stick on /dev/ttyUSB0. Does it work?
If it really blocks /dev/ttyUSB0: is this true for USB1 also? Just give it a try while plugging in “something” to USB0 and test functionality -> will not work, see above. Check /dev/ttyUSB* just to be sure, which USB* was used and plug in the next USB device. See what happens. I’d expect CC2652RB not to work on /dev/ttyUSB1 also (if it works: ugly workaround).
Whatever the results are: i’d expect them to give a better idea of what/where the problem might be.
From what you have written and what i remember bifi2090 did, i’d expect the problem to be somewhere where @chris (sorry!) already mentioned he remembers “something” (serial communications). The prob seems to be triggered by using CC2652RB for zigee2mqtt and caused by starting z-wave binding (or the other way round). It does not depend on docker, as we know now.
As mentioned - somewhere I recall there being an issue raised where the nrjavaserial driver tried to search for serial ports, and leaves ports open. I think it tries to open each port to see if it really exists, and this can block other devices (I think).
As I say, this is a little “from memory” so I could well be mistaken
I don’t think I can test this properly due to the lack of a different USB stick that uses a tty-port. A memory stick used in parallel works fine, but it is not a serial but a block device and thus gets a corresponding device “port” (like sdx). So I really don’t have a way of trying if ttyUSB1 is affected as well.
OK. And how can we prevent that?
So i´ve found another interesting behaviour, maybe it helps to isolate the error.
As mentioned by @Tron
I was wondering how this thing works. At my side i mentioned, that I have to disable the entire ZWave-Binding to make the CC2652RB work. @Tron says, that he only disabled the Serial Controller within the PaperUI - that doesn´t worked for me. So I decided as a test to change my EXTRA_JAVA_Oppts on the basis of
meaning, that /etc/default/openhab2 only contains the ZWave-Stick-Symlink and the two /dev/ttyACMx - Ports. And lo and behold, the CC2652RB now works by only disabling the Zwave-Controller within PaperUI. It is not necessary to put the symlinks for the CC2531/CC2652RB and the Port /dev/ttyUSB0 inside the EXTRA_JAVA_OPTS, because the zigbee2mqtt runs independently from OpenHAB on the Raspberry, and thus also sees indeed all available ports.
So long story short:
EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB-CC2652RB:/dev/ttyACM0:/dev/ttyACM1:/dev/ttyACM-AGen5:/dev/ttyACM-CC2531:/"
CC2652RB works only by disabling the whole ZWave-Binding (karaf-console)
and
EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyACM1:/dev/ttyACM-AGen5:/"
CC2652RB works by only disabling Zwave-Serial Controller within PapaerUI.
Hopefully this clearifies something.
As I said, my memory is not good on this issue. I did spend some time trying to find information on this, but was unsuccessful.
I had a glance at zigbee2mqtt and realized i had a faulty understanding of zigbee2mqtt. As it is not running standalone and doesn’t us java, ports don’t have to mentioned in EXTRA_JAVA_OPS. Thanks for pointing me to that one. @bifi2090: sorry for kind of wrong info above!
I wonder, what z-wave may do with a port it even doesn’t (possibly “shouldn’t” - better said) know about (because it is not metioned in EXTRA_JAVA_OPTS).
An other idea to isolate the source of the error: if CC2652RB is supported by the zigbee binding, you could install thatone just to look if it is functional or if it shows the same symptoms as zigbee2mqtt.
For almost all other bindings you won’t have to mess with adding ports to EXTRA_JAVA_OPTS. There are bugs in the ZWave and ZigBee code that cause all these discovery issues and people having to make all these manual configurations, see:
Are they bugs, or was this code added to solve other serial problems? I’m not super familiar with this, but the code seems to have been explicitly added to solve another problem from what I can see.
Workarounds causing issues/bugs.
Yes, maybe, but I guess there was a problem that required a workaround. Removing the workaround re-exposes the original problem.
So we end up trading one problem against another - we make some people happy, and others upset - unless there’s a better way, or the workaround isn’t needed as something changed elsewhere?
The workaround prevents the JVM from crashing if you unplug/reinsert a USB device. In OH3 a new nrjavaserial library is integrated which no longer crashes when that occurs. So that allows for safely removing the workaround and make everyone’s life easier.
I don’t know how common unplugging reinserting USB devices is with ZWave/ZigBee? But I don’t see that many community threads about crashing JVMs for other bindings. Those would have the same issue but don’t use such a workaround. Since they don’t use such a workaround, non-standard ports can be used without adding them to EXTRA_JAVA_OPTS.