FYI; Silicon Labs has released Silabs Zigbee EmberZNet SDK 6.7.10 (6.7.10.0 GA) bugfix release including support for older chips:

https://cn.silabs.com/documents/public/release-notes/emberznet-release-notes-6.7.10.0.pdf

zigpy/zigpy#595 (comment)

Note! Should note that there will not ever be any 6.8.x.x or later releases for EM35xx/EM35x as that hardware is now end-of-life.

@grobasoz @MattWestb Any throughs on this? -> zigpy/zigpy#1042

Sorry for abusing you more then i wold like to do !!

I have problem with flashing tuya Zigbee GW with one working EZSP.

I have using your https://github.com/grobasoz/zigbee-firmware/tree/master/MG1B232 and i can flashing it OK from the bootloader.

The problem is that tuya have implanting hardware flow control in the NCP and boot loader and in in the SOC side. One user have doing one socat server that making it possible coveting it to ZHA and its working with one older version of EZSP:

2021-02-12 20:34:43 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer:
2021-02-12 20:34:43 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name:
2021-02-12 20:34:43 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.5.0.0 build 188

I was getting you firmware being flashed but the socat is blocking the committing but one helpful user have cooking one socat with software flow control so it very likely i can coming out of the brick state without flashing the original firmware back (I like having it as original as possible for getting it working for experience user).
The modules hardware from GDB:

(gdb) mon sw
Target voltage: 2980mV
Available Targets:
No. Att Driver
 1      EFR32MG1B 232 F256 Mighty Gecko M3/M4
(gdb) at 1
Attaching to Remote target

(gdb) mon efm_info
DI version 1 (silabs remix?) base 0x0fe08000

EFR32MG1B 232 F256 = Mighty Gecko 256kiB flash, 32kiB ram
Device says flash page size is 2048 bytes, we're using 2048 bytes

Radio si0

