Apparently the Zwave binding blocks the / dev / ttyUSB0 port in Combination with a CC2652RB Zigbee2mqtt Dongle

Hello Guys,

I`m using the Zwave-Binding since 2 years and it´s great. Also i´m using Zigbee2mqtt (zigbee2mqtt.io) with a CC2531 Coordinator. Both are running great.

SOme Days ago i bought a new CC2652RB Coordinator (more Power, more controllable Zigbee-Devices), see https://slae.sh/projects/cc2652/.

The old CC2531-Coordinator come´s up on a /dev/ttyACM*-Port.
The same applies for my Aeotec Z-Stick. With appropriate UDEV-Rules I pointed the both Controllers to:

  • CC2531 (Zigbee2mqtt-Stick) --> /dev/ttyUSB-z2m
  • Aeotec- Zwave-Stick --> /dev/ttyUSB1

With this Configuration all both networks are working. Now i decided to change the CC2531 to the CC2652RB Stick. With it´s Onboard Bootloader (UART) this Stick now connects by default to the serial-Port /dev/ttyUSB0.

Now the Problem comes up. if the Zwave-Binding is active, although the Zwave-Stick is mapped to /dev/ttyUSB1, this Binding seems to Block the /dev/ttyUSB0 - Port further. Even if I Map the CC2652RB to another Port, for example /dev/ttyUSB33 via UDev-Rules and “Java-Opts” I can´t get Zigbee2mqtt running. Only if I stop the Zwave Binding it is usable. So I think the Zwave-Binding blocks in a certain way the Access on Port /dev/ttyUSB0.

I Hope some can help me.

Best regards

  • OH2 Version: 2.5.7
  • Binding Version: 2.5.7

Welcome!

That appears to be a serial binding issue. You can set tome EXTRA_JAVA_OPTS that may help. Details are in the documentation.

Hi @Bruce_Osborne,

first, thx for the fast reply.
I’ve forgotten to write down, that I already added the Extra Java-Opts as shown below (Excerpt from /etc/default/openhab2):

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB1:/dev/ttyUSB33:/dev/ttyUSB-z2m"

further below my additional “99-usb-serial.rules” (/etc/udev/rules.d):

SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyUSB1", GROUP="dialout", MODE="0666"

SUBSYSTEM==“tty”, ATTRS{idVendor}==“0451”, ATTRS{idProduct}==“16a8”, SYMLINK+=“ttyUSB-z2m”, GROUP=“dialout”, MODE=“0666”
SUBSYSTEM==“tty”, ATTRS{idVendor}==“10c4”, ATTRS{idProduct}==“ea60”, SYMLINK+=“ttyUSB33”, GROUP=“dialout”, MODE=“0666”

same behavior. Port “/dev/ttyUSB0” is (from me) not used at any single point. The CC2652RB stops working after some Seconds when started zigbee2mqtt in docker Container (Testsystem, before i tested this with bare-metal, but i don want to repair all my devices after every unsuccesful attempt) with running Zwave-binding. I see this also on the Stick (debug-firmware from SLaesh and Koenkk) when the blue LED turns off. No Pairing with other Zigbee-Devices, and no datacommunication is possible. As long as the blue LED is “ON”, Pairing is possible (some seconds). If Zwave-Binding is disable (Karaf Console) Zigbee2mqtt works as expected.

Best regards

It could be a zigbee2mqtt issue then. Why not use the zigbee binding without the mqtt complexity added?

I think it’s a question of philosophy. I use mqtt for several other things and behaviours. And my Network is now completely configured, it takes a lot of time to make now big changes, and i don want that. It worked as I have already written very good before. I only need a solution for the above written Problem :slight_smile: and hope to find that here.

1 Like

Is there some one (maybe developers of the Zwave binding) who has an idea what causes the Problem? I’ve teste up and down. Every time i start/run the Zwave binding, the Port /dev/ttyUSB0 seems to get a reset /
Or rather gets blocked

That might be an issue with serial on OH. the Z-Wave binding does not directly control the port, as far as I know.

Ok. Do you think it deoends from serial binding?
By the way, is there a possibillity to give exclusive rights on specific Port access to only specific Services on linux/raspbian?

No - it is not linked to the serial binding. However there is an intermediate library that provides a proxy layer. The binding communicates through this interface to the serial library.

The binding should only be accessing a single port - I’ve not seen any logs here, but I assume the logs show that is the case? If so, maybe there’s a problem in the way the serial driver works - I do seem to recall something about this in the past - I think it was to do with the way the driver enumerated ports.

1 Like

Sorry, I think I got confused between the serial binding & the serial library in the core.

1 Like

Oh sorry, I´ve forgotten to post the log. This weekend I´m not @home. So i will post the Zwave-log at start of the next week, if you can see anything in it at all.

Thank you so far, waiting for the things to come up :smiley:

1 Like

Good day,

i´ve made a short DEBUG log of the ZWAVE-Binding regarding the problem discussed above. See attachement.

   2020-08-11 20:48:14.919 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - Creating ZWave discovery service for zwave:serial_zstick:dc10b468 with scan time of 60
2020-08-11 20:48:14.921 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - ZWave discovery: Active zwave:serial_zstick:dc10b468
2020-08-11 20:48:14.921 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2020-08-11 20:48:15.028 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2020-08-11 20:48:15.029 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:dc10b468.
2020-08-11 20:48:15.092 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node8.
2020-08-11 20:48:15.115 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Channel zwave:device:dc10b468:node8:sensor_temperature linked - polling started.
2020-08-11 20:48:15.117 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Channel zwave:device:dc10b468:node8:thermostat_mode linked - polling started.
2020-08-11 20:48:15.120 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Channel zwave:device:dc10b468:node8:thermostat_state linked - polling started.
2020-08-11 20:48:15.121 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Channel zwave:device:dc10b468:node8:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.130 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node4.
2020-08-11 20:48:15.132 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node3.
2020-08-11 20:48:15.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node2.
2020-08-11 20:48:15.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:dc10b468:node4:sensor_temperature linked - polling started.
2020-08-11 20:48:15.140 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:dc10b468:node4:thermostat_mode linked - polling started.
2020-08-11 20:48:15.141 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:dc10b468:node4:thermostat_state linked - polling started.
2020-08-11 20:48:15.141 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Channel zwave:device:dc10b468:node4:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.145 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node7.
2020-08-11 20:48:15.145 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Channel zwave:device:dc10b468:node3:sensor_temperature linked - polling started.
2020-08-11 20:48:15.145 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Channel zwave:device:dc10b468:node3:thermostat_state linked - polling started.
2020-08-11 20:48:15.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node24.
2020-08-11 20:48:15.154 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Channel zwave:device:dc10b468:node3:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Channel zwave:device:dc10b468:node3:thermostat_mode linked - polling started.
2020-08-11 20:48:15.156 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Channel zwave:device:dc10b468:node2:sensor_temperature linked - polling started.
2020-08-11 20:48:15.157 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Channel zwave:device:dc10b468:node2:thermostat_mode linked - polling started.
2020-08-11 20:48:15.166 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Channel zwave:device:dc10b468:node2:thermostat_state linked - polling started.
2020-08-11 20:48:15.166 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Channel zwave:device:dc10b468:node2:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.172 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Channel zwave:device:dc10b468:node7:sensor_temperature linked - polling started.
2020-08-11 20:48:15.172 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Channel zwave:device:dc10b468:node7:thermostat_mode linked - polling started.
2020-08-11 20:48:15.173 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Channel zwave:device:dc10b468:node7:thermostat_state linked - polling started.
2020-08-11 20:48:15.174 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Channel zwave:device:dc10b468:node7:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.180 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node6.
2020-08-11 20:48:15.182 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Channel zwave:device:dc10b468:node24:blinds_control linked - polling started.
2020-08-11 20:48:15.183 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Channel zwave:device:dc10b468:node24:meter_watts linked - polling started.
2020-08-11 20:48:15.202 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Channel zwave:device:dc10b468:node6:sensor_temperature linked - polling started.
2020-08-11 20:48:15.202 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Channel zwave:device:dc10b468:node6:thermostat_mode linked - polling started.
2020-08-11 20:48:15.203 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Channel zwave:device:dc10b468:node6:thermostat_state linked - polling started.
2020-08-11 20:48:15.203 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Channel zwave:device:dc10b468:node6:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.209 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node11.
2020-08-11 20:48:15.215 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Channel zwave:device:dc10b468:node11:blinds_control linked - polling started.
2020-08-11 20:48:15.215 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Channel zwave:device:dc10b468:node11:meter_watts linked - polling started.
2020-08-11 20:48:15.217 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node10.
2020-08-11 20:48:15.218 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node9.
2020-08-11 20:48:15.242 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Channel zwave:device:dc10b468:node10:sensor_temperature linked - polling started.
2020-08-11 20:48:15.243 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Channel zwave:device:dc10b468:node10:thermostat_mode linked - polling started.
2020-08-11 20:48:15.244 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Channel zwave:device:dc10b468:node10:thermostat_state linked - polling started.
2020-08-11 20:48:15.244 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Channel zwave:device:dc10b468:node10:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.246 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node12.
2020-08-11 20:48:15.249 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Channel zwave:device:dc10b468:node9:sensor_temperature linked - polling started.
2020-08-11 20:48:15.250 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Channel zwave:device:dc10b468:node9:thermostat_mode linked - polling started.
2020-08-11 20:48:15.251 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Channel zwave:device:dc10b468:node9:thermostat_state linked - polling started.
2020-08-11 20:48:15.251 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Channel zwave:device:dc10b468:node9:thermostat_setpoint_heating linked - polling started.
2020-08-11 20:48:15.254 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Channel zwave:device:dc10b468:node12:blinds_control linked - polling started.
2020-08-11 20:48:15.254 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Channel zwave:device:dc10b468:node12:meter_watts linked - polling started.
2020-08-11 20:48:15.262 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node13.
2020-08-11 20:48:15.266 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Channel zwave:device:dc10b468:node13:blinds_control linked - polling started.
2020-08-11 20:48:15.268 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Channel zwave:device:dc10b468:node13:meter_watts linked - polling started.
2020-08-11 20:48:15.289 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node14.
2020-08-11 20:48:15.294 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Channel zwave:device:dc10b468:node14:blinds_control linked - polling started.
2020-08-11 20:48:15.295 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Channel zwave:device:dc10b468:node14:meter_watts linked - polling started.
2020-08-11 20:48:15.304 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node23.
2020-08-11 20:48:15.308 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Channel zwave:device:dc10b468:node23:blinds_control linked - polling started.
2020-08-11 20:48:15.309 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Channel zwave:device:dc10b468:node23:meter_watts linked - polling started.
2020-08-11 20:48:15.315 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node22.
2020-08-11 20:48:15.315 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node21.
2020-08-11 20:48:15.322 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Channel zwave:device:dc10b468:node22:blinds_control linked - polling started.
2020-08-11 20:48:15.322 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Channel zwave:device:dc10b468:node22:meter_watts linked - polling started.
2020-08-11 20:48:15.326 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Channel zwave:device:dc10b468:node21:blinds_control linked - polling started.
2020-08-11 20:48:15.326 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Channel zwave:device:dc10b468:node21:meter_watts linked - polling started.
2020-08-11 20:48:15.350 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node5.
2020-08-11 20:48:15.353 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Channel zwave:device:dc10b468:node5:scene_number linked - polling started.
2020-08-11 20:48:15.355 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Channel zwave:device:dc10b468:node5:battery-level linked - polling started.
2020-08-11 20:48:15.355 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Channel zwave:device:dc10b468:node5:switch_startstop1 linked - polling started.
2020-08-11 20:48:15.355 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Channel zwave:device:dc10b468:node5:switch_startstop2 linked - polling started.
2020-08-11 20:48:15.356 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Channel zwave:device:dc10b468:node5:switch_startstop3 linked - polling started.
2020-08-11 20:48:15.356 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Channel zwave:device:dc10b468:node5:switch_startstop4 linked - polling started.
2020-08-11 20:48:15.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node34.
2020-08-11 20:48:15.362 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 34: Channel zwave:device:dc10b468:node34:blinds_control linked - polling started.
2020-08-11 20:48:15.362 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 34: Channel zwave:device:dc10b468:node34:meter_watts linked - polling started.
2020-08-11 20:48:15.378 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node32.
2020-08-11 20:48:15.379 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node35.
2020-08-11 20:48:15.387 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Channel zwave:device:dc10b468:node32:blinds_control linked - polling started.
2020-08-11 20:48:15.388 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Channel zwave:device:dc10b468:node32:meter_watts linked - polling started.
2020-08-11 20:48:15.400 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 35: Channel zwave:device:dc10b468:node35:blinds_control linked - polling started.
2020-08-11 20:48:15.401 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 35: Channel zwave:device:dc10b468:node35:meter_watts linked - polling started.
2020-08-11 20:48:15.409 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node33.
2020-08-11 20:48:15.409 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node37.
2020-08-11 20:48:15.411 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node36.
2020-08-11 20:48:15.415 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Channel zwave:device:dc10b468:node33:blinds_control linked - polling started.
2020-08-11 20:48:15.416 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Channel zwave:device:dc10b468:node33:meter_watts linked - polling started.
2020-08-11 20:48:15.420 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 36: Channel zwave:device:dc10b468:node36:blinds_control linked - polling started.
2020-08-11 20:48:15.421 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 36: Channel zwave:device:dc10b468:node36:meter_watts linked - polling started.
2020-08-11 20:48:15.440 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node16.
2020-08-11 20:48:15.452 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Channel zwave:device:dc10b468:node16:sensor_binary linked - polling started.
2020-08-11 20:48:15.452 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Channel zwave:device:dc10b468:node16:alarm_smoke linked - polling started.
2020-08-11 20:48:15.453 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Channel zwave:device:dc10b468:node16:battery-level linked - polling started.
2020-08-11 20:48:15.460 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node19.
2020-08-11 20:48:15.465 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Channel zwave:device:dc10b468:node19:sensor_binary linked - polling started.
2020-08-11 20:48:15.465 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Channel zwave:device:dc10b468:node19:alarm_smoke linked - polling started.
2020-08-11 20:48:15.468 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Channel zwave:device:dc10b468:node19:battery-level linked - polling started.
2020-08-11 20:48:15.476 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node15.
2020-08-11 20:48:15.479 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Channel zwave:device:dc10b468:node15:sensor_binary linked - polling started.
2020-08-11 20:48:15.480 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Channel zwave:device:dc10b468:node15:alarm_smoke linked - polling started.
2020-08-11 20:48:15.480 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Channel zwave:device:dc10b468:node15:battery-level linked - polling started.
2020-08-11 20:48:15.486 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node18.
2020-08-11 20:48:15.488 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node17.
2020-08-11 20:48:15.489 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Channel zwave:device:dc10b468:node18:sensor_binary linked - polling started.
2020-08-11 20:48:15.489 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Channel zwave:device:dc10b468:node18:alarm_smoke linked - polling started.
2020-08-11 20:48:15.489 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Channel zwave:device:dc10b468:node18:battery-level linked - polling started.
2020-08-11 20:48:15.492 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Channel zwave:device:dc10b468:node17:sensor_binary linked - polling started.
2020-08-11 20:48:15.492 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Channel zwave:device:dc10b468:node17:alarm_smoke linked - polling started.
2020-08-11 20:48:15.492 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Channel zwave:device:dc10b468:node17:battery-level linked - polling started.
2020-08-11 20:48:15.494 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:dc10b468:node20.
2020-08-11 20:48:15.501 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Channel zwave:device:dc10b468:node20:sensor_binary linked - polling started.
2020-08-11 20:48:15.501 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Channel zwave:device:dc10b468:node20:alarm_smoke linked - polling started.
2020-08-11 20:48:15.501 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Channel zwave:device:dc10b468:node20:battery-level linked - polling started.
2020-08-11 20:48:20.047 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyUSB1'
2020-08-11 20:48:20.057 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Starting receive thread
2020-08-11 20:48:20.058 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2020-08-11 20:48:20.059 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Starting ZWave thread: Receive
2020-08-11 20:48:20.059 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initialising ZWave controller
2020-08-11 20:48:20.061 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2020-08-11 20:48:20.061 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2020-08-11 20:48:20.062 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2020-08-11 20:48:20.063 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2020-08-11 20:48:20.064 [DEBUG] [ve.internal.protocol.ZWaveController] - Event listener added.
2020-08-11 20:48:20.068 [DEBUG] [ve.internal.protocol.ZWaveController] - Event listener added.
2020-08-11 20:48:20.069 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Scheduling network mesh heal for 5 hours time.
2020-08-11 20:48:23.069 [DEBUG] [.ZWaveController$InitializeDelayTask] - Initialising network

Before that, I stoped the Zwave-Binding.
@ 20:48:14 I started both, the Zwave-Binding and the Docker-Container (the Zigbee CC2652RB-Stick Pointing now to /dev/ttyUSB0).
at about 20:48:20 the CC2652RB-Sticks gots a reset (only visible for me by looking at the Sticks blue and orange LED´s, as I write above the blue LED goes off, It´s a DEbug Firmware on the Stick, the developer of the Stick told me, If the blue LED turns off, the Sticks gots a reset). At this point I thought it has to do with the Zwave-Binding. This behaviour only happens, if I start the Zwave-Binding.

I hope you could help me further.
Best regards

Sorry for butting in …

i don’t think this

to be a good idea. Creating a symlink to a possibly existing and used port is a nogo from my point of view. So try an other name like ttyUSB-C2552 even if you think you don’t use ttyUSB1 currently.

What does ls -l /dev/ttyUSB* /dev/ttyA* show at your site?

This is, what it shows here:

[22:19:49] openhabian@openHABianPi:~$ ls -l /dev/ttyA* /dev/ttyUSB*
crw-rw---- 1 root dialout 204, 64 Aug 11 22:19 /dev/ttyAMA0
crw-rw---- 1 root dialout 188,  0 Aug 11 22:20 /dev/ttyUSB0
crw-rw---- 1 root dialout 188,  1 Aug 10 05:57 /dev/ttyUSB1
lrwxrwxrwx 1 root root          7 Jun 18 21:01 /dev/ttyUSB-ETRX3 -> ttyUSB0
lrwxrwxrwx 1 root root          7 Jun 18 21:01 /dev/ttyUSB-RFXTRX0 -> ttyUSB1

This means for my site:

  • ttyAMA0 is not aliased (used for razberry)
  • ttyUSB0 is aliased to ttyUSB-ETRX3 (and the alias is used by Zigbee Telegesis)
  • ttyUSB1 is aliased to ttyUSB-RFXTRX0 (and the alias is used by a RFXtrx)

Maybe your listing gives a hint

Did you include /dev/ttyUSB0 in EXTRA_JAVA_OPTS?

2 Likes

Hi yab,

the port /dev/ttyUSB1 you quoted first is used for my Aeotec-Zwave-Stick (Gen5). And is working with this rule so far. I couldn´t use other symlinks, e.g. /dev/zwave because in Paper-UI the Aeotec-Stick is only shown if not symlinked (/dev/ttyACx) or symlinked to a port like /dev/ttyUSBx. So this is working in this constellation for a long time.

I originally linked the CC2652RB to /dev/ttyUSB33 (this port is definitely not used). Currently I have adjusted the udev rules again (see below):

SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", SYMLINK+="ttyUSB-z2m", GROUP="dialout", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyUSB1", GROUP="dialout", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyUSB-CC2652RB", GROUP="dialout", MODE="0666"

So “ttyUSB1” is my Zwave-Stick, “ttyUSB-z2m” is my actually working CC2531-Zigbee2mqtt-Stick and “ttyUSB-CC2652RB” is the Link to my CC2652RB-Zigbee2mqtt-Stick.

See below the active “EXTRA_JAVA_Opts”:

#########################
## JAVA OPTIONS
## Additional options for the JAVA_OPTS environment variable.
## These will be appended to the execution of the openHAB Java runtime in front of all other options.
##
## A couple of independent examples:
##   EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0"
EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyACM0:/dev/ttyACM1"
##   EXTRA_JAVA_OPTS="-Djna.library.path=/lib/arm-linux-gnueabihf/ -Duser.timezone=Europe/Berlin -Dgnu.io.rxtx.SerialPorts=/dev/ttyS0"

EXTRA_JAVA_OPTS="-Xms192m -Xmx320m"

And this is the Output of ls -l /dev/ttyA* /dev/ttyUSB*

[13:29:46] root@openhab:~# ls -l /dev/ttyA* /dev/ttyUSB*
crw-rw-rw- 1 root dialout 166,  0 Aug 12 13:29 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166,  1 Aug 12 13:29 /dev/ttyACM1
crw-rw---- 1 root dialout 204, 64 Aug 12 13:29 /dev/ttyAMA0
crw-rw-rw- 1 root dialout 188,  0 Aug 12 13:29 /dev/ttyUSB0
lrwxrwxrwx 1 root root          7 Aug 12 13:29 /dev/ttyUSB1 -> ttyACM1
lrwxrwxrwx 1 root root          7 Aug 12 13:29 /dev/ttyUSB-CC2652RB -> ttyUSB0
lrwxrwxrwx 1 root root          7 Aug 12 13:29 /dev/ttyUSB-z2m -> ttyACM0
[13:29:48] root@openhab:~#

Best regards

Do you realize that this loks a bit strange and you made it look like this?

What i’d do:

1) go an rename your symlink entries in /etc/udev/rules.d/99-usb-serial.rules so they don’t interfere with standard port naming to something meaningful like:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", SYMLINK+="ttyACM-CC2531 ", GROUP="dialout", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyACM-AGen5", GROUP="dialout", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyUSB-CC2652RB", GROUP="dialout", MODE="0666"

The names doesn’t really matter. But i like to have them clearly showing what they are good for. And they should not interfere with standard name scheme.
The aliases do not create new ports. They are just - well - aliases, which are linked to an existing port. They will help you assinging the correct port in openHAB even if you are going to plugout/-in while selecting an other hardwareport.

2) go and change EXTRA_JAVA_OPTS in /etc/default/openhab2 to your needs:

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB-CC2652RB :/dev/tty:ACM0:/dev/ttyACM1:/dev/ttyACM-AGen5:/dev/ttyACM-CC2531"

Add your /dev/ttyAMA0 if that is something that should be usable by openHAB.

EXTRA_JAVA_OPTS “exposes” the named ports to openHAB. So in PaperUi f.e. you will see the ports you defined in this variable (if all devices are plugged in) and may assign them to your device.

In your /etc/default/openhab2 you override EXTRA_JAVA_OPTS with this line:

EXTRA_JAVA_OPTS="-Xms192m -Xmx320m"

If you need this setting too, go for

EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB-CC2652RB :/dev/tty:ACM0:/dev/ttyACM1:/dev/ttyACM-AGen5:/dev/ttyACM-CC2531:/"

You do not have to expose USB0, ACM0 and ACM1 because you are going to use the aliases. I’m doing it the way shown however.

3) make sure all devices are plugged in

4) reread rules and restart your serial ports

sudo udevadm control --reload-rules && udevadm trigger

5) restart openHAB

sudo systemctl restart openhab2.service

(or reboot your box to get 3) + 4) done)

6) assign the correct ports to the controllers using PaperUi f.e.

.
Hopefully all three devices will work. Let’s have a look.

2 Likes

@yab first of all thx for the good advice. i had´nt seen the overwriting of the EXTRA_JAVA_Opts :sweat_smile:
At least I could select the Zwave Stick with the corresponding Symlink at PAPERUI, that is nice.

My ls -l /dev/ttyACM* /dev/ttyUSB* shows now:

[21:28:41] root@openhab:~# ls -l /dev/ttyACM* /dev/ttyUSB*
crw-rw-rw- 1 root dialout 166, 0 Aug 12 21:28 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 1 Aug 12 21:28 /dev/ttyACM1
lrwxrwxrwx 1 root root         7 Aug 12 21:28 /dev/ttyACM-AGen5 -> ttyACM1
lrwxrwxrwx 1 root root         7 Aug 12 21:28 /dev/ttyACM-CC2531 -> ttyACM0
crw-rw-rw- 1 root dialout 188, 0 Aug 12 21:28 /dev/ttyUSB0
lrwxrwxrwx 1 root root         7 Aug 12 21:28 /dev/ttyUSB-CC2652RB -> ttyUSB0
[21:29:15] root@openhab:~#

accordingly, I had previously changed my udev rules to this mentioned from you:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", SYMLINK+="ttyACM-CC2531", GROUP="dialout", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyACM-AGen5", GROUP="dialout", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyUSB-CC2652RB", GROUP="dialout", MODE="0666"

and the EXTRA_JAVA_OPTS to:

#########################
## JAVA OPTIONS
## Additional options for the JAVA_OPTS environment variable.
## These will be appended to the execution of the openHAB Java runtime in front of all other options.
##
## A couple of independent examples:
##   EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0"
##   EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB-CC2652RB:/dev/ttyACM0:/dev/ttyACM1:/dev/ttyACM-AGen5:/dev/ttyACM-CC2531"
##   EXTRA_JAVA_OPTS="-Djna.library.path=/lib/arm-linux-gnueabihf/ -Duser.timezone=Europe/Berlin -Dgnu.io.rxtx.SerialPorts=/dev/ttyS0"

EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB-CC2652RB:/dev/ttyACM0:/dev/ttyACM1:/dev/ttyACM-AGen5:/dev/ttyACM-CC2531:/"

Unfortunately, the result remained the same for the CC2652RB. To be sure, I stopped the Zwave-Binding again, started the Docker-Container and Zigbee2mqtt was running. I could pair devices and got data from them for about 15 Minutes until i stopped the Docker Container.

The problem persists.

I’m a little at a loss

<\grmbl> After reading your posts again and again, i feared that. Your config was looking strange - but there was no “absolute” error.

Did i get right, what you are aiming for and how you do it? That’s what i got:

  • you are using AGen5 + CC2531 in parallel sucessfully since longer without issues (this is also true using your docker image, isn’t it?)
  • you want to replace your CC2531 by CC2652RB now
  • CC2531 and CC2652RB are both plugged in but only one is used by openHAB by zigbee2mqtt
  • starting openHAB with AGen5 → z-wave and CC2652RB → zigbee2mqtt everything seems to be allright but after some seconds zigbee2mqtt stops working / there’s no more communication between CC2652RB and openHAB
  • starting openHAB with z-wave disabled it runs fine with CC2652RB → zigbee2mqtt

Not knowing anything about docker, not to much about bindings and not using zigbee2mqtt i think i can’t be helpful beyond this point. Sorry for taking your time just to do a bit of a cleanup.

Maybe chris can help you, as he seems to “recall something”. Or the responsible for zigbee2mqtt.
You should create another log showing more than the above. I don’t know how to, but i’d expect you may set zigbee2mqtt to DEBUG mode also some way. It might be mentioned in the docs.
Maybe you can see where the communication with CC2652RB stops.

It certainly is!

Set log_level: debug in the advanced section of your configuration.yaml.

2 Likes

I had already set the log level of Zigbee2mqtt set to log_level: debug. The problem is, at the time when the stick loses its communication, there is no entry at the output of the log. Almost nothing. If i then stop the Zigbee2mqtt Docker I end up with a error like “couldn´t stop zigbb2mqtt”. This happens when the blue LED of the CC2652RB-Stick turns of and i stop the docker. see below the log:

    [08:44:59] root@openhab:/opt/z2m_docker# ./normal_start.sh
Using '/app/data' as data directory

> zigbee2mqtt@1.14.2 start /app
> node index.js

zigbee2mqtt:info  2020-08-13 08:45:04: Logging to console and directory: '/app/data/log/2020-08-13.08-45-04' filename: log.txt
zigbee2mqtt:debug 2020-08-13 08:45:04: Removing old log directory '/app/data/log/2020-08-12.20-50-41'
zigbee2mqtt:debug 2020-08-13 08:45:05: Can't load state from file /app/data/state.json (doesn't exist)
zigbee2mqtt:info  2020-08-13 08:45:05: Starting zigbee2mqtt version 1.14.2 (commit #faaf3e4)
zigbee2mqtt:info  2020-08-13 08:45:05: Starting zigbee-herdsman...
zigbee2mqtt:debug 2020-08-13 08:45:05: Using zigbee-herdsman with settings: '{"network":{"panID":6757,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[11],"networkKey":"HIDDEN"},"databasePath":"/app/data/database.db","databaseBackupPath":"/app/data/database.db.backup","backupPath":"/app/data/coordinator_backup.json","serialPort":{"path":"/dev/ttyUSB-CC2652RB"},"adapter":{"concurrent":null}}'
zigbee2mqtt:info  2020-08-13 08:45:16: zigbee-herdsman started
zigbee2mqtt:info  2020-08-13 08:45:16: Coordinator firmware version: '{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20200805}}'
zigbee2mqtt:debug 2020-08-13 08:45:16: Zigbee network parameters: {"panID":6757,"extendedPanID":"0xdddddddddddddddd","channel":11}
zigbee2mqtt:info  2020-08-13 08:45:16: Currently 0 devices are joined:
zigbee2mqtt:warn  2020-08-13 08:45:16: `permit_join` set to  `true` in configuration.yaml.
zigbee2mqtt:warn  2020-08-13 08:45:16: Allowing new devices to join.
zigbee2mqtt:warn  2020-08-13 08:45:16: Set `permit_join` to `false` once you joined all devices.
zigbee2mqtt:info  2020-08-13 08:45:16: Zigbee: allowing new devices to join.
zigbee2mqtt:info  2020-08-13 08:45:16: Connecting to MQTT server at mqtt://192.168.1.35:1883
zigbee2mqtt:info  2020-08-13 08:45:16: Connected to MQTT server
zigbee2mqtt:info  2020-08-13 08:45:16: MQTT publish: topic 'zigbee2mqtt_test/bridge/state', payload 'online'
zigbee2mqtt:info  2020-08-13 08:45:16: MQTT publish: topic 'zigbee2mqtt_test/bridge/config', payload '{"version":"1.14.2","commit":"faaf3e4","coordinator":{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20200805}},"log_level":"debug","permit_join":true}'
^Czigbee2mqtt:debug 2020-08-13 08:45:47: Saving state to file /app/data/state.json
zigbee2mqtt:info  2020-08-13 08:45:47: MQTT publish: topic 'zigbee2mqtt_test/bridge/state', payload 'offline'
zigbee2mqtt:info  2020-08-13 08:45:47: Disconnecting from MQTT server
zigbee2mqtt:error 2020-08-13 08:45:53: Failed to stop zigbee
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zigbee2mqtt@1.14.2 start: `node index.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the zigbee2mqtt@1.14.2 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-08-13T06_45_53_294Z-debug.log
[08:45:53] root@openhab:/opt/z2m_docker#

