It should be ok to just shutdown, wait 30 seconds (for no real reason, but it’s probably a good idea) and restart.
It’s the same as any other binding I guess. Just uninstall and reinstall from PaperUI (assuming of course that your running the snapshot builds).
I’ve not idea what KAR you are talking about.
I am talking about snapshot addons kar file in cloudbees…
It shows up in paper UI but installing results in this error message
16:22:36.150 [ERROR] [.core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-binding-zigbee’: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-zigbee; type=karaf.feature; version="[2.3.0.SNAPSHOT,2.3.0.SNAPSHOT]"; filter:="(&(osgi.identity=openhab-binding-zigbee)(type=karaf.feature)(version>=2.3.0.SNAPSHOT)(version<=2.3.0.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-zigbee/2.3.0.SNAPSHOT: missing requirement [openhab-binding-zigbee/2.3.0.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.zigbee.telegesis; type=osgi.bundle; version="[2.3.0.201805172001,2.3.0.201805172001]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.zigbee.telegesis/2.3.0.201805172001: missing requirement [org.openhab.binding.zigbee.telegesis/2.3.0.201805172001] osgi.wiring.package; filter:="(osgi.wiring.package=org.eclipse.smarthome.config.discovery.usbserial)"]]
I suspect that maybe you’re running a runtime that is too old? If it’s not quite recent, then it won’t work.
so the only way to run zigbee is upgrading core to latest snapshot?
the stable does not work at all for some reason… keeps showing up as unknown state…
If you want to run the latest (snapshot) binding, then you need to run a recent (snapshot) runtime. This is not uncommon - as new features are added to the core, the bindings need to be updated.
You can still use the stable binding with the stable 2.2 runtime.
Thank you Chris , the issue was baud setting for the zigbee stick… it works now …
I was wondering if there is a procedure to add devices ( similar to zwave )
I have an Ikea Tradfri Remote ,which is easily discovered and paired but
Is there anything I could do to help adding the definition of it?
These are cheap and nice looking zigbee remotes … should be quite nice alternative for tabletop light control ( or any other control as long as they are detected as generic switch )
The remotes have 5 buttons, and they do work with home assistant or smart things as online chatter indicate…
The binding works very differently to ZWave. There should be no need to add device definitions in the way that is done in ZWave. The binding will detect the services of the different devices and make channels available as required.
Now, the issue you have is that not all clusters are supported at the moment, and not all services within the supported clusters are supported. This will require further changes if you are missing information.
Currently, remote controls are not supported in general.
Oh I see, any plans to gradually build up support for these ?
Yes, it will be worked on. New device support is added regularly and somewhere in one of these threads is a discussion on remotes which I am working on as a background task.
Even for the ZWave binding, the database just allows you to define functionality that the binding already supports. The command classes still had to be coded - it’s fundamentally the same here - the functionality still has to be coded…
Chris, are there any ways we could offload you? I was trained as a programmer some 20 years ago, but have mostly used it for scripting. -So if there is something like “find pattern for this, add to table and give it a name”, or “copy this section to a new name, and change these items” kind of job, I could certainly volunteer for it!
Of course this is an OS project, so everyone is welcome to contribute 
. Unfortunately though, simple additions are, well, simple, and it’s probably easy for me to do. More complex issues take time and often additional equipment…
Is there a specific reason you’re asking? What do you want to actually add? Generally, I’ve tried to add common devices, so most common devices should work at this stage. The issue comes now when a device doesn’t work - it normally means that it is using a different cluster, or doing something non-standard, or, it’s just a less common device. In this case, it generally takes a bit of time to work out what the device is doing, and then add support for it…
Thanks. I am simply asking in case there are some parts that are particularly tedious for you, so you could focus on the heavy stuff instead It feels wrong to be asking you for additions and stuff without at least offering to help.
Thanks - and I do appreciate the offer. The binding is written in a way that makes adding support for new devices reasonably simple, so that’s often not the issue. The bigger problem (and maybe “problem” isn’t the best word - but more work anyway) comes with working out what to add.
For sure though, if there is “tedious stuff” I want adding, I’ll ask .
@chris, I’m testing a couple things right now, and I’m seeing Zigbee not starting up every now and then on snapshot 1293 (Things never come online but logging looks like everything is OK, just no handlers… might be related to 193). I don’t want to restart OH, so I’ve been trying to get the Zigbee binding restarted, but restarting org.openhab.binding.zigbee doesn’t seem to do it. Am I doing something wrong or could this be a bug?
After the binding is stopped, the OH and zsmartsystems dongle bindings are still active, and logging continues. I would have thought they would also be stopped when the main binding is stopped.
Hey,
a friend of mine and I’ve been using or trying to use the CC2531 with the ZigBee Binding for a few weeks now. These are the different firmware versions we tried out:
OH 2.2 2.3RC 2.3
38724.hex : n/a error n/a
Standard.hex: n/a okay error*1
LinkKeyJoin.hex: n/a n/a okay
*1: Problems with bootloader magic
Using the LinkKeyJoin firmware with version 2.3 of the binding, it seems to be stable for us right now. We are able to control Tradfri bulbs without any problems. Nice!
What we really want to get to work is the Xiaomi Temperature and Humidity sensor. The device gets discovered and we can add it as thing, but we do not have any channels. We have tried to push the button repeatedly during the discovery to keep the device from going to sleep, but it seems like the sensors endpoints/clusters cannot be discovered correctly, even though the sensor reports its values:
2018-06-01 22:00:14.571 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Temperature measurement: 38608/1 -> 0/1, cluster=0402, TID=12, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=2900]]
2018-06-01 22:00:14.591 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Relative humidity measurement: 38608/1 -> 0/1, cluster=0405, TID=13, reports=[Attribute Report: attributeDataType=UNSIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=5087]]
When receiving these reports after discovery, we only get „cluster 1029 not found for attribute response“ and „cluster 1026 not found for attribute response“.
Does anyone have an idea, how we can get these sensors working? We would be ready to make some adaptions to the binding, but don’t know where to start.
Thanks in advance!
Daniel
You need to press the button a number of times during the initial discovery. This is so that the binding can discover the services that the device provides, and then provide the appropriate channels. Pushing the button later will not work.
We could probably provide a static definition to work around this once this feature has been merged into the binding. This would help with the initial discovery, but may not solve all the issues related to the Xiaomi devices (such as the fact they tend to drop off the network over time). At the moment, this feature is not merged into the binding.
Hi @chris,
I have the same issue (2.3.0), and I think I have found out why this happens. It is tricky, as it depends on having a big and / or slow network, leading to a deadlock (see below the two involved threads and where this happens).
In my case I have 30+ devices, and several of them are on the ceiling very far away from the dongle, and take a lot to respond to discovery. At some moment, no more commands are sent, but reports still come in:
2018-06-09 11:29:36.546 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 7CB03EAA00A3C089: Polling...
2018-06-09 11:29:36.556 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 7CB03EAA00A3C089: Polling zigbee:device:57812c38:7cb03eaa00a3c089:7CB03EAA00A3C089_3_switch_onoff
2018-06-09 11:29:36.560 [DEBUG] [.zsmartsystems.zigbee.zcl.ZclCluster] - readSync request: ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=false, lastReportTime=Sat Jun 09 11:01:59 CEST 2018]
2018-06-09 11:36:27.406 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command 'ON' for item 'OfficeLight1' to handler for channel 'zigbee:device:57812c38:000b57fffe99ec70:000B57FFFE99EC70_1_switch_level'
2018-06-09 11:36:27.412 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.zigbee.handler.ZigBeeThingHandler@9b396d'.
2018-06-09 11:36:27.413 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command 'ON' for item 'OfficeLight2' to handler for channel 'zigbee:device:57812c38:000b57fffe92bc0d:000B57FFFE92BC0D_1_switch_level'
2018-06-09 11:36:27.419 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 000B57FFFE99EC70: Command for channel zigbee:device:57812c38:000b57fffe99ec70:000B57FFFE99EC70_1_switch_level --> ON
2018-06-09 11:36:27.421 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.zigbee.handler.ZigBeeThingHandler@205e50'.
2018-06-09 11:36:27.446 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 000B57FFFE92BC0D: Command for channel zigbee:device:57812c38:000b57fffe92bc0d:000B57FFFE92BC0D_1_switch_level --> ON
2018-06-09 11:38:18.935 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command 'OFF' for item 'OfficeLight1' to handler for channel 'zigbee:device:57812c38:000b57fffe99ec70:000B57FFFE99EC70_1_switch_level'
2018-06-09 11:38:18.947 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command 'OFF' for item 'OfficeLight2' to handler for channel 'zigbee:device:57812c38:000b57fffe92bc0d:000B57FFFE92BC0D_1_switch_level'
2018-06-09 11:38:18.956 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.zigbee.handler.ZigBeeThingHandler@9b396d'.
2018-06-09 11:38:18.958 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.zigbee.handler.ZigBeeThingHandler@205e50'.
2018-06-09 11:38:18.963 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 000B57FFFE99EC70: Command for channel zigbee:device:57812c38:000b57fffe99ec70:000B57FFFE99EC70_1_switch_level --> OFF
2018-06-09 11:38:18.967 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 000B57FFFE92BC0D: Command for channel zigbee:device:57812c38:000b57fffe92bc0d:000B57FFFE92BC0D_1_switch_level --> OFF
No errors on the log. Just commands won’t go out.
Launching a thread dump on the karaf console, everything is blocked waiting for the lock on ZigBeeNetworkManager.commandExecutions:
"pool-35-thread-1" Id=226 in BLOCKED on lock=java.util.HashSet@1843979
owned by ESH-thingHandler-38 Id=276
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.removeCommandExecution(ZigBeeNetworkManager.java:959)
at com.zsmartsystems.zigbee.CommandResultFuture.get(CommandResultFuture.java:99)
- locked com.zsmartsystems.zigbee.CommandResultFuture@761f4c
at com.zsmartsystems.zigbee.CommandResultFuture.get(CommandResultFuture.java:83)
and
"ESH-thingHandler-14" Id=241 in BLOCKED on lock=java.util.HashSet@1843979
owned by ESH-thingHandler-38 Id=276
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.addCommandExecution(ZigBeeNetworkManager.java:936)
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.unicast(ZigBeeNetworkManager.java:902)
- locked com.zsmartsystems.zigbee.zcl.clusters.general.ReadAttributesCommand@22b0b9
at com.zsmartsystems.zigbee.zcl.ZclCluster.send(ZclCluster.java:159)
Specifically all the available threads for ZigBeeNetworkManager.executorService and all ESH thing handlers except for this particular one:
"ESH-thingHandler-38" Id=276 in BLOCKED on lock=com.zsmartsystems.zigbee.CommandResultFuture@761f4c
owned by pool-35-thread-1 Id=226
at com.zsmartsystems.zigbee.CommandResultFuture.set(CommandResultFuture.java:62)
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.addCommandExecution(ZigBeeNetworkManager.java:944)
- locked java.util.HashSet@1843979
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.unicast(ZigBeeNetworkManager.java:902)
- locked com.zsmartsystems.zigbee.zcl.clusters.general.ReadAttributesCommand@1af1e58
at com.zsmartsystems.zigbee.zcl.ZclCluster.send(ZclCluster.java:159)
And here the deadlock:
This seems to happen here when we need to remove expired command executions, so a tricky one and only seen when we have several slow or not responding devices on a big network:
private void addCommandExecution(final CommandExecution commandExecution) {
synchronized (commandExecutions) {
final List<CommandExecution> expiredCommandExecutions = new ArrayList<CommandExecution>();
for (final CommandExecution existingCommandExecution : commandExecutions) {
if (System.currentTimeMillis() - existingCommandExecution.getStartTime() > 8000) {
expiredCommandExecutions.add(existingCommandExecution);
}
}
for (final CommandExecution expiredCommandExecution : expiredCommandExecutions) {
// --- Here the deadlock ------------------------------------------------------------
((CommandResultFuture) expiredCommandExecution.getFuture()).set(new CommandResult());
// ----------------------------------------------------------------------------------
removeCommandExecution(expiredCommandExecution);
}
commandExecutions.add(commandExecution);
addCommandListener(commandExecution.getCommandListener());
}
}
This totally kills the binding, which becomes irresponsive to commands till it is restarted.
I understand we are cleaning the queue of expired executions here, so I would reorder like this to prevent the deadlock:
private void addCommandExecution(final CommandExecution commandExecution) {
final List<CommandExecution> expiredCommandExecutions = new ArrayList<CommandExecution>();
synchronized (commandExecutions) {
for (final CommandExecution existingCommandExecution : commandExecutions) {
if (System.currentTimeMillis() - existingCommandExecution.getStartTime() > 8000) {
expiredCommandExecutions.add(existingCommandExecution);
removeCommandExecution(existingCommandExecution);
}
}
commandExecutions.add(commandExecution);
addCommandListener(commandExecution.getCommandListener());
}
for (final CommandExecution expiredCommandExecution : expiredCommandExecutions) {
((CommandResultFuture) expiredCommandExecution.getFuture()).set(new CommandResult());
}
}
I cannot 100% tell the side effects as I do not know the whole flow, but this seems harmless (more than a full deadlock) as we are cleaning up old commands, but also maybe there is a better place for this cleanup.
This one was tricky, sorry for the long message… 
Pedro
Thanks Pedro. I appreciate what looks to be a detailed analyses, so no problem with the long message 
. I’ll take a look at this in the next day or so and we can discuss further then.
Cheers
Chris
OK, not so harmless… as removeCommandExecution also syncs on the same objects, and moreover removes the CommandExecution, from the list…
Working now like this:
private void addCommandExecution(final CommandExecution commandExecution) {
final List<CommandExecution> expiredCommandExecutions = new ArrayList<CommandExecution>();
synchronized (commandExecutions) {
for (final CommandExecution existingCommandExecution : commandExecutions) {
if (System.currentTimeMillis() - existingCommandExecution.getStartTime() > 8000) {
expiredCommandExecutions.add(existingCommandExecution);
}
}
commandExecutions.add(commandExecution);
addCommandListener(commandExecution.getCommandListener());
}
for (final CommandExecution expiredCommandExecution : expiredCommandExecutions) {
synchronized (expiredCommandExecution.getFuture()) {
((CommandResultFuture) expiredCommandExecution.getFuture()).set(new CommandResult());
removeCommandExecution(expiredCommandExecution);
}
}
}
Now any lock on the command future always comes before a lock on the commandExecutions list (unless I missed something), preventing the deadlock. Working for some time now without issues (it was quite easy to reproduce in my environment)
Pedro
Hi @chris,
Has this finally made it into the 2.3 release version of the binding? I’ve just tried discovering to get the Aqara temp/hum sensor (the round version) and did get nothing in the logs (even with log:set DEBUG …).
I’m on TI CC2531 too same as @Peter_Horgonyi. I’ve pressed the button on the sensor quite often during the scanning - but nothing in the log 
Is that the rights way to include it?