ITead “SONOFF Zigbee Bridge Pro” (ZBBridge-P) new CC2652P and ESP32 based Zigbee Gateway to WiFi Bridge

[Hedda]

FCC leak show CC2652P and ESP32 based Sonoff ZBBridge-P v1.1 Zigbee Bridge variant and wireless Zigbee sensors is coming from ITead:

https://fccid.io/2APN5ZBBRIDGEP

UPDATE! "SONOFF Zigbee Bridge Pro" (ZBBridge-P a.k.a. ZB Bridge-P) has now been released an is in May 2020 being sold for $24.90:

https://itead.cc/product/sonoff-zigbee-bridge-pro/

According to @digiblur who broke/spotted this news, the Sonoff ZBBridge-P and the sensors are slated to be released in March of 2022:

https://www.digiblur.com/2021/12/new-sonoff-zigbee-bridge-and-sensors.html

Based on the specs it should be compatible with Tasmota and ESPhome, at least when used as remote adapter for Zigbee2MQTT and ZHA:

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

https://github.com/thegroove/esphome-zbbridge

Internal pictures posted from FCC show using an unannounced Texas Intruments CC2652P (CC2652P1) MCU chip based “SM-031 v1.1” radio module which must be made by CoolKit (the company that makes their EFR32MG21 based “SM-011 V1.0” module).

ESP32 (ESP32-D0WD-V3) has replaced the ESP8266/ESP8285, and it also looks like added an on-board clock-battery too, presumably for RTC (Real-Time Clock)?

https://fccid.io/2APN5ZBBRIDGEP/Internal-Photos/Internal-Photos-5613131

FFC also leaked new Sonoff branded Door/Window Sensor, Motion Sensor, Temp/Humidity Sensor, and a Button as wireless Zigbee devices, all with the same CCC2652P (CC2652P1/CC2652P1F) chip which +20 dBm capable power amplifier is really overkill for battery-operated sensors and should on theory use more battery power than if they would have used the compatible CC2652R or CC2652RB.

Sadly it looks like this new variant of Sonoff ZBBridge still uses Wi-Fi instead of a wired Ethernet network like the ESP32 based ZB-GW03:

https://community.home-assistant.io/t/zb-gw03-ewelink-ethernet-zigbee-gateway-now-hacked-with-tasmota-zbbridge-so-can-be-used-via-mqtt-or-as-a-remote-zigbee-adapter-with-home-assistant-zha-and-zigbee2mqtt/341223

#12764

https://github.com/syssi/esphome-zb-gw03/

Ethernet is preferred by DIY users who flash Tasmota or ESPHome in order to use it as a remote Zigbee adapter with ZHA or Zigbee2MQTT because tunnelling serial communication over a serial stream server connection and the serial APIs of the Zigbee stacks are not robust/stable over WiFi as assume a direct connection, which is why both ZHA and Zigbee warns against using WiFi-based networked-attached Serial-to-IP Zigbee bridges/gateways/adapters:

https://www.home-assistant.io/integrations/zha#warning-about-wi-fi-based-zigbee-to-serial-bridgesgateways

https://www.zigbee2mqtt.io/advanced/remote-adapter/connect_to_a_remote_adapter.html

Looking at the board pictures of "ITead SONOFF Zigbee 3.0 USB Dongle Plus" from @notenoughtech (Mat Zolnierczyk) my guess is it is the same engineer at CoolKit Technologies who engineered this “SM-031 v1.1” radio-module that helped ITead design the board for the SONOFF Zigbee 3.0 USB Dongle Plus adapter. Its bad start tuned out to only be issues with early firmware fixed now and not a faulty hardware design:

https://notenoughtech.com/home-automation/sonoff-zigbee-3-0-usb-dongle-plus/

https://notenoughtech.com/home-automation/is-sonoff-zigbee-dongle-plus-finally-ready-for-launch/

Not sure if this is intended to permanently replace the popular ITead Sonoff ZBBridge

https://community.home-assistant.io/t/sonoff-zbbridge-sonoff-zigbee-bridge-from-itead/187346

As I understand ITead have not abandoned Silicon Labs yet but it is just that Silabs chip stocks have suffered worse than most other companies during the still currently ongoing worldwide chip shortage.

PS: I assume it will use the same community firmware from Koenkk for CC2652P as they use for “Sonoff Zigbee 3.0 USB Dongle Plus”:

Koenkk/zigbee2mqtt#8840

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

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

[ascillato2]

Thanks for sharing. Very complete information.

The CC2652 chip from TI is a good one (very powerful) and the official IDE to program it is free. CC2652 can be programmed to support Thread, BT, Matter or ZigBee. The only change required is the firmware (the antenna and components are the same). It also supports Matter in parallel to ZigBee so it can become a Tasmotized Wi-Fi to Matter and ZigBee Bridge. A lot of exciting work ahead !

[Hedda]

It also supports Matter in parallel to ZigBee so it can become a Tasmotized Wi-Fi to Matter and ZigBee Bridge

Yes both Texas Instruments CC2652/CC1352 MCU chips and Silicon Labs EFR32 Mighty Gecko Series 2 (EFR32MG21) MCU stacks does have multi-protocol stack support, but I have not yet heard of anyone running Zigbee and Thread/Matter stacks concurrently at the same time. I understand that the Thread/Matter implementations always runs Thread/Matter and Bluetooth at the same time, however I believe that Bluetooth is then really only used for initial commissioning during the first setup via a smart phone before it is configured to connect to a Thread Border Router.

While I would never say never, I understand that CC2652/CC1352 chips as well as Silicon Labs EFR32 Mighty Gecko Series 2 (EFR32MG21) chips does on paper support multi-protocol with for example both a Zigbee stack and a Thread/Matter stack running on the MCU concurrently at the same time, I think that would generally only be recommended on the client/end-device side, as in for example battery-operated wireless sensors supporting Zigbee and Thread/Matter stacks at the same time, as I believe it would probably not be recommended to run a CC2652/CC1352 chip as Zigbee Coordinator and Thread Border Router (as Thread/Matter controller) as the same time.

It would therefore probably be best to run Zigbee and Thread/Matter stacks on their own seperate dedicated radio-module for now(?).

My guess is however that the next-generation of Texas Instruments multi-protocol chips (as well as the next-generation of Silicon Labs chips multi-protocol chips) will feature more RAM-memory and flash-storage than the current generation, which at least in theory should make them better at handling running concurrent protocol stacks like Zigbee and Thread/Matter at the same time.

Regardless, I did notice that Silicon Labs does seem to have more documentation about multiprotocol RCP and dynamic multiprotocol.

[notenoughtech]

The release is slated for march. I'll get one early to play with but not until Feb

…

On Fri, 14 Jan 2022, 08:06 Hedda, ***@***.***> wrote: It also supports Matter in parallel to ZigBee so it can become a Tasmotized Wi-Fi to Matter and ZigBee Bridge Yes both Texas Instruments CC2652/CC1352 MCU chips and Silicon Labs EFR32 Mighty Gecko Series 2 (EFR32MG21) MCU stacks does have multi-protocol stack support, but I have not yet heard of anyone running Zigbee and Thread/Matter stacks concurrently at the same time. I understand that the Thread/Matter implementations always runs Thread/Matter and Bluetooth at the same time, however I believe that Bluetooth is then really only used for initial commissioning during the first setup via a smart phone before it is configured to connect to a Thread Border Router. While I would never say never, I understand that CC2652/CC1352 chips as well as Silicon Labs EFR32 Mighty Gecko Series 2 (EFR32MG21) chips does on paper support multi-protocol with for example both a Zigbee stack and a Thread/Matter stack running on the MCU concurrently at the same time, I think that would generally only be recommended on the client/end-device side, as in for example battery-operated wireless sensors supporting Zigbee and Thread/Matter stacks at the same time, as I believe it would probably not be recommended to run a CC2652/CC1352 chip as Zigbee Coordinator and Thread Border Router (as Thread/Matter controller) as the same time. It would therefore probably be best to run Zigbee and Thread/Matter stacks on their own seperate dedicated radio-module for now(?). My guess is however that the next-generation of Texas Instruments multi-protocol chips (as well as the next-generation of Silicon Labs chips multi-protocol chips) will feature more RAM-memory and flash-storage than the current generation, which at least in theory should make them better at handling running concurrent protocol stacks like Zigbee and Thread/Matter at the same time. Regardless, I did notice that Silicon Labs does seem to have more documentation about multiprotocol RCP and dynamic multiprotocol. — Reply to this email directly, view it on GitHub <#14419 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKDRL224K47EHN3JOTWMJVLUV7KPBANCNFSM5L37PILQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[digiblur]

Hedda quoted the March already.

[Hedda]

FYI, ITead has apparently now started selling "SONOFF Zigbee Bridge Pro" which I assume are the same as the previously leaked "Sonoff ZBBridge-P" model based on CC2652P and ESP32-D0WD-V3?

https://itead.cc/product/sonoff-zigbee-bridge-pro/

Its packaging is the same as and their previous Zigbee gateway/bridge and the only listed difference mentioned on its website is that it can handle 128 instead of 32 devices, contains a “buzzer” which webpage mention that the buzzer can be used as an alarm (siren?) or as a doorbell chime (if use Zigbee wireless buttons as doorbells), and a “built-in high-precision local RTC” (Real-Time Clock with clock-battery) for gateway time synchronization of local scene schedules.

Note that they are also still selling the older ZBBridge based on EFR32MG21 and ESP8266/ESP8285 which has already been hacked with Tasmota (Zigbee2Tasmota) as a Zigbee to MQTT bridge (ZBBridge):

https://itead.cc/product/sonoff-zbbridge/

See also

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

and

https://templates.blakadder.com/ewelink_ZB-GW03

[Hedda]

@s-hadinger suggest also get a ZB-GW03 to also have variant based on ESP32 and ERF32MG21 with Ethernet for testing Silabs EZSP:

#12764

https://templates.blakadder.com/ewelink_ZB-GW03

https://github.com/xsp1989/zigbeeFirmware/

https://community.home-assistant.io/t/zb-gw03-ewelink-ethernet-zigbee-gateway-now-hacked-with-tasmota-and-esphome-so-can-be-used-via-mqtt-or-as-a-remote-zigbee-lan-adapter-with-home-assistants-zha-integration-or-zigbee2mqtt/341223

ZB-GW03 eWeLink Ethernet Zigbee Gateway is based on ESP32 and EFR32MG21 as previous Sonoff ZBBrige but got wired Ethernet

[aioue]

@Hedda to clarify, is the ZB-GW03 based on exactly the same chips as the Zigbee Bridge Pro, but with the addition of an ethernet port?

[s-hadinger]

It seems so, yes

[sfromis]

No, the GW03 has the same Zigbee chip as the non-pro Sonoff ZbBridge. The new Sonoff "pro" is using CC2652P instead. The GW03 has the older EFR32MG21 Zigbee chip, but paired with ESP32, like the "pro" Sonoff.

[Hedda]

is the ZB-GW03 based on exactly the same chips as the Zigbee Bridge Pro, but with the addition of an ethernet port?

No, "ZB-GW03" and first "Itead Sonoff ZBBridge" only use exact same EFR32MG21 Zigbee module (which requires a signed firmware, see https://github.com/xsp1989/zigbeeFirmware/), while the new "Itead Sonoff ZBBridge Pro" a CC2652P Zigbee module from Texas Instruments:

• "Itead Sonoff ZBBridge Pro" (a.k.a. "ZBBridge-P") ) is based on Texas Instruments CC26652P and ESP8266 so it only offers Wi-Fi.
• "ZB-GW03" is based on EFR32MG21 Zigbee module and ESP32 + 100Mb Ethernet (RJ-45 port).
• "Itead Sonoff ZBBridge" (not the new "Pro" model) is based on EFR32MG21 and ESP8266/8285 so it only offers Wi-Fi.

Note that while unlikely it is still unknown if the Texas Instruments CC2652P Zigbee module used in the new "Itead Sonoff ZBBridge Pro" also uses a signed firmware or not, it is more likely it uses unmodified firmware images from Koenkk -> https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

[Hedda]

FYI, there are more alternative options based on ESP32, both finished products as well ESP32 based DIY gateways as open-source hardware:

tube0013 sells his ESP32 based open-source hardware LAN/Ethernet to Zigbee gateways with Silabs EFR32MG21/MGM210 and TI CC2652P:

https://www.tubeszb.com/product/cc2652_coordinator/39?cp=true&sa=false&sbp=false&q=false&category_id=2

https://www.tubeszb.com/product/cc2652_poe_coordinator/47?cp=true&sa=false&sbp=false&q=false&category_id=2

https://www.tubeszb.com/product/efr32-pro-ethernet-usb-serial-coordinator-version-2/5?cp=true&sa=false&sbp=false&q=false&category_id=2

https://github.com/tube0013/tube_gateways

ZigStar LAN Gateway is an additional ESP32 based open-source hardware LAN/Ethernet to Zigbee gateway with CC2652P:

https://zig-star.com/projects/zigbee-gw-lan/

