Ok it’s been driving me nuts.
Situation:
I have two Sonoff Zigbee 3.0 -P dongles. Originally I had them both as coordinators and used the ‘migration’ flashing proceedure to help test the newer firmware. I since re-flashed the second one to a Router/Repeater instead of a Coordinator but the IEEE address has stuck cloned as the same as my main Coordinator. So I think this is creating some confusion in HA when I try to ‘manage’ the repeater vs coordinator and I want to change the IEEE of my router to something different but having no luck.
So to try changing the IEEE I’ve tried:
Flash Programmer 2 - no luck, shows as if it has updated but upon read-back it shows the old IEEE CC2538-bsl - no luck, shows as if it has updated but upon read-back it shows the old IEEE Zigstar - no luck, shows as if it has updated but upon read-back it shows the old IEEE
I’m using a Windows 10 machine.
So has anyone actually ever got this working a second time? Obviously mine worked the first time as it cloned the IEEE from my other dongle. But seems like it is stuck. I saw a one-off comment somewhere else on the internet that Silicon Labs chips only have a write-once IEEE ability and then it’s permanent. Can anyone confirm if this impacts the Sonoff Dongle-P?
hi all! i have checked this evening and i currently have the firmware 20210708 on my Sonoff_Zigbee_3.0_USB_Dongle_Plus. i use zigbe2mqtt.
what would be the benefits to update? will the procedure make me loose access to my current network configuration?
You FW is old. A lot of users were on 20221226 for a long time. Currently many use 20230922 and a new might come soon due to NWK problems. If you have no issues at all, then maybe wait for the new one…
You’re asking about cc2538-bsl on linux right? Here is the command as I used it: $python3 cc2538-bsl.py --bootloader-sonoff-usb -e -w -v CC1352P2_CC2652P_launchpad_coordinator_20221226.hex
and it auto-picked /dev/tty/USB0 which in my case was correct. If you already have another USB device there, the docs say you can use the -p option to select the serial device file yourself.
No. I was talking about the step prior to this. How to use the python scrypt to enter BSL? There is a python script, uartLog.py, that enter BSL on windows without disassembling the Sonoff stick. @sshaikh managed to make it work on Linux, but I can’t seem to follow his advice to make it work. See quote below.
That is what the above mentioned sonoff specific parameter does in JelmerT’s cc2538-bsl script:
”For ITead SONOFF Zigbee 3.0 USB Dongle Plus: For the CC2652P based “SONOFF Zigbee 3.0 USB Dongle Plus” (model “ZBDongle-P”) adapter from ITead you need to invoke toggle to activate bootloader with --bootloader-sonoff-usb if you do not want to open its enclosure to manually start the bootloader with the boot button on the PCB.”
I’ve got a new dongle on order and it was listed as having Z-Stack pre-flashed. Do I need to consider doing any flashing as mentioned in this thread before I start using it or go ahead and set things up with what it was flashed with?
It is not an absolute must but yes it is generally recommended to upgrade the firmware before you start using it the very first time (since they still ship them with a very old firmware with many known bugs that have been fixed in newer versions), …however also note the tip that it then also generally recommended to update again and again later if and when you have issues with any devices as future versions can contain bug fixes for issues with devices that have not yet been released yet, (so after the initial firmware update you can follow the rule “if it ain’t broke then don’t fix it”) see:
PS: Other than upgrading Zigbee Coordinator firmware the very first time, another tip is that the “if it ain’t broke then don’t fix it" rule also applies to other Zigbee devices too (for example the IKEA Trådfri Zigbee devices having problems with latest firmware so better not to upgrade firmware if not having any issues).
@Hedda thanks. I was able to easily use the ti-cc-tool Docker image to flash the latest Z-Stack. I got it plugged into my Raspberry Pi on and extension and got my entire Zigbee network migrated over to it with almost no effort.
for the record : may 2024 , on a raspberry pi 5 , i stuck it in a usb 3.0 port when i got it, and put a 2 meter usb3(blue…) extension in it when i read that was the thing to do, and it works just fine. Matter o fact when i re-plugged it into 2.0 trying to fig the herdsman error for 2mqtt it seems i had to manually reconfigure the whole thing and nothing worked anymore so i plugged it back into the original 3.0 and i had to kinda manually reconfigure it again, which worked fine up until the point where i choose “keep network settings” then i get “an” error … which apparently is fixed by after that point rebooting
this really is like doing linux in the 1990s …
so stuff might need revisiing in '24 for ra-pi 5s … i dont know and im by no means an expert but it works fine in a 3.0 slot
You only have to change the port configuration when moving it between different USB ports if you have not configurated the seriel device path as /dev/serial/by-id/
So suggest changing path in the configuration from /dev/ttyUSB0 to /dev/serial/by-id/ path as that will not change if change USB ports or add other USB devices.
Do not combine USB 3.0 port with a USB 3.0 cable as you will then get EMI interference. Use either a USB 2.0 port or a USB 2.0 cable (or both) to avoid EMI interference from USB 3. In fact, do not even place it close to other USB devices or cables. See:
Just jumped into the game and have a P with 20210708 loaded. However I want to go mainly with IKEA Tradfri Switches and Plugs for the beginning.
What is the latest stable Zstack recommended which does not have trouble with IKEA ?
It is newer IKEA device firmware updates that are known to cause issues so just do not update firmware on your IKEA devices unless you are already having major problems with them, (you really should not try to fix what is not broken, at least not when it comes to IKEA devices Zigbee firmware as IKEA’s newer firmware is known to have problems), but that is enough discussion about that in this thread, (please start a new thread if you want to discuss that more).
As for this Zigbee Coordinator adapter (which is what this thread is only about), as long as you follow other best practices then the latest Z-Stack Zigbee Coordinator version from Koenkk’s master branch is generally what is recommend for all CC2652/CC2652P based radio adapters, see → Z-Stack-firmware/coordinator/Z-Stack_3.x.0/bin at master · Koenkk/Z-Stack-firmware · GitHub
Again, first also make sure that you do your best to try to follow follow all other best practice tips as per this guide as it tella how to avoid the root causes for most issues and problems most users have if they do not optimize their Zigbee setup. Please start a new thread if you want to discuss that further:
FYI, there is a new experimental Z-Stack 20240710 firmware build available for those with issues in previous release who want to test + preferably also give feedback to the Z-Stack firmware developers:
Other testers have been testing it for three weeks now and most look to be reporting it as stable so far.
If no one reports it as troublesome then that version will likely soon become the next “master” version.
Note! Always remember to do a Zigbee network backup to file before upgrading firmware for restoring.
FYI, Koenkk’s community build of Z-Stack_3.x.0 coordinator 20240710 firmware version has now officially been released as the new “master” which means that is the latest cutting-edge release image available:
While this version now being the new “master” implies that it is mature enough for everyone to start using, but be aware that it does cutting-edge so it has still not been proven to be stable in the long-run, therefore if you stumble into issues you might need to revert to an older firmware version and restore your Zigbee network from a backup (thus you always remember to do a full Zigbee network backup to file before upgrading firmware for restoring!). Not sure how well it has been tested with the ZHA integration and zigpy-znp as Koenkk himself only test it with Zigbee2MQTT (because he is the leas developer of that project).
Note! Regadless of which Zigbee gateway software application that you are using it is common that zstack firmware flashing restore the adapter to factory default and therefore it is generally recommended and best practice to always do a full backup before flashing firmware and then restore that backup directly after flashed the adapter. Personally I always temporary stop/disable my Zigbee gateway software application use zigpy-cli as a stand-alone tool on a other computer for external backup and restore:
As always, flash at your own risk and be prepared to revert to older firmware if not working well for you with your specific devices (and then needing to restore backup from file so save that in a good place).
Again, post feedback on Z-Stack_3.x.0 coordinator 20240710 firmware specific issues on GitHub here: