Problem with fresh Openhab 2.5 / Zigbee / Bitronvideo Ember Dongle / Device Pairing

I only could find “stackVersion=5800”. If this isn’t the right one, is there any keyword to search for? How should the message look like?

Serial port is initialized, then there’s the “EzspVersionRequest” (but this is not a firmware version?), afterwards device configuration starts:

    2019-12-27 19:26:25.127 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP dongle initialize with protocol ASH2.
    2019-12-27 19:26:25.130 [DEBUG] [ding.zigbee.handler.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyUSB0] at 57600 baud, flow control FLOWCONTROL_OUT_XONOFF.
    2019-12-27 19:26:25.175 [DEBUG] [ding.zigbee.handler.ZigBeeSerialPort] - Serial port [/dev/ttyUSB0] is initialized.
    2019-12-27 19:26:25.248 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - AshFrameHandler thread started
    2019-12-27 19:26:25.261 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameRst []
    2019-12-27 19:26:25.660 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspVersionRequest [desiredProtocolVersion=4]
    2019-12-27 19:26:25.670 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
    2019-12-27 19:26:26.329 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameRstAck [version=2, resetCode=11, Reset: Software]
    2019-12-27 19:26:26.333 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Connected
    2019-12-27 19:26:26.337 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=0, ackNum=0, reTx=false, data=01 00 00 04]
    2019-12-27 19:26:26.363 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=0, ackNum=1, reTx=false, data=01 80 00 04 02 00 58]
    2019-12-27 19:26:26.367 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=0, ackNum=0, reTx=false, data=01 00 00 04]
    2019-12-27 19:26:26.378 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspVersionResponse [protocolVersion=4, stackType=2, stackVersion=5800]
    2019-12-27 19:26:26.382 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=1, notRdy=false]
    2019-12-27 19:26:26.384 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspGetConfigurationValueRequest [configId=EZSP_CONFIG_SOURCE_ROUTE_TABLE_SIZE]
    2019-12-27 19:26:26.387 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
    2019-12-27 19:26:26.390 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=1, ackNum=1, reTx=false, data=02 00 52 1A]
    2019-12-27 19:26:26.399 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=1, ackNum=2, reTx=false, data=02 80 52 00 00 00]
    2019-12-27 19:26:26.403 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=1, ackNum=1, reTx=false, data=02 00 52 1A]
    2019-12-27 19:26:26.414 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspGetConfigurationValueResponse [status=EZSP_SUCCESS, value=0]

Thanks - that’s fine. I think it gets reformatted at some point, but that’s what I was after.

It’s a new enough firmware version (but not super new - probably a couple of years old). The HZUSB-1 sticks that many people are using have firmware version 5.4 if I remember correctly and that also works fine.

1 Like

In fact I’ve just realised some of the testing I’m doing here for a Smart Energy product is using a 5.8 version of the stack, so it’s definitely fine.

1 Like

For testing, I downgraded to OpenHab 2.4. Otherwise, same OS and hardware as mentioned previously. Pairing works on the first try there.

Strange. Are you sure the link key is not being changed from the default? That would prevent joining from working properly.

1 Like

I just looked at this log - are you continually resetting the device?

In this log, it looks like the device starts to join. It announces itself on the network, and the binding starts to discover it. Then it announces itself again with a different address - this normally means it has been reset. Then it announces again with a different address - this happens a number of times -:



After the last join, you give it a little time to settle down, but the NCP is saying that the delivery fails -:

It’s hard to know why this is, but it means that the dongle doesn’t get the low level APS ack.

I did not touch the dongle settings if this is what you are referring to. Neither in 2.4, nor in 2.5.

As mentioned above, I made two pairing attempts. Since the lamp hasn’t been paired yet, it seems to go through the same steps as when resetting it after turning it on (it’s cycling through a couple of colors). Probably, this is what is causing the address changes.

Since the log included three different addresses, I guess I was too impatient during one discovery attempt. I remember the lamp didn’t show up at first, so I probably turned it off and on again, because I thought it would only go into pairing mode then.

I can provide a log with just a single attempt if this is off any help.