https://github.com/mercenaruss/zigstar_gateways

Gio-dot Z-Bee-Duo with only Wi-Fi (designed with CC2652P based Ebyte E72-2G4M20S1E or RFSTAR RF-BM-2652P2 Zigbee modules):

https://github.com/Gio-dot/Z-Bee-Duo

DIY Zigbee Gateway using CC2652P based ITead SONOFF Zigbee 3.0 USB Dongle Plus used as a Zigbee serial module instead of via USB:

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

DIY Zigbee Gateway using CC2652P based Ebyte E72-2G4M20S1E or RFSTAR RF-BM-2652P2 Zigbee modules ordered online from China:

https://www.szrfstar.com/product/237-en.html

https://www.ebyte.com/en/product-view-news.html?id=1002

DIY "Billy EZSP" and "IKEA TRÅDFRI MARKUS EZSP" ESP32 based bridge/gateway using Silicon Labs based "IKEA TRÅDFRI ICC-A-1 Module" ripped from an IKEA Tradfri Series device with hacked firmware (requires reflashing the Zigbee module with a JTAG adapter)

https://github.com/MattWestb/IKEA-TRADFRI-ICC-A-1-Module

zigpy/zigpy#584

[mercenaruss]

@Hedda I ordered the device and will adjust our firmware ZigStarGW-FW to work with it.
If anybody get hands on device before my own arrive,please let me know. To adjust firmware,so can be used with Z2M,ZHA.

[sfromis]

That looks like what I mentioned with making a serial connection instead of USB.

[salopette]

Can I flash Tasmota to Esp32 and then configure TX/ RX gpio.
Can Tasmota TCP?

[sfromis]

Yes, Tasmota has a TCP bridge feature to map serial to ser2net

[salopette]

thanks, i think it should work! Will try!

[Hedda]

Board of "ZBDongle-E" (EFR32MG21 based) variant does look to expose "TX" and "RX" which might be serial/UART access to EFR32MG21?

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

However the board of their "ZBDongle-P" (CC2652 based) variant does not expose "TX" and "RX" pads?

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

So could maybe be able to use "ZBDongle-E" (EFR32MG21 based) board with Zigbee2Tasmota (Z2T) just like a serial Zigbee radio module?

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

Suggest flash tasmota-zbbridge build as that already has a "ZHA" mode that can create a serial to TCP bridge (similar to ser2net) from the Zigbee serial module to Home Assistant or Zigbee2MQTT with serial socket mapped via socat, though it should be noted that it is not recommended to tunnel a Zigbee serial module traffic over Wi-Fi and instead should only be done on if use an ESP32/ESP8266/ESP8285 board with an Ethernet port for a wired connection.

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

https://www.zigbee2mqtt.io/how_tos/how_to_connect_to_a_remote_adapter.html

https://www.home-assistant.io/integrations/zha/#zigate-or-sonoff-zbbridge-devices

https://www.home-assistant.io/integrations/zha/#warning-about-wi-fi-based-zigbee-to-serial-bridgesgateways

FYI, check out these other relevant DIY examples:

https://github.com/MattWestb/IKEA-TRADFRI-ICC-A-1-Module/tree/master/Tasmota

zigpy/zigpy#584

https://templates.blakadder.com/tube_TUBE013_EFR32.html

Good luck and hope that you succeed and then publish a blog post or video with steps how to do it.

[Hedda]

FYI, both @notenoughtech and @digiblur have received theirs and while neither of them has tried to flash/hack it yet they posted some early thoughts on the original eWeLink hub firmware and hardware board, confirming that the first retail version ITead's SONOFF Zigbee Bridge Pro with PCB board labelled "ZBBridge-P V1.1 2021.11.12" is indeed based on Espressiff ESP32-DOWD-V3 rev.3 (that ESP32 variant by the way also has integrated support for Bluetooth 4.2 including BLE), Texas Instruments CC2652P Zigbee module labelled "SM-031 V1.1 2021.07.28" (so probably manufactured by CoolKit Technologies like the Zigbee module for previous Sonoff bridge), with a cell-battery for the RTC (Real-Time-Clock), a built-in buzzer for chime or alarm-siren, and also an Espressiff branded PSRAM (ESP-PSRAM16H) with 2MB/16Mbit capacity.

digiblurDIY also mention that he managed to backup original firmware from its ESP32 chip without issue so suspect that it is not locked:

https://www.youtube.com/watch?v=P5op57y5i6k?t=920&ab_channel=digiblurDIY

https://notenoughtech.com/home-automation/sonoff-zigbee-bridge-pro/

https://www.youtube.com/watch?v=fsIjFxCPJLA&ab_channel=NotEnoughTECH

Again, the new radio module based on Texas Instruments CC2652 probably come preloaded with Zigbee Coordinator firmware from Koenkk:

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

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

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

[s-hadinger]

I just received mine so we'll know more.

[digiblur]

I started pinning out a few things from ESP chip to the Zigbee module and such. Little more tedious being ESP32. I can share my notes when I am in front of them.

[s-hadinger]

Oh yes please. I'm curious what are the gpio connected to the Zigbee MCU. I suppose there are I2C connections that RTC as well

[mercenaruss]

If you have time we can adjust ZigStar Firmware to work with this gateway.

[s-hadinger]

Would it bring features not already covered by Tasmota?

[Hedda]

Would it bring features not already covered by Tasmota?

@s-hadinger ZigStar Zigbee Coordinator bridge firmware does support mDNS Zeroconf discovery as requested for Tasmota here -> #15579

While that is not important to the native Zigbee2Tasmota gateway it is a very nice feature for users of Home Assistant's ZHA integration:

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

That is, when mDNS Zeroconf discovery is enabled it allows Home Assistant to automatically discover it on your local network as a remote Zigbee Coordinator adapter and will show a notification suggesting "Zigbee Home Automation" as a "new devices discovered", the user then has option to just click on configure and so ZHA integration will automatically be installed using DNS record info from mDNS Zeroconf.

Example of direct-attached Sonoff Zigbee dongle USB discovery in Home Assistant which works similar from an end-users point-of-view which the exception that it will show socat socket and mDNS address instead of a local serial device path and USB-ID for the adapter:

[s-hadinger]

Sonoff was kind to make it easy to solder a header.

However a standard header is slightly too long, so it does not fit anymore. I will have to cut them a little

Flashing Tasmota32 went smoothly, here is the detected configuration.

Note that the PSRAM is not detected, so that's one thing we'll need to figure out.

[sfromis]

Female header fits nicely.

[arendst]

Remove the black plastic now that the pins are soldered in. Cut the pins a millimeter shorter. Fixed.

