hi, I’m also trying to flash with router firmware, but without success, so I try with coordinator firmware and it happened immediately. I use Windows with texas smartflasher. my conclusions are that the router firmware, the latest release in this case block the flash…
Like stated already anytime I got an error when using that flash program it was because the device was not in bootloader mode. That button is a bit of a pain to keep pressed when plugging in.
I followed the steps for python using the video below when I did mine last week. Much easier to flash with python.
Agreed.
But a tip: if you have a usb extension cable, you would find it very useful in this scenario…
Also, looks like your video link is broken at the moment…?
Hopefully the link is fixed now.
Another tip: you could also use something non-conductive to help press the button down.
I’ve tried to install the dongle on a synology (dsm6.2) with docker and a proxmoxserver. In both ways the dongle is not recognized . (on the syno it doesn’t make a TTYUSB0).
How can I see if the dongle is correctly flashed an does work correct ?
You can start by connecting to another computer (that is not using any virtualization or Docker) and update the firmware as that way will know at least there should be nothing wrong with your adapter.
Firmware → https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
Adapters based on CC1352 or CC2652 chips can be flashed after manually putting it in bootloader mode (see adapter manual) if not using CC2538-BSL with the sonoff parameters to make it go bootloader mode automatically. After have done that one of the following tools can be used to flash it.
- ZigStar GW Multi tool (multi platform GUI tool)
- CC2538-BSL (multi platform Python based command line tool) (instructions)
- Texas Instruments “FLASH PROGRAMMER 2” (Windows only)
Normally I could say that you always need to start by checking that have Silicon Labs CP210x USB to UART Bridge Virtual COM Port (VCP) drivers installed inside the operating system that runs Home Assistant which it needs to see the USB adapter exposed as a serial port but with you running both Docker container(s) and Proxmox virtualization do not know at what layer you would have what in your unique setup, and I feed to would be way to involved having a troubleshooting dialogue about that in this thread.
Anyway, it is probably either a problem with Docker Compose (i.e. Docker device forwarding to the docker image) and/or USB-passthrough (i.e. passing the USB through to Docker and/or the virtual machine).
For properly configuring USB-passthrough on your VM (also know as USB pass-though) you need to read the manual of your virualization platform (e.i. The virtual machine hypervisor)
For configuring the Docker Compose see example → https://www.home-assistant.io/integrations/zha#cant-connect-to-usb-device-and-using-docker
You see, for your type of unique setup the Home Assistant OS will not see the dongle hardware (which is a serial port device via a USB-to-serial bridge/converter chip) until both Docker device forwarding to the docker image and USB passthrough for your VM (Virtual Machine) is working properly, so bet that one of those or both of them is your issue.
For your sake and ours, it would be much better if you first ask questions in other external community forums that are dedicated to Proxmox, Synology, and/or Docker as the problem will surely be with Proxmox, Synology, or Docker and not be a problem with this USB dongle or Home Assistant.
Note that USB pass-through will not work if your virtualization hypervisor operating system is trying to use the device which is why you might need to uninstall device drivers there. Regardless you need to troubleshoot this from the side of your Docker container / Docker Compose and/or virtualization hypervisor / virtual machine manager.
You could post more info about your Docker setup and virtualization hypervisor + underlying operating system configuration if can not sort it out, but please understand that this is really off-topic for this 500+ posts thread that is specifically only about this Zigbee Coordinator USB dongle and not generic setup/configuration that is only indirectly related so much better is to go to the forum for your virtualization hypervisor and ask them about how to properly configure Docker Compose and USB-passthrough for the VM.
Ok thanks for your reply. I will search for usb pass-through…
thanks for helping me. It was the usb pass-through. Now the dongle is active. Searching for weaks and it was so easy (https://dannyda.com/2020/08/26/how-to-passthrough-usb-devices-in-proxmox-ve-pve-6-2-easy-and-quick/)
Just an idea - Would you like to open another topic and share what you have done to get things going, so that future users with similar setup like yours would know what or how exactly?
I just H/W installed the dongle-P and added it as a USB device in my Proxmox VM running Home Assistant. So far, so good, it is visible there. So the plan was to install zigbee2mqtt and looked up some tutorial in youtube. As a first step I looked up the dongle via system->hardware and copied the path (/dev/serial/by-id/usb-Silicon_Labs_Sonoff_Zigbee_3.0_USB_Dongle_Plus_0001-if00-port0).
Then I installed Mosquito broker via Add Ons, this works and still works. Hereafter the problems started; the MQTT card was not visible under integrations, also not after refreshing the page. The ZHA card was visible and I clicked it (stupid enough). Hereafter nothing happened anymore; it seems the HA system restarted, the dongle is not visible anymore under hardware, only in the VM it remains visible. All gone leaving me desperate. I rebooted several times, no result. Anything I could do rather than recover a backup (which I would prefer not to do since it is 4 months old).
@eddietheeagle better if you start a new thread since your issue is not specific to this adapter but rather using MQTT and Zigbee2MQTT with Home Assistant. This thread is already 500+ posts long and is trying to focus the ZBDongle-P itself, such as example upgrading firmware on it and such.
Got it; will do, thx.
FYI; those bold can if they want to help beta-test latest cutting-edge Koenkk’s Z-Stack_3.x.0 coordinator firmware image(s) for CC2652 Zigbee Coordinator adapters available in his development branch here:
https://github.com/Koenkk/Z-Stack-firmware/issues/439
That pre-release firmware still development that Koenkk is currently working on will as it looks right now in turn be based on TI’s SimpleLink SDK 6.41.00.17 https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/6.41.00.17/exports/changelog.html
Make sure flash correct firmware! Sonoff ZBDongle-P → “CC1352P2_CC2652P_launchpad_*.zip”
https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin
Hello @Hedda,
Could you share me the schematic of this Sonoff Zigbee 3.0 Dongle Plus (P)?
I’d like to understand the way they did to make this dongle could be flashed automatically without pushing any boot button.
Thank you very much.
@chinhhut Auto-BSL (automatic BSL mode) activation/usage is explained on Electrolama’s website and cc2538-bsl readme, but note ITead/Sonoff do not implement it in standard Texas Instruments way:
https://electrolama.com/radio-docs/bsl/
https://github.com/JelmerT/cc2538-bsl/blob/master/README.md#cc26xx-and-cc13xx
Please also see the code of read cc2538-bsl, the related pull request and previous discussions there:
https://github.com/JelmerT/cc2538-bsl/pull/114
https://github.com/JelmerT/cc2538-bsl/issues/113
https://github.com/JelmerT/cc2538-bsl/issues/63
You can also see open-source hardware and firmware as Auto-BSL (Pin 2) is a feature most Texas Instruments CC dongles support:
You can also see open-source hardware and firmware as this is a feature that most Texas Instruments CC dongles support:
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0
https://www.zigbee2mqtt.io/guide/adapters/
Example of some open source hardware (which ITead’s Sonoff ZBDongle-E is not as far as I know):
https://github.com/electrolama/zig-a-zig-ah
https://github.com/mercenaruss/zigstar_gateways
If want more info you might be best of asking the same question in https://github.com/Koenkk/Z-Stack-firmware/discussions and/or Koenkk/zigbee2mqtt · Discussions · GitHub are those are larger community for TI CC hardware and firmware enthusiasts.
But if you specifically want a hardware schematic of Sonoff ZBDongle-P then you have to ask ITead:
PS: Please understand that I am only a hobbyist/and have no official affiliations with ITead/Sonoff.
Thank you for your detail information. I will try to research more according to your suggestion.
FYI, Koenkk’s Z-Stack_3.x.0 coordinator 20230507 firmware images now released in master as stable:
Make sure flash correct firmware! Sonoff ZBDongle-P → “CC1352P2_CC2652P_launchpad_*.zip”
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
Thanks for your ever quick and comprehensive feedback/heads up on the subject Zigbee. Appreciated.
Can the Home Assistant Skyconnect be flashed with the ZBdongle-E firmware to act as a zigbee router device since they use the same chipset?
The “ZBDongle-P” dongle discussed in this thread does not use the same chip as Home Assistant SkyConnect as the “ZBDongle-P” dongle is based on a CC2652P chip from Texas Instruments, so I guess that you meant to post that question in the thread about “ZBDongle-E” dongle which is instead based on an EFR32MG21 chip from Silicon Labs → ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” (model "ZBDongle-E") based on Silicon Labs EFR32MG21 +20dBm radio SoC/MCU
Better might be to instead ask agners that same question here → Home Assistant SkyConnect - official radio USB dongle will be compatible with both Zigbee and OpenThread (including Matter/CHIP over Thread) …or perhaps try open a new feature request issue asking to suggest a dedicated Zigbee Router firmware image for the SkyConnect dongle in this Nabu Casa repository → https://github.com/NabuCasa/silabs-firmware/issues
Regardless I would not try flashing a firmware image meant for a other adapter/board/device myself as you risk bricking it because is not only the chip that matters but the GPIO (general purpose input and output) ports/pads/pins that have been mapped for the firmware software designed for that specific circuit board that is inside each product.
That is, as the chip has multiple GPIO ports/pads/pins that could be used for many different things it is up to the developer of each circuit board to choose what port/pad/pin will be physically traced to which function and then define that by mapping the same in the firmware for that device.
There is no standard for what function GPIO pins should be mapped to, (but most do use same pads).
If you successfully flash a firmware image that did not use the same mappings then you have technically “bricked” it, in this case meaning that you can no longer flash it again via USB using the ROM Bootloader (BSL), so you must then “unbrick” it by buying/getting a cJTAG ( c/JTAG) adapter like J-Link to flash it manually via the developer pins, see → https://electrolama.com/radio-docs/advanced/flash-jtag/