(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.
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?
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:
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
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.
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.
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.
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.
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?
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
A file URL takes the form:
where is the fully qualified domain name of the system on
which the is accessible, and is a hierarchical
directory path of the form //…/.