Zigbee binding

I’m not surprised - as I said earlier I didn’t think it would make any difference as the correct magic byte was already being sent elsewhere.

So, the binding (in theory) should configure a device for automatic reporting - a nice feature of Zigbee (a bit like ZWaves associations). It configures the bulb to send updates automatically rather than having to poll…

Unfortunately, it seems that many devices don’t support this - including Hue bulbs… So I’ll have a think about doing some polling which is a little more complicated, but clearly necessary…

I am having this problem as well. Stick stays in the bootloader for a long time, and then Zigbee bindung gives up. I know it is being worked on, just a “me too”. Would be great if it would work at some point.


You got it! I can report that an OOTB HUSBZB-1 is controlling both my zwave and zigbee networks. The Ember EM35x Coordinator needs the baud rate set to 57600 when it is first created. I tested the others, but the binding would hang and Java would do a core dump when the binding was stopped. The coordinator would need to be deleted at this point. The coordinator stayed in Initializing after it was created, but after a restart it went Online. I have only tested GE Link bulbs. Changing the name of the Thing took them Offline (at least in the UI… it was still controllable), but they went Online after a restart.

Question: In the PaperUI, the bulb Things have switches for Enable Join and Leave Network. How would they be used?

Awesome! I want to try this. Please forgive the newbie question…
How do I get the updated code? Is it as simple as getting the latest OH nightly build snapshot? Or do I have to build something myself and then somehow point my existing OH at some repo to find the new code?
Feel free to point me to existing docs.Thanks for the help.

Yes, it’s in the nightly snapshot. I’m using 2.1 release right now, so I just grab it from here (you’ll need to uninstall it from the UI, if you have it already, and drop this into Addons… but make sure you still have the serial bindng)… https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastSuccessfulBuild/artifact/bindings/org.openhab.binding.zigbee/target/org.openhab.binding.zigbee-2.2.0-SNAPSHOT.jar

Or build it from here…

This post may help too…

Nice one :smile:. Thanks for the feedback.

If you want it to leave the network, then click leave. If you want to enable inclusion for this router only, then you can click the join button.

This is on the bulb though. Does this mean I can start discovery from that bulb to expand the mesh from it? If so (super cool), does that mean the discovery from the controller will only include devices it can reach?

Yes.

Zigbee inclusion isn’t so simple (wrt Z-Wave)… You can enable inclusion for each router - a device can join a router that has association enabled and it can join the network this way. Once in the network, the device may rejoin on a different router without join being enabled, so you can’t guarantee that the mesh stays the way you create it…

No.

When you enable discovery through HABmin / PaperUI, it will enable join on all routers - not just on the controller.

Thank you for the education! I now have 24 GE Link bulbs and 1 SmartThings Outlet on the network. I’m battling with another bulb that refuses to join. It flashes during discovery, but never shows up in the Inbox. There was another bulb that did this but eventually showed up, so I probably just need to wait. Another bulb joined but is not responding to ON/OFF. WIP.

The SmartThings Outlet came up as CentraLite 4257050-RZHAC. Is the energy metering yet to be implemented in the binding (this device is capable)?

Also, I see a lot of these in the log… the last line of it anyway. Is this a normal message or something to be concerned about?

2017-07-05 16:04:04.000 [AshFrameHandler           ] - TX EZSP: EzspSendUnicastRequest [type=EMBER_OUTGOING_DIRECT, indexOrDestination=43726, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=253], messageTag=253, messageContents=00 07]
2017-07-05 16:04:04.010 [AshFrameHandler           ] - RX EZSP: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=200]
2017-07-05 16:04:04.010 [ZigBeeDongleEzsp          ] - RX: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=200]
2017-07-05 16:04:04.010 [ZigBeeDongleEzsp          ] - Unhandled EZSP Frame: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=200]

Thank you for this awesome binding! My rooted Wink hub has now gone to pasture.

Yes - I’ll add it soon.

It’s normal - don’t worry about it. At some point I’ll add support for this to improve the system a little more, but I don’t process all messages as many aren’t necessary.

Your dongle seems quite a nice option so I’m quite pleased it’s working well :slight_smile: .

:blush:

1 Like

Here are some NPEs from Karaf. Got it 6 times:

Exception in thread "pool-47-thread-6" 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)

Not sure if this one is from this binding. Got it 4 times:

Exception in thread "pool-47-thread-7" java.lang.NullPointerException

After stopping the binding, this comes up:

get_java_var: invalid file descriptor

And then these cycle continuously until OH is shutdown:

Exception in thread "pool-49-thread-703" java.lang.IllegalStateException: Could not update status, because callback is missing
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus(BaseThingHandler.java:388)
        at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.networkStateUpdated(ZigBeeCoordinatorHandler.java:645)
        at com.zsmartsystems.zigbee.ZigBeeNetworkManager$3.run(ZigBeeNetworkManager.java:709)
        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)

Here is what is in the log at the same time (sorry… wasn’t in debug). The first one repeats many times and the log ends with the last one:

2017-07-05 18:16:08.827 [AshFrameHandler           ] - AshFrameHandler IOException:
java.io.IOException
        at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1274)[184:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler$1.run(AshFrameHandler.java:151)[222:org.openhab.binding.zigbee:2.2.0.201707042200]
2017-07-05 18:16:08.828 [AshFrameHandler           ] - AshFrameHandler IOException:
java.io.IOException
        at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1274)[184:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler$1.run(AshFrameHandler.java:151)[222:org.openhab.binding.zigbee:2.2.0.201707042200]
2017-07-05 18:16:08.828 [AshFrameHandler           ] - AshFrameHandler exception count exceeded

Had a couple of these unhandled exceptions in the console this morning:

Exception in thread "pool-37-thread-245" java.util.ConcurrentModificationException
        at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
        at java.util.ArrayList$Itr.next(ArrayList.java:851)
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.nodeUpdated(ZigBeeThingHandler.java:302)
        at com.zsmartsystems.zigbee.ZigBeeNetworkManager$11.run(ZigBeeNetworkManager.java:1356)
        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)

I’d recommend that you try re-flashing your stick and provide the name of the file that you’re flashing to it. Can you also confirm what hardware config you’re on? I had some issues with VMWare ESXI 6.5 that I resolved through setting the USB to high priority.

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?