Uh I didn’t know there were new sensors coming. That is good info.
While the old ones are rock solid, I wonder what the new iterations bring to the table besides the battery life (which is a big plus!)
I guess not so much new but the version is different from MCCGQ12LM to MCCGQ14LM for the door sensors for example. And they’re different enough that it warrants some change firmware wise.
The reason is ITead missed they need to write “description” to EEPROM on USB-to-UART chip, see:
Great if more people report this issue to ITead as they need to make and release a script that writes a “description” to the CP2102N EEPROM so will no longer discovered using Silabs default description.
Hopefully, they will at least fix this in the next batch (or the next batch after that) so discovery will work.
You do not need to repair any devices if you backup your CC253x to an image file and restore that image file to a new CC2652 based adapter, (with that backup and restore method you can even migrate from Silicon Labs based adapters and vice versa). The migration procedure is shortly described here:
You do however usually have to power-cycle some or all of your devices that do still not connect even after you left it alone for a while, (then easiest for mains-powered Zigbee devices is probably to start by just temporary pull the main circuit-breaker for the house/apartment in order to power-cycle them all).
Specifications on ITead’s website is wrong, so see correct specs for Z-Stack_3.x.0 on CC2652P here:
https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/README.md
CC2652 can have 50 direct children = 50 direct attached devices, and each of those 50 directly attached devices can route another 50 devices, but in the end, 200 is the maximum of Zigbee 3.0 devices.
So in theory, it should be able to control 200 new Zigbee 3.0 devices + 1000 older Zigbee Home Automation 1.2 devices at the same as Zigbee Home Automation 1.2 devices have almost no overhead.
The 200 limit for Zigbee 3.0 devices is because security for Zigbee 3.0 devices have a lot of overhead.
Poor advertisement as yes the CC2652P hardware does support 20 dBm transmit power, however the current firmware is configured to use 5 dBm transmit power (same at the hardware limit for CC2652R).
It now sounds as ITead will work with the community to make a firmware for it that does 9 dBM because that will result in a dongle that achieves less than 10 dBm in ETSI spectral density test and that is a requirement for commercial certification.
https://github.com/Koenkk/zigbee2mqtt/discussions/9744
Meaning even if the hardware can do 20 dBm to transmit power, ITead can not legally sell and ship it with firmware a higher transmit power configuration if they want it to get commercially certified.
There is however nothing that is stopping you from building and compiling your own firmware configured to use 20 dBm to transmit power and then flash that, though it would be illegal to use in most countries.
2 Likes
Thanks for the info. I ended up switching to the Edge release of Zigbee2MQTT and was able to get the develop firmware of Z-Stack 3.x.0 working. Still doesn’t make sense to me but I bet if I switch back to ZHA, it will probably also work. Might have just needed a good reboot/replug dongle/power on/off devices. But thanks!
By the way, also vote + comment in this request for backup features in ZHA’s UI and nightly backups:
Having such automatic backup features in ZHA’s GUI would also enable users to do migrations easily.
1 Like
I had my Dongle Plus working well for a month. Then some time during the night it quit working, and HA would fail to set up ZHA on reboot. after many different attempts, I gave up, uninstalled ZHA and tried to reinstall it with the Dongle Plus. HA saw it on the USB, but could not set up. I think the dongle is dead.
Did you make a backup? If so then could restore to a new/spare hardware hardware as backup plan:
With the cost of Sonoff Zigbee 3.0 USB Dongle Plus being so relativly low priced and it as a Zigbee coordinator being so relativly essential in a Zigbee network it is a good idea to have spare hardware.
FYI, JelmerT made a “sonoff” patch for cc2538-bsl flashing tool that I confirmed working on Windows:
https://github.com/JelmerT/cc2538-bsl/pull/114
Hopefully, that will get merged as then users only need to use --bootloader-sonoff-usb parameter.
If you test it under other operatingsystem or other condications then report any issues to the PR there.
You can get it to test yourself from here:
https://github.com/JelmerT/cc2538-bsl/tree/feature/ITead_Sonoff_Zigbee-delay
Example:
cc2538-bsl.py -p COM5 -evw --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Yeah, I had it backed up when I transferred everything over from my HUSBZB-1. I kept that as a backup coordinator just for such emergencies. However, lasting only a month is discouraging. Maybe I just happened to get a rare bad one.
1 Like
were you using a usb hub? are you booting from a usb hdd/ssd?
I am booting from USB SSD. I tried two different hubs, but they caused more problems, so am not currently using one.
Not end of the week I know, but I would just ask here:
Does this batch comes with any different firmware or config, maybe, than the last batch?
IN STOCK NOW
AFAIK, the same
It is easy to flash other firmware. And new firmware should be available today, together with the Zigbee2mqtt update.
What power adapter are you using? I’m using a 3.5 amp. I myself have had problems with sata drives pulling to much power. It was probably a power fluctuation. If it’s connected through HDMI some monitors and TVs push power through a HDMI and can cause a crazy back feed. If you have the ssd drive and a ZigBee USB connected without external power that could of been to big a voltage swing for it. Kind of like flickering the lights on and off. I have a HDMI unit where somehow it would power my pi4 through it’s HDMI alone. (Not stable it would just keep it from restarting)
Hope they flashed a unique “product description” to CP2102N chip EEPROM for USB discovery in ZHA:
ITead replied before saying they change the default “CP2102 USB to UART Bridge Controller” text in the Product Description String value field to “Sonoff Zigbee 3.0 USB Dongle Plus” in their next batch
ITead has also had contact with Zigbee2MQTT developer about building a +9 dBM firmware for it, see:
_Originally posted by @Koenkk in TI SimpleLink CC13xx and CC26xx SDK 5.30 / 5.30.00.56 released with support for newer CC13xx and CC26xx hardware chips · Koenkk/zigbee2mqtt · Discussion #9744 · GitHub
“I have had contact with Sonoff about this, they are currently checking whether it is possible to set a default transmit power of 9dbm (to pass certifications), waiting for them to reply”
“This is what I got from them: As the certifier recommends us to set the default transmit power as 9.61 dbm, which need to lower than 10. You may take this as a reference to adjust your plan?”
_Originally posted by @Koenkk in “Sonoff Zigbee 3.0 USB Dongle Plus” model "ZBDongle-P" by ITead is based on Texas Instruments CC2652P can now be ordered for $19.90 · Koenkk/zigbee2mqtt · Discussion #8840 · GitHub
“No reply yet, I’ve send them a firmware which sets the default dbm to 9, they are currently testing it in their lab.”
1 Like
Yeah, I think you might be on to something. I put the USB hub back on (though it is itself unstable), and ordered another one to try again. I put both the hub and the RPi in a smart plug that I can toggle when everything goes to hell. Now I have to get my network stable again. Many endpoints just keep dropping off, and I can’t even add new ones.