[s-hadinger]

How to you remove safely the black plastic without breaking stuff?

[Jason2866]

or use 90° headers

[Hedda]

How to you remove safely the black plastic without breaking stuff?

Recommend "mini flush-cutter pliers" as a side cutter clipper tool commonly used by jewellery-makers and 3D-printer hobbyists, see:

https://www.google.com/search?q=%22mini+flush+cutter+pliers%22

[s-hadinger]

Good news, after guessing from the pictures:

• GPIO19: Zigbee TX
• GPIO23: Zigbee RX
• GPIO22: ??

Here are the logs:

rebooting ZNP device
ZbZNPSent 0xFF x 255
ZbZNPSent 410000
ut discarding byte 00
{"ZbZNPReceived":"418000020002070B"}
RESULT = {"ZbState":{"Status":1,"Message":"CCxxxx ZNP booted","RestartReason":"Power-up","MajorRel":2,"MinorRel":7}}
checking device configuration
ZbZNPSent 2102
{"ZbZNPReceived":"6102020002070B0000000000"}
RESULT = {"ZbState":{"Status":50,"MajorRel":2,"MinorRel":7,"MaintRel":11,"Revision":0}}
ZbZNPSent 2108600000
{"ZbZNPReceived":"61080200"}
RESULT = {"ZbState":{"Status":2,"Message":"Resetting configuration"}}
ZbZNPSent 21090300000103
{"ZbZNPReceived":"610900"}
ZbZNPSent 410000
ut discarding byte 00
{"ZbZNPReceived":"418000020002070B"}
ZbZNPSent 210983000002E022
{"ZbZNPReceived":"610900"}
ZbZNPSent 21092D000008E0E2E60BCCCCCCCC
{"ZbZNPReceived":"610900"}
ZbZNPSent 21098400000400080000
{"ZbZNPReceived":"610900"}
ZbZNPSent 21098700000100
{"ZbZNPReceived":"610900"}
ZbZNPSent 21096200001000009C9DE0E2E60B00009C9DE0E2E60B
{"ZbZNPReceived":"610900"}
ZbZNPSent 21096300000100
{"ZbZNPReceived":"610900"}
ZbZNPSent 210901010020FFFFFFFFFFFFFFFF5A6967426565416C6C69616E636530390000000000000000
{"ZbZNPReceived":"610902"}
ZbZNPSent 21098F00000101
{"ZbZNPReceived":"610900"}
ZbZNPSent 2107600001000100
{"ZbZNPReceived":"610709"}
ZbZNPSent 21096000000155
{"ZbZNPReceived":"610900"}
ZbZNPSent 2108620000
{"ZbZNPReceived":"61080200"}
RESULT = {"ZbState":{"Status":99,"Message":"Abort"}}
Abort
Stopping (99)

The pre-flashed version is ZNP 2.7.11. There is an issue while starting the MCU but probably a small glitch I need to investigate.

[Hedda]

The pre-flashed version is ZNP 2.7.11. There is an issue while starting the MCU but probably a small glitch I need to investigate.

If possible to get the CC2652 chip into BSL (Bootloader) mode suggest trying to flash latest "CC1352P2_CC2652P_launchpad_*.zip" from:

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

[s-hadinger]

The error is returned when trying to check the pre-configured key. I removed this optional check.

TADA.

ZIG: rebooting ZNP device
ZIG: ZbZNPSent 0xFF x 255
ZIG: ZbZNPSent 410000
ZbInput discarding byte 00
ZIG: {"ZbZNPReceived":"418000020002070B"}
RSL: RESULT = {"ZbState":{"Status":1,"Message":"CCxxxx ZNP booted","RestartReason":"Power-up","MajorRel":2,"MinorRel":7}}
ZIG: checking device configuration
ZIG: ZbZNPSent 2102
ZIG: {"ZbZNPReceived":"6102020002070B0000000000"}
RSL: RESULT = {"ZbState":{"Status":50,"MajorRel":2,"MinorRel":7,"MaintRel":11,"Revision":0}}
ZIG: ZbZNPSent 2108600000
ZIG: {"ZbZNPReceived":"6108000155"}
ZIG: ZbZNPSent 2108870000
ZIG: {"ZbZNPReceived":"6108000100"}
ZIG: ZbZNPSent 2108830000
ZIG: {"ZbZNPReceived":"61080002E022"}
ZIG: ZbZNPSent 21082D0000
ZIG: {"ZbZNPReceived":"61080008E0E2E60BCCCCCCCC"}
ZIG: ZbZNPSent 2108840000
ZIG: {"ZbZNPReceived":"6108000400080000"}
ZIG: ZbZNPSent 2108630000
ZIG: {"ZbZNPReceived":"6108000100"}
RSL: RESULT = {"ZbState":{"Status":3,"Message":"Configured, starting coordinator"}}
ZIG: ZbZNPSent 2F080100080000
ZIG: {"ZbZNPReceived":"6F0800"}
ZIG: ZbZNPSent 2F080000080000
ZIG: {"ZbZNPReceived":"6F0800"}
ZIG: ZbZNPSent 2F0504
ZIG: {"ZbZNPReceived":"6F0500"}
ZIG: {"ZbZNPReceived":"4F80010204"}
ZIG: {"ZbZNPReceived":"45C008"}
ZIG: {"ZbZNPReceived":"45C009"}
RSL: RESULT = {"ZbState":{"Status":40,"NewState":9,"Message":"Started as coordinator"}}
ZIG: ZbZNPSent 2700
ZIG: {"ZbZNPReceived":"4F80000200"}
ZIG: {"ZbZNPReceived":"670000E484B626004B12000000070900"}
RSL: RESULT = {"ZbState":{"Status":51,"IEEEAddr":"0x00124B0026B684E4","ShortAddr":"0x0000","DeviceType":7,"DeviceState":9,"NumAssocDevices":0}}
ZIG: ZbZNPSent 250200000000
ZIG: {"ZbZNPReceived":"650200"}
ZIG: {"ZbZNPReceived":"4582000000000000408F000050A000012CA00000"}
ZIG: ZbZNPSent 250500000000
ZIG: {"ZbZNPReceived":"650500"}
ZIG: {"ZbZNPReceived":"4585000000000000"}
ZIG: ZbZNPSent 2400010401050000000000
ZIG: {"ZbZNPReceived":"640000"}
ZIG: ZbZNPSent 24000B0401050000000000
WIF: Checking connection...
ZIG: {"ZbZNPReceived":"640000"}
ZIG: ZbZNPSent 21098400000400080000
ZIG: {"ZbZNPReceived":"610900"}
ZIG: ZbZNPSent 250500000000
ZIG: {"ZbZNPReceived":"650500"}
ZIG: {"ZbZNPReceived":"45850000000000020B01"}
ZIG: ZbZNPSent 25360200000000
ZIG: {"ZbZNPReceived":"653600"}
ZIG: {"ZbZNPReceived":"45B6000000"}
RSL: RESULT = {"ZbState":{"Status":0,"Message":"Started"}}
ZIG: Zigbee started
ZIG: No Zigbee device information
ZIG: No Zigbee device data

