Probably not - unless it’s very very old it won’t really matter. I think quite a few people are using this dongle without problems.
Hi,
I think I ran into the same or at least a very similar problem:
I was using OpenHab 2.4 with the following devices for about a year now:
- Bitronvideo ZigBee dongle (listed as BV 2010/10, Ember EM35x NCP in “Things”)
- 2 tint color+white light bulbs
I had no issues at all with OpenHabian 1.4 and OpenHab 2.4. The devices even kept working after updating to OpenHab 2.5. A couple of days ago, I decided to install OpenHabian 1.5 and OpenHab 2.5 from scratch (for no good reason actually … :-|)
So I needed to pair the two light bulbs again. I did a reset and put the ZigBee dongle and the bulbs into discovery mode. The devices only show up as “Unknown ZigBee Device XXXXXXXXXXXXXXXX”. Pairing never completes. I made like 30 attempts.
Usually, no channel shows up. Sometimes, I got a channel called “dimmer”, but it did nothing. Only once, the device showed up with its correct name and channel:
- Name: MLIZBTExtendedColor
- Channel 1: “Color Temperature”
- Channel 2: “Color”
Nevertheless, the lamps also didn’t signal pairing success (usually by flashing a couple of times) and I wasn’t able to control the lamps via OpenHab afterwards.
I did not capture any logs yet, but I can do so if you could provide some clear instructions.
Best,
Christian
As I already said, I very much doubt this, but I guess I should have asked what version you have? It will be displayed in the log on startup and should also be in the thing properties.
Are the instructions provided in the binding documentation unclear? If so, I’ll try and improve this, but please provide feedback on what you think is not clear.
Thanks.
1 Like
I forgot to mention that I made a disk image of my previous OpenHabian 1.4/OpenHab 2.5 installation before attempting the clean OpenHabian 1.5/OpenHab 2.5 install.
I reverted back to that image and it’s the same there: No successful pairing with OpenHab 2.5 and the BV dongle. So this issue seems to happen on fresh installs as well as on upgraded ones.
I’ll post my openhab.log in a minute.
That binding and the one from the new installation are identical, assuming you meant that 2.5 Stable was installed on both systems.
Here’s the OpenHab 2.5 log: openhab.log (768.5 KB)
I removed all the ZigBee things, including the dongle, and went through the discovery process again two times, both times adding the “Unknown ZigBee Device 00158D0001FE0393” as a thing.
On the seconds attempt, I noticed that the device was recognized as “online” and had two channels attached (Color Temperature and Color), but again, the lamp itself didn’t confirm the successful pairing and also didn’t respond to changes to the Color/Color Temperature via OpenHab.
To clarify:
First system:
- originally OpenHabian 1.4 + OpenHab 2.4
- pairing of devices was done via OpenHab 2.4 about a year ago
- upgrade to Openhab 2.5
- already paired ZigBee devices still working
- after resetting the ZigBee devices and deleting them from OpenHab, I was not able to pair them again
Second system:
- originally OpenHabian 1.5 + OpenHabe 2.5
- pairing never succeeded
Currently this is running an old version of the libraries so I won’t really look at this until I’ve updated the binding to the newest version. There are some conflicts between repositories that are causing problems with this, so until this is resolved I can’t do anything.
Hopefully I’ll get the binding updated in the next few days.
I checked both but could not find a version information.
The startup log shows a lot of configuration information about the dongle (and some strange “unsupported cluster” messages), but as far as I can tell no version information: openhab_log_startup.txt (137.4 KB)
Paper UI only shows two properties: usb_product_id": “35636.0”, and “usb_vendor_id”: “4292.0” (coordinator_jsondb.txt (5.2 KB) )
Is there another way to check the firmware? Or did I miss it in the startup log?
It will definitely be in the startup log - it’s almost the first thing that is logged when the EZSP layer starts. It will be something like 6.3.4.5.
Are the serial parameters set the same as the old system? That could cause communication issues.
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