I bought this Dongle recently and in Home Assistant it was seen as a Zwave coordinator. Which I ignored and set it up with Zigbee2Mqtt and it works fine (and worked fine before in ZHA also). But I have noticed the LQI ratings aren’t that brilliant. Even of devices quite close. Functionally I don’t experience any issues.
Is there a way for me to see what firmware version is flashed on it?
Would flashing newer firmware have a change of improving signal strength?
Will flashing newer firmware cause me to have to pair everything again or set the dongle up again in Zigbee2Mqtt?
As I’ve never in my life flashed firmware. I see lots of tutorials about how to do this. But they are all Windows based. I’m Mac based. I tried searching for a tutorial there but didn’t find anything. Does anybody know what would be the main differences?
cc2538-bsl.py using the /dev/serial/by-id link is usually the right thing to do. The only problems I am aware of (ironically) are programs which follow that link and cache the result. (Podman used to do that, but it’s fixed now.)
This isn’t necessary, because python looks in the current directory for files (as is usual) rather than following a search path. If you want to chmod +x cc2538-bsl.py; ./cc2538-bsl.py, then you’ll need that.
Note also that sudo pip3 install is a recipe for breaking your distro — it can mess with system packages. Better to only run pip as a non-root user.
Yikes, so my update of the stick worked. However I wasnt able to recover my network
I had a backup, but I wasnt unable to restore it using the zha toolkit, something about invalid param although I had just copied the command from help page.
Wife was not pleased and had to get the baby to bed so didnt have much time to debug…
Re-paired all my 86 devices in a couple of hours, all working now. The pairing process was alot easier though, seems like the update did make a difference compared to the July release I was on before. Not going to attempt this again though!
If you received one that is not from the very latest batch then upgrading firmware should definitely help as other than many bug-fixes from Texas Instruments (and community firmware fixes) Koenkk changed transmission amplification (TX power) from +5dBm to +9dBm by default, and before in earlier firmware it did not accept if tried to change the transmission amplification (TX power) via the application at all.
If you have the latest firmware then you will have the option to increase transmission amplification (TX power) all the way up to +20dBm if you want, though personally, I do not recommend using much higher transmission amplification (TX power) than +9dBm since it only makes it “shout louder” and not “listen better” so increasing it more means can get the effect that the Zigbee Coordinator can not receive all the signals/messages from Zigbee devices that are further away which have weak radios. It is much better to instead add more Zigbee Router devices to act as signal-repeaters/range-extenders to build out your Zigbee network mesh.
Anyway, if you flash the firmware using JelmerT’s latest cc2538-bsl from master branch on GitHub then it should not matter which operating-system as long as you install Python for that operating system and all of the dependencies that cc2538-bsl needs.
Regardless I recommend that you in addition perform a NVRAM backup and Zigbee network backup with zigpy-znp before flashing (just in case) → https://github.com/zigpy/zigpy-znp/blob/515f4a1b83d073f2e014d3fc2bcc930bab9712ba/TOOLS.md According to Zigbee2MQTT documentation you should not need to re-pair any devices after upgrading firmware but again create backups so you can restore if it happens to reset configuration on the Zigbee Coordinator (just to be sure).
Also know that Zigbee and especially the Zigbee Coordinator are known to be very susceptible to Radio Frequency Interference (RFI) / Electromagnetic interference (EMI) caused by different signal interfering sources, so all the tips to try to reduce interference are extremely important to follow even if they may sound silly.
Upgrade to the latest firmware on the Zigbee Coordinator adapter (whichever adapter you have).
Connect the Zigbee Coordinator adapter to a long USB extension cable to get it a bit way.
Be sure that Zigbee Coordinator adapter is connected to USB 2.0 port (or via USB 2.0 hub).
Shield any computers and USB 3.0 peripherals like hard drives by using metal enclosures.
Make sure Zigbee Coordinator adapter and devices is not close to WiFi router or access-points.
Zigbee devices do not have long-range (or good radio signal penetration) on their own so begin by successively adding more mains-powered Zigbee Router devices (a.k.a. Zigbee signal-repeaters/range-extenders) closer to the Zigbee Coordinator adapter and then in each room building outwards to form a stable Zigbee network mesh before adding devices further way.
Afting adding mains-powered Zigbee Router devices pair all the other devices where you plan to have them permanently installed and do not move them around afterwards.
If it is detected as a Z-Wave Controller is Home Assistant 2022.2 or later then means you got one of the earlier shipped batches that were missing a custom product description of “Sonoff Zigbee 3.0 USB Dongle Plus” written to their CP2102N chips that is needed for applications to identify it as a Zigbee compatible device and not just as a generic “Silicon Labs CP2102N USB to UART Bridge Controller”.
ITead released a Python script (and a Windows executable) that should fix it by writing the description to the CP210x chip (but( I could not get it working myself on my Windows 10 computer). There a link to download and more information posted about it previously in this thread as well as in this other thread
Thanks for the very extensive reply @Hedda ! It indeed did not recognize it correctly. I am going to take some time to flash the dongle. Sounds like something to take your time for.
I had already started working on building out a few devices to enhance the signal all the way through the house. And picking a channel that does not coincide with my two wifi channels and other zigbee (hue) channel. Its still very close to one of my routers, working on getting it placed somewhere else also.
First thing first, firmware flashing, glad to hear there is a way to do a backup, as I never done this
Guide for updating firmware via cc2538-bsl Python tool without opening enclosure
Install Silabs CP210x device drivers (CP2102N USB-to-UART bridge / USB-to-Serial converter chip) needed for Windows OS and Mac OS, (this also required a reboot of my operating-system).
Install Python (in my case I installed and tested with Python for Windows 3.10.1).
Launch command-prompt (cmd.exe) as elevated Administrator. Upgrade pip with python -m pip install --upgrade pip, (if pip is not available then first run python -m ensurepip --upgrade), then pre-install dependencies fro cc2538-bsl from PyPi via pip command: pip install wheel pyserial intelhex python-magic
Optional but recommended: Download and install zigpy-znp via pip/PyPI with pip install zigpy-znp then perform NVRAM backup by following instructions in TOOLS.md (also find more details ZNP radio backup procedure at Coordinator Backup and Migration · zigpy/zigpy Wiki · GitHub) for Windows backup command should be something like python -m zigpy_znp.tools.nvram_read COM5 -o nvram_backup.json and optionally also backup Zigbee network via python -m zigpy_znp.tools.network_backup COM5 -o network_backup.json
Download cc2538-bsl on GiHub from its “master” branch, (and not via pip/PyPI), unpact the zip to a folder then launch command-promt (cmd.exe) as elevated Administrator and run its setup.py to install its dependencies (should include “setuptools”, “wheel”, “pyserial”, “intelhex”, and “python-magic” packages).
Get latest firmware (I tested latest “CC1352P2_CC2652P_launchpad_*.zip” image available from its “master” branch at this time. Alternatively, you could get the latest “beta” version from the develop branch). Regardless make sure to get the correct image file as should be the one for “launchpad” (and not for “other)”!
Stop any applications or services that might be connected to the Zigbee adapter via serial port (ex. Home Assistant’s ZHA integration, Zigbee2MQTT, ioBroker, Jeedom, etc.). In my case, I ran the update on another computer so nothing to stop there.
Run command to flash from command-promt (cmd.exe) launched as elevated Administrator, example with firmware release available at this time: python cc2538-bsl.py -p COM5 -e -v -w --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20211217.hex
Obviously need to replace number in “COM5” with the port # actually shown used under ports in Device Manager on Windows on your computer as the OS will just assign the next available Serial/COM-port.
Also, if using Linux or Mac OS instead of Microsoft Windows then the COM# serial device path after -p will be different when set the port to use, (like for example /dev/ttyUSB0 or /dev/ttyUSB1) and might need different Silabs CP210x device drivers (CP2102N USB-to-UART bridge / USB-to-Serial converter chip) for your operating system, on Linux might have to run Python with sudo for the flashing command to get permission to the files, and read that many on Linux successfully run sudo python cc2538-bsl.py -e -v -w --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20211217.hex without setting serial device path with -p for port to use.
Both videos basically outlined the same thing, and are current at the moment 15-Feb-2022. In my case, it worked the first time I tried. If I have to flash a second dongle today, I probably can get it done within 10 minutes.
… and subsequently to change the device description, see above.
Dongles from newer batches would not have to do this, but mine was from July 2021.
Being on a Mac I got stuck a few times, but with google managed to get further and further. I got a bit, okay fully stuck on the part with the port. I also found another guide at Update iTead Sonoff Zigbee 3.0 USB Dongle Plus and combined it kind of with yours… It ran, crashed midway. Ran it again and worked!
All my devices in Zigbee2mqtt where still there. I needed to power the smartplugs who are acting as routers off/on before they could be pinged. But that was it. Back up and running.
Mains-powered Zigbee Router devices will usually reconnect by themselves after a while if you just wait a few hours (though sometimes up to 24-hours at longest), however any sleeping Zigbee end-device like battery-powered sensors devices will normally need to be manually woken up.
If you have for example a door/window sensor then you will need to activate it by open or close the door/window so it will send a state update in order for it to connect again, similarly temperature
sensors need the temperature to change to send state update in order to connect again.
So a workaround for quicker reconnections is to take out and put back batteries in any battery-powered devices and just unplug and replug any mains-powered devices if can not make it force a state chnage.
My battery powered sensors came in directly, the smart plugs I turned off and on and came back. So for my it wasn’t a huge issue. Not sure why the sensors directly reconnected. I do have availabilty check set to true in Zigbee2mqtt, but that should cause the plugs to be pinged, not the battery powered sensors. I’m glad it’s flashed and all working well
Thanks, it does appear to be a ZHA issue. Should I sit tight and hope for an update? Or do I bite the bullet and migrate again over to MQTT? It’s still odd that ZHA did control the Lutron Aurora before I updated to the Sonoff 3.0.
Regarding the Lutron Aurora. I finally moved the Aurora I am testing from ZHA with Sonoff zbbridge coordinator to zigbee2mqtt with Sonoff 3.0 dongle plus. I was only able to receive the dimming events on ZHA config cite, the on/off came thru maybe 10% of time. This is a bit of a hack solution in order to get both the on/off and dimming info into Home Assistant. The Aurora seems to send messages in a way that make if hard to capture the actionable events. This combined with it’s kind of poor physical UX design and high price make for not a good choice IMHO. Link to the steps I did below:
Hello,
In case of a machine failure (RPi4) which is running with HA and Sonoff stick installed, can I just use another machine (for example a mini PC) and plug in another Sonoff stick?
Or do I need the same stick plugged in to the new machine?
Or in case the Sonoff gateway may get damaged, can I just plug in another one (backup)?
Or do I need to do update the adrress, etc?
It depends if properly backup Zigbee network then restore backups to another computer and/or dongle.
Zigbee2MQTT does perform automatic backups to local storage by default so if you restore that backup on another computer then yes it should work with any other CC2652 backed stick, see their FAQ here:
ZHA does however not yet have perform automatic backups to local storage by default so you would need to setup daily/nightly backups yourself and make sure it is replicated to separate storage. See:
Anyway, restoring a proper Zigbe network backup should also restore the address, etc. needed, but note that it will take many hours for devices to connect and Zigbee network to repair itself, and some devices might need to be manually woken up by pressing buttons on them, etc. to force a state change.
I recently got Sonoff Zigbee 3.0 Dongle plus (firmware: 20210708).
I am using zigbee2mqtt with Electrolama ZZH (CC2652R Stick).
My plan was to replace coordinator to Sonoff stick and make ZZH stick as router.
I changed sticks - Sonoff dongle is up and running, all devices stayed connected and working ok.
Next plan to make ZZH as router. I flashed ZZH stick with router software with FlashProgrammer.
Now when I plug this stick in - i can’t see it in zigbee network - it doesn’t try to join network.
My question - what am i doing wrong? Is there any additional actions needed? I have 23 devices in zigbee network, couple relays working as router, i’ve never added stick as router before.
Will it autojoin or do i need to make it somehow in pairing mode?
I have had this dongle for a few weeks, installed it using ZHA.
It worked, but I never felt it was reliable: slow reaction time, automations/scripts partially interpreted (like lights not always picking the right level)…
So, I tried to clean and reinstall. In doing so I noticed that the LQI of my devices was 100 at the very best (when the device is 2 meters away from the dongle), usually it’s around 40…
Could it explain my “disappointment”?
Would Zigbee2mqtt work better?
My HA is running on a virtual machine on a synology nas.
So I just came here to look for opinions on the previous firmware, but spotted this. I am using the CC1352P2_CC2652P_launchpad_coordinator_20210708 without any real issues… I was looking into backing up and upgrading to the CC1352P2_CC2652P_launchpad_coordinator_20211217 with the increased gain… but am wondering if I should just leave well-enough alone. I have an occasional disconnected bulb that just power cycling resolves but that has been pretty rare lately. Seeing that another update is on the way maybe I should just wait for that one to get ironed out? Am I missing out on anything by not upgrading? As I said no “real” issues… just the desire for the latest and greatest. But also don’t want to open a can of worms for no reason.