[notenoughtech]

If you heat up the pins a little, plastic slides out before the solder melts. Ive done this before on accident :D Mat Zolnierczyk Maker, Robotics Engineer Owner | NotEnoughTech ***@***.*** notenoughtech.com Teesside, North Yorkshire, UK [image: facebook] <https://www.facebook.com/NotEnoughTECH/> [image: twitter] <https://twitter.com/NotEnoughTECH> [image: linkedin] <https://www.linkedin.com/in/mat-zolnierczyk/> [image: instagram] <https://www.instagram.com/notenoughtech/>

…

On Tue, May 17, 2022 at 9:53 AM s-hadinger ***@***.***> wrote: How to you remove safely the black plastic without breaking stuff? — Reply to this email directly, view it on GitHub <#14419 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKDRL247DKG735ZEQX3TSDTVKNNCFANCNFSM5L37PILQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[s-hadinger]

Thanks

[s-hadinger]

Trying to pair a device failed, so I guess that the pre-configured key (aka Well Know Key) is not pre-provisioned. Still some work to do.

[s-hadinger]

Anyways, I will stop for now. The rest will require a zigbee sniffer

[s-hadinger]

One last thing, GPIO22 seems to be connected to the Zigbee MCU, but driving it either LOW or HIGH makes the connection to the MCU fail. Only when leaving unconfigured can I connect to Zigbee MCU. Strange.

[Hedda]

Could that GPIO22 in LOW or HIGH maybe be what puts the CC2652 into BSL (Bootloader) mode making it ready for flashing? That is, the pin to trigger the BSL which enable Bootloader mode?

[s-hadinger]

Yes it looks indeed like driving it LOW makes the MCU enter an alternative mode. However I have no clue what would be the update protocol on this bootloader. Any ider?

[Jason2866]

Maybe this helps https://github.com/JelmerT/cc2538-bsl

[s-hadinger]

Found an official doc https://www.ti.com/lit/an/swra466d/swra466d.pdf

[Hedda]

FYI, Electrorama also got a short technical summary about how the BSL "backdoor" bootloader trigger pin is invoked:

https://electrolama.com/radio-docs/bsl/

While that cc2538-bsl by JelmerT is overkill for an integrated implementation it should indeed allow you to flash the application firmware on the CC2652 as long as can first trigger the BSL pin to enable Bootloader mode, as then you should be able to set up a ser2net style serial stream server to access it remotely to allow flashing via serial:

https://github.com/JelmerT/cc2538-bsl/blob/master/README.md#cc26xx-and-cc13xx

Note! If accidentally flash the wrong firmware image onto the CC2652 or manage to corrupt the Bootloader then you will brick it and in order to unbrick it you will need to flash it via a cJTAG (TMS and TCK pins) compatible external debugger adapter like either "CC-DEVPACK-DEBUG" or "XDS110" from Texas Instruments, which Electrorama also got a nice summary about unbricking with c/JTAG flashing here:

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

CC-DEVPACK-DEBUG is available from most common electronics distributors and is not very expensive at around $15 (USD).

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

https://www.google.com/search?q=%22CC-DEVPACK-DEBUG%22&tbm=shop

TI's XDS110 debug probe is much more expensive but there are cheaper Chinese clones of it available.

[s-hadinger]

Good news. The local flasher for CC2652 is now working.

Install the required files

You need at least 500KB of free space in the Zigbee Pro filesystem. If the flash space is too small, install Partition_Wizard.tapp, reboot and use it to increase the filesystem. Warning: this will erase the content of the filesystem.

