The log viewer won’t help since the log doesn’t contain the information the log viewer uses.
We know that the ZigBee dongles and devices are working and that OpenHab 2.5.1 (with 2.5.1 ZigBee binding) is generally able to make pairing work. So I am trying to narrow this down. We are having several Linux installations were this doesn’t work. Some on RPi, some on PC. We have at least a single Linux installation that seems to work (OpenSuse by @mrfrh). Your installation on macOS seems to work as well.
In an ideal world, the hardware and OS should not matter much to Java applications, but in my experience as a Java developer for several years, there are still more than enough platform specific details. They might seem minor, but they might make a major difference in practice.
I am trying to run OpenHab 2.5.1 on a MacBook Pro (macOS 10.14.6), but I am having trouble getting the BV 2010/10 to work. @chris Could you please point me to the driver download for this device? I could not find anything. Thank you very much.
My guess is that there is something misconfigured in the NCP - or - that there is even a bug in the NCP that shows up under some circumstances. I need to get the binding updated, but it’s problematic at the moment as I need to update the binding, then also update the distro - I’m trying to get this all centralised so it’s more under my control and I don’t need to wait weeks to get stuff merged.
I doubt though that this is a host issue.
There is no way to run the bitron dongle on a mac since they use non-standard USB IDs.
Yes, I already noticed that. I have the proper Silicon Labs driver installed, but I would need to disable macOS’ System Integrity Protection to be able to modify and load the driver with the non-standard device ID added … which I don’t want to do on this particular mac I use for work. 
1 Like
So how are we going to proceed with this issue? Do you further want to try to reproduce this issue? I just tested two things again and I can reliably reproduce the pairing problem:
- Install OpenHabian 1.5 on RPi 3B, add Zigbee binding, add BV dongle, test pairing with tint white+color → fails
- Install Ubuntu 19.10 x86_64 in VM on macOS, install OpenHab 2.5.1, add ZigBee binding, add BV dongle, test pairing tint white+color → fails
I don’t see what else I can do.
I hope to do an update to a new library in the near future. The libs are mostly complete - just a few more PRs to merge and then I will do a release. The issue is I currently have to update the binding, and also the distro which requires other people to also do stuff and this often takes a few weeks. I will try get it merged as soon as I can but it’s not completely in my control.
No - as I said a few days ago I have found an issue that I am looking at. I’ve also purchased more devices to allow me to test so I can confirm things work for you guys (but this is getting expensive for me!).
1 Like
Ok, thank you very much. Two last questions before I’ll stop bothering you:
- Is there a github issue for tracking the work you mentioned? If there is, I’d subscribe to it.
- Is there a way to donate to cover some of your expenses? Donating directly to the OpenHab Foundation wouldn’t help you much I suppose …
There was - but I closed it 3 days ago -:
I hope that this will help - I think that this setting was changed since 2.4 and earlier 2.5 milestones. At the time it was changed, there was an issue on another (non OH) system with ZB3.0 devices and this was the best approach to avoid key problems as per the following issue -:
This issue is not resolved as it is not easy to know when a device has really left the network - ie it’s left, and doesn’t plan on returning, versus it has left, but will be back shortly. This can happen if it’s a mobile device and changes parents.
For 2.5.1 I have now configured the system so that it installs the Ember console commands by default, so this can also help us debug if there are further issues with this sort of thing.
I do have a PayPal button on my web page, although it’s not especially prominent -:
https://www.cd-jackson.com/index.php/about
Thanks.
No - there was a big discussion about this a few years back when I purchased the ZWave devkit to allow me to add support for secure devices. The foundation stated it would not support this sort of activity so I end up covering costs myself (which cost me over $2000).
1 Like
Updated to latest snapshot build of the binding and now my sensor works.
1 Like
The latest snapshot I could find still doesn’t work for me, because (at the time of testing) it’s already a couple of days old. However, I compiled the com.zsmartsystems.zigbee.dongle.ember bundle myself containing the modified key exchange policy from
and put it in the OpenHab add-ons folder.
With this change, pairing works instantly for all the light bulbs that previously never completed pairing in OpenHab 2.5.x.
@chris Is there any ETA for releasing this via “official” channels such that it can be installed via the OpenHab UI or console? I prefer keeping my main OpenHab2 installation kind of clean.
The latest snapshot is now quite old. As I said somewhere above, we need to get updates made to multiple repositories and this will take some time.
Thanks - glad to hear this. Thanks for testing.
I hope in the next week. I have a few more PRs to merge into the libraries yet, and then I need to get openHAB updated which may take a week or three to get this all merged unfortunately.
2 Likes
That will not give you the latest updates as @porst17 posted earlier. I hope to get this updated in the next week or so.
Ahh. Well the version to downloads fixes my pairing problem at least for now. I’ll watch for when the other fixes get merged in and update from there.
Setup: Openhab 2.5.1
Zigbee Dongle: Bitron Video (Ember)
After I bought an Ember based Zigbee dongle all my devices were working and I was really happy about it. Unfortunately the happiness only lasted for one day.
After I’ve restarted openhab, some Devices were offline and didn’t come online again.
Status of the Device: Offline Node has not completed discovery
The device was online and working before the restart, so I’m wondering why I`m getting this error right now.
Okay so I tried to delete the thing and connect it again.
I was not able to connect the device!
Just to test I used an backup of the entire system (openhab version 2.4 stable) and tried to connect device. It works immediately.
So I have exactly the same problem as @mrfrh
Please use the latest binding.
I have these issues as well with Openhab 2.5.2 and Ember EM35x Coordinator.
I’m trying to pair a Xiaomi Temperature and Humidity Sensor and a 12134 Lupus Mini Temperaturesensor.
I used to be able to pair them in Openhab 2.5.0 (I think), but since 2.5.1/2.5.2 I can only get to Node has not completed discovery.
Just created my account here, so I’m not yet allowed to attach the logs. Short excerpt:
2020-03-12 21:55:52.581 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspTrustCenterJoinHandler [newNodeId=AEFB, newNodeEui64=14B457FFFE2EC6D9, status=EMBER_STANDARD_SECURITY_UNSECURED_JOIN, policyDecision=EMBER_SEND_KEY_IN_THE_CLEAR, parentOfNewNodeId=EAC1]
2020-03-12 21:55:52.582 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 14B457FFFE2EC6D9: nodeStatusUpdate - node status is UNSECURED_JOIN, network address is AEFB.
2020-03-12 21:55:52.584 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 14B457FFFE2EC6D9: Polling stopped
2020-03-12 21:55:52.584 [DEBUG] [pp.discovery.ZigBeeNetworkDiscoverer] - 14B457FFFE2EC6D9: Device status updated. NWK=AEFB
2020-03-12 21:55:52.586 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 14B457FFFE2EC6D9: Polling initialised at 1947740ms
2020-03-12 21:55:52.587 [DEBUG] [pp.discovery.ZigBeeNetworkDiscoverer] - 14B457FFFE2EC6D9: NWK Discovery add node AEFB
2020-03-12 21:55:52.589 [DEBUG] [com.zsmartsystems.zigbee.ZigBeeNode ] - 14B457FFFE2EC6D9: Node state updated from UNKNOWN to ONLINE
2020-03-12 21:55:52.591 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 14B457FFFE2EC6D9: Updating node NWK=AEFB
2020-03-12 21:55:52.593 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 14B457FFFE2EC6D9: Node AEFB update
2020-03-12 21:55:52.596 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 14B457FFFE2EC6D9: Node AEFB is not updated
2020-03-12 21:55:53.880 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 14B457FFFE2EC6D9: Node SVC Discovery: ActiveEndpointsResponse returned CommandResult [TIMEOUT]
2020-03-12 21:55:53.884 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 14B457FFFE2EC6D9: Node SVC Discovery: request ACTIVE_ENDPOINTS failed. Retry 1, wait 2104ms before retry.
2020-03-12 21:55:55.991 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 14B457FFFE2EC6D9: Node SVC Discovery: running ACTIVE_ENDPOINTS
2020-03-12 21:55:55.994 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - 14B457FFFE2EC6D9: Added transaction to queue, len=1, transaction=ZigBeeTransaction [ieeeAddress=14B457FFFE2EC6D9 queueTime=0, state=WAITING, sendCnt=0, command=ActiveEndpointsRequest [0000/0 -> AEFB/0, cluster=0005, TID=--, nwkAddrOfInterest=AEFB]]
2020-03-12 21:55:56.109 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspTrustCenterJoinHandler [newNodeId=AEFB, newNodeEui64=14B457FFFE2EC6D9, status=EMBER_STANDARD_SECURITY_UNSECURED_JOIN, policyDecision=EMBER_SEND_KEY_IN_THE_CLEAR, parentOfNewNodeId=EAC1]
I checked a bit in the code and it seems that in ZigBeeNodeServiceDiscoverer both requestPowerDescriptor and requestActiveEndpoints get a timeout on every retry which leave the node uninitialized.
I get that these devices may fall asleep mid-discovery, but mashing the wakeup button at various intervals during the discovery didn’t change anything for me.
I’m a java developer myself so I’m willing to get my hands dirty - be it a pull request or e.g. debugging - but I have no experience with ZigBee internals, so not sure where I should start looking.
Alternatively, I’d be willing to provide test hardware or a donation to acquire it.
Thanks for the awesome job with the binding btw 
[EDIT]
I figured out what my problem was. I had set to allow all joinings when trying to pair a device. As soon as I went back to ‘only secure joinings’ it worked right away…
2 Likes
I also had the option to “Allow all joins” with “Bitron video Ember” also activ and over 12 h many devices went offline and were not again properly recognized (unknown). I did this because of the XIAOMI (Lumi) devices that are partially recognized but e.g. a number channel was created instead of a switch, which of course then does not work (magnetic contact). Yesterday I put it back and the lost devices could be taught again. Even now in the morning everything is online and working. Thanks for the hint.
Okay, I take back the above statement, it was a coincidence. In my case had nothing to do with this setting.