Yeah it was mainly just to give you an status. Perhaps it could be usefull information.
Yes my EXTRA_JAVA_OPTS has all three ports, mysensors ttyUSB0, zwave ttyACM0, and zigbee ttyACM1. I now have zwave working with the zigbee installed, however I still only get the error that the serial port does not exist for the zigbee. Everything else works, kinda sucks. 
In your EXTRA_JAVA_OPTS, you need to use the names you created in your udev rules. These need to be the full path too (/dev/ttyUSB_cc2531, etc.). You wouldn’t need the EXTRA_JAVA_OPTS if you used a standard Linux naming convention (ref: check the note at the bottom).
Here are my udev rules for an HUSBZB-1 (no EXTRA_JAVA_OPTS required)…
# cat /etc/udev/rules.d/99-server.rules
KERNEL=="ttyUSB[0-9]*", ATTRS{interface}=="HubZ Z-Wave Com Port", SYMLINK+="ttyUSB-5", GROUP="dialout", MODE="0666"
KERNEL=="ttyUSB[0-9]*", ATTRS{interface}=="HubZ ZigBee Com Port", SYMLINK+="ttyUSB-55", GROUP="dialout", MODE="0666"
So here are my settings and my logs:
/etc/default/openhab2
EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyACM1:/dev/ttyUSB0:/dev/ttyUSB_cc2531"
udev rule
SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", ATTRS{serial}=="__0X00124B000E896C97", SYMLINK+="ttyUSB_cc2531"
gundark@doghouse:/var/lib/openhab2/jsondb$ ls -la /dev/
drwxr-xr-x 22 root root 4400 Aug 12 14:12 .
drwxr-xr-x 24 root root 4096 Aug 7 06:04 ..
crw-rw---- 1 root dialout 166, 0 Aug 12 14:08 ttyACM0
crw-rw---- 1 root dialout 166, 1 Aug 12 14:12 ttyACM1
crw-rw---- 1 root dialout 188, 0 Aug 12 14:14 ttyUSB0
lrwxrwxrwx 1 root root 7 Aug 12 14:12 ttyUSB_cc2531 -> ttyACM1
[del.core.internal.ModelRepositoryImpl] - Loading model 'home.rules'
[del.core.internal.ModelRepositoryImpl] - Loading model 'time.rules'
[del.core.internal.ModelRepositoryImpl] - Loading model 'guest.sitemap'
[del.core.internal.ModelRepositoryImpl] - Loading model 'home.sitemap'
[del.core.internal.ModelRepositoryImpl] - Loading model 'seanphone.sitemap'
[del.core.internal.ModelRepositoryImpl] - Loading model 'master.sitemap'
[del.core.internal.ModelRepositoryImpl] - Loading model 'home.things'
12.733[org.openhab.binding.mysensors ] - BundleEvent STARTING - org.openhab.binding.mysensors
12.746[org.openhab.binding.mysensors ] - BundleEvent STARTED - org.openhab.binding.mysensors
12.759[org.openhab.binding.mysensors ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={service.id=323, service.bundleid=196, service.scope=bundle, component.name=org.openhab.binding.mysensors.factory.MySensorsHandlerFactory, component.id=207} - org.openhab.binding.mysensors
12.971[ome.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from UNINITIALIZED to INITIALIZING
12.972[ensors.handler.MySensorsBridgeHandler] - Initialization of the MySensors bridge
12.978[ome.event.ThingStatusInfoChangedEvent] - 'weatherunderground:weather:denver' changed from UNINITIALIZED to INITIALIZING
12.986 [WARN ] [e.core.thing.binding.BaseThingHandler] - BaseThingHandler.initialize() will be removed soon, ThingStatus can be set manually via updateStatus(ThingStatus.ONLINE)
12.988[ome.event.ThingStatusInfoChangedEvent] - 'weatherunderground:weather:denver' changed from INITIALIZING to ONLINE
12.992[sensors.factory.MySensorsCacheFactory] - Cache file: given_ids.cached exist.
12.994[sensors.factory.MySensorsCacheFactory] - Cache (given_ids) content: [0, 1, 2, 130, 4, 6, 8, 9, 10, 138, 11, 12, 140, 13, 14, 142, 15, 144, 16, 17, 18, 146, 19, 20, 148, 21, 149, 22, 150, 23, 151, 24, 152, 25, 26, 27, 28, 29, 30, 31, 34, 36, 39, 40, 42, 43, 44, 45, 46, 174, 47, 48, 50, 51, 52, 53, 54, 55, 56, 57, 66, 74, 75, 77, 78, 79, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 93]
13.002[ocol.serial.MySensorsSerialConnection] - Set skip check on startup to: false
13.006[ocol.serial.MySensorsSerialConnection] - Enabling connection watchdog
13.039[org.openhab.binding.mysensors ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=325, service.bundleid=196, service.scope=singleton} - org.openhab.binding.mysensors
13.043[s.discovery.MySensorsDiscoveryService] - Starting MySensors discovery scan
13.047[ensors.handler.MySensorsBridgeHandler] - Initialization of the MySensors bridge DONE!
13.072[ocol.serial.MySensorsSerialConnection] - Connecting to /dev/ttyUSB0 [baudRate:115200]
13.412[ocol.serial.MySensorsSerialConnection] - Final port list: /dev/ttyACM0:/dev/ttyACM1:/dev/ttyUSB0:/dev/ttyUSB_cc2531
13.443[ocol.serial.MySensorsSerialConnection] - Successfully connected to serial port.
13.444[ocol.serial.MySensorsSerialConnection] - Waiting 3 seconds to allow correct reset trigger on serial connection opening
16.458[orsAbstractConnection$MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
16.476[orsAbstractConnection$MySensorsReader] - 0;255;3;0;2;2.3.0
16.478[orsAbstractConnection$MySensorsReader] - Good,Gateway is up and running! (Ver:2.3.0)
16.482[ome.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from INITIALIZING to ONLINE
16.502[sensors.factory.MySensorsCacheFactory] - Writing on cache given_ids, content: [0,1,2,130,4,6,8,9,10,138,11,12,140,13,14,142,15,144,16,17,18,146,19,20,148,21,149,22,150,23,151,24,152,25,26,27,28,29,30,31,34,36,39,40,42,43,44,45,46,174,47,48,50,51,52,53,54,55,56,57,66,74,75,77,78,79,81,82,83,84,85,86,87,88,89,90,91,93]
16.820[sensors.handler.MySensorsThingHandler] - Event listener for node 25-1 not registered yet, registering...
20.139[.basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
20.370[lassic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app
20.421[marthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
22.247 [ERROR] [ipse.smarthome.core.items.GenericItem] - Tried to set invalid state 90 (DecimalType) on item HotTubReturn of type StringItem, ignoring it
22.414[.ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
22.458[bpanel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
22.668[org.openhab.binding.zigbee.cc2531 ] - BundleEvent STARTING - org.openhab.binding.zigbee.cc2531
22.671[org.openhab.binding.zigbee.cc2531 ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={service.id=430, service.bundleid=320, service.scope=bundle, component.name=org.openhab.binding.zigbee.cc2531.internal.CC2531HandlerFactory, component.id=297} - org.openhab.binding.zigbee.cc2531
22.683[org.openhab.binding.zigbee.cc2531 ] - BundleEvent STARTED - org.openhab.binding.zigbee.cc2531
24.478[smarthome.event.ItemStateChangedEvent] - PhotoTrip changed from NULL to 0
24.480[gbee.discovery.ZigBeeDiscoveryService] - Creating ZigBee discovery service for zigbee:coordinator_cc2531:f88421c9
24.481[gbee.discovery.ZigBeeDiscoveryService] - Activating ZigBee discovery service for zigbee:coordinator_cc2531:f88421c9
24.482[org.openhab.binding.zigbee.cc2531 ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=433, service.bundleid=320, service.scope=singleton} - org.openhab.binding.zigbee.cc2531
24.510[ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:f88421c9' changed from UNINITIALIZED to INITIALIZING
24.515[g.zigbee.cc2531.handler.CC2531Handler] - Initializing ZigBee CC2531 serial bridge handler.
24.516[gbee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_cc2531:f88421c9].
24.517[gbee.handler.ZigBeeCoordinatorHandler] - Channel 11
24.518[gbee.handler.ZigBeeCoordinatorHandler] - PANID -26867
24.518[gbee.handler.ZigBeeCoordinatorHandler] - EPANID 00124B000E896C97
24.520[gbee.handler.ZigBeeCoordinatorHandler] - Key 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
24.520[gbee.handler.ZigBeeCoordinatorHandler] - Key String 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
24.524[gbee.handler.ZigBeeCoordinatorHandler] - Key initialised 3D6688D09EDF4D1FA1E763CC288C1413
24.534[gbee.handler.ZigBeeCoordinatorHandler] - Key final array 3D6688D09EDF4D1FA1E763CC288C1413
24.560[g.zigbee.cc2531.handler.CC2531Handler] - ZigBee CC2531 Coordinator opening Port:'/dev/ttyUSB_cc2531' PAN:ffff970d, EPAN:00124B000E896C97, Channel:11
24.620[gbee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
24.621[ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:f88421c9' changed from INITIALIZING to UNKNOWN
24.633[ome.event.ThingStatusInfoChangedEvent] - 'chromecast:chromecast:LongDogDOTgov' changed from UNINITIALIZED to INITIALIZING
25.208 [WARN ] [su.litvak.chromecast.api.v2.Channel ] - Error while reading
su.litvak.chromecast.api.v2.ChromeCastException: Remote socket closed
at su.litvak.chromecast.api.v2.Channel.read(Channel.java:417) [286:org.openhab.binding.chromecast:2.4.0.201806241822]
at su.litvak.chromecast.api.v2.Channel.access$200(Channel.java:50) [286:org.openhab.binding.chromecast:2.4.0.201806241822]
at su.litvak.chromecast.api.v2.Channel$ReadThread.run(Channel.java:132) [286:org.openhab.binding.chromecast:2.4.0.201806241822]
25.213 [WARN ] [su.litvak.chromecast.api.v2.Channel ] - <-- null payload in message
25.219[ome.event.ThingStatusInfoChangedEvent] - 'chromecast:chromecast:LongDogDOTgov' changed from ONLINE to OFFLINE
25.625[gbee.handler.ZigBeeCoordinatorHandler] - ZigBee network starting
25.626[gbee.handler.ZigBeeCoordinatorHandler] - Initialising ZigBee coordinator
25.634[gbee.handler.ZigBeeCoordinatorHandler] - Key initialise 3D6688D09EDF4D1FA1E763CC288C1413
25.637[nding.zigbee.handler.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyUSB_cc2531] at 115200 baud, flow control FLOWCONTROL_OUT_RTSCTS.
25.642 [ERROR] [nding.zigbee.handler.ZigBeeSerialPort] - Serial Error: Port /dev/ttyUSB_cc2531 does not exist.
25.643 [ERROR] [e.cc2531.network.ZigBeeNetworkManager] - Failed to open the dongle.
25.644[rnal.ZigBeeNetworkStateSerializerImpl] - Loading ZigBee network state: Start.
25.656[rnal.ZigBeeNetworkStateSerializerImpl] - Loading ZigBee network state: Done.
25.659[ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:f88421c9' changed from UNKNOWN to OFFLINE: Failed to initialize ZigBee transport layer
26.633[ome.event.ThingStatusInfoChangedEvent] - 'chromecast:chromecast:Doxiecast' changed from INITIALIZING to ONLINE
openhab-cli console
15 │ Active │ 80 │ 5.3.1.201602281253 │ OSGi JAX-RS Connector
16 │ Active │ 80 │ 2.4.5 │ Jackson-annotations
17 │ Active │ 80 │ 2.4.5 │ Jackson-core
18 │ Active │ 80 │ 2.4.5 │ jackson-databind
19 │ Active │ 80 │ 2.4.5 │ Jackson-dataformat-XML
20 │ Active │ 80 │ 2.4.5 │ Jackson-dataformat-YAML
21 │ Active │ 80 │ 2.4.5 │ Jackson-module-JAXB-annotations
22 │ Active │ 80 │ 2.7.0 │ Gson
23 │ Active │ 80 │ 18.0.0 │ Guava: Google Core Libraries for Java
24 │ Active │ 80 │ 3.0.0.v201312141243 │ Google Guice (No AOP)
25 │ Active │ 80 │ 1.5.8 │ swagger-annotations
26 │ Active │ 80 │ 3.19.0.GA │ Javassist
28 │ Active │ 80 │ 3.5.2 │ JmDNS
30 │ Active │ 80 │ 1.0.0 │ Units of Measurement API
32 │ Active │ 80 │ 1.1.0.Final │ Bean Validation API
33 │ Active │ 80 │ 2.0.1 │ javax.ws.rs-api
34 │ Active │ 80 │ 3.2.0.v201101311130 │ ANTLR Runtime
35 │ Active │ 80 │ 3.2.1 │ Commons Collections
36 │ Active │ 80 │ 1.1 │ Commons Exec
37 │ Active │ 80 │ 2.2.0 │ Commons IO
38 │ Active │ 80 │ 2.6 │ Commons Lang
48 │ Active │ 80 │ 4.1.5 │ Apache Karaf :: OSGi Services :: Event
67 │ Active │ 80 │ 2.11.0.v20150805-0538 │ EMF Common
68 │ Active │ 80 │ 2.11.1.v20150805-0538 │ EMF Ecore
69 │ Active │ 80 │ 2.11.1.v20150805-0538 │ EMF XML/XMI Persistence
70 │ Active │ 80 │ 3.8.0.v20160509-1230 │ Common Eclipse Runtime
71 │ Active │ 80 │ 3.6.100.v20160223-2218 │ Extension Registry Support
80 │ Active │ 80 │ 9.3.21.v20170918 │ Jetty :: Proxy
94 │ Active │ 80 │ 0.2.1.v20170706-0855 │ org.eclipse.lsp4j
95 │ Active │ 80 │ 0.2.1.v20170706-0855 │ org.eclipse.lsp4j.jsonrpc
96 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Config Core
97 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Configuration Discovery
98 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Configuration mDNS Discovery
99 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Config Dispatcher
100 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome Config XML
101 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core
102 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core Audio
103 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome AutoUpdate Binding
104 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core Binding XML
105 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core ID
106 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core Persistence
107 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Scheduler Service
108 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core Thing
109 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome Core Thing XML
110 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Transformation Service
111 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core Voice
112 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Console
113 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Console for OSGi runtime Karaf
114 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome JavaSound I/O, Fragments: 180
115 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Monitor
116 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Net I/O Bundle
117 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome REST Interface Bundle
118 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Core REST API
119 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome REST mDNS Announcer
120 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome REST Interface JAX-RS optimization Bundle
121 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Sitemap REST API
122 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome SSE REST API
123 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Voice REST API
124 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Bonjour/MDS Service Discovery Bundle
125 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Web Audio Support
126 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Model Core
127 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Item Model
128 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Item Model IDE
129 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Item Model Runtime
130 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Language Server
131 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Persistence Model
132 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Persistence Model IDE
133 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Persistence Runtime
134 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Rule Model
135 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Rule Model IDE
136 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Rule Runtime
137 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Script
138 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Script Model IDE
139 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Script Runtime
140 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Sitemap Model
141 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Sitemap Model IDE
142 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Sitemap Runtime
143 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Thing Model
144 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Thing Model IDE
145 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Thing Model Runtime
146 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Json Storage Service
147 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome UI
148 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome UI Icons
149 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Classic IconSet
150 │ Active │ 80 │ 2.12.0.v20170518-0757 │ Xtend Runtime Library
151 │ Active │ 80 │ 2.12.0.v20170518-0757 │ Xtend Macro Interfaces
152 │ Active │ 80 │ 2.12.0.v20170518-0959 │ Xtext
153 │ Active │ 80 │ 2.12.0.v20170519-0752 │ Xtext Common Types
154 │ Active │ 80 │ 2.12.0.v20171017-1700 │ Xtext IDE Core
155 │ Active │ 80 │ 2.12.0.v20170518-0959 │ Xtext Utility
156 │ Active │ 80 │ 2.12.0.v20170519-0752 │ Xbase Model
157 │ Active │ 80 │ 2.12.0.v20170519-0752 │ Xbase Generic IDE Services
158 │ Active │ 80 │ 2.12.0.v20170518-0757 │ Xbase Runtime Library
173 │ Active │ 80 │ 2.3.0 │ JUPnP Library
174 │ Active │ 80 │ 1.9.6 │ MIME streaming extension
175 │ Active │ 80 │ 5.0.2 │ Require-Bundle Fix :: org.objectweb.asm
177 │ Active │ 90 │ 2.3.0 │ openHAB Core
178 │ Active │ 80 │ 2.3.0 │ openHAB Karaf Integration
180 │ Resolved │ 80 │ 2.3.0 │ openHAB Sound Support, Hosts: 114
181 │ Active │ 80 │ 2.3.0 │ openHAB Dashboard UI
186 │ Active │ 80 │ 3.1.4 │ Stax2 API
187 │ Active │ 80 │ 1.0.2 │ Units of Measurement Common Library
188 │ Active │ 80 │ 1.0.8 │ Units of Measurement Implementation for Java SE
189 │ Active │ 80 │ 1.6.0 │ Commons Codec
190 │ Active │ 80 │ 3.2.0 │ Commons Net
191 │ Active │ 80 │ 4.2.3 │ Apache HttpClient OSGi bundle
192 │ Active │ 80 │ 4.2.3 │ Apache HttpCore OSGi bundle
193 │ Active │ 80 │ 3.1.0.7 │ Apache ServiceMix :: Bundles :: commons-httpclient
194 │ Active │ 80 │ 2.3.0 │ openHAB 1.x Compatibility Layer
196 │ Active │ 80 │ 2.1.0.201706190930 │ MySensors Binding
197 │ Active │ 80 │ 0.9.0.201701210957 │ WeatherUnderground Binding
198 │ Active │ 80 │ 1.1.1.201605111122 │ Swagger Provider
199 │ Active │ 80 │ 2.3.1 │ Gson
200 │ Active │ 80 │ 2.1.0 │ json-path
201 │ Active │ 80 │ 3.12.0.OH │ nrjavaserial
207 │ Active │ 80 │ 1.5.8 │ swagger-core
208 │ Active │ 80 │ 1.5.8 │ swagger-jaxrs
209 │ Active │ 80 │ 1.5.8 │ swagger-models
210 │ Active │ 80 │ 2.2 │ json-smart
211 │ Active │ 80 │ 3.4.0 │ Apache Commons Lang
212 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation API
213 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation commands
214 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Core
215 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Module Core
216 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Media Modules
217 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Module Script
218 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Script Globals
219 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Script RuleSupport
220 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Module Timer
221 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation GSON Parser
222 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation Providers
223 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Automation REST API
224 │ Active │ 80 │ 0.10.0.oh230 │ Astro Binding
225 │ Active │ 80 │ 0.10.0.oh230 │ ntp Binding
226 │ Active │ 80 │ 0.10.0.oh230 │ YahooWeather Binding
227 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Configuration USB-Serial Discovery
228 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Configuration USB-Serial Discovery Linux sysf Scanning
229 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Config Serial
230 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome IoT Marketplace Extension Service
231 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Serial Transport
232 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Serial Transport for RXTX
233 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome Exec Transformation Service
234 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome JavaScript Transformation Service
235 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome JSonPath Transformation Service
236 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome Map Transformation Service
237 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome RegEx Transformation Service
238 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome Scale Transformation Service
239 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome XPath Transformation Service
240 │ Active │ 75 │ 0.10.0.oh230 │ Eclipse SmartHome Xslt Transformation Service
241 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Basic UI, Fragments: 257
242 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome WebApp UI, Fragments: 258
243 │ Active │ 80 │ 0.10.0.oh230 │ Eclipse SmartHome Paper UI, Fragments: 261
245 │ Active │ 80 │ 1.12.0 │ openHAB MQTT Binding
247 │ Active │ 80 │ 1.12.0 │ openHAB Weather Binding
253 │ Active │ 80 │ 2.3.0 │ ZoneMinder Binding
254 │ Active │ 80 │ 2.3.0 │ openHAB REST Documentation
255 │ Active │ 80 │ 1.12.0 │ openHAB MQTT Transport Bundle
256 │ Active │ 80 │ 1.12.0 │ openHAB RRD4j Persistence Bundle
257 │ Resolved │ 75 │ 2.3.0 │ openHAB Basic UI Fragment, Hosts: 241
258 │ Resolved │ 75 │ 2.3.0 │ openHAB Classic UI Fragment, Hosts: 242
259 │ Active │ 80 │ 2.3.0 │ HABmin User Interface
260 │ Active │ 80 │ 2.3.0 │ HABPanel User Interface
261 │ Resolved │ 75 │ 2.3.0 │ openHAB Paper UI Theme Fragment, Hosts: 243
262 │ Active │ 80 │ 0.9.10.v20160429-1435 │ reflections (wrap)
263 │ Active │ 80 │ 1.5.8.v20160511-1038 │ swagger-jersey2-jaxrs (wrap)
274 │ Active │ 80 │ 2.4.0.201807242215 │ ZWave Binding
284 │ Active │ 80 │ 1.12.0 │ openHAB Serial Binding
286 │ Active │ 80 │ 2.4.0.201806241822 │ Chromecast Binding
314 │ Active │ 80 │ 1.0.11 │ com.zsmartsystems.zigbee
315 │ Active │ 80 │ 1.0.11 │ com.zsmartsystems.zigbee.dongle.cc2531
316 │ Active │ 80 │ 1.0.11 │ com.zsmartsystems.zigbee.dongle.ember
317 │ Active │ 80 │ 1.0.11 │ com.zsmartsystems.zigbee.dongle.telegesis
318 │ Active │ 80 │ 1.0.11 │ com.zsmartsystems.zigbee.dongle.xbee
319 │ Active │ 80 │ 2.3.0 │ ZigBee Binding
320 │ Active │ 80 │ 2.3.0 │ ZigBee CC2531 Binding
321 │ Active │ 80 │ 2.3.0 │ ZigBee Ember Binding
322 │ Active │ 80 │ 2.3.0 │ ZigBee Telegesis Binding
323 │ Active │ 80 │ 2.3.0 │ ZigBee XBee Binding
openhab>
I just feel kind of lost.
I don’t know how to modify your udev rule to work with my hardware, adding group and mode like you have accomplishes nothing, IE it doesn’t change the way the device is listed when I “ls -la”
Thanks though
Did you reboot or rerun the udev rules? This should work…
SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", ATTRS{serial}=="__0X00124B000E896C97", SYMLINK+="ttyUSB_cc2531", GROUP="dialout", MODE="0666"
You can test your udev rules running against a specific device, before actually running them, by using…
udevadm test `udevadm info -a /dev/ttyUSB_cc2531| grep "looking at device"| sed "s/looking at device '//"| sed "s/'://"`
The symlink won’t be put into the group, but the target of the symlink will be…
[root@fedora01 /]# ls -la /dev/ |grep ttyUSB
crw-rw-rw- 1 root dialout 188, 0 Aug 12 17:44 ttyUSB0
crw-rw-rw- 1 root dialout 188, 1 Aug 12 17:44 ttyUSB1
lrwxrwxrwx 1 root root 7 Aug 10 15:30 ttyUSB-5 -> ttyUSB0
lrwxrwxrwx 1 root root 7 Aug 10 15:30 ttyUSB-55 -> ttyUSB1
What do you see when you run (making sure you openhab account is in dialout and tty)…
# id openhab
uid=964(openhab) gid=963(openhab) groups=963(openhab),5(tty),18(dialout)
If you want to keep the nonstandard name, you may also want to try putting the EXTRA_JAVA_OPTS at the top of start.sh, in case the way you are doing it isnt working. This is what I have for setting up JSR223…
export EXTRA_JAVA_OPTS="-Xbootclasspath/a:/opt/openhab2/conf/jython/jython-standalone-2.7.0.jar -Dpython.home=/opt/openhab2/conf/jython -Dpython.path=/opt/openhab2/conf/lib"
A random thing to check when this is happening, is to look into /var/lock and see if you have a LCK..ttyUSB_cc2531 file. You should, if everything is working OK. I had been running OH as root, but when I changed it to an openhab account, I found that directory did not have permissions to allow the openhab account to write the lock file, and found errors showing this in journalctl…
Aug 12 18:35:15 fedora01 start.sh[7448]: Launching the openHAB runtime...
Aug 12 18:36:17 fedora01 start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file.
Aug 12 18:36:17 fedora01 start.sh[7448]: RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyUSB-55: Permission denied. FAILED TO OPEN: No such file or directory
This is a complete mystery that I’m currently looking into, but I’ve temporarily given rwx to everyone until I can figure it out. I’m also using snapshot 1325, so it may be related to some of the recent ESH changes or an updated nrjavaserial.
Hey everyone,
sorry for the wall of text.
I acquired a Elelabs ZigBee USB stick (uses a EM358) a while ago and have been using it for a few weeks without any big issues.
However, after I was done with testing I added the rest of my ZigBee devices and suddenly after a restart all of my ZigBee nodes are offline and won’t come back. I even reverted to an older config and yet the nodes are still not coming back.
So I reset the controller, removed all nodes and added them again just for it to happen again yesterday, all nodes were freshly added and are now dead again.
Since it ran for weeks without issues I assume one of the new devices messed up the network but I’m not sure which and I’m not sure if I can recover from this without having to add all nodes every time this happens. So before readding all nodes again I thought I would ask here.
I’m was using the Docker image 2.3.0-amd64-debian when it happened. When starting with this image the controller will come online but only 1-4 random nodes will come online with it, none of these are controllable however.
I also tried 2.4.0-snapshot-amd64-debian which handles things slightly differently. Now OpenHAB is stuck in a endless discovery loop at startup and the ZigBee log just keeps flowing forever. After like 10 minutes it will have discovered all nodes one by one (even ones that aren’t even powered) but none of them will be controllable.
Adding a fresh device will work and the controller can talk to it just fine. Until this happens again that is.
Actually, I can’t add a new node until I cleanup manually.
I’m seriously confused as to why this keeps happening and since the config rollback doesn’t help I assume something at the network level gets messed up with one of the devices I added? Does the Ember stick keep its own config like the Z-wave sticks do or has the controller simply removed all nodes from the network (for whatever reason)?
I took a debug log with 2.3.0 on startup after the issue occurred and I can post it (assuming it contains no sensitive info?). Not sure if it’s of any help though since the network is already messed up at this point.
Just for reference, these are the devices I added a day before the network died:
- 1x Innr RB 185 C (RGBW E27 bulb)
- 5x Philips LCT003 (RGBW GU10 spot)
- 2x Philips LTW012 (W E14 bulb)
- 1x Philips LST002 (RGBW LED strip)
- 1x Philips RWL021 (Dimmer switch)
- 1x Philips SML001 (Motion sensor)
That makes for a total of ~24 devices on this network (including the existing).
Everything kept working for a full day, at night I noticed that the motion sensor stopped reporting its luminance, the next morning the network was unresponsive, after a restart it was dead. Controller comes up with a few random nodes, nothing responds.
I’m assuming the issue lies with one of the battery powered ones or the LED strip since I added plenty of bulbs and spots before that and they all worked fine. Still, I hope this issue can be diagnosed before continuing, it sucks that one device can take your whole network down like this.
So, anybody experienced this before? Any idea how to get the network back without pairing everything again? Any idea what could cause this?
Exactly the same issue I had. Untill @chris has changed the Zigbee binding, I have given up on Zigbee.
Lucky for me, my Zigbee devices are all just test devices.
1 Like
That’s too bad, ZigBee would be working pretty well in OpenHAB (compared to Home Assistant) if it weren’t for this issue.
What are you using for lighting if ZigBee is only for testing?
The documentation from Silabs is not good regarding rejoins, and it might be misconfigured. I’ve asked Silabs to clarify this, and they agreed that the documentation was not correct, and they needed to check the source to see how it worked. I’ve asked a couple of times for an update, but unfortunately not had a response yet.
If you able to provide a sniffer log (probably not though), then it would be useful
Which part do you need sniffed? There are some cheap ZigBee sniffers on Amazon/eBay, will those work?
Did some more digging. Removing my ZigBee xml will allow new devices to join, copying over an old lamp to the new config will still make it show up as offline. So they indeed “left” the network.
ubuntu 64bit oder 32bit?
I’m running:
pixeldoc@pd-srv:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
pixeldoc@pd-srv:~$ uname -a
Linux pd-srv 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux
pixeldoc@pd-srv:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 1: Dev 7, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 1: Dev 7, If 1, Class=CDC Data, Driver=cdc_acm, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 4: Dev 9, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
pixeldoc@pd-srv:~$ find /sys/bus/usb/devices/usb*/ -name dev
/sys/bus/usb/devices/usb1/dev
/sys/bus/usb/devices/usb1/1-1/dev
/sys/bus/usb/devices/usb1/1-1/1-1.4/dev
/sys/bus/usb/devices/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB1/tty/ttyUSB1/dev
/sys/bus/usb/devices/usb2/2-1/dev
/sys/bus/usb/devices/usb2/2-1/2-1.1/2-1.1:1.0/tty/ttyACM1/dev
/sys/bus/usb/devices/usb2/2-1/2-1.1/dev
/sys/bus/usb/devices/usb2/dev
pixeldoc@pd-srv:~$ ls -la /dev/ttyA*
crw-rw---- 1 root dialout 166, 1 Aug 18 04:41 /dev/ttyACM1
pixeldoc@pd-srv:~$ ls -la /dev/ttyU*
crw-rw---- 1 root dialout 188, 1 Aug 18 00:12 /dev/ttyUSB1
lrwxrwxrwx 1 root root 7 Aug 6 02:07 /dev/ttyUSB_cc2531 -> ttyACM1
lrwxrwxrwx 1 root root 7 Jul 23 00:00 /dev/ttyUSB_mysensorsserialgw -> ttyUSB1
Please post your details!
Maybe try other Java version like zulu (Install Java for Openhab2)
Maybe your Java is missing the java rxtx library?
Try: sudo apt-get install librxtx-java
I’d like to see what is happening when the devices leave. ZigBee has a reasonably complex network model, and devices can leave the network, and then rejoin so long as they still have the key, and the key hasn’t changed. I’d like to see if the coordinator is chucking the devices off, or if the key changes, or if the trust centre isn’t allowing the devices back (or something else…).
They should work. They work with Wireshark - I’ve just been spending some time trying to familiarise myself with it again as I don’t tend to use it these days. It looks like it will do what is needed, and I will write a how-to if people want to try and set up a sniffer.
The cheap TI dongles available on the web from China tend to be a bit of a pain to program, but in theory you can buy them with the sniffer firmware already loaded, so it should (!!) be simple to set up. I’m not 100% sure how to pipe this data through to wireshark - I have found a python script on github which will work for Linux / Mac, but probably not for Windoze.
I mostly use Ember sticks, and I’ve spent a few hours this afternoon writing a sniffer to pipe data from the Ember chipset to Wireshark and this seems to work ok. It can use any reasonably new Ember firmware (at least 5.7.3 has these functions available - the Elelabs interface will work fine). Of course, you need 2 of them - one for the coordinator, and one for the sniffer, which is a little more expensive.
I’ll make this sniffer software available on Github soon.
Other options that are available are the CEL sticks from Silabs (a straight USB dongle) which is what I mostly use for development - the problem with them is they don’t come with any firmware and require reasonably expensive hardware to program. If there’s interest, I could probably offer to program some sticks for people to use.
1 Like
Wow! Are you saying that this will turn any Ember dongle running at least 5.7.3 into a Zigbee sniffer?! The HUSBZB-1 (at least the one I have) is running firmware 5.4.1.0… so it looks like it would need a firmware update. Any chance you can suggest a dongle available in the US that has 5.7.3+?
Yes - although I’m not saying that it needs 5.7.3 - just that I can confirm that 5.7.3 will support it. Older versions may also support it - I’ve just not checked back further than this, and I do know it’s not a really old feature. I’ll see if I can find docs for 5.4 to see if it’s supported.
The binding can do this 
. I can probably supply you the latest firmware, and I’d be reasonably sure it will work (but, there’s always that small possibility it won’t - but I think it’s really low).
No - only the CEL MeshConnect stick, but that doesn’t have ANY firmware, so it needs programming with the Silabs programmer. I could get some and program them if there’s interest.
1 Like
I can’t find the full docs for 5.4, but I did find an older one that indicates it might have already been included, so there’s a good possibility that it will work with 5.4.
Note that this does also need an update to the main library to work, and as there are some small breaking changes to the APIs in this version, it will also need a binding update. I’m trying to wrap all these changes into a single release if I can to avoid too much pain…
1 Like
That’s promising… I need some backup hardware anyway, so I’ll pick up a spare and try this out. Worst case, I’ll need to flash it. Hmmm, maybe updated firmware on my coordinator would stop my bulbs from dropping too… 
I am of course talking complete bollocks when I said you need the updated library etc! While this is true for the binding, the sniffer application is a completely separate application and not linked to the binding, so can include the updated library without impact on the binding - I can provide a copy to try if you want to try it.
I’ve created a JAR for the Ember sniffer, and started a document describing how to use it in case anyone wants to try. At the moment it focuses on the Ember sniffer I wrote since that’s what I’m currently using - I’ve added a link for some software to use the cheap TI dongles as well, but I’ve not tried this yet. I have purchased one off the web and document how to get it going once it arrives.
Document explaining the sniffer use is here, and the Ember sniffer software is here.
While I don’t tend to use Wireshark, I will try and make some effort to update the documentation, and provide updates to the analyses as we uncover issues, to try and make it more useful for everyone (which will hopefully allow me to further improve the binding 
).
I’d be interested!