https://github.com/arendst/Tasmota/blob/development/tasmota/berry/modules/Partition_Wizard.tapp
(always click on Download and don't use "Save as..." or you will get HTML instead)

You need to download and copy to filesystem the following files:

• cc2652_flasher.be from https://github.com/arendst/Tasmota/blob/development/tasmota/berry/zigbee/cc2652_flasher.be
• intelhex.be from https://github.com/arendst/Tasmota/blob/development/tasmota/berry/zigbee/intelhex.be
• sonoff_zb_pro_flasher.be from https://github.com/arendst/Tasmota/blob/development/tasmota/berry/zigbee/sonoff_zb_pro_flasher.be
• SonoffZBPro_coord_20220219.hex from https://github.com/arendst/Tasmota/blob/development/tools/fw_SonoffZigbeeBridgePro_cc2652/SonoffZBPro_coord_20220219.hex

Make sure you are using the following template:

backlog Template {"NAME":"Sonoff Zigbee Pro","GPIO":[0,0,576,0,480,0,0,0,0,1,1,5792,0,0,0,3552,0,320,5793,3584,0,640,608,32,0,0,0,0,0,1,0,0,0,0,0,0],"FLAG":0,"BASE":1}; Module 0

(optional) Backup the original firmware

You can keep a backup of your original CC2652 firmware. I'm not sure it's useful except if you need to send back a device under warranty.

Go to the Berry console and type:

import sonoff_zb_pro_flasher as cc
cc.dump_to_file("SonoffZBPro_dump.bin")

The dump process takes 3 minutes during which Tasmota is unresponsive. Wait for 3 minutes and connect again to the Tasmota Web UI. If you check your logs, you should see something similar to:

18:08:04.202 FLH: cc2652_flasher rx=23 tx=19 rst=15 bsl=22
18:08:04.208 FLH: Dump started (takes 3 minutes during which Tasmota is unresponsive)
18:10:56.727 FLH: Dump completed

The filesystem now contains a file SonoffZBPro_dump.bin of size 360448 bytes

Restart Tasmota.

Flashing the Koenkk firmware ZNP 2.7.11 (recommended)

Go to the Berry console and type:

import sonoff_zb_pro_flasher as cc
cc.load("SonoffZBPro_coord_20220219.hex")
cc.check()

This first step checks that the firmware is valid and that the BSL GPIO is set to DIO_8. The firmware is not touched. After 10 seconds you should see:

18:32:05.964 FLH: Starting verification of HEX file
18:32:15.190 FLH: Verification of HEX file OK

The firmware is valid and ready to flash.

cc.flash()

The flashing process takes 5 minutes during which Tasmota is unresponsive. Do not unplug nor restart Tasmota during 5 minutes (if this happens the CC2652 will not be bricked but you will need to flash again).

After 5 minutes, the Tasmota logs should show:

18:32:20.208 FLH: cc2652_flasher rx=23 tx=19 rst=15 bsl=22
18:32:20.228 FLH: Flashing started (takes 5 minutes during which Tasmota is unresponsive)
18:36:38.542 FLH: Flashing completed: OK
18:36:38.652 FLH: Flash crc32 0x000000 - 0x2FFFF = bytes('1598929A')

Restart Tasmota, Zigbee will start normally after 20 seconds and show Zigbee: ZNP v2.7.1.20220219

[s-hadinger]

@digiblur @darkxst I'm happy to have your feedback about the flashing method above. If ok, I will create a dedicated page in the Tasmota doc site.

[sfromis]

Nice.

Here's a oneliner for fetching the Partition Wizard tapp file directly from the Berry console:

var wc=webclient() wc.begin('https://raw.githubusercontent.com/arendst/Tasmota/development/tasmota/berry/modules/Partition_Wizard.tapp') var wstatus=wc.GET() if wstatus==200 print(wstatus, wc.write_file('Partition_Wizard.tapp')) wc.close() else raise 'connection_error', 'status: '..str(wstatus) end

Same method works with other files too, of course. You just have to avoid the redirect normally handled by the browser.

[sfromis]

{"ZbState":{"Status":0,"Message":"Started"}}

ZNP update procedure worked for me without issues. One detail could be changed to make the process reassuring to users, print the messages warning about unresponsive Tasmota in the Berry console when pasting the statements, and maybe have a short delay if that's needed to have it appear. In principle, the procedure could be automated, but when restarts are needed during the procedure, that would likely be too much work for modest benefit.

Of course, the suggested fs minimum of 500KB does not cut it to also take a backup of old firmware, if all the needed files are already uploaded.

[notenoughtech]

Hey guys, how do I use the Partition_Wizard.tapp? I'm a bit confused about this?
Also thank you for great work on this

[sfromis]

You load it into the file system, and restart Tasmota. This will cause .tapp files to run at boot time, and install themselves, in this case into the "Consoles" menu.

[notenoughtech]

Not having much luck, the Free size after reboot is still not sufficient for all files:

loading .tapp file and reboot didn't change the amount of free space for me

[sfromis]

You also need to run the Partition Wizard to resize the partitions, to get a bigger file system. Recommended to have 2048KB for the app0 partition, meaning 1152KB for the file system. This is after changing to the "safeboot" scheme first time you run the Partition Wizard.

[notenoughtech]

Ok that did the trick, thanks!

[notenoughtech]

One more error to deal with:

suggestions/explanations?

[sfromis]

Based on current files (from 3 hours ago), I verified that the nspanel and zbbrdgpro binaries are exactly the same. Would have surprised me if not....

[notenoughtech]

I fillmed everything now, so it's time to make the edit. If this is ok, then I will ref zbbrdgpro name in my guide as I think this is how it will be named moving forward?

[s-hadinger]

Yes please

[Mkloppie]

May i ask what to solution was for the issue in the screenshot i have the same error when trying to flash. Im using the webpage guide from @notenoughtech

[s-hadinger]

Please open a new discussion. This one is already crowded. And provide details about what you tried already

[notenoughtech]

Alright, the guide based on the @s-hadinger post is now completed and available to the wider public. Again, thank you guys for your hard work!
https://notenoughtech.com/home-automation/tasmota-on-sonoff-zb-bridge-pro/

[s-hadinger]

This is awesome. Thanks a lot !

I hope I can make it a little easier for downloading the required files (a magic Berry script like @sfromis one), and provide some progress indicator. But still not 100% sure I have a good solution for progress indicator.

[sfromis]

Great. A couple of "minor" comments.

While you may have luck with that red "FTDI" USB/serial adapter, it is a well-known troublemaker as the rather low ability to deliver 3.3V power is borderline for reliable flashing (especially with ESP32), and occasionally we have users unable to flash until they get a better one, like the "golden CH340G" recommended on our "Getting Started" guide; ~150 mA is a lot better than ~50 mA for both the adapter and the device to be flashed. And it is often cheaper than the red bastard :-)

Typo alert: Partition_Wizzard.tapp

While you have a preference for Zigbee2MQTT, getting Tasmota on the Sonoff Zigbee Pro should allow you to connect this device to Z2M, using the ser2net support in both.

[notenoughtech]

@sfromis Updated the typo, and added 2nd FTD choice to both. Thanks. Can't say I ever had issues with my FTD and I flashed loads of different devices with it. I guess YMWV

[notenoughtech]

The code and the file size was good enough for the .tapp if you are asking me. It's not worth the effort as you are doing it once or twice in the device lifetime but I won't question your life choices 😂😂

…

On Fri, 27 May 2022, 08:38 s-hadinger, ***@***.***> wrote: This is awesome. Thanks a lot ! I hope I can make it a little easier for downloading the required files (a magic Berry script like @sfromis <https://github.com/sfromis> one), and provide some progress indicator. But still not 100% sure I have a good solution for progress indicator. — Reply to this email directly, view it on GitHub <#14419 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKDRL2Z4ORVKALUN6W3BJ7LVMB3YRANCNFSM5L37PILQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Jason2866]

@s-hadinger as suggested the partition scheme is changed for the tasmota32-zbbrdgpro.bin (and will available with next commit for Tasmota). The Filesystem is now 1344KB. So no need for resizing anymore.

[notenoughtech]

@Jason2866 stop making my tuts obsolete in first 24h haha! I will make amends
@s-hadinger - "told you so!" -:)

[Jason2866]

@Jason2866 stop making my tuts obsolete in first 24h haha! I will make amends @s-hadinger - "told you so!" -:)

@notenoughtech You will probably need more changes to the tutorial soonish. The needed files for flashing will be in the Tasmota Filesystem, right after flashing :-) No download needed.

[Hedda]

CC2652 NVRAM backup also takes some space if implemented, which would be best as it is generally a good idea to backup NVRAM before upgrade firmware and then restore that after firmware has been updated as sometimes a firmware upgrade will wipe some things which is any annoying if it happens as may require repairing all Zigbee devices again

[s-hadinger]

I looked at how zigpy is handling saving of NVRAM. Actually they do it from the ZNP interface, and it does not require BSL mode. So it should be possible to do this with Berry scripting.

[notenoughtech]

It's a good thing I mentioned in the video to check the article for the most up to date version of the guide haha I was working till 1am last night to have it out and you will all make it out of date by the 1am tomorrow 😉

