I used the pro secure standard image. Anyway too late now. I threw away the programmer because I thought I would never need it again. I ordered the HUSBZB-1 yesterday, didn’t want to wait another month for China Post. I am running openhab on Ubuntu 16 on a kangaroo mini pc (Atom).
Hi Chris, did you find a solution for the problem with the Texas Instruments stick in the meantime?
No - I’m not sure there’s anything I can do as it works fine for me. Unless I have something to go on I’m not sure where to go with it…
I found out what caused the problem. I think I did a reset of the controller while testing the console app which did a reset of the PANID. I now flashed the firmware again and took the ti stick away from my Hue lamps. (If the lamps are near the stick it will set a random PANID because it see’s that the provided PANID is already used)
Then I started the console app with my network key and PANID and it did accept the ID. Then I plugged the stick back into my Rasperry and started the bundle. After a few seconds all my lamps appeared in Paper UI! I am also able to control the lights.
I also get a lot of these errors in the log:
2017-07-10 22:44:25.161 [ZToolPacketStream ] - Packet parsing failed due to exception.
com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolParseException: Read -1 from input stream while reading packet!
at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketStream.read(ZToolPacketStream.java:320)[231:org.openhab.binding.zigbee:2.2.0.201707042025]
at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketStream.read(ZToolPacketStream.java:303)[231:org.openhab.binding.zigbee:2.2.0.201707042025]
at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketStream.readRemainingBytes(ZToolPacketStream.java:351)[231:org.openhab.binding.zigbee:2.2.0.201707042025]
at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketStream.parsePacket(ZToolPacketStream.java:125)[231:org.openhab.binding.zigbee:2.2.0.201707042025]
at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketParser.run(ZToolPacketParser.java:106)[231:org.openhab.binding.zigbee:2.2.0.201707042025]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Any idea what could cause this?
The -1 means there was an error or timeout returned fro the serial port. How often do you see this?
About every 30 to 60 seconds. Also the lamps are often displayed as offline and there are delays when sending commands. Could this be the cause of this problem?
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.