Firmware upgrade the Bitronvideo BV 2010/10 ZigBee USB dongle

I had some success upgrading a Bitronvideo BV 2010/10 ZigBee USB dongle :slight_smile:
Firmware needed: https://github.com/grobasoz/zigbee-firmware/raw/af7c35ea8d580152eb9853af1d3fab91bef3b5d4/EM3587/NCP_USW_EM3587-LR_678-115k2.ebl

(I used the the zigbee-binding dongle firmware upgrade command in openhab-console)

This is NOT the latest commit, but it is the first commit grobasoz did for EM3587:
“I have added the firmware to the repository. I used 115k2 Baud, S/W flow control, and PC6 for PA/LNA.”
He later changed this to PC5 for the firmware build. This do not work on my testing Bitronvideo stick.
I have no clue what “PA/LNA” is, PC6 is some sort of default setting from Silabs?.
More details in here: https://github.com/grobasoz/zigbee-firmware/issues/14

Only tested with one of my zigbee v.3 device that was troublesome on old firmware for now,
but it looks OK.
openhab.deb “unstable” 3.2.0~S2577-1

But, there is one thing that do not work:
I had to use a .things file for the coordinator settings because the new baudrate would not “save” in the UI. It always find its own way back to 57k6.

Edit: there is this bug: https://github.com/openhab/org.openhab.binding.zigbee/issues/726
If you have trouble with getting the stick take the settings from the UI, a .thing file may be a workaround.
I use my Bitronvideo stick just for testing and sniffing these days…

2 Likes

Thanks for the feedback @NilsOF

:+1:

I wonder if we shouldn’t try and make this easier for OH users and potentially add the FW to the zigbee repo, and also provide a simple way to manage this. I’ll have a think about this. I recently added this to the documentation, but I’m sure we can make this even easier.

It’s the Power Amplifier and Low Noise Amplifier control. PC6 is the port.

Strange - it should be controllable and I always use 115k2 here so it is certainly possible to set this. I wonder if you can work out why this didn’t work so it can be resolved?

2 Likes

That would be great.
I did have some hassle getting the stick back into working order after a flash was over.
It looks to me like a reset issue where the binding and the stick was not in sync.
I just restartet the whole openhab as this “installation” only has the zigbee binding with very few devices. I would guess that just a binding restart would do the trick

Been thinking about that. The baud setting must come from somewhere.
Also these two openhab builds behaved a bit different:

Start-Date: 2021-11-16  20:32:22
Commandline: apt install openhab
Install: openhab:amd64 (3.2.0~M4-1)
End-Date: 2021-11-16  20:32:25

Start-Date: 2021-11-16  23:29:26
Commandline: apt install openhab
Upgrade: openhab:amd64 (3.2.0~M4-1, 3.2.0~S2577-1)
End-Date: 2021-11-16  23:29:38

On M4:
the stick settings behaved until I did a scan for new zigbee devices.
The settings in UI would then fall back to 57k6 and sometimes the port settings jumped to /dev/ttyUSB1.
Syslog on my computer showed no trace of something happening on the USB level.

On the 2577 snapshot:
it is impossible to get so far as do a scan for new devices as the UI refused to save the baud settings, causing the binding to proceed with 57k6

I welcome any suggestions on how to further troubleshoot :slight_smile:

I’m wondering if I can make this installable. Some time back I wrote a “firmware provider” -:

This allows people to install this bundle, and then drop a zip file with firmware and a metadata file into a folder. With the new marketplace it should be possible to make this simpler - possibly the thing to do is to create a new binding that effectively just pulls in this firmware provider, and also has a repository of the firmware.

I need to think about this a little more yet, but this would potentially allow users to install the firmware from the marketplace, and then do the update in the UI and not have to go anywhere near the console.

It’s been a while since I’ve used the firmware update in OH itself, but if I do the above I’ll do some more testing.

I’ll take a look at the config description to make sure nothing is out of limits in the way it’s defined. I think I added some more configuration recently so maybe something is wrong there.

1 Like