…

On Fri, 27 May 2022, 10:24 Jason2866, ***@***.***> wrote: @Jason2866 <https://github.com/Jason2866> stop making my tuts obsolete in first 24h haha! I will make amends @s-hadinger <https://github.com/s-hadinger> - "told you so!" -:) You will probably need more changes to the tutorial soonish. The needed files for flashing will be in the Tasmota Filesystem, right after flashing :-) No download needed. — Reply to this email directly, view it on GitHub <#14419 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKDRL22ZWHYTNZUXKF4TZQ3VMCIFZANCNFSM5L37PILQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[notenoughtech]

Added that info too. Thanks I didnt know about that

[s-hadinger]

At least esptool should work on factory files too, right?

Anyways TasmotaWebInstaller makes it so easy!

[sfromis]

Yes, for other devices, I've used .factory files with esptool.py

[darkxst]

I flashed the factory nspanel build onto one
fine with esptool.py also

[Jason2866]

esptool.py does always work. All tools we provide are based on esptool.py (or code parts from).

[s-hadinger]

@Hedda I have tried the router firmware and it works with the same tweak to be able to enable BSL. The router tries to pair at boot, however there is no button to reset the router to factory setting. I will try to recompile it with DIO_8 set as BTN1

[s-hadinger]

Here is the flashed router firmware to be used on Sonoff ZBBridge Pro
https://github.com/arendst/Tasmota/blob/development/tools/fw_SonoffZigbeeBridgePro_router_only_cc2652/SonoffZBPro_router_20220125.hex

[animal6496]

OK my router works for now but from the comment @s-hadinger that I missed (as I was flashing the hardware) I probably won’t be able to update the firmware easily anymore. I updated what I did to avoid others are following the same dead end route. Thanks @s-hadinger.

[roburb]

Thanks for great work.
I am newbie and I would like rum my Zigbee Bridge Pro as a router.
Could someone make for newbie more detailed HowTo please?
Thank you all

[a24me]

Great work all of you!

@ptvoinfo
Nice work. Would be nice to add a new .ini file for the ZBBP device, as you did for the stick.

@animal6496,
After following your above instructions and commented out the code for the checks in file "sonoff_zb_pro_flasher_new.be" as follows

#################################################################################
# Flash the firmware to the device
#
#################################################################################
def flash()
# if !self.file_checked
# print("FLH: firmware not checked, usecc.check()")
# raise "flash_error", "firmware not checked"
# end
# if !self.file_validated
# print("FLH: firmware not validated, usecc.check()")
# raise "flash_error", "firmware not validated"
# end

the flush fails with the following errors:

Case A:
use of cc.check()

14:04:41.062 FLH: Starting verification of HEX file
14:05:01.045 BRY: Exception> value_error - invalid checksum
14:05:01.047 stack traceback:'
14:05:01.050 <unknown source>: in function parse
14:05:01.053 <unknown source>: in function check
14:05:01.056 <unknown source>: in function main

Case B:
without using cc.check()

13:11:08.893 FLH: Flashing started (takes 5 minutes during which Tasmota is unresponsive)
13:16:28.424 BRY: Exception> value_error - invalid checksum
13:16:28.427 stack traceback:
13:16:28.430 <unknown source>: in function flash
13:16:28.432 <unknown source>: in function main

It seems that in both cases the failure is the same: <unknown source>
Thus, I suppose that I am doing something in the wrong way and need your and the community's valuable support to do it in the correct one.

Could you instruct the below and anything else needed to correctly perform the flashing?
a. The template to be used in Tasmota "Configure Other"
b. The "sonoff_zb_pro_flasher_new.be" file
c. The Berry script for the flashing

Many thanks in advance.

[s-hadinger]

Please don't remove code that is explicitly there to avoid bricking the device

I also suggest to open a new topic, this discussion is off topic compared to the original topic

[Hedda]

@mercenaruss Nice, however, please respect that this specific discussion forum is really only for Tasmota, though if narrow the discussion to only be about the firmware for the CC2652P Zigbee module and pinouts then OK to discuss that part here, but for the more off-topic ESPHome specific stuff not related to Tasmota you might want instead to post to either the Home Assistant community forum here -> https://community.home-assistant.io/t/itead-sonoff-zigbee-bridge-pro-zbbridge-p-new-cc2652p-and-esp32-based-zigbee-gateway-to-wifi-bridge/378924/ or to this ESPHome feature-requests discussion -> esphome/feature-requests#688

@mercenaruss also note that needs to be clear that users should for now not flash unmodified CC2652P images from Koenkk which the community nornmally uses as the CC2652P Zigbee module in this ZBBridge-P does not use the standard pins for BSL so flashing an unmodified firmware will mean that will not be able to flash it again via BSL and will instead need to use a cJTAG debug adapter.

[icvdok]

hi, I'm just installed Tasmota on my Sonoff ZB bridge Pro (many thanks to everybody!). I'm not an expert , sorry in advance if my question sound stupid. I'm and HA user, there is a wa to configure it in a ZHA mode instead of Z2M?

[sfromis]

I'm assuming that you mean instead of Z2T. Configuring for Z2M would be the same as configuring for ZHA. Also I'm assuming that ZHA even supports the ZNP firmware instead of EZSP.

I'm not using ZHA, and have tried nothing there, but the basics should be the same as for the older ESP8266-based "non-pro" ZbBridge; go to the section "For Home Assistant (ZHA)". While the ESP8266-based template there will not work for ESP32, the change is to the two serial pins, which instead of configuring as "Zigbee Tx/Rx" should be "TCP Tx/Rx". Other than that, I'd expect the same setup steps to work, if you select radio type "TI_CC" instead of "EZSP".

[Hedda]

ZHA support this (Texas Instruments ZNP) and all other type of Zigbee Coordinator adapters that Zigbee2MQTT suppors (as well as more). The configuration on the Tasmota side to act as as serial proxy server will be exactly the same for ZHA and Zigbee2MQTT (and also the same for other third-party Zigbee software). For configuration on the ZHA of network attached Zigbee Coordinator radios see https://www.home-assistant.io/integrations/zha#zigate-or-sonoff-zbbridge-devices

[icvdok]

Thanks sfromis, you put me in the right direction. What I did:

• Change the template GPIO 19 and 23 from Zigbee to TCP (TX/RX).
• Started the server on port 8888 run
  backlog rule1 on system#boot do TCPStart 8888 endon ; rule1 1 ; template {"NAME":"Sonoff Zigbee Pro","GPIO":[0,0,576,0,480,0,0,0,0,1,1,5792,0,0,0,5472,0,320,5793,5504,0,640,608,32,0,0,0,0,0,1,0,0,0,0,0,0],"FLAG":0,"BASE":1} ; module
