openhab/org.openhab.binding.zigbee

openHAB binding for ZigBee

org.openhab.binding.zigbee's Issues

NumberFormatException when adding ZigBee things

Openhab2 nightly v2.1.0~20170513100611-1
ZigBee Binding v2.0.0.201705102217

When adding a new thing, my Osram lightbulbs are identified and the pairing process is successful, but the things in openhab stay in UNINITIALIZED state because of the following error:

2017-05-13 16:42:08.938 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while initializing handler of thing 'zigbee:device:ea6edccc:1234567812ca12e1': java.lang.NumberFormatException: For input string: "1234567812CA12E1"
java.util.concurrent.ExecutionException: java.lang.NumberFormatException: For input string: "1234567812CA12E1"
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_65]
	at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_65]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:194)[99:org.eclipse.smarthome.core:0.9.0.201705120951]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83)[99:org.eclipse.smarthome.core:0.9.0.201705120951]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67)[99:org.eclipse.smarthome.core:0.9.0.201705120951]
	at org.eclipse.smarthome.core.thing.internal.ThingManager$9.run(ThingManager.java:710)[106:org.eclipse.smarthome.core.thing:0.9.0.201705120951]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_65]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
Caused by: java.lang.NumberFormatException: For input string: "1234567812CA12E1"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)[:1.8.0_65]
	at java.lang.Long.parseLong(Long.java:592)[:1.8.0_65]
	at com.zsmartsystems.zigbee.IeeeAddress.<init>(IeeeAddress.java:29)[183:org.openhab.binding.zigbee:2.0.0.201705102217]
	at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.initialize(ZigBeeThingHandler.java:76)[183:org.openhab.binding.zigbee:2.0.0.201705102217]
	at org.eclipse.smarthome.core.thing.internal.ThingManager$9$1.call(ThingManager.java:713)[106:org.eclipse.smarthome.core.thing:0.9.0.201705120951]
	at org.eclipse.smarthome.core.thing.internal.ThingManager$9$1.call(ThingManager.java:1)[106:org.eclipse.smarthome.core.thing:0.9.0.201705120951]
	at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[99:org.eclipse.smarthome.core:0.9.0.201705120951]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
	... 3 more

The problem was verified with multiple zigbee bulbs from the same vendor.

Representing extended PAN ids

Going through the code yesterday, I noticed the extended PAN id is stored using a Long (in ZigBeeCoordinatorHandler.java). As I understand (for example from here), the extended PAN id is a 64-bit identifier used in conjunction with the regular PAN id.

64 bits give 2^64 = 18446744073709551616 = 16^16 possible values; hence the 0xFFFFFFFFFFFFFFFF mask at ZigBeeCoordinatorHandler.java:178. Java's Long can only represent half that range, however. While it is represented using 64 bits, it's also singed; so it has a range of -2^63 to 2^63 - 1. So in order to support all possible values, we need to change something.

I can see a couple of options:

1. Change the backing type to something with a larger precision, e.g. BigInteger. This is probably the easiest;
2. As per this answer, Java 8 supports parsing and printing unsigned long values to/from the long primitive;
3. Do not store it as a number at all, but keep it as a string and convert to/from numbers where necessary.

The main issue is probably not with our code though. In the initialiseZigBee() method, the extended PAN id is passed through to the network manager, which is imported from com.zsmartsystems.zigbee.ZigBeeNetworkManager. (I wasn't able to quickly find the source of that; can I assume it was based on org.bubblecloud.zigbee.network.ZigBeeNetworkManager from zigbee4java?) That class stores the value as a long as well; so if we want to change it, we'll have to do it on both sides.

What do you think; is this worth chasing?

Add static device definitions

Currently the binding produces things completely dynamically by reading the device supported clusters, and the supported commands and attributes within these clusters. This allows devices to be supported with no definition.

It does however have some limitations in that device specific features can't be supported, and additional information can't be included. Therefore static thing definitions should be supported to either override the static definitions, or supplement them.

Innr (RS 125 GU10) bulb support

Hi,
I am using a TI CC2531EMK dongle with openHab2 to control my bulbs, a Philips Hue and an Innr GU10.
The Hue can be connected successfully while the Innr does not show up in the UI or the org.openhab.binding.zigbee logs.

If I enable the debug logs for com.zsmartsystems.zigbee I can see the device address (00158D0001C8A692) showing up but I am not able to interpret the log.

This is a log snippet shortly after I started a search in the UI (all other ZigBee devices are offline):
debug.log

I have also a "ConBee" dongle from dresden elektronik which is not compatible with openHab but has its own software "DeCONZ". Using this software I am able to connect both bulbs without any problems so i guess it should also work with openHab.

Anyway, I am not sure if this is a bulb related issue or a general bug.

Attribute reports are duplicated

Some (all?) attribute reports are duplicated in the converters although this doesn't appear to be 100% reproducable -:

2018-01-14 12:06:11.215 [DEBUG] [.z.z.d.t.ZigBeeDongleTelegesis:559  ] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=29187, profileId=260, destinationEp=0, sourceEp=11, clusterId=6, messageData=18 38 01 00 00 00 10 00, rssi=-80, lqi=255]
2018-01-14 12:06:11.215 [DEBUG] [.z.zigbee.ZigBeeNetworkManager:531  ] - RX APS: ZigBeeApsFrame [sourceAddress=29187/11, destinationAddress=0/0, profile=0104, cluster=6, addressMode=null, radius=0, sequence=0, payload=18 38 01 00 00 00 10 00]
2018-01-14 12:06:11.215 [DEBUG] [.z.zigbee.ZigBeeNetworkManager:604  ] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=56, commandId=1]
2018-01-14 12:06:11.215 [DEBUG] [.z.zigbee.ZigBeeNetworkManager:570  ] - RX CMD: ReadAttributesResponse [On/Off: 29187/11 -> 0/0, cluster=0006, TID=38, records=[ReadAttributeStatusRecord [attributeDataType=BOOLEAN, attributeIdentifier=0, status=SUCCESS, attributeValue=false]]]
2018-01-14 12:06:11.216 [DEBUG] [.z.c.ZigBeeConverterColorColor:419  ] - 0017880100ED0B0E: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=false] from {}
2018-01-14 12:06:11.216 [DEBUG] [.z.c.ZigBeeConverterColorColor:419  ] - 0017880100ED0B0E: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=false] from {}
2018-01-14 12:06:11.216 [DEBUG] [z.c.ZigBeeBaseChannelConverter:222  ] - 0017880100ED0B0E: Channel zigbee:device:5f9ece59:0017880100ed0b0e:0017880100ED0B0E_11_color_color updated to 82.20473,56.692913,0.39370078
2018-01-14 12:06:11.216 [DEBUG] [z.c.ZigBeeBaseChannelConverter:222  ] - 0017880100ED0B0E: Channel zigbee:device:5f9ece59:0017880100ed0b0e:0017880100ED0B0E_11_color_color updated to 82.20473,56.692913,0.39370078
2018-01-14 12:06:11.216 [INFO ] [smarthome.event.ItemStateEvent:52   ] - zigbee_device_5f9ece59_0017880100ed0b0e_0017880100ED0B0E_11_color_color updated to 82.20473,56.692913,0.39370078
2018-01-14 12:06:11.217 [INFO ] [smarthome.event.ItemStateEvent:52   ] - zigbee_device_5f9ece59_0017880100ed0b0e_0017880100ED0B0E_11_color_color updated to 82.20473,56.692913,0.39370078
2018-01-14 12:06:11.217 [INFO ] [ome.event.ThingStatusInfoEvent:52   ] - 'zigbee:device:5f9ece59:0017880100ed0b0e' updated: ONLINE
2018-01-14 12:06:11.218 [INFO ] [ome.event.ThingStatusInfoEvent:52   ] - 'zigbee:device:5f9ece59:0017880100ed0b0e' updated: ONLINE

