Zigbee binding

Tags: #<Tag:0x00007f4332d6c730> #<Tag:0x00007f4332d6c668>

That last 4 restart (after reboot) I have gotten this error during startup:

2018-12-24 00:42:41.779 [ERROR] [converter.ZigBeeConverterSwitchOnoff] - 7CB03EAA00A05370: Error 0xffff setting server binding

You can ignore this - there is a discussion about it somewhere, but it isn’t a problem and the latest binding has removed this as an error.

See this post -:

Further to this, I have found a way to increase the ageing timer in the Ember - by default this is set to 5 minutes (ie requiring devices to poll parents within a 5 minute period, or they will be removed from the child table and asked to rejoin).

I will look at providing a way to configure this - it may be generally a good idea to increase it in most applications, but some care will be needed to avoid devices that have been removed from clogging up the child table and preventing devices from joining… As always, there’s a compromise!

I have just created a PR to allow changing the Ember child aging. This should help those with Xiaomi devices as they should stay connected to the network longer (I’ve allowed this to be set up to around 7 weeks). It should be noted though that setting this too long may cause the coordinator child table to fill up, which could mean it doesn’t allow devices to join! It may also mean that devices don’t change parents in the mesh if conditions change.

I’ve set this to a default of 1 day - by default at the moment (ie in the NCP firmware) it is set to 5 minutes. If you use Xiaomi devices, you might want to increase this further - if you are happy with your network now, you might want to decrease it (personally I think 5 minutes is too short as it will in any case generate more network traffic than is necessary, and on large networks, this could become problematic).

Note as well that this only changes the Ember coordinator - so if your devices are connected to the network via a different parent (eg a light bulb), then this will not change the aging policies of those routers.

From the readme -:

ZigBee routers (and the coordinator) only have room to allow a certain number of devices to join the network via each router - once the child table in a router is full, devices will need to join via another router (assuming the child can communicate via another router). To avoid the child table becoming full of devices that no longer exist, routers will age out children that do not contact them within a specified period of time.

Once a child is removed from the child table of a router, it will be asked to rejoin if it tries to communicate with the parent again. Setting this time too large may mean that the router fills its tables with devices that no longer exist, while setting it too small can mean devices unnecessarily rejoining the network.

Note that ZigBee compliant devices should rejoin the network seamlessly, however some non-compliant devices may not rejoin which may leave them unusable without a manual rejoin.

1 Like

I’ve made a few updates today that may benefit people - especially those using the Ember coordinator - and I would welcome any feedback.

The main features that have changed -:

  • As per the post above, I’ve now added a new option in the Ember coordinator to change the way devices are aged. This should reduce the occurrences of devices having to rejoin, and for devices that are “not very compliant” to ZigBee, it may stop them leaving.
  • I’ve improved the transaction management for the Ember and Telegesis dongles. This is the first part of a larger update to transaction management, but the framework now uses dongle feedback when handling transactions. The main thing this will help is to timeout failed transactions much quicker than previously.
  • I’ve changed the way that rejoins are handled. Previously, when a device left, and then rejoined, the binding removed the node, and then had to rediscover it! This adds a lot of overhead, and when coupled with the low default aging in the Ember dongle, may be contributing to devices disappearing.

You should be able to upgrade to the latest binding snapshot, and the latest ZssBee libraries using the script from @5iver -:

The latest ZSS library version is 1.1.8.

I welcome any feedback on this.


1 Like

Everything installed well for me, and no errors in the log. Was spooked at first because it took a minute for the devices to come up, but they all came back online and functioning. My GE Link bulbs have been working really well lately, so not sure if this could improve them, although I did pull a bunch of them out. Thank you!

Thanks Scott - as always when there are significant changes, there’s always that possibility that something got screwed up, so good to know it at least runs :sunglasses: .

Does this also include the change where bulbs would return to their proper state if they rejoin?

No - I’ve not merged that PR. All the Deutsche Telekom guys are now out of the office until after Christmas so it’s likely I won’t get this reviewed until the new year.

Hmmm… I might just merge it :wink:

1 Like

I fetched the latest and there are several classes showing errors due to a ZclCluster bind method without any arguments. My IDE is a little tweaked right now, so it may just be me.

I assume that’s the same error discussed elsewhere - or do you mean this is a linker error or something?

I’m not sure if/where it may have been discussed :slight_smile:. I usually have the most recent, so this should be relatively new.

Ah - your code is out of date. This was changed quite a while back (before 2.4 was released). This was a change in the library a few months back, and then there was an update to the libraries about a week before 2.4 was released to mop everything up…

Edit: If you wait another 5 minutes, the new version with the poll on reconnect should be complete.

OK… sorry for the scare! Eclipse has been tripping me up all day, so par for course…

Build is now complete…

Cool! Now I need to make one of my bulbs drop… :crazy_face:

Can’t you turn off the power and back on again? That’s what I did to test - set the dimmer to some level, power cycled the bulb and when the bulb comes on, it’s at full brightness. 5 or 10 seconds later and it should show this in the UI.


I don’t think the files are updated though… or I misunderstood the functionality. Lights came on and stayed at 100. UI’s reflected this too, but I was expecting them to dim back to the old state.

This may be related…

2018-12-24 16:33:23.800 [ERROR] [com.zsmartsystems.zigbee.app.discovery.ZigBeeNodeServiceDiscoverer] - 7CE524000013F7EF: Node SVC Discovery: exception: 
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2eb64d71 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@5ab9f61[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 1023]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533) ~[?:?]
	at com.zsmartsystems.zigbee.ZigBeeNetworkManager.rescheduleTask(ZigBeeNetworkManager.java:585) ~[284:com.zsmartsystems.zigbee:1.1.8]
	at com.zsmartsystems.zigbee.app.discovery.ZigBeeNodeServiceDiscoverer$NodeServiceDiscoveryTask.run(ZigBeeNodeServiceDiscoverer.java:632) [284:com.zsmartsystems.zigbee:1.1.8]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	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) [?:?]

The PR was merged - I can’t see how it can’t be updated.

This will not change the level of the bulbs - it will update the UI to reflect the state - but only if the bulb sends an announce message that is received by the coordinator.