Zigbee binding

Tags: #<Tag:0x00007f014ba61500> #<Tag:0x00007f014ba61398>

(Chris Jackson) #1707

Well, this is the problem you have according to the log you just posted. Or is the log an old log?

(Welf Rogalski) #1708

no, its from today 14:23

(Chris Jackson) #1709

Ok, then this is the problem you have today, so I would suggest to use the command I posted to install the serial driver as that is the error reported in your log.

(Welf Rogalski) #1710

how can I avoid to install the serial driver every day?
seems that the system looses it by stopping openhab for backup

(Chris Jackson) #1711

Sorry - I’m not really sure. I can sympathise with you, but this is really a framework issue and I’m not sure why it’s removing the feature. I would suggest to post a more general question in a new thread to see is someone can answer.

ZigBee Binding - necessary serial driver gets lost
(Welf Rogalski) #1712

ok - thanks for your quick reply!!

(Scott Rushworth) #1713

The backup is likely removing the cache, which also removes the feature. The easiest way I know to avoid this is to install the serial binding through Paper UI. You could also reinstall it in your backup script.

ZigBee Binding - necessary serial driver gets lost
(Welf Rogalski) #1714

ok - i’ll try it first with the serial binding.
I opened a new post in parallel:
(ZigBee Telegesis Dongle does not initialize - serial driver gets lost)
I keep it open and wait for the results by using the binding or the backup script.

(Chris Jackson) #1715

You might be better off renaming this new thread to broaden the number of people who read it as this should be a general issue and not related to the Telegesis ZigBee dongle…

(Welf Rogalski) #1716

you saved my day: installing the serial binding in Paper UI solves this issue:
(ZigBee Binding - necessary serial driver gets lost)

(Kim Andersen) #1717

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

(Chris Jackson) #1718

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.

(Chris Jackson) #1719

See this post -:

(Chris Jackson) #1720

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!

(Chris Jackson) #1721

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.

(Chris Jackson) #1722

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.


(Scott Rushworth) #1723

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!

(Chris Jackson) #1724

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: .

(Scott Rushworth) #1725

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

(Chris Jackson) #1726

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: