Is there any pattern you can spot? eg always x seconds after the last message received, or coincident with another message or ???
I would guess that the exception is probably causing the issue, but that’s just a guess.
I did some more tests. It seams that the error occurs right after I sent the first command. After that it appears several times in the log, even if I don’t send any more commands. I will send you a complete debug log via private message because it contains a lot of sensible information.
I also found out that I don’t have to wait a minute after plugging in the ti stick. It only works if I start the binding right after I’ve plugged in the usb stick. It also seams that I have to plug the stick in and out again before restarting the plugin or else it cannot be initialized. I hope there is a way to make this easier in the future.
Edit: I also just found out that also my Hue Bridge is detected as a “Generic ZigBee Device”.
I’m not really sure what’s happening here - and more to the point, why your system is doing this when others using the same stick are working fine.
The initial error (read -1…) means that the packet never completed. So the binding starts to receive a packet, and then it never completes within the 2 second timeout so the serial driver returns -1.
Clearly this does recover as we see packets being received later.
However, I’m also seeing a lot of Failed to send AF_DATA_REQUEST messages in the log, so something isn’t running well here.
What system are you running on - ie what’s the computer, operating system etc. Anything else “non-standard” about your setup (USB port, hubs, virtualisation…).
I’m seeing the following sporadically for some of my devices, which are not responsive but still online. Habmin also shows they do not have neighbors. Powering the device off and back on usually fixes them, but I think they might also just eventually come back with time too.
[ZigBeeNetworkMeshMonitor ] - 8916: ManagementRoutingRequest returned ManagementRoutingResponse [8916/0 -> 0/0, cluster=8032, TID=NULL, status=NOT_SUPPORTED, routingTableEntries=null, startIndex=null, routingTableListCount=null, routingTableList=[]]
And this comes up in the console, which might be related:
Exception in thread "pool-35-thread-9" java.lang.NullPointerException
at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.getAssociatedNodes(ZigBeeNetworkMeshMonitor.java:305)
at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor.access$500(ZigBeeNetworkMeshMonitor.java:59)
at com.zsmartsystems.zigbee.internal.ZigBeeNetworkMeshMonitor$2.run(ZigBeeNetworkMeshMonitor.java:233)
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)
The cause of the empty routingTableList and the NPE could just be flaky device hardware/firmware. I’m dealing with GE Link bulbs, which are notorious for dropping off the network. I have 2 bulbs that are completely offline right now, and will likely need to be reset to bring them back. I didn’t have much issue while using the Wink hub, but it was in a much more centralized location. Which reminds me… will Habmin display the firmware version for a zigbee device, like the zwave binding? Maybe it’s the zigbee_datecode?
Can you open an issue on this - pasting in the exception. At the very least the framework should handle this without throwing an exception even if the root cause is the flakey bulb…
Yes, it should. When a device is first associated (and maybe on each restart) the binding requests a bunch of stuff and it includes the various versions of firmware, hardware, zigbee, etc.
One of the reasons I was so pleased to use this binding, was to be able to manually choose a channel and eliminate wifi interference. I’m not sure where the best place would be to put it, but IMO it would be handy to have this
http://www.nickhunn.com/rf4ce-–-the-wireless-remote-control-that-keeps-coming-back/
https://www.digi.com/wiki/developer/index.php/Channels,_Zigbee)
information somewhere in the documentation. And/or incorporate it into the channel drop down like:
11 (overlaps WiFi channels 1,2)
12 (overlaps WiFi channels 1,2,3)
13 (overlaps WiFi channels 1,2,3,4)
14 (overlaps WiFi channels 1,2,3,4,5)
15 (overlaps WiFi channels 2,3,4,5,6)
16 (overlaps WiFi channels 3,4,5,6,7)
17 (overlaps WiFi channels 4,5,6,7,8)
18 (overlaps WiFi channels 5,6,7,8,9)
19 (overlaps WiFi channels 6,7,8,9,10)
20 (overlaps WiFi channels 7,8,9,10,11)
21 (overlaps WiFi channels 8,9,10,11,12)
22 (overlaps WiFi channels 9,10,11,12,13)
23 (overlaps WiFi channels 10,11,12,13,14)
24 (overlaps WiFi channels 11,12,13,14,15)
25 (overlaps WiFi channels 12,13,14)
26 (overlaps WiFi channels 13,14)
Although not a current concern in my setup, that second link makes me wonder about interference from RF remotes, like the Harmony.
Hmmm… I see other info in Habmin under Attributes, but I do not see anything related to firmware for my Zigbee devices. Unless zigbee_datecode is firmware related?
In just reviewing my Zigbee Things, I noticed that my Centralite outlet has zigbee_routes, but none of the bulbs have any. They do have neighbors (usually).
Is a Zigbee Network Viewer in Habmin somewhere in your backlog? 
It should be zigbee_appversion.
Routes and neighbours aren’t quite the same thing, but typically yes, they should see neighbours (not necessarily routes though).
Maybe. Currently I have written a network viewer for ZigBee in PaperUI as it was done for a specific contract within in ESH. For sure we’ll have something - either in PaperUI or HABmin.
My bulbs show this as just a 4. Maybe there’s a conversion gone wrong? Smartthings shows the GE Link bulb firmware as 0x001030400 and Wink as 0.1b03/0.4b00 (these were both taken from the ST forum… so not mine specifically). No zigbee_appversion for the Centralite outlet.
Maybe there’s other information somewhere, but the standard clearly shows the application version is 8 bits long -:
I’ll take a look at what else might be available in other clusters when I get a chance.
Can you post the information provided by your bulb (ie from HABmin).
I wonder if what these other devices are showing is effectively a concatenation of the different versions - stack, app, hardware and cluster? This would give a 4 byte value the same as the GE Link hub is showing and clearly (IMHO) Wink looks the same as the GE, but just different format…
I think the quickest way to test your hypothesis is to plug in my hubs and add a bulb!
Something else I saw tonight caught my eye… this is my coordinator info from Habmin. Why would the bulbs all have joining:ENABLED in their zigbee_neighbors, but the coordinator has it as UNKNOWN? Would the joining:UNKNOWN mean that the coordinator would not enable join on the bulbs when turned on through Habmin? This could explain some difficulties I’ve had where I could not include bulbs outside the range of the controller without starting a join from another bulb that was close to it.
I’m not completely sure what you’re looking at here, but firstly, I’ve not found this information to be reliable. As I understand it, it is detected by neighbour nodes from the beacons each router sends – the neighbours are then sending this back to the binding, so it kind of second hand news as it’s not coming from the device itself. The UNKNOWN just means that the router doesn’t know the join state of its neighbour – really, I wouldn’t trust it – from my experience it’s unreliable, and it’s also only updated periodically (and less frequently than the duration of the join itself!).
When you start a join using the discovery, it will send a message to ALL routers to enable join for 30 seconds, so there should not be any issue associating new devices that are outside of the range of the controller.
Great, thank you! My concern was that, when starting discovery, the coordinator would not turn discovery on for neighbor routers that have a join state of UNKNOWN.
This won’t happen. When discovery is started, a network wide broadcast is sent to all routers to enable join mode for 30 seconds (or it might be 60 seconds actually, but it’s a fixed time as required by ZB3).
Hey Chris, any progress in getting the Conbee dongles working?
I would love to use Zigbee natively in OH. I even would like to use it commercially.
But the cc2531 is a developer Kit and therefore nothing I can really place in my parents/customers house.
It seems like here, in Germany, the only available dongles are: Conbee, Qivicon, Ubisys. The other dongles (like the Linear HUSBZB-1) are not available and need to be imported. Yes, one can do this. You can even buy those cheap china clones, but I don’t want to bother myself with warranty or even liability when importing/using their hardware (I am not speaking of software!))
Conbee is not as cheap as the china clones but also not as expensive as TI and also available in many other countries, therefore I think it would great to support them and could help to increase the number of people using your binding. The only downside with conbee as I know is their strange (sudo and xsession needed) interface called deCONZ. But as I read an github Dresden Electronic offered their help right?
Unfortunately not as much as I hoped. I have a dongle, but I’ve not managed to get it working yet. I had some information from Dresden which I’d hope would help, but it didn’t - I’ve asked them some further questions a week or so back, but I’ve not yet had a response.
They supplied me the API which looks simple enough. I’ve implemented the basic communications, but am not getting any response to my requests. I’ve sent them what I’m sending to the device as I’m sure it’s correct and this is what I’m waiting for an answer on. It may just be summer holiday time so I’ll give them a bit longer before I’m too annoying ;).
Thats still some kind of progress. Glad you are working on it. Thanks!
Yes this seems to be fair. I think they will easily sell a couple of units when their stick is supported and therefore they should spend a few minutes on answering your questions. And I am pretty sure they will.
But in case nobody responds let me know, then I will ask them too 
Thanks - this is also what I’ve tried to tell them. Let’s see how it goes - they have generally been quite responsive.