Do you get any error with this? I just had a quick look and the only change I made to the config definition was to add the Group Registration setting. This is a simple text definition so should be fine. I guess that the UI is generating this error and preventing the config being saved.

I’ll try and take a look at this more in a couple of days, but if there is any additional error returned, that might be useful.

@NilsOF I found a bug that meant some config wasn’t being managed properly in the Ember handler. This should now be fixed - thanks for reporting.

1 Like

Thank you! :slight_smile:
Will test as soon as the build propagates and time allow.

I will try to reopen my github acount, and report this to grobasoz.
Edit: [REQUEST] em3587 Bitronvideo BV 2010/10 · Issue #15 · grobasoz/zigbee-firmware · GitHub

Just tested with snapshot 2589 and the baud rate for the coordinator can now be saved from the UI. :slight_smile:

@chris : Thank you so very much!

Now it would be great if someone can confirm the firmware for the Bitronvideo stick and the work Chris has done on the zigbee binding :wink:

Just to round off this thread:
openHAB 3.2 should have the bug fixes (from around 3.2 RC1 and later)
Edit: and the bug only existed in snapshots some short time before RC1
Edit2: See first post, there is another bug that may have some influence on this.

This is still happening for me on the 3.2.0 release.
The stick is “online” until I do a scan where it goes to “unknown”. If I go to the settings, it’s back to 57k6
Any idea what I have done wrong?

The only thing I can think of; Are you shure you are not running a old zigbee binding? That can happen if it was manually installed.
I use the Bitronvideo sticks as sniffers right now so it might take some time before I can test.

I installed it via the UI, and if I go to Settings, Bindings, openHAB ZigBee Binding, I see this:

So I believe it is up to date, but maybe there is something else to check.

Looking further around, there is this issue being discussed: discovery of new thing will reset the baudrate of the BV2010/10 · Issue #726 · openhab/org.openhab.binding.zigbee · GitHub
I’ll keep an eye on it

1 Like

Probably you are seeing a different issue. There is a problem that is under discussion that is due to the way the discovery system works. We just need to work out how to resolve it.

1 Like

So, I got around that problem somehow…
I used a thing file for the stick as a temporary workaround.
I did remove the .thing file and did set up the stick in the UI with the same key, IDs and so on.
I tested a couple snapshots before one worked.

I run openhab:3.2.0.M3 in a docker environment. Therefore, I copied the *.ebl to the “userdata”-volume, but the openhab-console does not seem to have access to that location. In the logs, I see that the file cannot be found.

openhab> firmware update zigbee:coordinator_ember:bitron /openhab/userdata/NCP_USW_EM3587_6710-LR.ebl
# An unexpected error occurred during execution.

how did you access the firmware file from within the OH-console?

Excerpt from RFC 1738:

3.10 FILES

The file URL scheme is used to designate files accessible on a
particular host computer. This scheme, unlike most other URL schemes,
does not designate a resource that is universally accessible over the
Internet.

A file URL takes the form:

   file://<host>/<path>

where is the fully qualified domain name of the system on
which the is accessible, and is a hierarchical
directory path of the form //…/.

For example, a VMS file

 DISK$USER:[MY.NOTES]NOTE123456.TXT

might become

 <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

As a special case, can be the string “localhost” or the empty
string; this is interpreted as `the machine from which the URL is
being interpreted’.

The file URL scheme is unusual in that it does not specify an
Internet protocol or access method for such files; as such, its
utility in network protocols between hosts is limited.

@Ap15e thanks for the excerpt. unfortunately, i do not understand it yet.

my openhab-container runs in host mode and therefore should be localhost.

openhab> firmware update zigbee:coordinator_ember:bitron file:///openhab/userdata/NCP_USW_EM3587_6710-LR.ebl
# An unexpected error occurred during execution.

the path still seems wrong.
the files have the openhab:openhab user:group-definitions and are 755 readable.

Thanks for your advice!

Just from memory the command would bee:

zigbee firmware /path/to/the/firmwarefile

As long as the file is readable by openHAB, it should work.

Just type zigbee in the console to get some info for the “sub-commands”.