well maybe partially destroyed - bricked?
when i unplug it and plug there same model of stick, via same cable, to same distance from rpi4 all works Fine. so i wont believe interference… maybe i am wrong?
Or perhaps it was already broken, which caused the firmware flash to fail in the first place. If it has bad flash memory, it may fail randomly, which sounds like what’s happening. But it would be a hardware problem, not caused by flashing the firmware itself (at least I don’t see how).
1 Like
@robertklep
ah now i got it, so basically device is Bad ready to be trashed?
well strange i still dont get it … first time it crashed - now i can flash but it doesnt work in linux … doesnt make sense…
it was brand new stick … so crazy.
maybe i activated something on it? and its messing things up … as i used that stupid chinese docx … .and it failed few times - the intermediate steps. …
maybe i messed up something with these steps> no clue what it did.
Well, that’s what “random” means 
If your flashing tool has the option to completely erase the flash memory of the stick, you could try that. But I don’t think I would trust it to work reliably anymore.
If you managed to flash correct Zigbee Coordinator firmware then you can test it with zigpy-znp tools:
https://github.com/zigpy/zigpy-znp/blob/19df5c01e9f4675ad1e206446575c4a02e28c073/TOOLS.md
You can with it for example do an energy scan:
Note that this and other CLI tools to test it can only be used with Zigbee Coordinator firmare, not router.
I don’ know an easy way to test Zigbee Router firmware. Best would be to use seperate Zigbee Sniffer:
https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html
Using the correct terminology is very important for troubleshooting, so please understand that if you can still access the Bootloader (BTL/BSL) and can thus still flash firmware via USB/serial then your CC2652 by definition is not truly “bricked”. Not being able to pair devices when it has router firmware does not mean that it is “bricked”, because as long as you can still access the bootloader to flash firmware via USB/serial then it is not “bricked” by definition. Being “bricked” means that it can not be reflashed with firmware at all via normal means.
If the device is not bricked then you can still flash a firmware image via Bootloader to fix its problem. But do not get me wrong here, your device can still be faulty in a different way that makes it broken and might still need to be replaced, but technically that does not mean that it is “bricked” by definition.
Adapters based on CC1322 or CC2652 chips are easiest flashed by putting them in bootloader mode. After have done this you should use one of the following tools can be used to flash a firmware image:
- FLASH PROGRAMMER 2 by Texas Instruments (Windows only)
- ZigStar GW Multi tool (multi platform GUI tool)
- cc2538-bsl (multi platform Python based command line tool)
- llama-bsl (multi platform Python based command line tool, a fork of cc2538-bsl)
When it comes to CC2652 the definition of it being “bricked” means that the Bootloader (BTL/BSL) which is used to flash application firmware via normal USB or TTL-serial has been corrupted or no longer working due to a incorrect configuration.
The most common way to truly “brick” it is to flash the firmware image meant for a different adapter. This usually happens if you accidentally flashed the wrong firmware image because a firmware image meant for a different dongle does not have the same pinout (ie. a firmware image made for another type of USB adapter/dongle which board does not use the same pins).
Note thereforeITead Sonoff Zigbee 3.0 USB Dongle Plus need “CC1352P2_CC2652P_launchpad_*.zip” firmware image and flashing it with one of the other images will brick it (in which case is a user error):
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
In order to “unbrick” a truly “bricked” CC2652 device which has a wrong/corrupt Bootloader you need need to buy and use a cJTAG adapter → https://electrolama.com/radio-docs/advanced/flash-jtag/
When it comes to Zigbee2MQTT and any Zigbee Router questions like not being able to pair/join devices (if flashed correct Zigbee Router firmware image) it is best to ask/discuss in a new thread/discussion their dedicated discussions forum at https://github.com/Koenkk/zigbee2mqtt/discussions and Discord chat at https://discord.gg/NyseBeK or if it seems to be a bug then post it as a new issue for developers to track at https://github.com/Koenkk/zigbee2mqtt/issues
2 Likes
Hi guys, Zigbee2mqtt router firmware still suffocates the power of this dongle and some custom ones didn’t work for me that well.
Have somebody tried router firmware by PTVO? Any recommended settings? (tbh I’m not sure about it)
Thanks for any tips!
Not me but FYI read the discussion here → https://github.com/Koenkk/Z-Stack-firmware/issues/341
ptvoinfo stated that he implemented RF signal level control feature in his PTVO Premium version:
https://ptvo.info/zigbee-configurable-firmware-features/rf-signal-level-control/
That feature should allow user to change RF power transmit amplification config, though you will first need to add custom converter for Zigbee2MQTT or respective matching quirk for ZHA Device Handlers:
https://ptvo.info/zigbee-configurable-firmware-features/expert/
https://github.com/Koenkk/zigbee-herdsman-converters
https://github.com/zigpy/zha-device-handlers/
https://www.home-assistant.io/integrations/zha#zha-exception-and-deviation-handling
Thanks!
That’s why I’ve asked actually. I saw that mentioned but to be honest I’m not sure about the right settings for ITead’s dongle via the FW configurator, so I was interested if somebody actually tried it and if there is any confirmed settings.
EDIT: Ok I see the recommended fw is 20211217, but shouldn’t this work out of the box without fw upgrade anyway? Maybe I got a lemon.
Hi all,
I’m in need of some help… just received my Sonoff dongle last week and got it setup on Zigbee2MQTT just fine. Logs report connected to MQTT and all. Terminal shows it on ttyUSB0. Noticed the fw for coordinator is 20210708 though and i haven’t done an upgrade yet because I wanted to test if it works as-is first. Sure enough, it doesn’t pick up any zigbee devices I throw into pairing mode, from two different Sengled LED bulbs to Visonic MCT-340 E door/window sensors, to Iris motion sensors.
Think I have a dud Sonoff stick? Or do I absolutely have to upgrade fw first to make this work? It’s plugged directly into RPi3b’s USB port without USB extension. Have brought the devices right next to the antenna to attempt pairing as well.
Also tried ZHA and also nada.
Zigbee2MQTT log:
[quote]s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/socat.sh
[01:48:33] INFO: Socat not enabled, marking service as down
cont-init: info: /etc/cont-init.d/socat.sh exited 0
cont-init: info: running /etc/cont-init.d/zigbee2mqtt.sh
cont-init: info: /etc/cont-init.d/zigbee2mqtt.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun socat (no readiness notification)
services-up: info: copying legacy longrun zigbee2mqtt (no readiness notification)
[01:48:38] INFO: Handing over control to Zigbee2mqtt Core …
[email protected] start
node index.js
Zigbee2MQTT:info 2022-06-26 01:48:52: Logging to console and directory: ‘/config/zigbee2mqtt/log/2022-06-26.01-48-52’ filename: log.txt
Zigbee2MQTT:info 2022-06-26 01:48:52: Starting Zigbee2MQTT version 1.25.2 (commit #unknown)
Zigbee2MQTT:info 2022-06-26 01:48:52: Starting zigbee-herdsman (0.14.34)
Zigbee2MQTT:info 2022-06-26 01:48:56: zigbee-herdsman started (resumed)
Zigbee2MQTT:info 2022-06-26 01:48:56: Coordinator firmware version: ‘{“meta”:{“maintrel”:1,“majorrel”:2,“minorrel”:7,“product”:1,“revision”:20210708,“transportrev”:2},“type”:“zStack3x0”}’
Zigbee2MQTT:info 2022-06-26 01:48:56: Currently 0 devices are joined:
Zigbee2MQTT:warn 2022-06-26 01:48:56:permit_joinset totruein configuration.yaml.
Zigbee2MQTT:warn 2022-06-26 01:48:56: Allowing new devices to join.
Zigbee2MQTT:warn 2022-06-26 01:48:56: Setpermit_jointofalseonce you joined all devices.
Zigbee2MQTT:info 2022-06-26 01:48:56: Zigbee: allowing new devices to join.
Zigbee2MQTT:info 2022-06-26 01:48:56: Connecting to MQTT server at mqtt://192.168.1.34:1883
Zigbee2MQTT:info 2022-06-26 01:48:57: Connected to MQTT server
Zigbee2MQTT:info 2022-06-26 01:48:57: MQTT publish: topic ‘zigbee2mqtt/bridge/state’, payload ‘{“state”:“online”}’
Zigbee2MQTT:info 2022-06-26 01:48:57: Started frontend on port 0.0.0.0:8099
Zigbee2MQTT:info 2022-06-26 01:48:57: MQTT publish: topic ‘zigbee2mqtt/bridge/state’, payload ‘{“state”:“online”}’
Zigbee2MQTT:info 2022-06-26 01:49:59: Zigbee: disabling joining new devices.
Zigbee2MQTT:info 2022-06-26 01:50:00: MQTT publish: topic ‘zigbee2mqtt/bridge/response/permit_join’, payload ‘{“data”:{“time”:254,“value”:false},“status”:“ok”,“transaction”:“o1lxk-1”}’
Zigbee2MQTT:info 2022-06-26 01:50:00: Zigbee: allowing new devices to join.
Zigbee2MQTT:info 2022-06-26 01:50:00: MQTT publish: topic ‘zigbee2mqtt/bridge/response/permit_join’, payload ‘{“data”:{“time”:254,“value”:true},“status”:“ok”,“transaction”:“o1lxk-2”}’
Zigbee2MQTT:info 2022-06-26 01:54:13: Succesfully changed options
Zigbee2MQTT:info 2022-06-26 01:54:13: MQTT publish: topic ‘zigbee2mqtt/bridge/response/options’, payload ‘{“data”:{“restart_required”:false},“status”:“ok”,“transaction”:“o1lxk-3”}’
Zigbee2MQTT:info 2022-06-26 01:54:19: Zigbee: disabling joining new devices.
Zigbee2MQTT:info 2022-06-26 01:54:19: Succesfully changed options
Zigbee2MQTT:info 2022-06-26 01:54:19: MQTT publish: topic ‘zigbee2mqtt/bridge/response/options’, payload ‘{“data”:{“restart_required”:false},“status”:“ok”,“transaction”:“o1lxk-4”}’
Zigbee2MQTT:info 2022-06-26 01:54:23: Zigbee: allowing new devices to join.
Zigbee2MQTT:info 2022-06-26 01:54:23: MQTT publish: topic ‘zigbee2mqtt/bridge/response/permit_join’, payload ‘{“data”:{“time”:254,“value”:true},“status”:“ok”,“transaction”:“o1lxk-5”}’[/quote]
Try with an extension lead and/or with a different Zigbee channel.
Thanks. Changed to CH 20, but still no joy. Waiting on an extension lead to arrive, but I didn’t think not having one would outright make the sonoff not even see a device sitting right next to antenna, but rather affected its total range.
FYI, I collected all my general tips here are highly recommend following them all before troubleshooting:
https://github.com/zigpy/zigpy/wiki/General-tips-on-improving-Zigbee-network-range
@neoshi My guess is that the root cause of your problem is probably not using a USB extension cable because the most commonly seen problem is with EMF/EMI/RFI interference (and not just range). Regardless, I was you then I would regardless go ahead and also upgrade the firmware to 20220219.
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
Thanks. I did try many of those actions, as I’ve seen that list or a similar one somewhere.
However, I think I found the problem… I saw an Amazon user report that they had a defective antenna, so just as a test, I started to wiggle my antenna base (or rather push it and keep it pushed in any direction at the base of the antenna) and sure enough, devices were seen. However, when I stopped pushing the antenna base, the pairings failed to complete. Likewise, if I did this after the devices paired, pushing the antenna would produce real time contact state change reports, but not pushing on the base would missed reports. I think I have a bad antenna connection here.
I think I’m just going to request a replacement at this time from Sonoff. I didn’t want to commit to a FW upgrade until I had some idea of what was the culprit and also just in case a FW upgrade failed, I didn’t want to be stuck with a bricked stick without recourse from Sonoff.
FYI, ITead has now also released a new “ZBDongle-E” Zigbee dongle based on Silabs EFR32MG21 with similar specifications that will be sold side-by-side as an alternative option to the CC2652 dongle:
Comparing “ZBDongle-P” vs. “ZBDongle-E” vs. barebone EFR32MG21 dongle
verseu 
versus 
| Feature/Model | ZBDongle-P | ZBDongle-E | 9888010100045 |
|---|---|---|---|
| SoC/MCU chip | Texas Instruments CC2652P | Silicon Labs EFR32MG21 | Silicon Labs EFR32MG21 |
| Zigbee Stack (Serial Interface Protocol API/CLI) | Z-Stack v3 (ZNP 3) | EmberZNet (EZSP v8) | EmberZNet (EZSP v8) |
| Optional Zigbee Router firmware | Yes | Yes | Yes |
| USB to UART/Serial Converter Chip | CP2102 or CP2102N | CH9102F | CH340 |
| USB EEPROM Product Description ID | SONOFF Zigbee 3.0 USB Dongle Plus | SONOFF Zigbee 3.0 USB Dongle Plus V2 | None (no USB chip EEPROM) |
| Home Assistant USB Auto Disovery | Yes | Not yet | Not possible |
| Flow Control | None by default (Hardware flow control optional with alternative firmware and flipped dip-switch） | Software flow control | Software flow control |
| RF Transmit Output Power | 9dBm (firmware hardcoded), Max: 20dBm | 20dBm (default) | 20dBm (default) |
| Antenna | External (rotatable and tiltable) | External (rotatable and tiltable) | Onboard circuit board antenna |
| Enclosure/case | Aluminum all-metal shell casing | Aluminum all-metal shell casing | None |
| Length | 63mm | 52mm | ? |
| Packaging | Retail-box with manual | Retail-box with manual | Anti-static bag only |
| Home Assistant ZHA | Supported | Supported | Supported |
| Zigbee2MQTT | Supported | In development by zigbee-herdsman dev | In development by zigbee-herdsman dev |
| IoBroker | Supported | In development by zigbee-herdsman dev | In development by zigbee-herdsman dev |
| OpenHAB ZigBee Binding | Not yet | Supported | Supported |
| Domoticz Zigbee Plugin | Supported | Supported | Supported |
| Jeedom Zigbee Plugin | Supported | Supported | Supported |
2 Likes
Is it supported by Z2M yet?
Yes if asking about new “ZBDongle-E” Zigbee dongle but please discuss it in the other thread instead:
In case anyone is interested, I found an easy way to update the firmware using docker compose (no need to unplug or touch the dongle in any way)
Just make sure you stop Home Assistant or anything else using the dongle.
version: '3'
services:
ti-cc-tool:
image: "ckware/ti-cc-tool"
environment:
FIRMWARE_URL: "https://github.com/Koenkk/Z-Stack-firmware/raw/master/coordinator/Z-Stack_3.x.0/bin/CC1352P2_CC2652P_launchpad_coordinator_20220219.zip"
devices:
- /dev/ttyUSB0:/dev/ttyUSB0
command: [ "-ewv", "-p", "/dev/ttyUSB0", "--bootloader-sonoff-usb" ]
Shouldn’t take more than a minute.
Then restart Home Assistant and should be everything in place.
Hope this helps.
5 Likes
FYI, ITead have now raised the price of this Texas Instruments CC2652P-based “ZBDongle-P ” adapter to $19.99, matching the price of their new Silicon Labs EFR32MG21-based “ZBDongle-E” adapter:
https://itead.cc/product/sonoff-zigbee-3-0-usb-dongle-plus/
ITead’s have tried to make it clear that they plan on continuing to sell their CC2652P-based variant of “Sonoff Zigbee 3.0 USB Dongle Plus” (non-“V2” that has recently been rebranded to “ZBDongle-P”) side-by-side as an alternative to the new “ZBDongle-E” so that potential buyers have the option to buy eother a Texas Instruments and Silicon Labs based USB adapter because different home automation applications currently do not offer the same support for all SoC manufacturers.
Again, the “ZBDongle-P” variant is not supported by for example OpenHAB, while the “ZBDongle-E” " variant is not yet well supported by Zigbee2MQTT (though their developers are working on improving it).
Found a new, at least for me, version of the FW. I believed 20220219 was latest version, however found this in another thread. I believe it is a new version of the FW called 20220726 for the ZBDongle-P. Anybody tried it with HA and Z2M?
Not tested it myself yet but yes Koenkk’s Z-Stack-firmware repository tree has “master” and “develop” branches where “master” has well-tested FW and “develop” branch has not-well-tested FW images:
https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0
20220726 Changelog says:
- Increase request retry attempts
- Increase routing table sizes
- SimpleLink SDK 6.10.00.29 (changelog) and SimpleLink SDK 6.20.00.29 (changelog)
So for fixed issues also need to look into these upstream changelogs (under “TI Z-Stack”) as well:
| ID | Summary |
|---|---|
| ZIGBEE-1779 | “TxPower” API should set maximum power to 2dBM in some channels in RSIP |
| ZIGBEE-1741 | Interpan messages crash stack because of network task idle state |
FYI, Zigbee2MQTT testers discuss + report issues develop and master firmware images together here:
https://github.com/Koenkk/zigbee2mqtt/discussions → https://github.com/Koenkk/zigbee2mqtt/discussions?discussions_q=20220726
https://github.com/Koenkk/zigbee2mqtt/issues → https://github.com/Koenkk/zigbee2mqtt/issues?q=is%3Aissue+20220726
2 Likes