I would say “probably”, but as far as I know it’s not tested. I’ve tested it with the Hue motion sensor, and the SmartThings sensor - these are quite different (ie they use different reporting strategies) so there’s a reasonable chance the Tradfri version will use one of these.
If not, I’m sure we can make it work 
Devices came online, but getting these on 2.3.0.201801020943…
2018-01-02 07:16:48.918 [ERROR] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - 7C252400001632EA: Exception getting binding table
java.util.concurrent.ExecutionException: java.lang.ClassCastException: com.zsmartsystems.zigbee.zdo.command.ManagementLqiResponse cannot be cast to com.zsmartsystems.zigbee.zdo.command.ManagementBindResponse
at java.util.concurrent.FutureTask.report(FutureTask.java:122) [?:?]
at java.util.concurrent.FutureTask.get(FutureTask.java:192) [?:?]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:256) [16:org.openhab.binding.zigbee:2.3.0.201801020943]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:171) [16:org.openhab.binding.zigbee:2.3.0.201801020943]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:165) [16:org.openhab.binding.zigbee:2.3.0.201801020943]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [16:org.openhab.binding.zigbee:2.3.0.201801020943]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.ClassCastException: com.zsmartsystems.zigbee.zdo.command.ManagementLqiResponse cannot be cast to com.zsmartsystems.zigbee.zdo.command.ManagementBindResponse
at com.zsmartsystems.zigbee.ZigBeeNode$1.call(ZigBeeNode.java:356) ~[?:?]
at com.zsmartsystems.zigbee.ZigBeeNode$1.call(ZigBeeNode.java:339) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
... 1 moreThere’s no obvious issue in the library but I suspect there’s an issue with the transaction correlation for the ZDO requests. I’ll have a look at how the library is handling these requests…
Hi all
I am a bit confused about which ZigBee dongles are actually working well. As far as I understand, there are two different ZigBee SoCs available from Silabs, namely the EM358 supported by coordinator_ember and the EM357 supported by coordinator_telegesis. Is this correct?
I could find three different dongles based on those SoCs which are available in Germany:
Unfortunately, I own the last one which is not working with OpenHAB. Is there any chance to get it working (maybe by flashing a new firmware)? Or should I better buy an EM357 based dongle? BTW is there any other EM358 available in Germany/Europe? I couldn’t find one.
All 3 of these may work, but only the first one WILL work…
The Qivicon devices will work, but only under certain circumstances. The problem is that they use modified product IDs, so they will not be detected on a Mac or Windows computer, or on Linux - unless you modify the PIDs (as reported elsewhere)…
This is a Telegesis ETRX357 with slightly modified firmware.
This currently runs standard NCP 5.8.1 firmware.
Again - neither of these will work without modifying drivers to make them recognised by your computer.
So…
It’s not necessarily the best stick, but as things currently stand, it’s the best supported.
No - unfortunately not if you use Windows or Mac. The issue is not with the firmware - it’s with the product codes that your computer uses to install drivers. Linux computers can bypass this as mentioned earlier.
I hope this helps a little at least.
@cmorlok I got mine (ETRX357USB-LRS+8M) for 56 Euro from Farnell Germany (shipping to Austria included). But maybe they raised the price, didn’t check…
Hopefully this should be fixed with the following PR -:
I’ll flow this into the binding this afternoon.
edit…
Since I am running linux, the driver should not be the issue. But it somehow does not initialize:
[ 2.061317] usb 1-1.5: new full-speed USB device number 4 using dwc_otg
[ 2.197146] usb 1-1.5: New USB device found, idVendor=10c4, idProduct=8b34
[ 2.198796] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.200429] usb 1-1.5: Product: BV 2010/10
[ 2.202067] usb 1-1.5: Manufacturer: Silicon Labs
[ 2.203630] usb 1-1.5: SerialNumber: 0137F531
[ 3.699657] usbcore: registered new interface driver brcmfmac
[ 3.727834] usbcore: registered new interface driver usbserial
[ 3.727927] usbcore: registered new interface driver usbserial_generic
[ 3.728004] usbserial: USB Serial support registered for generic
[ 3.734936] usbcore: registered new interface driver cp210x
[ 3.735072] usbserial: USB Serial support registered for cp210x
[ 3.735219] cp210x 1-1.5:1.0: cp210x converter detected
[ 3.748323] usb 1-1.5: cp210x converter now attached to ttyUSB0
12:23:09.464 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'binding-zigbee' has been installed.
12:23:57.604 [DEBUG] [.zigbee.internal.ZigBeeHandlerFactory] - Creating coordinator handler for org.eclipse.smarthome.core.thing.internal.BridgeImpl@e3eba0b2
12:23:57.648 [DEBUG] [gbee.discovery.ZigBeeDiscoveryService] - Creating ZigBee discovery service for zigbee:coordinator_ember:7623efdf
12:23:57.655 [DEBUG] [gbee.discovery.ZigBeeDiscoveryService] - Activating ZigBee discovery service for zigbee:coordinator_ember:7623efdf
12:23:57.664 [DEBUG] [org.openhab.binding.zigbee ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=308, service.bundleid=207, service.scope=singleton} - org.openhab.binding.zigbee
12:23:57.754 [DEBUG] [org.openhab.binding.zigbee ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.firmware.FirmwareUpdateHandler}={service.id=309, service.bundleid=207, service.scope=singleton} - org.openhab.binding.zigbee
12:23:57.801 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_ember:7623efdf' changed from UNINITIALIZED to INITIALIZING
12:23:57.849 [DEBUG] [handler.ZigBeeCoordinatorEmberHandler] - Initializing ZigBee Ember serial bridge handler.
12:23:57.859 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_ember:7623efdf].
12:23:57.869 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Channel -1
12:23:57.876 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - PANID 0
12:23:57.882 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - EPANID 0000000000000000
12:23:57.896 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Key 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
12:23:57.906 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Initialising network
12:23:57.915 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Created random ZigBee PAN ID [2997].
12:23:57.959 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Created random ZigBee extended PAN ID [93679A70C85D0689].
12:23:57.970 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zigbee:coordinator_ember:7623efdf' has been updated.
12:23:57.991 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zigbee:coordinator_ember:7623efdf' has been updated.
12:23:58.003 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Key String 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
12:23:58.006 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zigbee:coordinator_ember:7623efdf' has been updated.
12:23:58.021 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Key initialised 9AA7DD49DAD89F3ACB4D408A1C24E765
12:23:58.038 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Key final array 9AA7DD49DAD89F3ACB4D408A1C24E765
12:23:58.112 [DEBUG] [handler.ZigBeeCoordinatorEmberHandler] - ZigBee Coordinator Ember opening Port:'/dev/ttyUSB0' PAN:2997, EPAN:93679A70C85D0689, Channel:-1
12:23:58.135 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_ember:7623efdf' changed from INITIALIZING to UNKNOWN
12:23:58.140 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
12:23:58.173 [INFO ] [arthome.event.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:coordinator_ember:7623efdf changed to UNKNOWN.
12:23:59.157 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - ZigBee network starting
12:23:59.168 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Initialising ZigBee coordinator
12:23:59.232 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Key initialise 9AA7DD49DAD89F3ACB4D408A1C24E765
12:23:59.248 [DEBUG] [ding.zigbee.internal.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyUSB0] at 115200 baud, flow control FLOWCONTROL_OUT_RTSCTS.
12:23:59.293 [INFO ] [ding.zigbee.internal.ZigBeeSerialPort] - Serial port [/dev/ttyUSB0] is initialized.
12:23:59.459 [WARN ] [gbee.dongle.ember.ash.AshFrameHandler] - Trying to send when not connected.
12:28:42.291 [DEBUG] [gbee.discovery.ZigBeeDiscoveryService] - ZigBee coordinator is offline - aborted scan for zigbee:coordinator_ember:7623efdf
It’s 81 Euro plus VAT now. But since Farnell doesn’t ship to end users, it doesn’t matter. Best price I could find is 62 Euro plus shipping. That’s the official Farnell/Element14 reseller for end users btw.
Probably I’ll buy one of those.
At least in the UK, Farnell will ship to anyone as far as I know (certainly I’ve never had any trouble buying stuff from them).
However, a cheaper deal is of course better
Yes, they ship to anyone nearly everywhere but not in Germany.
@chris I would like to test the new version with polling, but for some reason I was not able to build the plugin with the latest code:
[ERROR] 80) Error injecting: private org.eclipse.aether.spi.log.Logger org.eclipse.aether.internal.impl.DefaultUpdatePolicyAnalyzer.logger
[ERROR] while locating org.eclipse.aether.internal.impl.DefaultUpdatePolicyAnalyzer
[ERROR] while locating java.lang.Object annotated with *
[ERROR] at org.eclipse.sisu.wire.LocatorWiring
[ERROR] while locating org.eclipse.aether.impl.UpdatePolicyAnalyzer
[ERROR] for parameter 0 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.<init>(Unknown Source)
[ERROR] while locating org.eclipse.aether.internal.impl.DefaultUpdateCheckManager
[ERROR] while locating java.lang.Object annotated with *
[ERROR] at org.eclipse.sisu.wire.LocatorWiring
[ERROR] while locating org.eclipse.aether.impl.UpdateCheckManager
[ERROR] for parameter 4 at org.eclipse.aether.internal.impl.DefaultDeployer.<init>(Unknown Source)
[ERROR] while locating org.eclipse.aether.internal.impl.DefaultDeployer
[ERROR] while locating java.lang.Object annotated with *
[ERROR] at org.eclipse.sisu.wire.LocatorWiring
[ERROR] while locating org.eclipse.aether.impl.Deployer
[ERROR] for parameter 7 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.<init>(Unknown Source)
[ERROR] while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
[ERROR] while locating java.lang.Object annotated with *
[ERROR] while locating org.apache.maven.artifact.installer.DefaultArtifactInstaller
[ERROR] at ClassRealm[plexus.core, parent: null]
[ERROR] at ClassRealm[plexus.core, parent: null]
[ERROR] while locating org.apache.maven.artifact.installer.ArtifactInstaller
[ERROR] while locating org.apache.maven.plugin.install.InstallMojo
[ERROR] at ClassRealm[plugin>org.apache.maven.plugins:maven-install-plugin:2.3.1, parent: sun.misc.Launcher$AppClassLoader@55f96302]
[ERROR] while locating org.apache.maven.plugin.Mojo annotated with @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-install-plugin:2.3.1:install)
[ERROR] Caused by: java.lang.IllegalArgumentException: Can not set org.eclipse.aether.spi.log.Logger field org.eclipse.aether.internal.impl.DefaultUpdatePolicyAnalyzer.logger to org.eclipse.aether.internal.impl.PlexusLoggerFactory
Can you tell me how I can fix this or where I can download the latest version of the binding?
Sorry - I have no idea what this is, so I can’t really offer any solution.
The latest binding can simply be downloaded in the same way as any other snapshot binding - ie through PaperUI if you are using the snapshot runtime.
I don’t have a snapshot installation of Openhab, but I found a compiled version here: https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/ws/bindings/org.openhab.binding.zigbee/target/
I hope this is the right version.
You can find it here…
https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastSuccessfulBuild/org.openhab.binding$org.openhab.binding.zigbee/
I’ve just sent you an email with a debug log from the latest version. The lamps are still taking a lot of time to turn to online and I wasn’t able to switch them.
The following PR ought to fix the exception and I think the exception might solve the lamps not coming online issue… Let’s see…
This threw me for a loop when I upgraded to 2.3 yesterday. It broke a few of my rules that used the switches and dimmers on OSRAM LIGHTIFY RGBW lights. I’ve got it fixed now, but thought I would mention it since others may have the same problem.
Other than that, everything seems to be working better than before. Thanks for all your hard work!
Hi Chris, did you receive my mail containing the latest log? I’ve tested the newest version, but still only a few lights changed to online and I wasn’t able to switch any lights.