(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs
0   y   0x00000000 0x00040000 flash blocksize 0x800 nocache
1   y   0x0fe00000 0x0fe00800 flash blocksize 0x800 nocache
2   y   0x0fe10000 0x0fe12800 flash blocksize 0x800 nocache
3   y   0x20000000 0x20008000 rw nocache

(gdb) dump memory TZ01.bin 0x00000000 0x00040000
(gdb) dump memory TZ01.bin 0x0fe00000 0x0fe00800
(gdb) dump memory TZ03.bin 0x00004000 0x00040000
(gdb) dump memory TZ04.bin 0x0fe10000 0x0fe12800
TZ01 = Flash
TZ02 = User data
TZ03 = APP (Flash - first and main boot loader)
TZ04 = Lockbits

I have not finding any force bootloader pin on the module so i think tuya is only using software reboot to bootloader and reset pin but then you still in the kitchen i like having on bootloader 2 if its possible.

Pinout: RXD PA1, TXD PA0 and boot pin: PB11 (for the boot loader).
115k2 SW. GBL and S37 files is enough.

If you like see some of the story you can taking on look at TYGWZ01 Smart Gateway Rooted and SSH access !! Alternative firmware ?

I have one private repro with the flash dumps but i think its not interesting for you but im inviting you to it if im being wrong. https://github.com/MattWestb/TYGWZ01

One more great thanks with all firmware you have cooked especially the hard cooked EM3581 one that i think you is one of the few in the community that have the knowledge to do.

Best regards and all the best for the best firmware cooker in the community.

Mvh Mattias W

Please consider making use of the "Silicon Labs firmware builder" which is a new open-source firmware build system that Home Assistant founders have now among other things announced as a common script tool set for building firmware images for Silabs based hardware.

https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/#building-firmware-for-silicon-labs-chips

(Note that this is only just one section from https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/ )

In summary, they have open-sourced and released the ""Silicon Labs firmware builder" project which is a collection of automated build scripts to help make it easier to create reproducible firmware builds for Zigbee and Thread based SoCs from Silicon Labs.

Please consider making use of this firmware build system and if possible also contribute any improvements to upstream project:

https://github.com/NabuCasa/silabs-firmware-builder

As I understand it, right now it allows you to build either Zigbee EmberZNet NCP (Zigbee Coordinator on Silicon Labs Network Co-Processor) firmware images, OpenThread RCP (Radio Co-Processor), or RCP Multi-PAN firmware images for OTBR (multi-protocol Zigbee EmberZNet and OpenThead Border Router using Radio Co-Processor) profiled for their own Home Assistant SkyConnect USB stick/dongle and their EFR32MG21-based radio module integrated into the Home Assistant Yellow appliance, however, the idea is that you can build profiles for other Silicon Labs hardware adapters/dongles/sticks/modules as well. It could of course also be extended to not only support different Silicon Labs based hardware adapters/dongles/sticks/modules but also different type of firmware images, (like maybe OpenThead Border Router on NCP).

(Examples of firmware image builds that it can produce can be found here -> https://github.com/NabuCasa/silabs-firmware ).

Note that was just one of their announcements in that blog post; in related news, they also released "SL Web Tools" which enable flashing firmware to Silabs-based adapters directly from a web page as well as a "SiLabs multi-flasher" as a Python script flashing tool:

https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/#silabs-multi-flasher--sl-web-tools

(Again note that this is only just one section from https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/ )

https://github.com/NabuCasa/universal-silabs-flasher

https://github.com/NabuCasa/sl-web-tools

https://www.youtube.com/watch?v=-88K23e8XYw&t=2s&ab_channel=HomeAssistant

The "SL Web Tools" project is available as open source. It allows users to manage the firmware on Zigbee/Thread sticks using SiLabs chips directly from their browser, with no terminals or compilation necessary. This allows any creator to offer easy firmware updates to their users and make experimental updates available to test bug fixes quickly."

To see it in action, SL Web Tools for flashing firmware has been added to the Home Assistant SkyConnect documentation.

https://skyconnect.home-assistant.io

SL Web Tools is powered by another new open-source Python package “silabs-universal-flasher” → GitHub - NabuCasa/universal-silabs-flasher: Flashes Silicon Labs radios running EmberZNet or CPC multi-pan firmware

For reference; the firmware build system for Silicon Labs was made by Home Assistant developer/engineer and Nabu Casa employee Stefan Agner (a.k.a. agners, who also developed the EFR32MG21-based Home Assistant SkyConnect USB stick/dongle as well as the EFR32MG21-based radio module integrated into the Home Assistant Yellow appliance for Rasberry Pi 4 Compute Module). And the "universal-silabs-flasher" firmware tool was made by puddly who is also one of the lead developers of zigpy and the radio libraries for zigpy that is used in Home Assistant's ZHA integration (among other projects).

PS: They made updates to their documentation as relevant to Silicon Labs based adapters with correct firmware for Zigbee or Thread:

• https://www.home-assistant.io/integrations/thread
• https://www.home-assistant.io/integrations/matter
• https://www.home-assistant.io/integrations/zha
• https://skyconnect.home-assistant.io/

Originally posted by @grobasoz in #8 (comment)

There are also a couple bootloader options...
1. The "standalone" bootloader (I call BTL_STD) like EZSP uses and allows XModem uploads.
2. The "application" bootloader (I call BTL_INT) that uses the device application and can support over the air (OTA) updates.

I prefer the latter (BTL_INT) as it means the firmware can be uploaded to flash without interfering with the functioning of the Zigbee device and supports OTA updates from a gateway - it also allows for me to implement a BLE based flashing interface so mobile phones can be used for OTA updates.

@grobasoz have you considered building ESP Zigbee NCP (Espressif ESP NCP host) firmware for ESP32-C6 and/or ESP32-H2 SoCs?

espressif/esp-zigbee-sdk#124

Espressif ESP NCP host firmware builds wanted for testing:

https://github.com/espressif/esp-zigbee-sdk/tree/main/examples/esp_zigbee_ncp

You already built ESP Zigbee RCP firmware but ESP Zigbee NCP is for less complicated projects like ZHA via zigpy to make use of:

https://github.com/grobasoz/zigbee-firmware/tree/master/ESP32-C6/Zigbee_RCP

ESP32-C6 NCP host can be implemented as a single SoC solution while the ESP32-H2 needs another external chip for interface, like for example either USB-to-UART/Serial converter/bridge chip (e.i. CP210x, FT231X, CH9102F or CH340B) to make a simple USB-adapter or a ESP32-C3 for a network-attached adapter (ie. Zigbee remote adapters similar to https://github.com/tube0013/tube_gateways and https://github.com/mercenaruss/zigstar_gateways ).

Looking at recent commits in their esp-zigbee-sdk SDK looks like they have begun working on implementing an NCP host component:

https://github.com/espressif/esp-zigbee-sdk/tree/main/examples/esp_zigbee_ncp

https://github.com/espressif/esp-zigbee-sdk/blob/main/examples/esp_zigbee_ncp/README.md

https://github.com/espressif/esp-zigbee-sdk/tree/main/components/esp-zigbee-ncp

https://github.com/espressif/esp-zigbee-sdk/blob/main/docs/en/application.rst

https://github.com/espressif/esp-zigbee-sdk/blob/main/docs/en/api-reference/esp_zigbee_ncp.rst

PS: FYI, it looks like Espressif themselves have one of their developers working on a zigpy radio library for esp-zigbee-ncp API/CLI:

zigpy/zigpy-cli#42

zigpy/zigpy#1052

Follow-up to EmberZNet Zigbee Router application firmware from #2

@grobasoz Might also be nice idea to offer a Zigbee router firmware as an option, similar to request in tube0013/zb_ebyte_eth#1

It would be very nice to have a few EFR32MG21 based Zigbee routers as Zigbee network mesh extender (a.ka. Zigbee signal repeater)

That would be an excuse for some of us to buy several devices too ;)

@Hedda - It's on my list 😎 Actually just a USB-Zigbee in Router mode! But right now I have to work on Thread based firmware for a customer 😒

@grobasoz FYI, @tube0013 revealed a couple of days ago that he is working on a Zigbee Router based on an a Texas Instruments CC2652P (+20dBa power amplified) module as open source hardware, you can read about that here -> zigpy/zigpy#664

I suggested he make a EmberZNet Zigbee Router variant with that design as well but he answered that he currently has no plans to do so himself at this time.

I don't think I'm going to look at an efr32mg equivalent to this router design though, the module availability and options are not abundant on that side.

@tube0013 FYI, if you are looking to buy modules as surface mounted components to make and sell boards then know that MGM210P (and MGM210L) RF modules by Silicon Labs that contains EFR32MG21 and are also available.

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules

https://www.silabs.com/documents/public/data-sheets/mgm210l-datasheet.pdf

https://www.silabs.com/documents/public/data-sheets/mgm210p-datasheet.pdf

MGM210PA32JIA and MGM210PB32JIA are both is a +20 dBm TX pre-certified module based module with both built-in antenna and RF Pin for optional external antenna.

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules/device.mgm210pa32jia

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules/device.mgm210pb32jia

The differnce between those two is that MGM210PB32JIA also have support for features Silicon Labs' enhanced security option, "Secure Vault" https://www.silabs.com/security

MGM210PA32JIA and MGM210PB32JIA looks to cost about $11 (US) dollars each when not buying in bulk

https://octopart.com/click/track?ai=1872&sig=02b5980&sid=459&ppid=108099587&vpid=615228293&ct=offers

https://octopart.com/click/track?ai=1872&sig=045aafa&sid=2401&ppid=108099587&vpid=618359838&ct=offers

https://octopart.com/click/track?c=1&ai=1872&sig=0881c5f&sid=459&ppid=112348737&vpid=667261090&ct=offers

https://octopart.com/click/track?ai=1872&sig=09e2041&sid=819&ppid=112348737&vpid=692111326&ct=offers

Hi gary hope you have one good time down under and you is on the beach with one tequila in you hands !!
Up in the north is around ZERO °C and snow in the air but nice sunny.

We have hunting problems in ZHA that IKEA controller devices is draining batteries and especially on Sonoff zigbee bridge and have pinpointing the largest problem to one bug in EZSP that is used in the coordinator. Silabs have fixing it in the last 6.7.8.0 release and Stephan is informed and very likely hi is posing one request for one updated firmware for Sonoff zigbee bridge.

Its looks like the bug is more likely being triggered on second gens EFR32 but its have happening on the first gen to.

Ther for i asking you kindly if you can "cooking" one 6.7.8.0 for the "IKEA Billy platform" as you have successfully have done before.

HW config:

MCU: EFR32MG1P132F256GM32
PB15: RX
PB14: TX
PA0: Force bootloader boot

NCP UART SW (Software Flow Control)

Your cocked bootloader is working OK so no need for new one if you dont have other opinion.
Please s37 and GBL if its possible.

Thanks in advance and all the best for you in the new year !!!
And keep safe from (Great white and Wire) SHARKS and CORONA (beer) things !

Mvh Mattias

Hi folks,

I am trying to upgrade the OS installed on the Wink Hub 1 to a modern OpenWrt build, and in the process, am trying to make sure that the various radios are up to date and functioning properly. I see that there is currently a file em357-ncp-uart-xon-xoff-use-with-serial-uart-bl-560.ota on the device which would appear to be the firmware for the EM357 zigbee peripheral.

Is there a matching updated firmware available, and how would I install it? The debug pins (JTAG/SWD) are broken out, so if needed I can go down to the metal to flash it or recover.

When running /usr/sbin/ZigBeeHACoord, I can see that the conversation with the dongle looks like (very abbreviated log, I can post more if needed), and the device responds (at 57600):

> 1970/01/01 04:26:33.961875  length=5 from=0 to=4
 1a c0 38 bc 7e
< 1970/01/01 04:26:34.051594  length=1 from=0 to=0
 11
< 1970/01/01 04:26:35.031594  length=7 from=1 to=7
 1a c1 02 0b 0a 52 7e
> 1970/01/01 04:26:35.041656  length=12 from=5 to=16
 80 70 78 7e 00 42 21 a8 50 ed 2c 7e
< 1970/01/01 04:26:35.051219  length=11 from=8 to=18
 01 42 a1 a8 50 28 15 e4 5c 53 7e

However, when trying to expose the tty via socat to the network for e.g. zigbee2mqtt to talk to it, I see:

socat -x TCP-L:20108,reuseaddr,keepalive,nodelay,keepintvl=1,keepcnt=5 /dev/ttySP4,b57600
> 1970/01/01 04:00:42.414687  length=1 from=0 to=0
 ef
> 1970/01/01 04:00:43.429031  length=5 from=1 to=5
 fe 00 21 01 20
> 1970/01/01 04:00:49.431749  length=5 from=6 to=10
 fe 00 21 01 20
> 1970/01/01 04:00:55.436844  length=5 from=11 to=15
 fe 00 21 01 20

and the dongle doesn't respond.

That suggests that the controlling programs are speaking a different protocol (and zigbee2mqtt is speaking the wrong one).

I am very new to the zigbee world, so would appreciate a pointer in the right direction if possible.

Many thanks!

Hi,

I was looking to flash E180-ZG120B-TB.

The firmware given here contains 2 version combined.s37 and .hex.
I want to flash using openocd and hence not sure if openocd today supports .s37 format .
What is the exact difference between the 2 firmware and do we have a combined version in .hex format ?
This would simplify the firmware flashing through openocd

Details on hardware are as below :
https://modkam.ru/?p=1889

Thanks and Regards
Sharath

Hi Gary.
Nice to see you again & thank you for your work.

Can you cooking a Zigbee router mode firmware for EFR32MG1 (gen1) ?
With UART 115200 baud SW
GPIO TX:PA0, RX:PA1
bootloader GPIO activation pin PD15.
SDK 6.7.8

Thanks.

Missed this but Silicon Labs have on December 15, 2022 released Gecko SDK (GSDK) 4.2.0 with Zigbee EmberZNet SDK 7.2.0.0 GA:

https://github.com/SiliconLabs/gecko_sdk/releases/tag/v4.2.0

Any chance you would consider releasing some experimental builds if zigpy and zigbee-herdsman developers want to test 7.2?

That is, EmberZNet 7.2.0.0 is probably not ready for general use yet but great if firmware images were available to test for issues.

EmberZNet 7.2 looks to use EZSP v9 (EmberZNet Serial Protocol version 9) same as Zigbee EmberZNet 7.1 (or does it not?)?

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.2.0.0.pdf

New features in it are mostly related to Dynamic Multiprotocol and multi-PAN 802.15.4 in RCP mode:

• Secure key storage support for MG2x parts that support Secure Vault-High.
• Dynamic Multiprotocol Bluetooth and multi-PAN 802.15.4 in RCP mode.
• Dynamic Multiprotocol Zigbee-NCP + Bluetooth-NCP (experimental).
• Manufacturing Library (MfgLib) support for Concurrent Multiprotocol RCP.
• Zigbee + OpenThread Concurrent Lis-tening on MG24 parts (experimental).
• Zigbee on Host (ZigbeeD) support for 32 bit and 64 bit x86 architecture (experimental).
• MGM240S SiP Module Support.

They also added simultaneous Dual-Band and Dual-PHY for Zigbee Smart Energy on MG24/MG12:

• MG24+Si4468 Dual-PHY Zigbee Smart Energy support.
• MG12 Dual-Band 2.4GHz + Sub-GHz Zigbee Smart Energy support.

Deprecated in release 7.2.0.0:

• The Secure EZSP feature will be removed in a future release.

PS: Silicon Labs has also released Gecko SDK Version 4.1.4.0 as a stable bug-fix release containing Zigbee EmberZNet SDK 7.1.4.0:

https://github.com/SiliconLabs/gecko_sdk/releases/tag/v4.1.4

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.1.4.0.pdf

I tried to flash NCP_USW_115k2_ZBBridge_6103.gbl firmware using standard Tasmota firmware update interface, but every time the process failed. At the same time flashing the older version from https://github.com/arendst/Tasmota/tree/development/tools/fw_SonoffZigbeeBridge_ezsp worked well.

Is there some trick to flash 6.10.3 to ZBBridge?

Hello Gary.
We saw issue with request: #6

Can you cooking a Zigbee router mode firmware for P series - Perfomance Silicon Labs EFR32MG1PxxxF256( Marked as EFR32MG1P232GG) ?

WE need UART 115200 baud SW
GPIO TX:PA0, RX:PA1
bootloader GPIO activation pin PB11.

SDK 6.7.8 or other

Thank you so much!

Home Assistant developer agners has begun working on an add-on for Silabs Multiprotocol stack requiring Multi-PAN firmware. See:

zigpy/zigpy#894

For the Add-on to be useful, you need the Multi-PAN firmware on a Silicon Labs radio: The example firmware is called rcp-uart-802154 in SimplictyStudio. I did compile it for the MGM210P(A32JIA) module we are using, and I use this firmware with testing.

and

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

NOTE: Requires Silicon Labs based radio with RCP Multi-PAN firmware flashed!

Maybe help with Zigbee coordinator RPC firmware with EmberZNet 6.8 RCP and NCP applications with Multi-PAN Library plugin?

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.0.2.pdf

https://community.silabs.com/s/article/building-rpc?language=en_US

This project does require that firmware include Multi-PAN Library plugin. That new Multi-PAN Library plugin is new since EmberZNet SDK 6.8.0.2 and new multi-PAN feature can create a host/NCP application that can support up to two coordinator networks:

https://www.silabs.com/documents/public/application-notes/an724-multi-network.pdf

Very early so would not advise any users use "Multi-PAN" firmware testing unless interested in testing and/or contributing to that project.

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

Concept could in the future even allow running both Zigbee 3.0 and Thread/Matter (OpenThread) stacks applications on a single radio.

It also changes architecture from NCP (Network Co-Processor) based to "DMP RPC" (Dynamic Multiprotocol Radio Co-Processor) based which if I understand correctly offload the network part to the the Zigbee integration application running on system CPU and the adapter becomes slightly more of a "dumb" Zigbee radio (still using EZSP) which for Zigbee removes some limitations on routing tables etc. (meaning that can probably have almost unlimited of devices connected even on radio adapter that has an MCU with limited RAM-memory.

PS: agners is Nabu Casa lead engineer working on Home Assistant Yellow and its EFR32MG21 (MGM210P SiP module) based radio:

https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

https://www.nabucasa.com/about/

Please consider if you might be interested in also providing OpenThread Border Router (OTBR) "RCP mode" firmware images well as "NCP mode" firmware images (with support for the OpenThread spinel+hdlc+uart protocol) for Silicon Labs EFR32MGxx adapters?

Short term goal would be to provide firmware for existing Silabs EFR32MG1x and EFR32MG1x based adapters that should be compatible with the "SiliconLabs Zigbee/OpenThread Multiprotocol Add-on" and "OpenThread Border Router Add-on" that Home Assistant developer agners (Nabu Casa employee Stefan Agner) is currently developing. Check out:

zigpy/zigpy#894

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

https://github.com/home-assistant/addons-development/tree/master/openthread_border_router

https://github.com/agners

https://community.home-assistant.io/u/agners/summary

https://groups.google.com/g/openthread-users/

FYI; Elelabs are already providing OpenThread RCP firmware with Spinel for their EFR32MG13 + an upcoming EFR32MG21 based adapter:

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility

OTBR have a list of certified chips under "Thread Certified Component" which currently lists EFR32MG12, EFR32MG13. and EFR32MG21:

https://github.com/openthread/ot-efr32

https://github.com/openthread/openthread/tree/main/examples/platforms

https://openthread.io/vendors/silicon-labs

https://www.threadgroup.org/What-is-Thread/Thread-Benefits#certifiedproducts

The main reason for this request is that an "RPC" firmware with OTBR (OpenThread Border Router) support will make your adapter will be compatible with upcoming Thread based "Matter" (Project CHIP / Connected Home over IP) devices if used in Home Assistant with their other add-ons for the that is also in development. This addon by agners requires that the radio hard a firmware in "RPC" mode instead of the no traditional "NCP" mode:

https://github.com/home-assistant/addons-development/tree/master/chip_controller_repl

https://github.com/home-assistant/addons-development/tree/master/chip_tool

https://github.com/project-chip/connectedhomeip

https://buildwithmatter.com

https://csa-iot.org/all-solutions/matter/

Also having optional OpenThread "NCP" border router firmware would allow users to alternatively use other existing OpenThread applications that use "NCP" mode instead of the newer "RPC" mode which require additional component running on the host. Ex:

https://github.com/openthread/wpantund

Note that so far agners has only worked with Silicon Labs based adapter with OpenThread "RPC" firmware for Thread based Matter (as well as ESP32-C3 based devkit for Matter over WiFi) and that is only because it is a Silabs EFR32MG21 chip based adapter that will ship inside the official Home Assistant Yellow (formerly Home Assistant Amber) hardware:

https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

PS: By the way, you might be interested in the the "Matter" workshop that Home Assistant is holding on the 15th of June even if they are in that specific workshop will not use a Thread based controller or devices and instead use a WiFi (+ Bluetooth) based "Matter" devices:

https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/

https://www.youtube.com/watch?v=9fOHBl5w0_k

https://community.home-assistant.io/t/matter-in-home-assistant-workshop-announcement/426129/

hello grobas,

I am a new Zigbee user and I have encountered some issues, and I hope to request your assistance.

I have a board that runs the Android system, and its Zigbee chip is the EFR32MG13.

I have installed Termux on it. Using the command from the elelabs-zigbee-ezsp-utility, python3 Elelabs_EzspFwUtility.py restart -m btl -p /dev/ttyS5, the feedback I get is:

Generic Zigbee EZSP adapter detected:
Firmware: 6.5.5-176
EZSP v7
Launch in bootloader mode
Generic Zigbee EZSP adapter detected:
Firmware: 6.5.5-176
EZSP v7

python3 Elelabs_EzspFwUtility.py flash -f efr32mg13p-v8-6910-115200.gbl -p /dev/ttyS5,the feedback I get is:

Generic Zigbee EZSP adapter detected:
Firmware: 6.5.5-176
EZSP v7
Launch in bootloader mode
Generic Zigbee EZSP adapter detected:
Firmware: 6.5.5-176
EZSP v7
EZSP adapter not in the bootloader mode. Can't perform update procedure

It seems that the chip did not enter the Bootloader mode as per the command. Does this mean that this chip does not have a Bootloader? Do I have any other methods to write a new firmware?

I have already successfully carried out similar operations on another board that uses the TYZS13 (EFR32MG13P) module, and have flashed the relevant firmware. These two boards seem to only differ slightly in their Zigbee chip.

I am not sure if it is appropriate for me to seek your help here. If you are able to assist me, I would be greatly appreciative. If you are not comfortable with this issue, I will close it.

I apologize for the inconvenience.

Best regards

Tuya is apparently making a 10 dBm "Zigbee 3.0 Range Extender" / "Zigbee 3.0 Signal Repeater" (Tuya SKU: "RP280") described as Zigbee Router device in a USB dongle/stick format, which at looks good on paper but has bad firmware so should not be used unless flashed with other firmware. Flashing this with custom Zigbee router firmware could maybe be of interest to the community?

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

Zigbee 3.0 Signal Repeater Model TS0207 manufactured by Tuya

Zigbee ID: "TS0207"; "_TZ3000_m0vaazab"; "FNB54-WTS08ML1.0"; "_TZ3000_ufttklsz"; "_TZ3000_5k5vh43t"

zigpy/zigpy#736

https://community.home-assistant.io/t/tuya-zigbee-signal-repeater-working-with-zha-and-conbee-2/249329/

I think it is based Silabs EFR32MG13 / EFR32MG13P732HI chip, the same as the not so common Tuya TYZS1L module, if so should have 512KB Flash storage and 64KB RAM memory?

https://developer.tuya.com/en/docs/iot/zigbeetyzs1lmodule?id=K989rjcbpt4cx

https://developer.tuya.com/en/docs/iot/light-design?id=K95afopz8waah

https://usermanual.wiki/Hangzhou-Tuya-Information-Technology/TYZS1L-4315271.pdf

Obviously the Tuya USB Signal Repeater can not be flashed with Zigbee Coordinator firmware as it does not have a USB-to-UART bridge chip / USB-to-Serial converter chip, and the Tuya TYZS1L module is probaly only used in router devices and not gateways/bridges?

I would like to suggest that should consider lowering the firmware default for transmit power (TX power) to maybe 8dBm or 9dBm.

Since this value is still configurable via software and not hardcoded or locked, end-users who wish to set it higher will still have the option to specify other transmit_power / tx_power in Zigbee gateway applications like Home Assistant's ZHA integration, Zigbee2MQTT, and others. So to clarify this to end-users; lowering the default transmit power (TX power) does not remove the option for them to change it to a higher setting if they want, as all it does is set it to a standard setting if no other setting is set in the software application.

FYI, I read that ITead ship their Sonoff ZBDongle-P adapter with 9dBm RF Transmit Output Power, which they initially primarily set to meet the International and Federal Equipment Authorization specification requirements set by FCC and ETSI governance bodies to get the legal certification in order to sell those as radio equipment in the USA / North America, Japan, and the Europen Union.

By the way, I also read that Elelabs Zigbee adapter (which uses Silicon Labs chips) ship with firmware that has TX power 8dBm by default.

The main reason for wanting a lower transmit power setting by default is not a legal reason by rather due to the fact that the reception on the Zigbee Coordinator / Zigbee Router is not changed so just raising its transmit power only makes the Zigbee Coordinator / Zigbee Router ”scream louder” but not actually ”listen better”, and then users will normally get weird symptoms such as some very far away devices connecting directly to the Zigbee Coordinator / Zigbee Router since those can ”hear” the Zigbee Coordinator / Zigbee Router fine but when those same devices try to send back their weak signals the Zigbee Coordinator / Zigbee Router can not ”hear” them as good, because the Zigbee Coordinator / Zigbee Router has not improved.

Another reason why you want to lower the firmware default for transmit power (TX power) is that in many countries (not all) it is actually not legal to sell radios internationally that have too high transmit power set by default, especially in the USA / North America and Japan, however, that also depends heavily on which frequency range (e.i. Zigbee channel) that it will be transmitting on, (for example, in Europe the transmitter power will not exceed +3 dBm output on Zigbee channel 26 but for all the other Zigbee channels you can go to 20dBm in the European Union).

https://www.eetimes.com/sorting-out-zigbee-power-options/

https://docs.silabs.com/bluetooth/5.0/general/system-and-performance/tx-power-limitations-for-regulatory-compliance-etsi-fcc

https://community.silabs.com/s/article/maximum-allowed-power-for-zigbee-applications-under-etsi-en-300-328?language=en_US

https://www.digi.com/resources/documentation/Digidocs/90001506/reference/r_cmd_pl.htm%3FTocPath%3DAT%2520commands%257CMAC%252FPHY%2520commands%257C_____5

https://www.digi.com/resources/documentation/Digidocs/90002002/Content/Reference/r_cmd_PL.htm?TocPath=AT%20commands%7CRF%20interfacing%20commands%7C_____1

https://www.nxp.com/docs/en/application-note/AN2975.pdf

I trying getting EZSP NCP up and running on Ikeas ICC-A-1 module (You finding them in most Ikea Tradfri products).

mtx512 have done one first set of firmware with standalone bootloader (UART XMODEM Bootloader) and standalone bootloader with external storage and NCP.

The both bootloaders are working also applying them on Ikeas original firmware.
But the NCP its crashing hard (cant access SWD without booting in bootloader).

Hi have done one test app that working as expected and running on the MCU.

We are stuck between hardware and software parts that we don't have not enough experience off.
Likely its a combination of the external flash and the 2 serial busses used for UART and flash (USARTx) that making it crashing.

Can you trying compiling one NCP and also if possible bootloader with one new hardware config ??

MCU: EFR32MG1P132F256GM32
PB15: RX
PB14: TX
PA0: Force bootloader boot

NCP UART SW (Software Flow Control)

Here its the main steps for doing it: Koenkk/zigbee-herdsman#168 (comment)

And my ICC-A-1 project git: https://github.com/MattWestb/IKEA-TRADFRI-ICC-A-1-Module

Thanks in advance !!

Mattias W

Hi. Would it be possible to add etrx3587-lr (EM3587) ncp uart with sw flow control firmware ebl?

Hi friend.
Thank you for your work.
I have a request to make additional assemblies of your firmware with modified ports for UART with TX:PA0, RX:PA1 and bootloader's GPIO activation pin PD15.
And please change file format to HEX, but too many flashers use only HEX or ELF formats, to get it like this:
BTL_STD_S1_256-COM_PA0-PA1-PD15.hex
NCP_USW_115K2_S1_F256_676_PA0-PA1.hex

This module (EFR32MG1B232F256GM48) used in popular Wifi routers by SerComm (PCB ID: CQR00B-1.6) and this GPIO pins is use for CPU interconnect & placed out from EMI shield, see photo.

Thanks

Which bootloader and NCP firmware are used for EFR32MG13 adapters like Tuya TYZS13 module and Elelabs ELR023 or ELU013?

TYZS13 Module Datasheet says that it used EFR32MG13P732F512GM48 (i.e. EFR32MG13P) with 512 kB Flash Storage.

https://developer.tuya.com/en/docs/iot/tyzs13-module-datasheet?id=K98u373pszqe3

Is this the same EFR32MG13P SoC that Elelabs Zigbee USB Adapter ELU013 and Elelabs Zigbee Raspberry Pi Shield ELR023 uses?

https://elelabs.com/products/elelabs-usb-adapter.html

https://elelabs.com/products/elelabs-zigbee-shield.html

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/tree/master/data/EFR32MG13

efr32mg13p

https://github.com/zha-ng/EZSP-Firmware/tree/master/Elelabs-ELU013

efr32mg1b-bootloader

• EFR32MG13P target
• Standalone Bootloader
• NCP UART TX --> PA0
• NCP UART RC <-- PA1
• Version: 1.10.3
• DCDC bypass

efr32mg13p-v8-678-sw-115200

• EFR32MG13P target
• NCP Software flow control, 115200 baudrate
• NCP UART TX --> PA0
• NCP UART RC <-- PA1
• EZSP Version 8
• EmberZNet 6.7.8
• DCDC bypass

Use case

Among other products, Tuya TYZS13 module is used in Tuya T6E Android-based panels which have now been hacked by blakadder to run Zigbee2MQTT directly but that first require you to reflash the Zigbee adapter:

https://blakadder.com/t6e-z2m/

https://community.home-assistant.io/t/tuya-t6e-4-inch-control-panel-for-ccs-central-control-system-android-based-in-wall-4-inch-smart-display-with-touch-screen-now-sold-under-many-different-brands/473366

blakadder has also hacked ITead's Sonoff NSPanel Pro (which looks to be a rebranded Tuya T6E) the same way by to run Zigbee2MQTT by getting the ADB access that is needed:

https://blakadder.com/nspanel-pro-sideload/

https://community.home-assistant.io/t/sonoff-nspanel-pro-android-based-in-wall-4-inch-smart-display-with-touch-screen-by-itead-available-for-pre-order/448841

Silicon Labs have now released Silicon Labs Zigbee EmberZNet SDK 7.0.0.0 (and matching Gecko SDK Shite 4.0.0 for it)

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.0.0.0.pdf

http://docs.silabs.com/zigbee/7.0

Gecko SDK Suite 4.0 release is also the first time Silicon Labs posted Gecko SDK Suite to a publicly available repository on GitHub:

https://github.com/SiliconLabs/gecko_sdk/tree/gsdk_4.0/protocol/zigbee

https://github.com/SiliconLabs/gecko_sdk/

https://github.com/SiliconLabs/gecko_sdk/releases

https://github.com/SiliconLabs/gecko_sdk/releases/download/v4.0.0/demo-applications.zip

https://github.com/SiliconLabs/gecko_sdk/releases/download/v4.0.0/documentation.zip

https://github.com/SiliconLabs/gecko_sdk/releases/download/v4.0.0/gecko-sdk.zip

https://github.com/SiliconLabs/gecko_sdk/releases/download/v4.0.0/pintool.zip

https://github.com/SiliconLabs/gecko_sdk/archive/refs/tags/v4.0.0.zip

https://github.com/SiliconLabs/gecko_sdk/archive/refs/tags/v4.0.0.tar.gz

Update: Looks like it was released publicly on purpose.

https://community.silabs.com/s/article/Notes-on-the-recent-Simplicity-Studio-version-5-3-0-0-release?language=en_US

https://github.com/SiliconLabs/gecko_sdk/releases

Link to 4.0 ALSO seems to work through:

https://docs.silabs.com/gecko-platform/4.0/

Silicon Labs EmberZNet version 6.10.7.0 is the latest bug-fix release in the 6.10 series so should be the latest stable in that series.

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.10.7.0.pdf

Like to ask to add/update all "B" images (e.i. images for EFR32MG2x like the EFR32MG21) from EmberZNet 6.10.3.0 to 6.10.7.0

• https://github.com/grobasoz/zigbee-firmware/blob/master/README.md#versions
  • https://github.com/grobasoz/zigbee-firmware/blob/master/README.md#notes

Fixed in release 6.10.7.0

Fixed in release 6.10.5.0

Could a Bluetooth controller firmware be built for EFR32 that is compatible with Home Assistant's native Bluetooth integration?

https://www.home-assistant.io/integrations/bluetooth/

That is, could you build a Bluetooth controller firmware with Bluetooth Low Energy (BLE) support for ex. EFR32MG21 adapters?

Home Assistant 2022.8 August 2022 release now got first-class Bluetooth support (though still not got many integrations using it):

https://www.home-assistant.io/blog/2022/08/03/release-20228/#first-class-bluetooth-support

Read EFR32MG2x multi-protocol SoCs support Bluetooth but have not seen any Bluetooth adapter for computers based on them?

https://www.silabs.com/wireless/bluetooth

Silicon Labs mention Bluetooth 5, Zigbee, and Thread protocol stacks are provided for EFR32MG21, EFR32MG22, and EFR32MG24:

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs

Would be awesome if could flash existing 20 dBm EFR32MG21 adapters sold for Zigbee with "Bluetooth Long Range" firmware.

Home Assistant currently lists known working Bluetooth adapters based on BCM20702A1, RTL8761BU/RTL8761B, CSR8510A10:

https://github.com/home-assistant/home-assistant.io/blob/next/source/_integrations/bluetooth.markdown#known-working-adapters

PS: Home Assistant 2022.9 (September 2022) release will also add support for using multiple Bluetooth adapters at the same time:

https://github.com/home-assistant/home-assistant.io/blob/next/source/_integrations/bluetooth.markdown#multiple-adapters

For reference; this question was already discussed a little previously in -> zigpy/zigpy#727 as well as here -> zha-ng/EZSP-Firmware#11

Availability of Silicon Labs EFR32MG21 based SiP/SiL radio modules like MGM210 (MGM210P/MGM21L) are still scarce so just want to ask:

You think Ebyte E104-BT11G modules which look to be based on Silabs 1024kB EFR32MG21 can be flashed with Zigbee NCP firmware?

https://www.cnx-software.com/2021/05/04/ebyte-e104-bt11-bluetooth-mesh-module-features-silicon-labs-efr32mg21-mcu/

https://www.cdebyte.net/bluetooth-module/2-4g-ble-mesh-network-bluetooth-module.html

https://www.ebyte.com/en/downpdf.aspx?id=1010

https://www.manualslib.com/manual/1895760/Ebyte-E104-Bt11.html

https://www.ebyte.com/en/downpdf.aspx?id=1010

https://www.ebyte.com/downpdf.aspx?id=990

E104-BT11 series include "E104-BT11x-IPX" (IPX antenna) and Ebyte "E104-BT11x-PCB" (PCB trace antenna), where the only difference between the "G" and "N" variants looks to be one is pre-configured as Bluetooth Gateway and other as Bluetooth Node for a BT mesh.

• https://www.aliexpress.com/wholesale?catId=0&SearchText=E104-BT11G-PCB

  • https://www.aliexpress.com/item/1005001726039426.html
  • https://www.aliexpress.com/item/1005003221082503.html
  • https://www.aliexpress.com/item/1005003676741873.html

• https://www.aliexpress.com/wholesale?catId=0&SearchText=E104-BT11G-IPX

  • https://www.aliexpress.com/item/4001260142336.html
  • https://www.aliexpress.com/item/1005001671008992.html

• https://www.alibaba.com/product-detail/GFSK-BLE-mesh-integrated-circuits-blue_1600200894074.html

• https://www.alibaba.com/product-detail/E104-BT11G-PCB-EFR32-2-4g_1600080880779.html

• https://www.alibaba.com/product-detail/Ebyte-Wireless-Communication-E104-BT11G-IPX_1600080305209.html

Pin definition

Pin | Function | Description
-- | -- | -- | --
1 | GND | Ground, connect to power reference ground
13 | NetLink | Network indicator, pin outputs high level after successfully networking
17 | TXD | TX pin of UART，for UART receiving
18 | RDX | RX pin of UART，for UART transmitting
19 | VCC | Power supply 1.9～3.6V（It is recommended to add a ceramic filter capacitor externally)
20 | GND | Ground, connect to power reference ground
22 | PC03 | Low-power role selection pin (internal pull-up). Low power consumption role: pull up or float. Other roles: Go directly to the ground.
23 | PC04 | Reset. Except for hardware information (UART configuration), factory settings are restored.
24 | Wakeup | The wake-up pin is valid in low level under low power mode.
25 | RST | Chip reset trigger input pin, valid in low level
26 | GND | Ground, connect to power reference ground

PS: The G-version is configured as one "coordinator" and the N as router device all with BT mesh.

Hi Gary !

I have some very strange observation then sleeping end device is direct connected to one coordinator and is pulling its parent (the coordinator) or trying sending one attribute report or commands to it and the coordinator is ignoring its children but is responding to other childrens requests.

See zigpy/zigpy#604 (reply in thread)

Its looks like EZSP coordinator its some time lazy and not responding on received frames and also not replaying with ack in the IEEE 802.15.4 layer.

I think its some of the "personality" of the EZSP stack, then IKEA lights is famous for not responding on multiple commands being sent to them (Like power on, dimmer up and changing color in fast pace).

I was using your latest EZSP 6.5.1.0 and its looks being worse then the 6.7.8.0 that have the "NCP fix"so 6.7.8.0 is defiantly being helping our systems. The test above is with the better 6.7.8.0.

If having one router in the near the sleeping end device can jumping to it if the coordinator is "lazy" and the device is not leaving. If not having any routers is very likely the end device is doing some beacon requests and if dot finding any router it is leaving the network until being waked up by pressing one button.

I cant see if some frames is corrupted from end device or the coordinator then EZSP sniffer is not sending them to the host app.

Is it possible using the PIT interface for see that and wot is needed for using PIT sniffing with EZSP devices ?
Is one original dev kit needed or is it possible with one "Billy" ?
Is PIT working without licence in Simplicity Studio ?

ZHA is configuring long pull with 24 (6 seconds) that is to short (and only draining batteries and dont do any good) and i is trying the "IKEA standard" 1160 (4.88 min) and its working much better and its much unlikely triggering the leaving then the coordinator is having one "lazy period".

No priority then you have your work and socials life in the first row but i welcome your experience and knowledge.

Thanks in advance and all the best !!

Mvh Mattias

@grobasoz just noticed that you added some Zigbee RCP and CLI firmware images for ESP32-C6.

• https://github.com/grobasoz/zigbee-firmware/tree/master/ESP32-C6
  • https://github.com/grobasoz/zigbee-firmware/tree/master/ESP32-C6/ZigbeeCLI
  • https://github.com/grobasoz/zigbee-firmware/tree/master/ESP32-C6/Zigbee_RCP

Can you please consider also providing similar Zigbee RCP and CLI firmware images for ESP32-H2?

As I understand the ESP32-H2 is very similar to ESP32-C6, with the major difference being that ESP32-H2 does not have a WiFi radio. ESP32-H2 has not been made available until now so firmware support for it lags behind the ESP32-C6 even though it is actually newer.

Espressif recently announced their ESP Thread Border Router / Zigbee Gateway development board based on ESP32-H2, see here:

https://www.cnx-software.com/2023/06/20/espressif-esp-thread-border-router-board-combines-esp32-h2-esp32-c3-wireless-chips/

https://www.hackster.io/news/espressif-launches-a-kit-to-turn-its-esp32-modules-into-certified-thread-border-routers-for-matter-c61db0fce050

https://github.com/espressif/esp-thread-br

https://docs.espressif.com/projects/esp-thread-br/en/latest/esp32/

https://www.aliexpress.us/item/1005005688193617.html

Als, for reference, an earlier two-board ESP Thread Border Router solution was previously available as example gateway/bridge project:

https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br

https://openthread.io/guides/border-router/espressif-esp32

This type of two-SoC setup setup could initially be useful in a proof-of-concept as a remote network-attached Zigbee Coordinator
where the ESP32-S3 would be flashed with for example ESPHome or Tasmota and the ESP32-C6 would only run Zigbee/OpenThread firmware to simply act as a Zigbee/Thread radio connected via serial using CLI or RCP interface.

PS: DamKast recently also announced "zigpy-zboss" as an (unofficial and experimental) ZBOSS radio library for zigpy -> https://github.com/kardia-as/zigpy-zboss and that could in theory make zigpy compatible with ESP32-C6/ESP32-H6 if their firmware use the standard ZBOSS API/CLI which if it is the case should make it usable as a remote network-attatched Zigbee Coordinator for Home Assistant's ZHA integration if configure via serial server pass-through as proxy using socat (similar to ser2net) -> zigpy/zigpy#1052 (More zigpy-zboss discussion related to zigpy here -> zigpy/zigpy#394)

Can you please confirm if your current firmware images have "touchlink" (touchlinking) enabled or disabled?

https://www.zigbee2mqtt.io/guide/usage/touchlink.html

Question about ezsp adapter touchlink for Zigbee Light Link (ZLL) devices was brought up here -> Koenkk/zigbee-herdsman#319

kirovilya then wrote in this other thread that the current firmware for ITead's new "ZBDongle-E" does not have Touchlink support enabled in firmware but that the ezsp adapter for zigbee-herdsman/Zigbee2MQTT/IoBroker does support touchlink and touchlinking functionality does work on other efr32 adapters:

Koenkk/zigbee2mqtt#13893

Originally posted by @kirovilya in Koenkk/zigbee2mqtt#13893 (reply in thread)

I know that in other dongles on efr32, the touchlink functionality works. But in the firmware for sonoff dongle-e it is disabled (according to my information). To make it work - you need another firmware (I don’t know which one yet).

Actually, the Bitronvideo BV 2010/10 is already working using the first commit intended for etrx3587-lr.
Unlike etrx3587-lr, the Bitronvideo BV 2010/10 uses PC6 for PA/LNA while etrx3587-lr uses PC5.

#14 is what led me to try the em3587 firmware.

IOW, I used https://github.com/grobasoz/zigbee-firmware/raw/af7c35ea8d580152eb9853af1d3fab91bef3b5d4/EM3587/NCP_USW_EM3587-LR_678-115k2.ebl
and it works on my Bitronvideo BV 2010/10

Thank you @grobasoz ! :-)

@grobasoz OK to request or suggest that release precompiled EmberZNet 6.8 NCP application firmware as optional downloads?

Silicon Labs EmberZNet SDK version 6.8.0 (6.8.0.2) was released this summer so it is new but not quite cutting-edge any more.

Update 1! EmberZNet SDK 6.8.2.0 GA (General Availability) is officially available to the public since October 14, 2020.

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.2.0.pdf

Update 2! EmberZNet SDK 6.9.0.0 GA (6.9 General Availability) is officially available to the public since December 9, 2020.

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.9.0.0.pdf

Mostly interesting in testing this on the Sonoff ZBBridge (Sonoff Zigbee Bridge) by ITead with Tasmota zbbridge as it is versatile.

Preferably also as a Sonoff key signed firmware in an OTA image format as well that can be flashed with Tasmota itself:

https://github.com/arendst/Tasmota/tree/development/tools/fw_zbbridge

Sonoff ZBBridge when flashed with Tasmota zbbridge and custom EmberZNet firmware can be used in two ways:

Zigbee2Tasmota (Z2T) is Tasmota's own native Zigbee to MQTT solution which is lightweight but not very user-friendly:

https://tasmota.github.io/docs/Zigbee/

Sonoff ZBBridge as a remote pass-through WiFi bridge adapter to be used by other software like Home Assistant ZHA:

https://www.digiblur.com/2020/07/how-to-use-sonoff-zigbee-bridge-with.html

Note! Sonoff ZBBridge is no longer recommended remote pass-through as WiFi is not stable enough for the EZSP protocol.

Additional notes

Please note that release notes say that EmberZNet PRO stack version 6.8.x requires latest Simplicity Studio 5 (SSv5) which is new.

Might be nice for developers and users to have the option to upgrade to the latest and greatest firmware available from SiLabs ;)

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.0.2.pdf

