ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P +20dBm radio MCU now sold for $19.99

If the default Zigbee channel is conflicting with your Wi-Fi channel then you should really consider changing the channels on your Wi-Fi router and/or access-points instead as per the suggestions here:

https://github.com/home-assistant/home-assistant.io/pull/18864

https://github.com/home-assistant/home-assistant.io/pull/18864/commits/b21c49589d898d60a1a235afa7b9c148d013cfee

It is generally recommended not to change Zigbee channel on your Zigbee coordinator from default as not all Zigbee devices will initiate pairing on all channels. There are some mentions of this on a few specific devices listed in blakadder’s Zigbee Device Compatibility Repository so maybe add a comment:

https://zigbee.blakadder.com/

https://zigbee.blakadder.com/Sonoff_ZBDongle-P.html

Example:

https://zigbee.blakadder.com/Legrand_064873.html

Some Legrand devices work only on Zigbee channel 11. With certain devices you need the Legrand Hub to update the firmware to have all features available.

Regardless, probably also want to report any such issues to this Z-Stack firmware development repo:

https://github.com/Koenkk/Z-Stack-firmware

https://github.com/Koenkk/Z-Stack-firmware/issues

Hello!
I also messed up the SONOFF USB ZIGBEE after router firmware the flash.
Unfortunately, flash again doesn’t work at all.

D:\Utils\cc2538-bsl-feature-ITead_Sonoff_Zigbee-delay>cc2538-bsl.py -p COM6 -evw --bootloader-sonoff-usb CC1352P2_CC2652P_other_coordinator_20210708.hex
sonoff
Opening port COM6, baud 500000
Reading data from CC1352P2_CC2652P_other_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target…
ERROR: Timeout waiting for ACK/NACK after ‘Synch (0x55 0x55)’

Is there another solution to the problem, or has USB become completely brick?
Thanks!

Yeah should use “CC1352P2_CC2652P_launchpad_*.zip” and not “CC1352P2_CC2652P_other_*.zip

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

Did you try removing enclosure and manually hold physical boot-button while plugging into USB-port?

https://sonoff.tech/sonoff-zigbee-3-0-usb-dongle-plus-firmware-flashing-2/

If you messed up the bootloader firmware then only way to unbrick the hardware is to flash with cJTAG:

https://electrolama.com/radio-docs/advanced/flash-jtag/

The cheapest option for an officially supported debugger is Texas Instruments CC-DEVPACK-DEBUG:

https://www.ti.com/tool/CC-DEVPACK-DEBUG

The official TMDSEMU110-U XDS110 JTAG Debug Probe is better option though as offer more options:

https://www.ti.com/tool/TMDSEMU110-U

Texas Instruments XDS110 JTAG debug probe is a bit expensive but cheap clones of it should work, ex:

https://aliexpress.com/item/4000751867419.html

Also, note that original Segger J-Link V9 (legacy) debug probes does not support cJTAG, so need at least a Segger J-Link V10:

https://wiki.segger.com/J-Link_Model_Overview

Where exactly can the output power setting be increased to 20dBm after flashing ‘CC1352P2_CC2652P_launchpad_coordinator_20211217.hex’ which has the output set to 9dBm by default?

1 Like

Yes, I removed the cover and pressed the boot button. Unfortunately, it still doesn’t reach the bootloader.
Do I have an adapter like this
https://www.aliexpress.com/item/32833502027.html?spm=a2g0o.9042311.0.0.27424c4dxH7r72
that could be used to flash?

Probably not. You need to verify that the debugger you buy supports 2-pin cJTAG (“IEEE 1149.7” a.k.a C-JTAG or c/JTAG) compatibility mode and not just common JTAG SWD as TI CC2652 debug do not use SWD and SWDCLK, etc. but instead only TMS and TCK cJTAG is not SWD/SWDCLK as cJTAG (IEEE 1149.7) is an extension to the JTAG standard (IEEE 1149.1). See details at → Flash Firmware using c/JTAG - Electrolama

Looking at pictures on ITead’s product page for the Sonoff CC2552P board you see that no SWD and SWDCLK pads are exposed, but it does expose TMS and TCK pads so those is what you need to use.

So will probably need cJTAG debug probe with TMS and TCK, and thus you will need to user a cJTAG compatible debugger probe adapter like Texas Instruments XDS110 or a clone of TI’s XDS110.

image

The cheapest option for an officially supported debugger is Texas Instruments CC-DEVPACK-DEBUG:

https://www.ti.com/tool/CC-DEVPACK-DEBUG

The official TMDSEMU110-U XDS110 JTAG Debug Probe is better option though as offer more options:

https://www.ti.com/tool/TMDSEMU110-U

Texas Instruments XDS110 JTAG debug probe is a bit expensive but cheap clones of it should work, ex:

https://aliexpress.com/item/4000751867419.html

Also, note that original Segger J-Link V9 (legacy) debug probes does not support cJTAG, so need at least a Segger J-Link V10:

https://wiki.segger.com/J-Link_Model_Overview

Finally Texas Instrument’s registration is working again :face_with_hand_over_mouth:

FLASH-PROGRAMMER-2

3 Likes

Hello !
I would like to know too :slight_smile:

There:

https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html#transmitter-power

1 Like

Posted details above in a previous post → https://community.home-assistant.io/t/sonoff-zigbee-3-0-usb-dongle-plus-by-itead-is-based-on-texas-instruments-cc2652p-can-be-pre-ordered-for-10-99/340705/189

Copy:

https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html#transmitter-power

Zigbee2MQTT adapter settings examples:

transmit_power: 5
transmit_power: 9
transmit_power: 14
transmit_power: 20

ZHA integration advanced configuration examples:

https://www.home-assistant.io/integrations/zha/#configuration—yaml

Also, looking at zigpy-znp configuration example sounds as if 19 dBm is highest can set for CC2652P?

https://github.com/zigpy/zigpy-znp/blob/dev/README.md#configuration

zha:
  zigpy_config:
    znp_config:
      tx_power: 5

5 versus 9 in tx_power configuration

zha:
  zigpy_config:
    znp_config:
      tx_power: 9

9 versus 14 in tx_power configuration

zha:
  zigpy_config:
    znp_config:
      tx_power: 14

14 versus 19 in tx_power configuration

zha:
  zigpy_config:
    znp_config:
      tx_power: 19

etc.

PS: Recommendation after testing is just to leave it at the new +9 dBm default and use that instead of using a higher setting thinking to get better result, as it is just the Zigbee coordinator “shouting louder” and not “listening better” so if Zigbee devices from very far away try to connect directly to the Zigbee coordinator instead of going through a Zigbee router then their signals back might not always be strong enough.

1 Like

Hey, everybody,
I have a few questions. I have HA running on HAOS (non-virtual environment). I currently have ZHA installed with about 75 devices. Every time HA restarts then only about 60 devices boot back up. Most of the time the end battery sensors go down. So I updated the coordinator firmware (Sonoff ZigBee 3.0 USB) to the latest version 20211712 according to the instructions

Unfortunately, after putting the coordinator back in, no devices loaded and I had to re-pair all 75 devices. Unfortunately, even so, this did not help solve my problem that after restarting HA some devices do not load (and I have to manually add them again).

  • Please, is it necessary to do some IEEE backup or something like that before updating the firmware (using FLASH-PROGRAMMER)?

Thank you very much for your help

Hello everyone,

Newbie on HA with Zigbee2mqtt , aqara devices and this sonoff dongle plus. I started pairing with two aqara devices : a temp/humidity sensor and a wireles mini button.
The battery indicator of the temp/humidity sensor shows a “?” symbol instead of the battery level/status.

I have read other people having battery level indicator issues with aqara devices and this sonoff dongle plus. Has anyone else had this problem and solved it ?

Thank you

Sometimes takes several hours before xiaomi zigbee devices will report a battery value, it should hopefully show a value after a few more hours.

Unfortunately even then the battery value is only an approximation. Often with some of the older xiaomi / aqara devices the battery value will seem OK but its only when the device drops off the network that I realise the battery is dead. Pretty much anything below 50% means it could die at any time. Most of the xiaomi sensors have brilliant battery life though (years, in some cases).

I’ve bought one of these sticks to replace a flakey cc2531 (would have to be unplugged and plugged back in every couple days to work)