• On HA I've configured the ZHA integration using the "Texas Instruments radio options"

I've registered ad temp sensor and it'seams to work. :-)

[sfromis]

Great that you got it up and running. To fully work, your backlog command should end with module 0 instead of just module, as the latter will only make Tasmota print the current module selection, not change it to activate the template.

[icvdok]

OK, thanks, new command added:
backlog rule1 on system#boot do TCPStart 8888 endon ; rule1 1 ; template {"NAME":"Sonoff Zigbee Pro","GPIO":[0,0,576,0,480,0,0,0,0,1,1,5792,0,0,0,5472,0,320,5793,5504,0,640,608,32,0,0,0,0,0,1,0,0,0,0,0,0],"FLAG":0,"BASE":1} ; module 0
Would make sense to rename the template in something more related to ZHA but this is only cosmetics :-). Again many thanks for the support.

[sfromis]

You could submit the ZHA guidance and way of doing it to the template for the "pro" bridge. All those templates have a "edit" link for you to click on.

[rafaelnfernandes]

Guys, can you please point out what is the current BIN file to use? It seems like the NS Panel and the "zigbeePro" are no longer available on the repository.

I flashed mine with the tasmota32-zigbeebridge.bin, it boots, but is unstable (going back to the "set your wifi" page...

[sfromis]

The recommendation is to use the Tasmota web installer, and select development "Tasmota32 Sonoff-ZigbeeBridgePro". This will select tasmota32-zbbrdgpro.factory.bin. You can also use that binary for esptool.py, if you prefer.

To upgrade after having flashed another Tasmota binary (not really recommended), you could use tasmota32-zbbrdgpro.bin from the same place, or from the OTA site http://ota.tasmota.com/tasmota32/tasmota32-zbbrdgpro.bin

It is still recommended to not do such an upgrade, but to do the full install from scratch, as this will give you a configured file system with the relevant files for also flashing the CC2652.

As the support is fresh, zbbrdgpro has not gotten to the release binaries yet.

[umairyounus]

Thanks everyone for the great work, has anyone been able to connect it with Zigbee2Mqtt?

[umairyounus]

strangely it's started working after 2 days.

[surfrock66]

I'm curious to know more about your setup. I already had mosquitto set up on home assistant. I did the following:

1. Flashed it to tasmota and updated the firmware with this guide: https://notenoughtech.com/home-automation/tasmota-on-sonoff-zb-bridge-pro/#flash
2. I ran the command you indicated:
   backlog rule1 on system#boot do TCPStart 8888 endon ; rule1 1 ; template {"NAME":"Sonoff Zigbee Pro","GPIO":[0,0,576,0,480,0,0,0,0,1,1,5792,0,0,0,5472,0,320,5793,5504,0,640,608,32,0,0,0,0,0,1,0,0,0,0,0,0],"FLAG":0,"BASE":1} ; module 0
3. I installed the Zigbee2MQTT repo and installed the addon in Home Assistant
4. In the Z2M configuration, I added the following:

port: tcp://10.5.9.161:8888
adapter: zstack

I do see this message in my tasmota console:
17:03:17.585 TCP: Got connection from 10.2.2.71
I also see this message in my mosquitto log:
2022-09-29 09:06:18: New client connected from 172.30.33.4:53730 as mqttjs_1b181f4b (p2, c1, k60, u'addons').
I can load up my Z2M web interface. If I click "Permit Join (All Devices)" I get this in the logs of the addon:

info 2022-09-29 09:37:11MQTT publish: topic 'zigbee2mqtt/bridge/response/permit_join', payload '{"data":{"time":254,"value":true},"status":"ok","transaction":"ch7z1-3"}'

But nothing shows up in the tasmota console, and my devices don't pair. Are there an additional step I'm missing here?

[sfromis]

When you config for ser2net access, you give that system (Z2M or whatever) total control over the Zigbee chip, with Tasmota merely providing the tunnel. Expect nothing in the Tasmota console, Tasmota is just not involved in Zigbee traffic. What happens with your pairing attempt is a matter between the CC2652 firmware and Z2M.

[surfrock66]

Hmm ok, that makes sense; that makes me think I should see something in the Z2M logs when attempting to pair, I don't get any messages at all. I'm wondering where else I should debug?

[surfrock66]

I did a battery pull from my sensor, it seems that was the problem. Thanks so much!

[notenoughtech]

Sadly, my old Sonoff contact left, and new one let me down so I won't have the unit for another week or so before I can share my hands on with the Pro version. Anyone has questions then tag me and may include some of these in testing Mat Zolnierczyk Maker, Robotics Engineer Owner | NotEnoughTech ***@***.*** notenoughtech.com Teesside, North Yorkshire, UK [image: facebook] <https://www.facebook.com/NotEnoughTECH/> [image: twitter] <https://twitter.com/NotEnoughTECH> [image: linkedin] <https://www.linkedin.com/in/mat-zolnierczyk/> [image: instagram] <https://www.instagram.com/notenoughtech/>

…

On Thu, May 5, 2022 at 1:05 PM Hedda ***@***.***> wrote: is the ZB-GW03 based on exactly the same chips as the Zigbee Bridge Pro, but with the addition of an ethernet port? No, "ZB-GW03" and first "Itead Sonoff ZBBridge" only use exact same EFR32MG21 Zigbee module (which requires a signed firmware, see https://github.com/xsp1989/zigbeeFirmware/), while the new "Itead Sonoff ZBBridge Pro" a CC2652P Zigbee module from Texas Instruments: - "Itead Sonoff ZBBridge Pro" (a.k.a. "ZBBridge-P") ) is based on Texas Instruments CC26652P and ESP8266/8285 so it only offers Wi-Fi. - "ZB-GW03" is based on EFR32MG21 Zigbee module and ESP32 + 100Mb Ethernet (RJ-45 port). - "Itead Sonoff ZBBridge" (not the new "Pro" model) is based on EFR32MG21 and ESP8266/8285 so it only offers Wi-Fi. Note that while unlikely it is still unknown if the Texas Instruments CC2652P Zigbee module used in the new "Itead Sonoff ZBBridge Pro" also uses a signed firmware or not, it is more likely it uses unmodified firmware images from Koenkk -> https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin — Reply to this email directly, view it on GitHub <#14419 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKDRL24B6MKJWXJZPZ4HUYDVIO2RBANCNFSM5L37PILQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[s-hadinger]

Locking this conversation for now. For router mode please open a new discussion