The Blue LED turns off (stick gets reset) at about 08:45:20 - 08:45:25. The Last Log-entry before this happens is:
MQTT publish: topic 'zigbee2mqtt_test/bridge/config', payload '{"version":"1.14.2","commit":"faaf3e4","coordinator":{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20200805}},"log_level":"debug","permit_join":true}'

when the problem comes up, no additional logging is seen. When the blue LED was off, i stoppt the docker-container (at 08:45:47) and got an error (see above).

The behaviour of the Stick, if i stop the Container just before the blue LED turns of is seen in the log below:

> zigbee2mqtt@1.14.2 start /app
> node index.js

zigbee2mqtt:info  2020-08-13 08:56:12: Logging to console and directory: '/app/data/log/2020-08-13.08-56-12' filename: log.txt
zigbee2mqtt:debug 2020-08-13 08:56:12: Removing old log directory '/app/data/log/2020-08-12.21-05-26'
zigbee2mqtt:debug 2020-08-13 08:56:13: Loaded state from file /app/data/state.json
zigbee2mqtt:info  2020-08-13 08:56:13: Starting zigbee2mqtt version 1.14.2 (commit #faaf3e4)
zigbee2mqtt:info  2020-08-13 08:56:13: Starting zigbee-herdsman...
zigbee2mqtt:debug 2020-08-13 08:56:13: Using zigbee-herdsman with settings: '{"network":{"panID":6757,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[11],"networkKey":"HIDDEN"},"databasePath":"/app/data/database.db","databaseBackupPath":"/app/data/database.db.backup","backupPath":"/app/data/coordinator_backup.json","serialPort":{"path":"/dev/ttyUSB-CC2652RB"},"adapter":{"concurrent":null}}'
zigbee2mqtt:info  2020-08-13 08:56:23: zigbee-herdsman started
zigbee2mqtt:info  2020-08-13 08:56:23: Coordinator firmware version: '{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20200805}}'
zigbee2mqtt:debug 2020-08-13 08:56:23: Zigbee network parameters: {"panID":6757,"extendedPanID":"0xdddddddddddddddd","channel":11}
zigbee2mqtt:info  2020-08-13 08:56:23: Currently 0 devices are joined:
zigbee2mqtt:warn  2020-08-13 08:56:23: `permit_join` set to  `true` in configuration.yaml.
zigbee2mqtt:warn  2020-08-13 08:56:23: Allowing new devices to join.
zigbee2mqtt:warn  2020-08-13 08:56:23: Set `permit_join` to `false` once you joined all devices.
zigbee2mqtt:info  2020-08-13 08:56:23: Zigbee: allowing new devices to join.
zigbee2mqtt:info  2020-08-13 08:56:23: Connecting to MQTT server at mqtt://192.168.1.35:1883
zigbee2mqtt:info  2020-08-13 08:56:23: Connected to MQTT server
zigbee2mqtt:info  2020-08-13 08:56:23: MQTT publish: topic 'zigbee2mqtt_test/bridge/state', payload 'online'
zigbee2mqtt:info  2020-08-13 08:56:23: MQTT publish: topic 'zigbee2mqtt_test/bridge/config', payload '{"version":"1.14.2","commit":"faaf3e4","coordinator":{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20200805}},"log_level":"debug","permit_join":true}'
^Czigbee2mqtt:debug 2020-08-13 08:56:26: Saving state to file /app/data/state.json
zigbee2mqtt:info  2020-08-13 08:56:26: MQTT publish: topic 'zigbee2mqtt_test/bridge/state', payload 'offline'
zigbee2mqtt:info  2020-08-13 08:56:26: Disconnecting from MQTT server
zigbee2mqtt:info  2020-08-13 08:56:26: zigbee-herdsman stopped
[08:56:27] root@openhab:/opt/z2m_docker#

There is no error to be seen, as the stick doesn´t gets a reset.

Here is my “configuration.yaml” for the z2m in docker (CC2652RB):

homeassistant: false
permit_join: true
mqtt:
  base_topic: zigbee2mqtt_test
  server: 'mqtt://192.168.1.35:1883'
  user: openhabian
  password: '**********'
serial:
  port: /dev/ttyUSB-CC2652RB
advanced:
  network_key:
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
    - *
  pan_id: 6757
  log_level: debug

And for comparison from bare-metal z2m (CC2531):

homeassistant: false
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://192.168.1.35:1883'
  user: openhabian
  password: '************'
  include_device_information: false
serial:
  port: /dev/ttyACM-CC2531
  disable_led: true
devices: devices.yaml
advanced:
  channel: 25
  network_key: [*, *, *, *, *, *, *, *, *, *, *, *, *, *, *, *]
  pan_id: 0x1a66
 #availability_timeout: 60
 #availability_whitelist: ['LA_WZ_r','LA_WZ_l']

Did i get right, what you are aiming for and how you do it? That’s what i got:

  • you are using AGen5 + CC2531 in parallel sucessfully since longer without issues (this is also true using your docker image, isn’t it?)
  • you want to replace your CC2531 by CC2652RB now
  • CC2531 and CC2652RB are both plugged in but only one is used by openHAB by zigbee2mqtt
  • starting openHAB with AGen5 → z-wave and CC2652RB → zigbee2mqtt everything seems to be allright but after some seconds zigbee2mqtt stops working / there’s no more communication between CC2652RB and openHAB
  • starting openHAB with z-wave disabled it runs fine with CC2652RB → zigbee2mqtt

completely correct! Except for the point that z2m with the 2531 and z2m-docker with the 2652RB run as parrallel instances (If I stop zwave-binding…, otherwise only the bare-metal z2m with CC2531 runs).
But running two parallel instances of z2m is no problem.