I followed the instructions on the Z2M site for updating the ieee address of the sonof to match the old device and it looked like it had worked

Starting Zigbee2MQTT fails with the below error message.

2022-01-09T09:28:01.202Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
Zigbee2MQTT:error 2022-01-09 09:28:59: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2022-01-09 09:28:59: Failed to start zigbee
Zigbee2MQTT:error 2022-01-09 09:28:59: Exiting...
Zigbee2MQTT:error 2022-01-09 09:28:59: Error: Coordinator failed to start, probably the panID is already in use, try a different panID or channel
    at /app/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/startZnp.js:172:23
    at Generator.throw (<anonymous>)
    at rejected (/app/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/startZnp.js:25:65)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: `node index.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2022-01-09T09_28_59_820Z-debug.log

If i change the panID zigbee2MQTT loads but then will have to repair all my devices.

Have i missed something? Would rather avoid repairing if i can.

1 Like

You are still using the deprecated daniel welch add-on. Upgrade your add-on to the official one

Reinsert your cc2531, start the add-on with version 1.22.2 at least once, then swap to the CC2652.

3 Likes

Backup of your old dongle and restore to new is required for ZHA when migrating from another dongle.

Firmware upgrades usually erase network settings so best to perform a backup before upgrading.

Backup is not strictly necessarily required when upgrading firmware on the same dongle however it is still always recommended to do backups. If you for example mess up and flash the wrong firmware image (as some people do) then you will need that backup to restore without having to pair all devices again. Upgrading firmware can sometimes also reset some configurations stored on the dongle itself.

https://community.home-assistant.io/t/zha-integration-to-do-nightly-backup-of-both-zigbee-coordinator-adapter-dongle-stick-and-zigbee-database/357558

https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#backup-and-restore

1 Like

Tip! le_top added possibility to backup your Zigbee network to a JSON file within Home Assistant ZHA via “zha_custom” custom component by mdeweerd (originally fork of zha_custom by Adminiuga):

https://community.home-assistant.io/t/zha-custom-service-to-send-custom-zha-commands-extra-functions/373346

I must have missed the change of repo for the add-on! Thanks seems to be working now.

Hopefully the new dongle wont still keep losing connection every couple days!

1 Like

FYI, not confirmed but someone now claims Auto-BSL is also working in the ZigStar GW Multi tool too:

1 Like

I bought one of these dongles as my first foray into Zigbee having only started with HA about 9 months ago and only used WiFi devices before now. My HA runs as a VirtualBox VM on a Windows host and I’ve been able to pass through USB to connect the dongle to the HA VM and ZHA detects it OK from within HA. All good so far, this it where it all unravels though.

I have 3 Sonoff Zigbee devices, two motion sensors and a door sensor, all battery powered. When I put them in pairing mode ZHA seems extremely hit and miss whether it detects the device or not despite only being 1 plasterboard wall and about 3m from the dongle. Having added all 3 again last night after reinstalling the integration from scratch just in case, by this morning 2 of the devices reported as “unavailable”. I then moved the sensors so they sat within 20cm of the dongle and although one sensor then reconnected the other stays “unavailable”. What’s more the door sensor that is back online continually reports 2% battery despite the battery having 3.2v tested and having swapped it for another new battery just in case.

My host PC is fairly close to my main Asus WiFi router so could be a source of interference but I’ve connected it to a 2m USB extension lead to get it as far away as practical, surely connectivity shouldn’t be this flaky should it? Is there a chance I’ve got a faulty aerial on the dongle perhaps?

I have a similar setup except I’m using ESXi that also sits next to my ASUS router. My first suggestion is to upgrade the firmware to the latest. I’m running the latest dev version. The firmware that is pre-flashed may not be that great. There is a YouTube vid a few post up that shows the process if you are not familiar. After that try increasing the tx. I was getting a big delay with the default tx. Changing mine to tx 10 helped a great deal. Instructions for that is posted before the YouTube vid about the firmware update. Another thing to check is the make sure your wifi and zigbee network are not using the same channel. I use Zigbee2mqtt and that defaults to channel 11. I assume zha does as well. Hope that helps.

2 Likes