Add support for atmospheric pressure

Add converter for atmospheric pressure

ST Motion sensors only show temperature channel

My ST motion sensors won’t join although they are in join mode. When I hold reset while connecting the battery, they join, but only show the temperature channel.

New Text Document (3).txt

Support for ZigBee remotes

Hi @cdjackson,

I was thinking of getting a ZigBee remote, to make switching my lights as easy as it used to be with physical switches. For example the Hue dimmer switch, the Lightify smart switch or the Trust ZigBee remote control.

Are there any plans to add support for remotes to this binding? I only see dongles and bulbs listed in the README at the moment, so I'm assuming they aren't already. What would be needed to implement such a feature?

Cheers!

The binding cannot be compiled against OSGi 4.2 (due to used generic type parameter introduced in 4.3)

In OSGi 4.3, a generic type parameter was introduced for the class org.osgi.framework.ServiceRegistration (cf. the API docs for 4.2, https://osgi.org/javadoc/r4v42/index.html, and for 4.3, https://osgi.org/javadoc/r4v43/core/index.html).

Since this generic type parameter is used in the binding, the binding cannot be compiled against a target platform that only supports OSGi 4.2.

While seeing the benefit of using the generic type parameter, I propose to remove it to become compatible with OSGi 4.2, the minimum framework version supported by Eclipse SmartHome (cf. https://www.eclipse.org/smarthome/documentation/development/guidelines.html Part C).

Unit tests not run by maven (as testSourceDirectory incorrectly configured)

In the pom.xml, the source directory for the tests is configured as <testSourceDirectory>src/test</testSourceDirectory>, although the unit tests are actually in directory src/main/test. In consequence, the maven build will not run any unit tests.

Besides that, would it be sensible to move the unit tests to /src/test/java, to align with default maven directory layout?

Add Channel for color state

Hue bulbs can operate in two color modes: Hue / Saturation / Brightness or Color Temperature / Brightness. To coordinate with other lights which onyl show white, it would be helpful to have a channel which reflects the operating mode, since this is not reflected in the available channels. The original Hue hub API seems to have a state.colormode [hs|ct] paramter for this, so it is probably transmitted somewhere.
I suggest to call it colormode with possible values ct or hs, for maximum compatibility with people who might have gotten this value from the hue hub.

Exception processing Telegesis frame

Hey Chris, wasn't sure if this is of interest for you but I figured you can always close the issue if it isn't 😉

This came up in the log today playing around with the latest nightly version of the binding (2.2.0.201712080732):

12:35:43.921 [DEBUG] [egesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=45692, profileId=260, destinationEp=0, sourceEp=10, clusterId=25, messageData=10 19 01 02 00 86, rssi=-97, lqi=255]
12:35:43.939 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=45692, profileId=260, destinationEp=0, sourceEp=10, clusterId=25, messageData=10 19 01 02 00 86, rssi=-97, lqi=255]
12:35:43.957 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=45692/10, destinationAddress=0/0, profile=0104, cluster=25, addressMode=null, radius=0, sequence=0, payload=10 19 01 02 00 86]
12:35:43.973 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=25, commandId=1]
12:35:43.994 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [OTA Upgrade: 45692/10 -> 0/0, cluster=0019, TID=19, records=[Read Attribute Status Record: attributeDataType=null, attributeIdentifier=2, status=134, attributeValue=null]]
12:35:44.036 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - D85DEF11A1002826: OTA firmware request timeout
12:35:44.047 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - D85DEF11A1002826: ZigBee node property discovery complete: {zigbee_logicaltype=ROUTER, zigbee_powerlevel=FULL, modelId=RM01, zigbee_networkaddress=45692, zigbee_powersource=MAINS, zigbee_stkversion=1, zigbee_datecode=20161209, zigbee_zclversion=1, vendor=Busch-Jaeger, zigbee_appversion=1, zigbee_powermode=RECEIVER_ON_IDLE, zigbee_powersources=[RECHARGABLE_BATTERY, DISPOSABLE_BATTERY, MAINS], hardwareVersion=0}
12:35:44.082 [DEBUG] [gbee.discovery.ZigBeeDiscoveryService] - D85DEF11A1002826: Update ZigBee device zigbee:device with bridge zigbee:coordinator_telegesis:49455deb
12:36:07.678 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 37 39 36 43 2C 43 30 35 45 2C 30 31 2C 31 32 2C 30 30 30 36 2C 30 37 3A 18 D9 0A 00 00 10 00 2C 2D 34 36 2C 46 46
12:36:07.717 [DEBUG] [egesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=49246, destinationEp=1, sourceEp=18, clusterId=6, messageData=18 D9 0A 00 00 10 00, rssi=-70, lqi=255]
12:36:07.749 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=49246, destinationEp=1, sourceEp=18, clusterId=6, messageData=18 D9 0A 00 00 10 00, rssi=-70, lqi=255]
12:36:07.769 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=31084/18, destinationAddress=0/1, profile=C05E, cluster=6, addressMode=null, radius=0, sequence=0, payload=18 D9 0A 00 00 10 00]
12:36:07.788 [DEBUG] [egesis.internal.TelegesisFrameHandler] - Exception processing Telegesis frame: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=49246, destinationEp=1, sourceEp=18, clusterId=6, messageData=18 D9 0A 00 00 10 00, rssi=-70, lqi=255]: 
java.lang.ArrayIndexOutOfBoundsException: 7
    at com.zsmartsystems.zigbee.serialization.DefaultDeserializer.readZigBeeType(DefaultDeserializer.java:170) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.zcl.ZclFieldDeserializer.deserialize(ZclFieldDeserializer.java:79) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.zdo.command.MatchDescriptorRequest.deserialize(MatchDescriptorRequest.java:205) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.ZigBeeNetworkManager.receiveZdoCommand(ZigBeeNetworkManager.java:595) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.ZigBeeNetworkManager.receiveCommand(ZigBeeNetworkManager.java:550) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.dongle.telegesis.ZigBeeDongleTelegesis.telegesisEventReceived(ZigBeeDongleTelegesis.java:573) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.dongle.telegesis.internal.TelegesisFrameHandler.notifyEventReceived(TelegesisFrameHandler.java:364) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.dongle.telegesis.internal.TelegesisFrameHandler.access$300(TelegesisFrameHandler.java:38) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
    at com.zsmartsystems.zigbee.dongle.telegesis.internal.TelegesisFrameHandler$1.run(TelegesisFrameHandler.java:125) [206:org.openhab.binding.zigbee:2.2.0.201712080732]
