Zigbee binding

I have the bulbs here and was not able to make it work with the Telegesis dongle - it works fine with the Ember dongle.

This is just from my experience - if you have a different experience, then please let me know. I can’t really say if your bulbs will be different - only that my bulbs had problems.

As a matter of interest - I thought you had the Ember dongle and the bulbs were working? Or are you planning to change dongle?

I have put a test binding version here for anyone who wants to try some new features before I merge them.

The main features this adds is a change in the way discovery/mesh updates work, and an increase in the amount of data that is persisted. The overall goal here is to reduce network congestion (especially following a startup) by persisting information between restarts. This avoids having to request all the basic information about the device again (and again…) which puts a huge load on the system on large networks.

Before I merge this I’d welcome some feedback (maybe @5iver and @TheNetStriker you might be interested in testing :wink: ). The XML file that the system creates is likely to be quite large now - I’d be interested to know how large your files get. I could possibly consider writing the data into separate files per device (as per ZWave) if it’s a problem.

I’ve also added a random logarithmic backoff for devices that don’t respond to discovery requests - I’m thinking of slowly increasing the lower bound on the retry time to slowly remove all communications from these devices if they aren’t responding to basic requests.

More information on these two changes if you want to comment are below -:

This version also has converters for atmospheric pressure and humidity in support of the Xiaomi Aqara sensor - (I might merge these into the master sooner rather than later) -:

As always, comments welcome :wink: .

1 Like

Yes they work fine with the Ember dongle until the Ember dongle stops sending commands. I have looked through the windows logs, and found nothing. I tried debug logging on nrjavaserial, but that is not very informative, nothing is turning up. Unlikely to be serial communication anyway since I still get incoming events.

Resetting the binding also doesn’t really work, only full restarts work. Would like to get a more stable system.

So far, so good (HUSBZB-1). XML is currently 886KB (27 devices, 5 of which are powered off). I usually have to refresh Habmin after restarting the binding to get the links to show up, but with this version, they seem to pop right in. [EDIT: I take it back… I got lucky. Only a few of them popped in and the rest were missing links so had to refresh.]

Filtering the log for error and exception turned up a lot of these which I do not recall seeing before (GE Link bulbs)…

2018-02-11 13:04:53.675 [DEBUG] [ystems.zigbee.internal.ZigBeeNodeServiceDiscoverer] - 7C25240000161884: ManagementRoutingRequest returned CommandResult [ERROR (UNKNOWN,0x02), ManagementRoutingResponse [48516/0 -> 0/0, cluster=8032, TID=NULL, status=NOT_SUPPORTED, routingTableEntries=null, startIndex=null, routingTableList=[]]]
2018-02-11 13:04:53.675 [DEBUG] [ystems.zigbee.internal.ZigBeeNodeServiceDiscoverer] - 7C25240000161884: Node service discovery request ROUTES failed. Retry 18, wait 30688ms before retry.

I’ve not seen a problem where the Ember dongle stops sending commands. If you are referring to the previous log you posted, it’s not related to the Ember I think - it’s somewhere else in the system. The Ember is still sending and receiving just fine in that log.

If you are thinking of changing to another dongle to resolve this issue, I suspect the same problem will exist.

I’ve seen this before with a bulb I have here. When I power cycled the bulb they stopped (it’s a “Trust” bulb so not GE). It would be interesting to see a debug log of the response that’s causing this if you can grab one.

Thanks for the log @5iver - I simply didn’t look hard enough at what you posted above or I would have clicked earlier - it’s reporting the command is unsupported.

So I don’t think this will be any different to the previous version - just that you’ve noticed it this time. I’ll try and find a way to not do this when the command reports it’s unsupported.

Thanks.

1 Like

Hi,
I got a CC2531 device flashed with CC2531ZNP-Pro-Secure_Standard.hex

I still get this message:
2018-02-11 22:07:32.765 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 37270: Node discovery request IEEE_ADDRESS failed. Wait before retry.

CC2531 version is Software=2.6 Product=0 Hardware=3 Transport=2

zigbee_lastupdate 2018-02-11T20:45:53Z

I’m a newbie here, so sorry for the stupid question. I read through this topic, but I can’t find the solution.

Is anybody successfully implemented Xiaomi devices into OpenHab trough cc2531?

I’ve not tried this with a TI dongle, but Xiaomi devices tend to sleep VERY quickly so you need to keep waking them up during the initialisation.

In the logs I see that the Zigbeenetworkmanager just stops posting TX events and most RX events. After that, it still reports back for occasional RX MatchDescriptorRequest events.

Do you think that could be caused by the environment outside OH? My problems are always resolved by restarting OH as a whole.

Yes - but this doesn’t have anything to do with the dongle - right? The network manager is not sending anything TO the dongle so the dongle doesn’t respond. There are a few messages received from the dongle as other things also happen from time to time. All the ASH communication (ie the dongle communication) is working perfectly (at least from what I saw in your logs). For this reason I don’t believe that this is related to the dongle - or do you disagree?

No - it’s likely an issue with the binding is my best guess. It could be another binding, but probably unlikely.

How can a device be unpaired from the network? There used to be options in Advanced settings (Habmin), but I no longer see them.

Hi Chris, I just tested the new binding. Is it normal that I have to re-add all lamps again? (All channels on the existing things were gone)

The xml got about 1.6 MB big, but switching the lights was still only possible with a delay of more than a minute. Do you need a complete debug log again?

FYI, I saw this too… but thought it was just because I had dropped the updated jar (after renaming it) while OH was running or due to the new changes and the devices hadn’t been queried yet. After restarting the binding (might have been an OH restart), the channels came back.

Just delete it. When you delete it, the binding will send the leave commands.

1 Like

No - there shouldn’t be any real reason to have to do this, but devices need to somehow be rediscovered again - if the dongle doesn’t report them, and they don’t send updates (as is the problem with Hue bulbs) then it can be difficult to discover them.

The new binding uses a new persistence, so any previous data is not used.

Yeah - why not. I’ll take a look at what’s happening - I expect it’s still a case of overloading with polling etc (I think all your devices are Hue lamps?).

The reason for the long delay is as I thought - there’s a large backlog of traffic getting queued. Unfortunately at the moment there’s no transaction management layer in the binding to handle this better (it’s on the list…)

@5iver @AFromD if you have a debug log handy (it doesn’t necessarily have to be current) can you do a search for AshFrameNak and see if it occurs regularly, occasionally, or near never…

Thanks.

There was one I posted in the ticket… bet you get to it before I can…