Here is a log of the successful pairing from OpenHab 2.4 (used the other lamp 00158D0001FDF3BD this time, but it’s the same for both): openhab_2.4.log (623.6 KB)

Once I get the development environment working I will migrate the binding to the latest libraries. These are already in use by Deutche Telekom (who also use the binding) so hopefully that will help. I can’t really work on the 2.4 binding as it’s really very very old now - sorry.

1 Like

The OpenHab 2.4 log I posted above was just for reference to check how a successful pairing between the mentioned dongle and lamp looks like.

Once your dev environment is ready, I can help testing if necessary. I have a spare OpenHab 2.5 installation I can use for that without breaking my main OpenHab system.

Thanks a lot for your efforts!

Best,
Christian

Ok, that’s fine. I know what the pairing and interrogation looks like. Once I get the development system working I’ll take a look at this.

Just for your information:

  • I downgraded this system to 2.5~M2. (I did not try any of the other 2.5 milestones)
  • With the same hardware (dongle & bulbs / relay) at the same locations (–> range), discovery and pairing works almost instantly :slight_smile:

Once I get the development system working I’ll take a look at this.

Hi, are there any news on this issue?

Not really - we can only wait for the merge to happen I’m afraid :frowning:

While pull request #1043 is still waiting, shouldn’t it be possible to manually update zigbee binding & libraries as the manual install script used to do?

Or do I miss something and things will break?

I assume these are these most recent versions that should fit to OH 2.5 stable:

Libraries:
https://dl.bintray.com/zsmartsystems/com.zsmartsystems/com/zsmartsystems/zigbee/com.zsmartsystems.zigbee/1.2.9/:com.zsmartsystems.zigbee-1.2.9.jar
https://dl.bintray.com/zsmartsystems/com.zsmartsystems/com/zsmartsystems/zigbee/com.zsmartsystems.zigbee.dongle.ember/1.2.9/:com.zsmartsystems.zigbee.dongle.ember-1.2.9.jar

Binding (files updated 11-Jan-2020):
https://openhab.jfrog.io/openhab/sandbox-all/org/openhab/addons/bundles/org.openhab.binding.zigbee/2.5.1/org.openhab.binding.zigbee-2.5.1.jar
https://openhab.jfrog.io/openhab/sandbox-all/org/openhab/addons/bundles/org.openhab.binding.zigbee.ember/2.5.1/org.openhab.binding.zigbee.ember-2.5.1.jar

Xstream:
http://central.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.xstream/1.4.7_1/org.apache.servicemix.bundles.xstream-1.4.7_1.jar

Yes, this should work fine if you manually install the files.

1 Like

So I tried this out :smiley:
I upgraded my system to openhab 2.5 stable, uninstalled zigbee binding and manually installed the above versions of binding and libraries. With this setup, my existing zigbee network seems to work fine, and I could successfully pair one Osram Smart Plug which I had removed previously.

But when trying to pair more devices (even an identical Osram Smart Plug), I just end up with “Unknown Zigbee Devices”. I took a debug log, here’s what the debug log includes:

  1. Put Zigbee Binding in discovery mode
  2. Reset Osram Smart Plug (7CB03EAA0A02AF24)
    (wait some time)
  3. Put Zigbee Binding in discovery mode
  4. Reset Xiaomi Temperature and Humidity Sensor (00158D00032170C3)
    (wait some time)
  5. Put Zigbee binding in discovery mode
  6. Reset Xiaomi Aqara Wireless Mini Switch (00158D000204B50B)
    (wait some time)

Log file is a .zip-file, please rename to .zip:
openhab.txt (91.0 KB)

After this procedure, all devices are still listed in the inbox as “Unknown Zigbee Device”. I know the Xiaomi devices can be problematic, but at least the Osram Plug shouldn’t be. And I used all these devices successfully with my previous system (cc2531, openhab 2.5 M2), and also successfully paired them quite often.

Maybe you can take a look at the log file?

Strange - it is working fine here, and I have other users I support with the latest binding where it is also working fine. We also just completed a ZigBee certification this week for a system based on this.

I’m using it here with Osram bulbs, Ikea bulbs and a number of other devices.

I will try and take a look at the log when I get a chance.

Thank you for your efforts!

If there’s anything I can do to help, please let me know.