https://www.silabs.com/documents/public/quick-start-guides/qsg106-efr32-zigbee-pro.pdf

Major new Zigbee feature in EmberZNet 6.8 and later is support for concurrent multiple PANs (multi-PAN) on one coordinator:

https://www.silabs.com/documents/public/application-notes/an724-multi-network.pdf

There is also support for "Dynamic Multiprotocol Development with Bluetooth and Zigbee" which might not be as interesting.

https://www.silabs.com/documents/public/application-notes/an1133-dynamic-multiprotocol-bluetooth-zigbee.pdf

Keywords: Silabs NCP EZSP Ember ZNet 6.8 Stack EFR32 EFR32MG EFR32MG1 EFR32MG2 EFR32MG21 Sonoff ZBBridge IKEA icc-a-1

Hi I've followed this link: https://zigbee.blakadder.com/Lidl_TYGWZ-01.html in order to use the SilverCrest Zigbee with Home Assistant and I've upgraded the EZSP Version to 6.7.8.0 (firmware: https://github.com/grobasoz/zigbee-firmware/raw/master/EFR32%20Series%201/EFR32MG1B-256k/NCP/NCP_UHW_MG1B232_678_PA0-PA1-PB11_PA5-PA4.gbl)

I wonder if there are any chance to upgrade to a newer version?

Thanks in advance for your support!

@grobasoz Can you tell if existing firmware releases are compatible with ITead's new “ZBDongle-E” that is also based on EFR32MG21 and is confusingly referred to as "Sonoff Zigbee 3.0 USB Dongle Plus V2”.

https://itead.cc/product/zigbee-3-0-usb-dongle/

As far as I can tell it does look like the ZBDongle-E uses the exact same EFR32MG21A020F768IM32 SoC used on their previous model 9888010100045 ITead Zigbee 3.0 USB Dongle. EFR32MG21A020F768IM32 is well as on CoolKit Technologies “SM-011 V1.0” module used in the ITead Sonoff ZBBridge Zigbee Bridge and in Tuya ZS3L and Tuya ZSLC5 SoC modules. That includes an 80 MHz ARM Cortex-M33 core, 768 kB Flash Storage, 64 kB RAM in a QFN32 package

I guess that my question is if this new “ZBDongle-E” dongle board is probably pin-compatible with the first/old ITead barebone Zigbee 3.0 USB Dongle (model "9888010100045"), as well as on CoolKit Technologies “SM-011 V1.0” (ZYZBP008) module used in the "ITead Sonoff ZBBridge Zigbee Bridge" as well as the unbranded ZB-GW04 USB dongle (a.k.a. "easyiot stick") ?

https://github.com/xsp1989/zigbeeFirmware

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle-NoSigned/EZSP

Here is by the way link to FCC filing/report for the new “ZBDongle-E” (a.k.a. "ZBD-E" ) adapter which contains copy of the user manual + a lot more detailed + many more internal and external pictures:

https://fccid.io/2APN5ZBD-E

https://fccid.io/2APN5ZBD-E/User-Manual/User-Manual-6012461.pdf

https://fccid.io/2APN5ZBD-E/Internal-Photos/Internal-Photos-6012455

https://fccid.io/2APN5ZBD-E/External-Photos/External-Photos-6012451

It at least looks to use the same EFR32MG21A020F768IM32 (EFR32 Mighty Gecko Series 2) SoC used on the first ITead Zigbee 3.0 USB Dongle, as well as on CoolKit Technologies "SM-011 V1.0" module used in th ITead Sonoff ZBBridge Zigbee Bridge and in Tuya ZS3L and Tuya ZSLC5 SoC modules. It includes a 80 MHz ARM Cortex-M33 core, 768 Flash Storage, 64 RAM, in a QFN32 package, which radio has + 20 dBm maximum power output and receive sensitivity of -104 (250 kbps O-QPSK DSSS) dBm.

There are further details and more users discussion here:

https://community.home-assistant.io/t/itead-s-sonoff-zigbee-3-0-usb-dongle-plus-model-zbdongle-e-based-on-silicon-labs-efr32mg21-20dbm-radio-mcu-now-sold-for-19-99/442695

and here:

Koenkk/zigbee2mqtt#13373

By the way, news is that a similar Silabs EFR32MG21 SoC will also be used in the official "Home Assistant SkyConnect USB Stick", see:

https://community.home-assistant.io/t/home-assistant-skyconnect-usb-stick-announced-will-be-compatible-with-both-zigbee-and-thread-including-matter-chip-over-thread/433594

You can submit your interest in the official "Home Assistant SkyConnect USB Stick" here if want to get mailed updates on that dongle:

https://docs.google.com/forms/d/e/1FAIpQLScEjHSBJszUZfgO3MIDO51IHr3Oeohcs8BLpRIjY1liJ58IpA/viewform

Silicon Labs EmberZNet 6.10.3.0 GA should really be mature and stable enough now as only contain bug-fixes since 6.10.0.0 GA.

Silabs EmberZNet Zigbee 6.10.0.0 was released on the 16th June of 2021 and newer EmberZNet 6.10 updates since then:

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.10.0.0.pdf

EmberZNet 6.10.2.0 was released on the 8th of September of 2021

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.10.2.0.pdf

EmberZNet 6.10.1.0 was released on the 21st June of 2021

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.10.1.0.pdf

EmberZNet 6.10.3.0 was released on the 13th October of 2021

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.10.3.0.pdf

FYI, Elelabs has now released EmberZNet v6.10 firmware for their EFR32 based adapters (based on EFR32MG12):

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/blob/master/data/EFR32MG13/ELE_MG13_zb_ncp_115200_610_211112.gbl

Elelabs/elelabs-zigbee-ezsp-utility@31f8e9c

Added

• 6.10 Zigbee Firmware for ELU013/ELR023 (just keep up with the latest EmberZnet SDK)

Their firmware update tool has also been updated with a few new features:

Elelabs/elelabs-zigbee-ezsp-utility@721019c

Elelabs/elelabs-zigbee-ezsp-utility@e9b3fe1

Changed

• ele_update parameters changed. Now the function only updates to latest version of available Zigbee or Thread firmware
• probe and restart functions can now detect Thread adapters as well

Silicon Labs released EmberZNet Zigbee 7.0.2.0 (7.0.2) for general availability and like to request a such firmware image for EFR32MG21

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.0.2.0.pdf

What are the pros and cons with 115200 verses 57600 bit rate speed for Silabs EZSP serial protocol on EFR32MG1/EFR32MG2?

kirovilya brought up the question in Koenkk/zigbee-herdsman#168 for EByte-E180-Z120B and SM-011 V1.0 modules.

PS: The upcoming Sonoff Zigbee 3.0 dongle from ITead will ship with firmware config for 115200 -> https://fb.watch/386X5ET50f/

Silicon Labs Gecko SDK (GSDK) 4.1.0 released with Zigbee EmberZNet SDK 7.1.0.0 so like to request Zigbee NCP firmware images.

Believe that currently is only wanted by developers for testing EZSP v9 (EmberZNet Serial Protocol version 9), so not for end-users.

https://github.com/SiliconLabs/gecko_sdk/releases

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.1.0.0.pdf

• EZSP v9 (EmberZNet Serial Protocol version 9)
• 2.4GHz Zigbee Smart Energy support for xG24
• 802.15.4 Signal Identifier and MAC CCA Mode 2 and 3 support for xG24
• Zigbee Green Power Gateway Backup
• Updated GCC and IAR compiler version
• Alpha Concurrent Multiprotocol Zigbee in NCP mode and Open-Thread in RCP mode
• Alpha Dynamic Multiprotocol Bluetooth and multi-PAN 802.15.4 in RCP mode

Silicon Labs have on the 7th of June 2023 released Gecko SDK (GSDK) v4.3 / 4.3.0 with Zigbee EmberZNet SDK v7.3 / 7.3.0.0 GA:

https://github.com/SiliconLabs/gecko_sdk/releases/tag/v4.3.0

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.3.0.0.pdf

https://www.silabs.com/wireless/zigbee?tab=software#software

Any chance consider releasing some experimental builds if zigpy and zigbee-herdsman developers want to test EmberZNet 7.3?

Reference -> zigpy/bellows#563 and Koenkk/zigbee-herdsman#319

While brand new and not yet supported in any open-source Zigbee gateway solution, early cutting-edge can help pre-release testing.

Normal end-users should be warned against flashing this firmware was is the EZSP protocol version been incremented to EZSP v12 and Zigbee gateway solutions such as Home Asssitant's ZHA integration and Zigbee2MQTT are still only compatible with EZSP v11 and earlier EZSP versions at this time.

EZSP protocol version been incremented to EZSP v12 in Silicon Labs Gecko SDK v4.3 (4.3.0.0) / Zigbee EmberZNet v7.3 (7.3.0.0):

https://github.com/SiliconLabs/gecko_sdk/blob/gsdk_4.3/protocol/zigbee/app/util/ezsp/ezsp-protocol.h#L33

0x0C hexadecimal = 12 in decimal.

Sidenote - EmberZNet 7.3 is the first Silabs firmware release to be "Zigbee PRO 2023" compatible

Silicon Labs EmberZNet 7.3.0.0 is the first Silabs SDK that offers Zigbee R23 compliance, with it making their Silabs Zigbee stack compatible with Zigbee Protocol Specification Revision 23 / R23 (also known as "Zigbee PRO 2023" and "Zigbee 2023" ).

Zigbee

• Zigbee R23 compliance, with these Security enhancements among others:
  • Dynamic link key negotiation
  • Device interview to query devices before they are allowed to join
  • Trust Center Swap Out to replace an existing Trust Center with a new one
  • Frame Counter Synchronization
• Zigbee Direct Device (ZDD) support for:
  • Onboarding/commissioning
  • Communication to all Zigbee devices without a hub (Alpha), using Bluetooth LE
• Zigbee Smart Energy 1.4a compliance (Alpha)
• Enhancements to Zigbee Green Power (ZGP) APIs
• New Zigbee Security upgrade component for moving encryption keys from cleartext NVM3 tokens into secure storage

https://www.silabs.com/blog/zigbee-pro-2023-spec-released-increases-security

https://csa-iot.org/newsroom/zigbee-pro-2023-improves-overall-security-while-simplifying-experience/

https://csa-iot.org/wp-content/uploads/2023/04/05-3474-23-csg-zigbee-specification-compressed.pdf

Reference:

zigpy/zigpy#1211

PS: Nabu Casa at least offers official EmberZNet 7.3 NCP firmware beta builds for the Home Assistant SkyConnect USB dongle:

https://github.com/NabuCasa/silabs-firmware/tree/main/EmberZNet/beta

@grobasoz Any chance could release a "Zigbee Router" firmware for ITead Zigbee 3.0 USB Dongle Model 9888010100045 ?

https://www.itead.cc/zigbee-3-0-usb-dongle.html

Think it uses the same pad/pin layout as the Sonoff ZBBridge

https://github.com/xsp1989/zigbeeFirmware

zigpy/zigpy#586

1.ETX - Pin PB01 ERX Pin PB00 connect to your pc
2.Ground PA00
3.Temporary ground the reset pin Z_RST (nRST) to reset
4.Choice "1. upload gbl"
5.Using xmodem(128 byte) send this ota file to you device.

Update: Nabu Casa developer working on Zigbee NCP + OpenThread RCP combination firmware for Home Assistant SkyConnect:

https://github.com/NabuCasa/silabs-firmware

Those firmware images feature support for simulations running Zigbee NCP (EZSP) + OpenThread RCP for backward compatibility:

https://github.com/NabuCasa/silabs-firmware/tree/main/EmberZNetAndOpenThreadRCP/beta

The reason for also wanting OpenThread RPC support is that Home Assistant 2022.12 has now been released with initial multiprotocol support Zigbee NCP (via EZSP) and Thread (OpenThread RCP Multi-PAN which indirectly can support Matter over Thread), as tested with "Home Assistant SkyConnect" USB adapter and "Home Assistant Yellow" embedded radio:

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow/updates/more-yellows-shipping-and-thread-plus-matter-updates

https://www.home-assistant.io/blog/2022/12/07/release-202212/

https://community.home-assistant.io/t/home-assistant-skyconnect-usb-stick-announced-will-be-compatible-with-both-zigbee-and-thread-including-matter-chip-over-thread/433594/

Silicon Labs Gecko SDK 4.1.0 was released with "Alpha Concurrent Multiprotocol Zigbee in NCP mode and OpenThread in RCP mode":

https://github.com/SiliconLabs/gecko_sdk/releases

It means that can now build a unified firmware image that can support Zigbee in NCP mode and OpenThread in RCP mode.

I guess means that could have a multiprotocol firmware that is simultaneously backwards compatible with an Zigbee NCP application as well as also compatible OpenThread RPC application support too at the same time?

If this is the case then such backwards-compatible firmware images might be interesting for users of existing applications that use "old school" Zigbee in NCP mode as it would open up the ability to concurrently also use the same radio adapter for OpenThread/Thread (and thus also the upcoming Matter connectivity protocol), or does it not?

Please see a somewhat related discussion here (though it only discusses RPC mode and not NCP + RPC) -> zigpy/zigpy#894

Silabs Zigbee EmberZNet SDK 7.1.0.0

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.1.0.0.pdf

• ...
• Alpha Concurrent Multiprotocol Zigbee in NCP mode and Open-Thread in RCP mode
• Alpha Dynamic Multiprotocol Bluetooth and multi-PAN 802.15.4 in RCP mode

OpenThread SDK 2.1.0.0 for Silabs

https://www.silabs.com/documents/public/release-notes/open-thread-release-notes-2.1.0.0.pdf

• ...
• Alpha Concurrent Multiprotocol Zigbee in NCP mode and OpenThread in RCP mode
• Alpha Dynamic Multiprotocol Bluetooth and multi-PAN 802.15.4 in RCP mode

New in release 7.1.0.0

The Z3GatewayCpc application has been added a host-side application that can send and receive EZSP frames using CPC. This application is meant to work with an NCP application that also uses the CPC feature. This application requires the CPC daemon to be running on the host. CPC setup is described in https://github.com/SiliconLabs/cpc-daemon/blob/main/readme.md.

Two Zigbee - NCP + OpenThread – RCP applications have been added, one for UART and one for SPI. These applications demonstrate the Zigbee NCP and OpenThread RCP running concurrently using an RTOS. For more information on these applications, see AN1333: Running Zigbee, OpenThread, and Bluetooth Concurrently on a Linux Host with a Multiprotocol RCP.

https://www.silabs.com/documents/public/application-notes/an1333-concurrent-protocols-with-802-15-4-rcp.pdf