12:36:07.908 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 37 39 36 43 2C 43 30 35 45 2C 30 31 2C 31 32 2C 30 30 30 38 2C 30 37 3A 18 DA 0A 00 00 20 01 2C 2D 35 35 2C 46 46
12:36:07.925 [DEBUG] [egesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=49246, destinationEp=1, sourceEp=18, clusterId=8, messageData=18 DA 0A 00 00 20 01, rssi=-85, lqi=255]
12:36:07.945 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=49246, destinationEp=1, sourceEp=18, clusterId=8, messageData=18 DA 0A 00 00 20 01, rssi=-85, lqi=255]
12:36:07.991 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=31084/18, destinationAddress=0/1, profile=C05E, cluster=8, addressMode=null, radius=0, sequence=0, payload=18 DA 0A 00 00 20 01]
12:36:08.008 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - Incoming message did not translate to command.
12:36:17.578 [DEBUG] [stems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Starting mesh update

New channel discovery mechanism bugs

Here is the log where the dongle was offline, but messages were still happening in the background:
dongleoffline.txt
Here is an example of the binding trying to communicate with my Hue motion sensor:
Huenotfound.txt

Telegesis Stick Configuration

Does anyone establish a successful connection to the Telegesis ETRX3USB stick in openHab?

I can start the binding but no devices are found during scan.

My system is a Raspberry PI with Ubuntu.

My system settings:
export EXTRA_JAVA_OPTS=-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0
sudo chmod 666 /dev/ttyUSB0

I installed the the Zigbee binding snapshot: org.openhab.binding.zigbee-2.2.0-SNAPSHOT.jar

Set the debug log level:
log:set DEBUG org.openhab.binding.zigbee

openHab logfile:

[DEBUG] [zigbee.internal.ZigBeeHandlerFactory] - Creating coordinator handler for org.eclipse.smarthome.core.thing.internal.BridgeImpl@d035b982
[DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Creating ZigBee discovery service for zigbee:coordinator_telegesis:9a1e58bd
[DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Activating ZigBee discovery service for zigbee:coordinator_telegesis:9a1e58bd
[DEBUG] [org.openhab.binding.zigbee          ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=347, service.bundleid=224, service.scope=singleton} - org.openhab.binding.zigbee
[DEBUG] [org.openhab.binding.zigbee          ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.firmware.FirmwareUpdateHandler}={service.id=348, service.bundleid=224, service.scope=singleton} - org.openhab.binding.zigbee
[DEBUG] [er.ZigBeeCoordinatorTelegesisHandler] - Initializing ZigBee Telegesis serial bridge handler.
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_telegesis:9a1e58bd].
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Channel -1
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - PANID 0
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - EPANID 0000000000000000
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key null
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising network
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Created random ZigBee PAN ID [3165].
[ome.core.thing.internal.ThingManager] - Initializing handler for thing 'zigbee:coordinator_telegesis:9a1e58bd' takes more than 5000ms.
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Created random ZigBee extended PAN ID [A74769766C2B9E92].
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key String 
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key initialised 7070CCB0ECE8D086AACB01EBF9099995
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key final array 7070CCB0ECE8D086AACB01EBF9099995
[DEBUG] [er.ZigBeeCoordinatorTelegesisHandler] - ZigBee Coordinator Telegesis opening Port:'/dev/ttyUSB0' PAN:3165, EPAN:A74769766C2B9E92, Channel:-1
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee network starting
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising ZigBee coordinator
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Key initialise 7070CCB0ECE8D086AACB01EBF9099995
[DEBUG] [ing.zigbee.internal.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyUSB0] at 19200 baud, flow control FLOWCONTROL_OUT_NONE.
[INFO ] [ing.zigbee.internal.ZigBeeSerialPort] - Serial port [/dev/ttyUSB0] is initialized.
[DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: done.
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - initResponse is JOINED
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - initializeNetwork is true
[DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialise done....... 25  12645  A74769766C2B9E92
[DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Starting ZigBee scan for zigbee:coordinator_telegesis:9a1e58bd

How can I verify that the Telegesis stick works and where the problem might originate?

[Feature Request] Add support for transition time

I'm using the binding for some GE Link bulbs, which I had previously configured through SmartThings to slow fade when turned off and when changing the dim setting (IIRC, these were different settings). So, I know these bulbs support it... and it would be very nice to be able to change the setting after now moving the bulbs around :). Apparently, the settings persist after a reset.

Binding startup and discovery is too chatty

When the binding starts and devices are discovered, it will request static information such as model, manufacturer, versions etc, even if they are already known. This can cause a lot of noise on the network - especially for larger networks.

A smarter approach should be taken so as not request data that is known, and will not change.

See also some discussion on #93

CT Channel should only be rendered if CT attribute supported

The CT channel should only be rendered if the appropriate commands and attributes are supported.

ZigBeeCoordinatorHandler must not use bundleContext

The bundleContext field will be removed from the BaseThingHandler at some point in time and it is not intended to be used by bindings.
The ZigBeeCoordinatorHandler uses it in order to register a discovery service. This must be changed to registering it in the handler factory instead as it is e.g. done in the Hue binding (and many others) as well.

Add documentation for textual config

Hi,

In most of openhab configs I've seen until now, the config rely only on .things and .items files.
The documentation does not mention how to write a correct config file for this binding.
I could be very helpful to give, at least, a sample config.

Regards,
Albin

Binding continues to run after being stopped

Zigbee binding 2.3.0.201801042145

I've seen this on previous versions too. After doing a bundle:stop, there are still messages coming up in the log for org.openhab.binding.zigbee. These messages continue after the binding is started again. I'm now stopping OH to upgrade or restart the binding.

2018-01-04 21:12:24.023 [DEBUG] [org.openhab.binding.zigbee                        ] - BundleEvent STOPPED - org.openhab.binding.zigbee
2018-01-04 21:12:28.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:29.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:32.972 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:38.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:39.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:48.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:49.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:58.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:12:59.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:08.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:09.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:18.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:19.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:28.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:29.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:38.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:39.483 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...
2018-01-04 21:13:48.291 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - null: Polling...

No control of paired devices after binding has been running for hours

Binding release: 2.3.0.201801042145

OpenHAB2 release: openHAB 2.3.0~20180104230956-1 (Build #1163)

Problem Description
After starting OpenHAB2 SNAPSHOT 2.3.0, all paired devices can be controlled. My devices are:

• a CC2531 ZigBee dongle
• a Tradfri warm white bulb
• 2 SengLED color temperature settable bulbs
• 1 SengLED warm white bulb

The only anomaly noted after OH2 has been started is that occasionally some commands are not acted on when they are issued, there is a noticeable -- several second -- delay before a command action is noted by observing the target device.

About seven hours after starting OH2, no device commands have any effect. No warnings and no errors are found in the ZigBee binding log.

Exception creating channels

Zigbee binding 2.3.0.201801032157
OH 2.3 snapshot 1159

Possibly related to this recent PR... #68? Sorry, I was not in debug at the time.

2018-01-04 01:09:07.574 [ERROR] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - 7CE5240000139646: Exception creating channels
java.lang.ClassCastException: com.zsmartsystems.zigbee.zcl.clusters.general.ReportAttributesCommand cannot be cast to com.zsmartsystems.zigbee.zcl.clusters.general.ReadAttributesResponse
        at com.zsmartsystems.zigbee.zcl.ZclCluster.readSync(ZclCluster.java:214) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at com.zsmartsystems.zigbee.zcl.clusters.ZclOnOffCluster.getOnOff(ZclOnOffCluster.java:113) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.converter.ZigBeeConverterSwitchLevel.initializeConverter(ZigBeeConverterSwitchLevel.java:93) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:229) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:171) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:165) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [16:org.openhab.binding.zigbee:2.3.0.201801032157]
        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) [?:?]

Trust Lamp color channel type not identified

My Trust branded lamps leave an warn message in the logs because the color type is not known, but assumed. The assumed Hue/Sat seems to work. See attached log.
Devices are 00158D0000AF412C and 00158D00011E871A
New Text Document (4).txt

Build broken

Hi Chris

Commit ac176d7 removed the THING_PROPERTY_PERMITJOINING constant from ZigBeeBindingConstants - not sure if this was deliberate or not - but there are usages of the constant in other classes so the mvn build currently fails.

Discovery handler is including the coordinator in new things

Coordinator should be ignored.

Switch does not set HSB and Brightness Channels to zero

Outline

When trying to use a switch item on a Colour or Brightness channel, I notice that the 'B' of the HSB, and the Brightness linked items never go to zero, only to very low values 0.39370078. Since they're non-zero, this seems to flick the switch back on after a very short time after it polls. See the event log for a logical summary.

Could be related to #81 but since I've got a slightly different result I thought it be best to make a new issue.

Same thing happens for Brightness channels for brightness only bulbs.

Configuration

Configuration	Description
Coordinator used	Telegisis
openHAB version	2.3.0-SNAPSHOT (#1176) [2.3.0~20180109005608]
Hardware	RPi 3
Memory	1GB
Java version	Zulu Embedded 8.25.0.76-linux-aarch32hf (build 1.8.0_152-b76)
Devices	3 Hue Colour Lights, 3 Hue Brightness Lights

Logs

Event Log

2018-01-09 15:49:10.194 [ome.event.ItemCommandEvent] - Item 'Bedroom_Light_Switch' received command OFF
2018-01-09 15:49:10.205 [vent.ItemStateChangedEvent] - Bedroom_Light_Switch changed from ON to OFF

2018-01-09 15:49:12.479 [vent.ItemStateChangedEvent] - Bedroom_Light_Colour changed from 82.20473,55.51181,100.0 to 82.20473,55.51181,0.39370078
2018-01-09 15:49:12.483 [vent.ItemStateChangedEvent] - Bedroom_Light_Dimmer changed from 100.0 to 0.39370078
2018-01-09 15:49:12.514 [vent.ItemStateChangedEvent] - Bedroom_Light_Switch changed from OFF to ON

Zigbee Log

switch_conflict.log

Only initialise converter when channel gets linked

This could help improve startup performance (maybe!) and should generally reduce traffic if the user isn't linking all channels (which most probably do, so maybe the benefit is minimal?).

HUE motion sensor: request LED indicator configuration

When paired to a HUE bridge, the LED on the sensor is configured to just blink in case of battery is low or empty (orange==low, red==almost empty, steady red==no connection to coordinator).

When connected to the Zigbee binding, the LED flashes every time when motion is detected.
This is somehow distracting/annoying.

It seems, that Philips has some attribute in the basic cluster
0x0000/0x0033* config.ledindication
which likely is intended to set the “LED mode”.

From your sniffer, you should see that the Hue bridge sets up bindings to the bridge for the following clusters on endpoint 02:

- 0x0000 (Basic)

- 0x0001 (Power)

- 0x0400 (Illuminance Measurement)

- 0x0402 (Temperature Measurement)

- 0x0406 (Occupancy Sensing)

Then, it sets up attribute reporting for the following attributes:

- 0x0000/0x0032* config.usertest

- 0x0000/0x0033* config.ledindication

- 0x0001/0x0021 config.battery

- 0x0400/0x0000 state.lightlevel

- 0x0402/0x0000 state.temperature

- 0x0406/0x0000 state.presence

- 0x0406/0x0030* config.sensitivity

*) these are manufacturer specific attributes.`

So would it be possible to make the LED configurable, or switch it off completely, or initialize it just similar to Philips (just blink if battery is weak)?

See: https://developers.meethue.com/content/philips-hue-motion-sensor-and-zigbee-attributes
See also: https://community.openhab.org/t/zigbee-binding/15763/735

[Busch-Jaeger 6735/01] Device becomes offline/unreachable

I've noticed that the battery-operated BJ control element becomes unresponsive after working just fine for maybe a day, or immediately if restarting OH.
I think you mentioned something that sounded a bit similar with another battery powered device (I think a ST motion sensor)?

Currently I have to remove the device in PaperUI and add it back to make it work again.

I still have to gather a debug log and will post it as soon as I can catch it. So far I can only say that the device doesn't respond to the node discovery request on restart:

11318: Node discovery request IEEE_ADDRESS failed. Wait before retry.

Color converter potential OnOff / LevelControl issue

As seen in #81 use of OnOffCluster to turn a device off can result in a discrepancy between OnOff and LevelControl reports.

Checking the ZCL spec, it seems that the ZclCluster.xxxWithOnOff() methods should be used to ensure synchronisation between the two clusters.

@puzzle-star do you have any thoughts on this?

Dimmer items don't display correct values

OH 2.3.0 build 1191
Zigbee 2.3.0.201801200902

I have rules that set the lights to a specific level, and don't adjust them if they are not at that specific level. This way, I can manually turn the light on (which sets it to 100), and the light won't turn off when motion stops or be adjusted by lux changes. I noticed this wasn't working for my Zigbee bulbs, and that when I send 99 through the rule, the lights are reporting 98 in the logs and UI. It looks like there may be a rounding issue in ZigBeeConverterSwitchLevel.java.

Here is a light being set to 99 through a rule, which is sent to the device, but then the bulb reports back 98...

2018-01-21 17:14:59.361 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - 7CE524000011F4D1: Command for channel zigbee:device:9b51c72d:7ce524000011f4d1:7CE524000011F4D1_1_switch_level --> 99
2018-01-21 17:14:59.788 [DEBUG] [inding.zigbee.converter.ZigBeeConverterSwitchLevel] - 7CE524000011F4D1: ZigBee attribute reports ZclAttribute [cluster=LEVEL_CONTROL, id=0, name=CurrentLevel, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=1]
2018-01-21 17:14:59.789 [DEBUG] [inding.zigbee.converter.ZigBeeConverterSwitchLevel] - 7CE524000011F4D1: ZigBee attribute reports ZclAttribute [cluster=LEVEL_CONTROL, id=0, name=CurrentLevel, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=58]
2018-01-21 17:14:59.790 [DEBUG] [inding.zigbee.converter.ZigBeeBaseChannelConverter] - 7CE524000011F4D1: Channel zigbee:device:9b51c72d:7ce524000011f4d1:7CE524000011F4D1_1_switch_level updated to 22
2018-01-21 17:14:59.789 [DEBUG] [inding.zigbee.converter.ZigBeeBaseChannelConverter] - 7CE524000011F4D1: Channel zigbee:device:9b51c72d:7ce524000011f4d1:7CE524000011F4D1_1_switch_level updated to 22
2018-01-21 17:15:00.756 [DEBUG] [inding.zigbee.converter.ZigBeeConverterSwitchLevel] - 7CE524000011F4D1: ZigBee attribute reports ZclAttribute [cluster=LEVEL_CONTROL, id=0, name=CurrentLevel, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=251]
2018-01-21 17:15:00.757 [DEBUG] [inding.zigbee.converter.ZigBeeBaseChannelConverter] - 7CE524000011F4D1: Channel zigbee:device:9b51c72d:7ce524000011f4d1:7CE524000011F4D1_1_switch_level updated to 98

Since lastValue=251 (98.8), it looks like this...

org.openhab.binding.zigbee/src/main/java/org/openhab/binding/zigbee/converter/ZigBeeConverterSwitchLevel.java

Line 128 in 25dfb38

updateChannelState(new PercentType(value * 100 / 254));

... is truncating to an integer when converting to PercentType or because of integer division. Either way, adding 0.5 to the value (like you have in the outbound command at line 100) should fix this? In looking at the scripts that I had used with a Wink hub, this is basically how I handled refreshing values correctly from the hub.

Telegesis Coordinator not correctly initialized

This is from my log when adding a Telegesis coordinator:

17:35:09.597 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_telegesis:67d97600' changed from UNINITIALIZED to INITIALIZING
17:35:09.639 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_telegesis:67d97600' has been updated.
17:35:09.643 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_telegesis:67d97600' has been updated.
17:35:09.647 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_telegesis:67d97600' has been updated.
17:35:09.666 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_telegesis:67d97600' changed from INITIALIZING to UNKNOWN
17:35:09.747 [INFO ] [arthome.event.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:coordinator_telegesis:67d97600 changed to UNKNOWN.
17:35:13.313 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_telegesis:67d97600' changed from UNKNOWN to OFFLINE: Failed to startup ZigBee transport layer
17:35:15.273 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_telegesis:67d97600' changed from OFFLINE: Failed to startup ZigBee transport layer to ONLINE
17:35:15.569 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_telegesis:67d97600' changed from ONLINE to OFFLINE: Failed to startup ZigBee transport layer
17:35:16.937 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_telegesis:67d97600' has been updated.
17:35:16.943 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_telegesis:67d97600' has been updated.

As you can see, it briefly goes to ONLINE, but in the end it is set to OFFLINE (although it managed to start up the transport layer). Editing and saving the coordinator Thing made it come ONLINE correctly.
I assume that there are some timing issues during initialization, which might be due to the rather many Thing updates that are done in that process (could those be reduced?).

Ieee Address for XXXX returned null

ZigBee Binding v2.1.0.201705152139

When a new device joins the controller, the IEEE Address Request never returns, and the device is not added to OpenHAB. This is happening with both a GE Link bulk and a Philips Hue White and Color bulb.

You can see that the end device is in the neighbor list of the controller (with the IEEE address), but it still tries to do an IEEE Address Request on it which subsequently fails. Couldn't it just use the IEEE Address from the neighbor table instead?

2017-05-17 07:05:56.571 [DEBUG] [ee.internal.ZigBeeNetworkMeshMonitor] - 0: Starting mesh update
2017-05-17 07:05:56.573 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - Ieee Address for 8866 returned null
2017-05-17 07:05:56.574 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 0/0, cluster=0031, TID=06, startIndex=0]
2017-05-17 07:05:56.574 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 8866: Discovery request IEEE_ADDRESS failed. Wait before retry.
2017-05-17 07:05:56.575 [DEBUG] [31.network.impl.CommandInterfaceImpl] - ->  AF_DATA_REQUEST (Packet: subsystem=null, length=12, apiId=24 01, data=FE 0C 24 01 00 00 00 00 31 00 06 30 1F 02 00 00 33, checksum=33, error=false)
2017-05-17 07:05:56.593 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-  AF_DATA_SRSP (FE 01 64 01 00 64)
2017-05-17 07:05:56.604 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-- ZToolPacket (FE 23 45 FF 00 00 00 31 80 00 00 00 00 00 01 00 01 00 B0 47 45 50 C0 D9 7E 57 AD 26 10 01 88 17 00 A2 22 15 02 01 AA C3)
2017-05-17 07:05:56.606 [DEBUG] [31.network.impl.CommandInterfaceImpl] - Received Async Cmd: Packet: subsystem=null, length=35, apiId=45 FF, data=FE 23 45 FF 00 00 00 31 80 00 00 00 00 00 01 00 01 00 B0 47 45 50 C0 D9 7E 57 AD 26 10 01 88 17 00 A2 22 15 02 01 AA C3, checksum=C3, error=false
2017-05-17 07:05:56.626 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ManagementLqiResponse [0/0 -> 0/0, cluster=8031, TID=NULL, status=SUCCESS, neighborTableEntries=1, startIndex=0, neighborTableListCount=1, neighborTableList=[NeighborTable [extendedPanId=7ED9C0504547B000, extendedAddress=001788011026AD57, networkAddress=8866, deviceType=ROUTER, rxOnWhenIdle=RX_ON, relationship=CHILD, permitJoining=UNKNOWN, depth=1, lqi=170]]]
2017-05-17 07:05:56.634 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: IeeeAddressRequest [0/0 -> 0/0, cluster=0001, TID=07, nwkAddrOfInterest=0, requestType=1, startIndex=0]
2017-05-17 07:05:56.636 [DEBUG] [31.network.impl.CommandInterfaceImpl] - ->  AF_DATA_REQUEST (Packet: subsystem=null, length=15, apiId=24 01, data=FE 0F 24 01 00 00 00 00 01 00 07 30 1F 05 00 00 00 01 00 07, checksum=07, error=false)
2017-05-17 07:05:56.639 [DEBUG] [ee.internal.ZigBeeNetworkMeshMonitor] - 8866: Starting mesh update
2017-05-17 07:05:56.640 [DEBUG] [ee.internal.ZigBeeNetworkMeshMonitor] - 8866: ZigBee node not found during mesh update
2017-05-17 07:05:56.660 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-  AF_DATA_SRSP (FE 01 64 01 00 64)
2017-05-17 07:05:56.670 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-- ZToolPacket (FE 18 45 FF 00 00 00 01 80 00 00 00 00 00 7C 04 EB 09 00 4B 12 00 00 00 01 00 A2 22 61)
2017-05-17 07:05:56.672 [DEBUG] [31.network.impl.CommandInterfaceImpl] - Received Async Cmd: Packet: subsystem=null, length=24, apiId=45 FF, data=FE 18 45 FF 00 00 00 01 80 00 00 00 00 00 7C 04 EB 09 00 4B 12 00 00 00 01 00 A2 22 61, checksum=61, error=false
2017-05-17 07:05:56.675 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: IeeeAddressResponse [0/0 -> 0/0, cluster=8001, TID=NULL, status=SUCCESS, ieeeAddrRemoteDev=00124B0009EB047C, nwkAddrRemoteDev=0, numAssocDev=1, startIndex=0, nwkAddrAssocDevList=[8866]]
2017-05-17 07:05:56.682 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementRoutingRequest [0/0 -> 0/0, cluster=0032, TID=08, startIndex=0]
2017-05-17 07:05:56.684 [DEBUG] [31.network.impl.CommandInterfaceImpl] - ->  AF_DATA_REQUEST (Packet: subsystem=null, length=12, apiId=24 01, data=FE 0C 24 01 00 00 00 00 32 00 08 30 1F 02 00 00 3E, checksum=3E, error=false)
2017-05-17 07:05:56.706 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-  AF_DATA_SRSP (FE 01 64 01 00 64)
2017-05-17 07:05:56.713 [DEBUG] [31.network.impl.CommandInterfaceImpl] - <-- ZToolPacket (FE 0D 45 FF 00 00 00 32 80 00 00 00 00 00 00 00 00 05)
2017-05-17 07:05:56.715 [DEBUG] [31.network.impl.CommandInterfaceImpl] - Received Async Cmd: Packet: subsystem=null, length=13, apiId=45 FF, data=FE 0D 45 FF 00 00 00 32 80 00 00 00 00 00 00 00 00 05, checksum=05, error=false
2017-05-17 07:05:56.720 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ManagementRoutingResponse [0/0 -> 0/0, cluster=8032, TID=NULL, status=SUCCESS, routingTableEntries=0, startIndex=0, routingTableListCount=0, routingTableList=[]]
2017-05-17 07:05:56.739 [DEBUG] [ee.internal.ZigBeeNetworkMeshMonitor] - 0: Ending mesh update

BJ 6711 U relay state not updated

As discussed in the community thread, the state of the Busch-Jaeger 6711 U relay does not get updated in OH if the physical switch is used to change its state.

Here's the requested log:
oh_zigbee_binding_debug.log.zip

I've also changed the state of the relay to on/off twice. First time via OH, second time via the physical switch, should be at the end of the log.

IO exception on dongle initialization

Trying my TI dongle, I get the following exception on startup (on my Mac):

2017-05-09 15:46:15.559 [DEBUG] [ZigBeeCoordinatorCC2531Handler:143  ] - Opening ZigBee CC2531 serial port
2017-05-09 15:46:15.559 [DEBUG] [ZigBeeCoordinatorCC2531Handler:95   ] - Connecting to serial port [/dev/tty.usbmodem1421]
2017-05-09 15:46:15.593 [INFO ] [ZigBeeCoordinatorCC2531Handler:110  ] - Serial port [/dev/tty.usbmodem1421] is initialized.
2017-05-09 15:46:15.605 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:301  ] - initResponse is JOINED
2017-05-09 15:46:15.605 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:308  ] - initializeNetwork is true
2017-05-09 15:46:15.889 [ERROR] [z.d.c.n.i.CommandInterfaceImpl:136  ] - IO exception in packet parsing.java.io.IOException: Device not configured in readByte
	at gnu.io.RXTXPort.readByte(Native Method)
	at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1286)
	at com.zsmartsystems.zigbee.dongle.cc2531.zigbee.util.MarkableInputStream.read(MarkableInputStream.java:100)
	at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketParser.run(ZToolPacketParser.java:102)
	at java.lang.Thread.run(Thread.java:745)

What does that want to tell me?

Add support for relative humidity

Add relative humidity converter

Initialization of CC2531 coordinator always fails

With the 2.2.0.201712022337 build of the ZigBee Binding, CC2531 coordinator initialization always fails. This is with openhab2-2.2.0_SNAPSHOT build #1106. I am attaching a TRACE level log output from the time the ZigBee bundle was stopped and then started.

I see that the binding attempts to open the coordinator's serial port a second time after it has already opened it earlier in the bundle startup sequence.

zigbee-2.2.0.201712022337.log

Add support for Philips Hue Dimmer switch

See zsmartsystems/com.zsmartsystems.zigbee#225

Additional code required once the above has been implemented.

Telegesis: Devices becoming unresponsive

After some time devices won't respond to commands anymore. The corresponding things are still online in OH but stop working. Judging from the comments in the community thread this problem seems to affect other users as well.

Is it possible this is caused by the growing TX queue also discussed here?

Sending a command does nothing:

10:35:28.616 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'LivingroomLights1' received command ON
10:35:28.630 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - D85DEF11A1002826: Command for channel zigbee:device:49455deb:d85def11a1002826:D85DEF11A1002826_18_switch_onoff --> ON
10:35:28.632 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingroomLights1 changed from OFF to ON
10:35:28.635 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - TX CMD: OnCommand [On/Off: 0/0 -> 45692/18, cluster=0006, TID=45]
10:35:28.639 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - TX ZCL: ZclHeader [frameType=CLUSTER_SPECIFIC_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=false, manufacturerCode=0, sequenceNumber=69, commandId=1]
10:35:28.648 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/1, destinationAddress=45692/18, profile=0104, cluster=6, addressMode=DEVICE, radius=31, sequence=69, payload=01 45 01]
10:35:28.652 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=45692, sourceEp=0, destEp=18, profileId=260, clusterId=6, messageData=01 45 01, messageId=null]
10:35:28.655 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1587

And the tx queue is just growing and growing:

2017-12-11 10:37:06.178 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Starting mesh update
2017-12-11 10:37:06.181 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 0/0, cluster=0031, TID=4E, startIndex=0]
2017-12-11 10:37:06.184 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=49, addressMode=DEVICE, radius=31, sequence=78, payload=00 00]
2017-12-11 10:37:06.186 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=49, messageData=00 00, messageId=null]
2017-12-11 10:37:06.189 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1596
2017-12-11 10:37:16.191 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: ManagementLqiRequest returned null
2017-12-11 10:37:16.194 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: IeeeAddressRequest [0/0 -> 0/0, cluster=0001, TID=4F, nwkAddrOfInterest=0, requestType=1, startIndex=0]
2017-12-11 10:37:16.197 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=1, addressMode=DEVICE, radius=31, sequence=79, payload=00 00 00 01 00]
2017-12-11 10:37:16.199 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 00 00 01 00, messageId=null]
2017-12-11 10:37:16.201 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1597
2017-12-11 10:37:26.204 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Ieee Address request returned null
2017-12-11 10:37:26.207 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementRoutingRequest [0/0 -> 0/0, cluster=0032, TID=50, startIndex=0]
2017-12-11 10:37:26.210 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=50, addressMode=DEVICE, radius=31, sequence=80, payload=00 00]
2017-12-11 10:37:26.213 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=50, messageData=00 00, messageId=null]
2017-12-11 10:37:26.215 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1598
2017-12-11 10:37:36.218 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: ManagementRoutingRequest returned null
2017-12-11 10:37:36.220 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Ending mesh update
2017-12-11 10:38:36.178 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Starting mesh update
2017-12-11 10:38:36.182 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 0/0, cluster=0031, TID=51, startIndex=0]
2017-12-11 10:38:36.185 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=49, addressMode=DEVICE, radius=31, sequence=81, payload=00 00]
2017-12-11 10:38:36.188 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=49, messageData=00 00, messageId=null]
2017-12-11 10:38:36.191 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1599
2017-12-11 10:38:46.193 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: ManagementLqiRequest returned null
2017-12-11 10:38:46.202 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: IeeeAddressRequest [0/0 -> 0/0, cluster=0001, TID=52, nwkAddrOfInterest=0, requestType=1, startIndex=0]
2017-12-11 10:38:46.211 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=1, addressMode=DEVICE, radius=31, sequence=82, payload=00 00 00 01 00]
2017-12-11 10:38:46.219 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 00 00 01 00, messageId=null]
2017-12-11 10:38:46.226 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1600
2017-12-11 10:38:56.239 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Ieee Address request returned null
2017-12-11 10:38:56.247 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementRoutingRequest [0/0 -> 0/0, cluster=0032, TID=53, startIndex=0]
2017-12-11 10:38:56.255 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=50, addressMode=DEVICE, radius=31, sequence=83, payload=00 00]
2017-12-11 10:38:56.264 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=50, messageData=00 00, messageId=null]
2017-12-11 10:38:56.277 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1601
2017-12-11 10:39:06.313 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: ManagementRoutingRequest returned null
2017-12-11 10:39:06.318 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Ending mesh update
2017-12-11 10:40:06.178 [DEBUG] [tems.zigbee.ZigBeeNetworkMeshMonitor] - 0: Starting mesh update
2017-12-11 10:40:06.181 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 0/0, cluster=0031, TID=54, startIndex=0]
2017-12-11 10:40:06.183 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=49, addressMode=DEVICE, radius=31, sequence=84, payload=00 00]
2017-12-11 10:40:06.187 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=0, sourceEp=0, destEp=0, profileId=0, clusterId=49, messageData=00 00, messageId=null]
2017-12-11 10:40:06.189 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1602

Here is a full debug log from OH startup up to a queue count of 8, maybe that helps. Queue seems to start growing around 2017-12-10 14:55:06:
zigbee_tx_queue_growing.log.zip

Exception on SwitchOnoff

When i toggle the switch from OH the following exception occurs

Exception in thread "pool-52-thread-25" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Boolean #011at org.openhab.binding.zigbee.converter.ZigBeeConverterSwitchOnoff.attributeUpdated(ZigBeeConverterSwitchOnoff.java:127) #011at com.zsmartsystems.zigbee.zcl.ZclCluster$4.run(ZclCluster.java:777) #011at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) #011at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) #011at java.lang.Thread.run(Thread.java:748)

Looks like the SwitchOnoff Converter expects a Bool but it is receiving a Integer, may I suggest that the value should be checked for the type, the same way its done in the handleCommand function in the same file?

Thanks.

NPE renaming a thing

Caught this in the log renaming a thing in PaperUI:

20:20:20.207 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.binding.zigbee.handler.ZigBeeThingHandler@98ae78': null
java.lang.NullPointerException: null
    at org.openhab.binding.zigbee.converter.ZigBeeConverterSwitchOnoff.disposeConverter(ZigBeeConverterSwitchOnoff.java:106) [206:org.openhab.binding.zigbee:2.3.0.201801211741]
    at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.dispose(ZigBeeThingHandler.java:293) [206:org.openhab.binding.zigbee:2.3.0.201801211741]
    at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:269) [116:org.eclipse.smarthome.core.thing:0.10.0.201801152239]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
    at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [109:org.eclipse.smarthome.core:0.10.0.201801152239]
    at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [109:org.eclipse.smarthome.core:0.10.0.201801152239]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]

Refactor each dongle into separate bundle

The binding needs to be split into separate packages to make it more manageable/extensible, and reduce installation footprint. There should be a single bundle containing the majority of the code (ZigBee stack, thing handler, converters...) and another bundle with just the dongle driver JAR, the bridge handler and XML.

@kaikreuzer your thoughts would be very welcome with the following...

My initial thinking was to use fragments for the dongle bundles - this should solve getting all the bits in one place, the XML file should be read fine. The HandlerFactory could have a method to directly register a new handler (eg registerBridge(BridgeTypeUID, BridgeHandler))... Given the discovery service is instantiated from the factory, we can pass in the same list of bridge UIDs...

I think this ought to work ok and hopefully you won't tell me it violates too many OSGi principals ;)

This is a similar issue to the discussion we had a few months back for BLE and I think you said you were looking at other possible extensions to the framework to support this sort of structure (??) so any further suggestions welcome.

I'm not in a huge hurry to do this, but when you find an elusive "few minutes" I'd welcome your thoughts...

Exception creating channels

OH 2.3.0 snapshot build 1202
HUSBZB-1 (Ember)

I updated from 2.3.0.201801281348 to 2.3.0.201801311135 and only the controller comes online. No devices are controllable. Restarting did not help. The log has the following:

2018-01-31 23:18:35.759 [ERROR] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - 7CE52400001272D3: Exception creating channels 
java.lang.NullPointerException: null
	at com.zsmartsystems.zigbee.zcl.ZclCluster.bind(ZclCluster.java:437) [16:org.openhab.binding.zigbee:2.3.0.201801311135]
	at org.openhab.binding.zigbee.internal.converter.ZigBeeConverterSwitchLevel.initializeConverter(ZigBeeConverterSwitchLevel.java:51) [16:org.openhab.binding.zigbee:2.3.0.201801311135]
	at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:232) [16:org.openhab.binding.zigbee:2.3.0.201801311135]
	at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:173) [16:org.openhab.binding.zigbee:2.3.0.201801311135]
	at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:167) [16:org.openhab.binding.zigbee:2.3.0.201801311135]
	at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [16:org.openhab.binding.zigbee:2.3.0.201801311135]
	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) [?:?]

013118 exceptions and unresponsive.zip

startDeviceDiscovery() not fully implemented

Hey @cdjackson, I am trying to add a custom lamp, I had it working back in 2016 release, but after you refactored the code I can not seem to get it discovered. I poked around in the code and found that inside startDeviceDiscovery() method networkManager.permitJoin(60); does not get called for some strange reason. 'permitJoin()' method is declared like this:

public void permitJoin(final int duration) {
        logger.debug("Permit join for {} seconds.", duration);
        permitJoin(new ZigBeeDeviceAddress(ZigBeeBroadcastDestination.BROADCAST_ROUTERS_AND_COORD.getKey()), duration);
    }

So it should log a message on DEBUG level, but it doesn't and if I add a few more log messages like this:

        logger.debug("Allowing devices to join.");
        networkManager.permitJoin(60);
        logger.debug("Did networkManager log something?")

I only get this:

14:00:54.121 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Allowing devices to join.
14:00:54.156 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Did networkManager log something?

Also as the title claims startDeviceDiscovery() method hasn't been fully implemented. I can see that you wanted to add devices from ZigBeeDevice list, but never implemented it there. Have you done so somewhere else in the code? Furthermore what did you want to move to discovery handler from this method? The whole method or just the permitJoin() part? What did you want to do with ZigBeeDiscoveryManager?

Consolidated channels reporting conflicting attributes

This might have to do with channel consolidation, the reported attributes are inverted wrong depending on the channel.

The On/Off channel seems to be correct, the Level channel is always reporting the same value.

14:17:50.513 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: 45692/18 -> 0/1, cluster=0006, TID=D7, reports=[Attribute Report: attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=false]]
14:17:50.531 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingroomLights1 changed from ON to OFF


14:17:50.568 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: 45692/18 -> 0/1, cluster=0008, TID=D8, reports=[Attribute Report: attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=254]]
14:17:50.581 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingroomLights1 changed from OFF to ON

14:47:52.224 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: 45692/18 -> 0/1, cluster=0006, TID=DD, reports=[Attribute Report: attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]

14:47:52.265 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: 45692/18 -> 0/1, cluster=0008, TID=DE, reports=[Attribute Report: attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=254]]

complete log including startup

Discovery handler doesn't update inbox

I'm not sure if this should be "always" doesn't update the inbox, or if there's some conditional issue, but often the inbox remains with the "unknown" name and is not updated after the device properties are discovered.

Unable to control devices after 30-50 minutes

I have reported this previously in the forum. My Ember stick (nortel) will no longer control any devices after running for less than an hour. It will still register changes on the network. The following log shows me commanding brightness on a lamp to zero at 11:13:33. In Paper UI, the brightness updates to 0, however, the lamp itself does not react. Meanwhile, you can see a motion sensor updating, which is acted upon correctly by openhab.

Properties of the zigbee thing I tried to control:

zigbee_logicaltype	ROUTER
zigbee_powerlevel	FULL
modelId	LCT010
zigbee_networkaddress	27819
zigbee_powersource	MAINS
zigbee_stkversion	1
zigbee_datecode	20160906
zigbee_zclversion	1
zigbee_routes	[]
zigbee_lastupdate
vendor	Philips
zigbee_appversion	2
zigbee_permitjoining	false
zigbee_powermode	RECEIVER_ON_IDLE
zigbee_powersources	[MAINS, RECHARGABLE_BATTERY, DISPOSABLE_BATTERY]
hardwareVersion	1
zigbee_neighbors	[]
firmwareVersion	01000B0E
zigbee_devices	[]

New Text Document.txt

[Busch-Jaeger 6711] On/Off state of level channel is wrong

Following up on your comment, it looks like your assumption was right.

It seems like the BJ relays are intermittently reporting wrong level values:

10:18:43.890 [DEBUG] [.converter.ZigBeeConverterSwitchLevel] - D85DEF11A1001973: ZigBee attribute reports ZclAttribute [cluster=LEVEL_CONTROL, id=0, name=CurrentLevel, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=1]
10:18:43.910 [DEBUG] [.converter.ZigBeeBaseChannelConverter] - D85DEF11A1001973: Channel zigbee:device:cb2e62e2:d85def11a1001973:D85DEF11A1001973_18_switch_level updated to 0

09:27:23.647 [DEBUG] [.converter.ZigBeeConverterSwitchLevel] - D85DEF11A1002826: ZigBee attribute reports ZclAttribute [cluster=LEVEL_CONTROL, id=0, name=CurrentLevel, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=2]
09:27:23.653 [DEBUG] [.converter.ZigBeeBaseChannelConverter] - D85DEF11A1002826: Channel zigbee:device:cb2e62e2:d85def11a1002826:D85DEF11A1002826_18_switch_level updated to 1

Maybe you could make the threshold for the Off state configurable?

Color lights supporting only XY command set do not work (i.e. IKEA Tradfri)

The current color channel converter implementation only supports Hue/Saturation commands and attributes, so some lights do not work.

I have submitted a pull request with the required changes, referencing to this issue.

Support for Tradfri E27 980 lm dimmable bulbs

Chris, in #57 you said:

If you start to see timeouts in the log, please let me know - I'm not 100% sure that 500ms will cover every transaction, but I think it should ;)

I do get some timeouts:

09:52:36.987 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - D85DEF11A1002A12: Manufacturer request timeout
09:52:47.050 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - D85DEF11A1002A12: Model request timeout
09:52:57.119 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - D85DEF11A1002A12: Hardware version request timeout

The device is a BJ battery powered switch, so you should be able to reproduce it with your switch. Maybe the device just doesn't respond to the requests, but I figured I'd report it and let you decide if it's relevant ;)