Adventures with Sonoff Zigbee Bridge

[s-hadinger]

Have you looked for this feature in other issues and in the docs?
Yes

Is your feature request related to a problem? Please describe.
This issue is opened to track progress for the support of Sonoff Zigbee Bridge.

Describe the solution you'd like
Z2T full support, like with CC2530.

Describe alternatives you've considered
CC2530

Additional context
This issue is only to report about progress and issues on the Sonoff Zigbee Bridge with Tasmota. It shall not contain any speculation like in #8197. All speculations should stay in #8197.

[s-hadinger]

The form factor is cool and similar to the Sonoff RF Bridge, in white.

Opening the box is super easy, remove the 4 rubber protections, and unswcrew.

As reported before, it is based on ESP8266EX so flashing Tasmota shouldn't be hard.

The good news is that pads are easily accessible. Sonoff made available lots of GPIOs, although it looks only RX/TX (GPIO1/3) are used to communicate with the Zigbee module.

There is a Z_RST pad which should be the RESET for the Zigbee module. This may be useful since GPIO1/3 are connected to the module. If we want to flash Tasmota without interference, I guess we should keep Z_RST low.

Useful pads: GPIO1, GPIO3, GPIO0, 3.3V, GND, Z_RST

We'll however need to wait a little more to analyze the protocol, my logic analyzer is arriving next week.

[s-hadinger]

First test with the Sonoff Zigbee Bridge in pairing mode, using another Z2T in device mode.

The Z2T device finds the Sonoff coordinator, connects to the network but then nothing happens, the device does not receive any more packets from the coordinator. It looks like Sonoff is restricting to its own devices, either filtering on IEEE Address, or waiting for a specific packet.

[s-hadinger]

Listening to TX at boot, 76800 bauds, 8N1, here is what is printed to Serial:
(3 sequences)

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 2592, room 16 
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8 
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4 
tail 0
chksum 0x22
csum 0x22

2nd boot version : 1.7(5d6f877)
SPI Speed : 40MHz
SPI Mode : DOUT
SPI Flash Size & Map: 16Mbit(1024KB+1024KB)
jump to run user1 @ 1000

OS SDK ver: 2.0.0(e271380) compiled @ Mar 30 2018 18:54:06

phy ver: 1055_1, pp ver: 10.7

rf cal sector: 507

Then the ESP pulls down Z_RST for 10ms.

The MCU sends two identical frame burst at 115299 bauds:

FE 0D 01 80 02 00 00 00 00 01 01 04 74

The first is sent at power-up, then the ESP resets the MCU and it sends it again.

First line is TX, second is RX, third is Z_RST

Edit: corrected baud rates.

[s-hadinger]

Here is the complete sequence at start (115200 bauds, 8N1):

• ESP pulls down Z_RST for 10ms
• MCU signals it has booted with FE 0D 01 80 02 00 00 00 00 01 01 04 74
• later, ESP sends FE 0A 01 01 02 00 00 00 43 B5 and FE 0C 01 04 02 00 00 00 43 00 03 B5
• MCU responds FE 0D 01 41 02 00 00 00 43 01 01 04 F6
• MCU also responds 8ms later FE 15 01 44 02 00 00 00 43 00 03 00 FA A4 66 FE FF 14 2E 84 6B

Edit: encoding looks similar to the one used by CC2530:

• FE signals a new frame
• second byte is the length of the frame in bytes
• last byte is a checksum over the frame
• the actual payload starts at the first byte and is of length n-3

[arendst]

So it starts with fe followed by the total byte count

[s-hadinger]

Aha, listening to the UART port of the MCU:

First sequence:

Reset info: 0x04 (PWR)
Extended Reset info: 0x0401 (HV )

52ms later:

init pass
Build Time Apr 29 2020 17:12:29

EEPROM init: 0x00

EMBER_NETWORK_UP 0x0000
[Z3Coord_callbacks.c:emberAfStackStatusCallback]
status = 0x90
Send Data:
FE 0D 01 80 02 00 00 00 00 01 01 04 74 

Enter password:

Then after the ESP pulls down MCU Reset, we see a similar sequence again:

Reset info: 0x03 (EXT)
Extended Reset info: 0x0301 (PIN)
init pass
Build Time Apr 29 2020 17:12:29
EEPROM init: 0x00
EMBER_NETWORK_UP 0x0000
[Z3Coord_callbacks.c:emberAfStackStatusCallback]
status = 0x90
Send Data:
FE 0D 01 80 02 00 00 00 00 01 01 04 74 

Enter password:

And 175ms later:

InitNetworkEventHandler
PANID = D136

[Hedda]

@s-hadinger It would be absolutely great if that SONOFF ZBBridge (SONOFF Zigbee Bridge) already has its firmware based on EmberZNet Zigbee Stack with their standard EZSP (EmberZNet Serial Protocol) serial protocol interface / API over UART bus on the EFR32 base MCU, as it now looks to have.

If it already has EmberZNet firmware with EZSP interfaces then will hopefully not need to worry about any firmware upgrade of in the first place and instead just focus on hacking its ESP8266 instead and maybe offering a serial server service (like ser2net or similar) to offer remote access the Zigbee module.

Otherwise, if the Zigbee SoC module used in the SONOFF ZBBridge (SONOFF Zigbee Bridge) is at all similar to other Silicon Labs EFR32 family modules, like the E180-ZG120B by Ebyte, then at least according to the Ebyte manual can flash the firmware on EFR32 module with J-Link over GPIO/JTAG.

• http://www.ebyte.com/en/product-view-news.aspx?id=842
  • http://www.ebyte.com/en/downpdf.aspx?id=842
  • http://www.ebyte.com/en/pdf-down.aspx?id=1618

JTAG

• 4-wire interface for programming and debugging, using the pins TCK, TMS, TDI, and TDO.

• https://www.silabs.com/documents/public/application-notes/an105.pdf

SWD (Serial Wire Debug)

• 2-pin serial wire debug interface for programming and debugging, using the pins SWCLK and SWDIO.

• https://www.silabs.com/documents/public/application-notes/an0062.pdf

In the Ebyte E180-ZG120B manual, the "burning program" sais that GPIO pins for J-Link interface is:

• VCC (Positive Supply Voltage)
• SWCLK (Clock Pin)
• SWDIO (SWD - Serial Wire Debug - IO)
• GND (Ground)

FYI, there's also a related discussion about flashing firmware on these type of EFR32 modules here:

• Added new Ember Outgoing Message Type. zigpy/bellows#24

If still are serious about flashing that firmware then checkout a Silicon Labs document called AN136

• https://silabs-prod.adobecqms.net/documents/public/application-notes/AN136-production-programming-options.pdf

Maybe it is possible to just use the Command-Line Interface (CLI) of Simplicity Commander as it supports using Serial Wire Debug (SWD) or Joint Test Action Group (JTAG) as the target interface?

• https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf

AN136 otherwise refers to other documents for many different methods, like SWD, JTAG, and C2:

• AN0062 https://www.silabs.com/documents/public/application-notes/an0062.pdf
• AN105 https://www.silabs.com/documents/public/application-notes/an105.pdf
• AN127 https://www.silabs.com/documents/public/application-notes/AN127.pdf

MarkDing who work at Silicon Labs summarized their Serial Wire Debug (SWD) in their forum here:

• https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2014/10/21/serial_wire_debugs-qKCT

The same @MarkDing also maintains a wiki about development with Silicon Labs IoT MCU SoCs:

• https://github.com/MarkDing/IoT-Developer-Boot-Camp/wiki
  • https://github.com/MarkDing/IoT-Developer-Boot-Camp/

[Hedda]

To all, by the way, here are a few related discussions specifically about hacking SONOFF ZBBridge:

• [REQUEST] Use zigpy & bellows with the new Sonoff ZBBridge (cheap Zigbee to WiFi Bridge/Gateway by Itead) zigpy/zigpy#385
• [REQUEST] ESPurna firmware on Sonoff ZBBridge (Sonoff Zigbee Bridge) xoseperez/espurna#2224
• [REQUEST] ESPHome support on Sonoff ZBBridge as a network-attached remote Zigbee Coordinator adapter (or Zigbee Router) for Home Assistant's ZHA integration and Zigbee2MQTT esphome/feature-requests#688
• Feature Request: Zigbee Support 1technophile/OpenMQTTGateway#205
• [REQUEST] ESPEasy firmware on Sonoff ZBBridge (Sonoff Zigbee Bridge) letscontrolit/ESPEasy#3021
• [REQUEST] Support for Silicon Labs EFR32 (Mighty Gecko family) based Zigbee radio adapters using EZSP serial protocols? Koenkk/zigbee-herdsman#168
• [REQUEST] Support for Silicon Labs EFR32 (Mighty Gecko family) based Zigbee radio adapters using newer EZSP serial protocol? zigpy/bellows#243

[s-hadinger]

More data:

When entering Pairing mode, MCU sends:

FE 0B 02 01 02 F9 FF 00 04 37 C1

MCU responds:

FE 0B 02 41 02 F9 FF 00 04 00 B6 

MCU logs:

Recv Data:

FE 0B 02 01 02 F9 FF 00 04 37 C1 
pJoin for 55 sec: 0x00
Open network: 0x00
Send Data:
FE 0B 02 41 02 F9 FF 00 04 00 B6 

Edit: sending a new Pairing mode request shows:

FE 0B 02 01 02 F9 FF 00 0B 37 CE 
pJoin for 55 sec: 0x00
Open network: 0x00
Send Data:
FE 0B 02 41 02 F9 FF 00 0B 00 B9 

It shows that the n-2 byte is actually a sequence number, probably so that the ESP knows which response correspond to which request.

[s-hadinger]

Aborting Pairing mode:

Recv Data:

FE 0B 02 01 02 F9 FF 00 03 00 F1 
pJoin for 0 sec: 0x00
Send Data:
FE 0B 02 41 02 F9 FF 00 03 00 B1 

[s-hadinger]

Finally, when trying to join the network from a Z2T device, the MCU logs the following but does not report to the ESP:

[Z3Coord_callbacks.c:emberAfTrustCenterJoinCallback]
add dev:NodeID=4351 mac:4B:CB:9D:19:00:4B:12:00ParentOfNewNode=0, status = 1 decision=0
Adding device to the queue
Adding to queue at index 0

It looks like Ember layer did accept the connection, but the app layer dropped it; probably filtering based on IEEE address.

[s-hadinger]

Connecting to the EFR32 with a JLink probe (SWD mode using SWDIO and SWCLK), it shows that the device is debug-locked but can be erased and should be possible to reflash with a custom firmware:

Or Sonoff is kind enough to give the unlock key?

[digiblur]

Excellent work so far! I see they have a new board revision listed on yours. I'll have to compare to see what changed.

[stevew817]

Or Sonoff is kind enough to give the unlock key?

According to that screenshot, there is no unlock key on the device, so Sonoff wouldn't be able to give you one either way :)

[Hedda]

Sounds as if don't need an unlock key to erase & flash firmware via JTAG interface or SWD interface:

• https://www.silabs.com/mcu/programming-options#programming
  • https://www.silabs.com/documents/public/application-notes/an958-mcu-stk-wstk-guide.pdf
    • https://www.silabs.com/documents/public/application-notes/an105.pdf
    • https://www.silabs.com/documents/public/application-notes/an0062.pdf

Simplicity Commander support CLI as the target for EFx32 but it is not open-source or for Arduino.

• https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2016/12/29/simplicity_commander-DqhR

"Simplicity Commander is a software package provided by Silicon Labs that provides a very powerful GUI and command-line utility for working with your EFR32 parts. With Simplicity Commander you can flash firmware (bootloaders and applications), update the WSTK firmware, reset locked parts and unlock debug access. It is the EFR32 version of the ISA3 Utilities."

Simplicity Commander GUI and CLI interfaces with software download for Linux, Mac, and Windows.

• https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf

Simplicity Studio also includes a simpler tool called "Flash Programmer" that allows the user to flash the device with a binary or hex file, supporting flashing to EFM8, EFM32, C8051, EZR32, and EFR32.

• https://www.silabs.com/products/development-tools/software/simplicity-studio

[Hedda]

Will you brick the EFR32 if erasing application firmware also erases the bootloader firmware?

That is if erasing the bootloader firmware is not optional, sounds strange if that is not optional?

If that is the case and EFR32 gets bricked then can you still unbrick it by flashing a new bootloader via the JTAG or SWD interface on EFR32 using just a Raspberry Pi / Arduino or will you need a purpose-built debugger for EFR32 or an official EFM32 Gecko Development Kit to unbrick it?

[Gamester17]

Or Sonoff is kind enough to give the unlock key?

ITead (Sonoff) as a company has benefited a lot from alternative firmware from the community in the past and there are today more aware of that fact so would not hurt for you to ask.

Suggest that you sent a mail to "Jerry Shi" <jerry.shi 'at' itead.cc> and "Stan Li" <stan.li 'at' itead.cc> and explain that you are an open-source developer from the Tasmota community that is looking into developing an alternative firmware for the Sonoff ZBBridge and are therefore wondering if they could share the key to disable the debug lock. Jerry Shi and Stan Li

I have no affiliations to ITead/Sonoff myself however in the past I have sent a few questions or suggestions to them and got relatively quick replies from Jerry Shi and Stan Li. I think that Jerry is in marketing at ITead so he has to pass on the technical questions to the developers, however, I know he helped the community in the past and since he is in marketing I assume he would especially helpful if it directly or indirectly helps ITead sell more products, which is something Tasmota surely does.

[stevew817]

Again, there is no secure boot key installed in the device, so there are no obstacles to mass-erasing and writing a new bootloader + application over SWD. The only thing you cannot do is reading out the current firmware.

Whether or not a new firmware can be flashed through the use of the factory-installed bootloader depends on how that bootloader is configured. If ITead's bootloader requires a signed and/or encrypted upgrade image, then those keys would be relevant in order to leverage the factory bootloader for upgrading over the UART interface, instead of having to go through JLink.

[Hedda]

Unlocking / disabling debug lock also erase all data to prevent reading or?

That is, does it also do a full erase of bootloader + application firmware?

That part is still unclear for me even after trying to interpret that from these:

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2016/11/04/unlock_a_brickedefr-GkC7

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/06/07/erasing_the_lockbit-WVQL

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2017/10/09/how_to_lock_or_disab-mb2d

https://silabs-prod.adobecqms.net/content/usergenerated/asi/cloud/content/siliconlabs/en/community/mcu/32-bit/knowledge-base/jcr:content/content/primary/blog/unlock_a_brickede-xkAm.social.$%7BstartIndex%7D.10.html

https://silabs-prod.adobecqms.net/content/usergenerated/asi/cloud/content/siliconlabs/en/community/mcu/32-bit/forum/jcr:content/content/primary/qna/bricked_efr32-1EjX.social.list-item.0.15.html

https://silabs-prod.adobecqms.net/content/usergenerated/asi/cloud/content/siliconlabs/en/community/mcu/32-bit/knowledge-base/jcr:content/content/primary/blog/debug_unlock_withj--QGXr.social.0.10.html

[stevew817]

@Hedda correct. Unlocking a locked device, or disabling a debug lock that has been set, will result in an erase of main flash and RAM.

Some devices in EFR32 Series 1 (e.g. EFR32MG12) have a separate flash area where a bootloader optionally can reside.
This is not the case for Series 2 (e.g. EFR32MG21 as used here), where a bootloader always resides at the start of main flash, and is thus erased together with the rest of it during an unauthorised unlock sequence.

[cyber-junkie9]

Make sure that all the pins have coresponding connections on both sides ok and try the OTA

just now tested.
ERX , ETX all are okay from EFR to ESP . tested VCC , GND too on EFR chip
Still same issue :/

btw my board has different ROHS certification logo , rest PCB looks same

ps - i am not able to find path of ERX , ETX on EFR chip so directly tested from breakout / test point instead of EFR chip
check marked area if it is possible to test path of this breakout point (ERX , ETX) to EFR chip

[MattWestb]

For the module pinot https://github.com/CoolKit-Technologies/DevDocs/blob/master/Zigbee/SM-011%E5%BA%94%E7%94%A8%E6%8C%87%E5%AF%BC%E4%B9%A6.md

[cyber-junkie9]

For the module pinot

thank you so much.
VCC and both GND are okay but not getting continuity signal on ERX/ ETX - PB01-TX , PB0O-RX. (connected before resistor too)
if someone got time can you please check it ?

[cjitariu]

@Tech-freak you need to test from the other side of the board too. You could have a breakout of the 2 sides. The connection for the EFR is on the other side goes to R11-R12

[MattWestb]

TX and RX is pad 2 and 3 on and then to R12 and R11the module and it should being PCB traces on the underside of the main PCB to the 2 red marked points and from there to the ESP.

Edit: R12 and R13

[cyber-junkie9]

you need to test from the other side of the board too.

not possible to check from back ig @cjitariu
there are different pads which are okay

@MattWestb
yes from pad 2 and 3 to R12 and R13 is okay but from there to 2 red marked area or ESP not getting any signal

by any chance if you have hub can you please check it ?

[MattWestb]

You can following them on the underside to the red marked points:
https://user-images.githubusercontent.com/49731213/83330646-d756c600-a290-11ea-8a0d-0396cb832cba.jpg to ERX and ETX and from there to the ESP

[MattWestb]

Most likely is its some micro cracking in the PCB between upper and under layer in the hole marked ERX and ETX.

[cyber-junkie9]

ERX and ETX and from there to the ESP

red (ERX.ETX) marked points(back side) to ESP is okay , not getting any signal on R12/R13 or pad 2/3

some micro cracking

if someone confirms continuity then i might try soldering jumper wire to R12/R13 from ERX/ETX

[MattWestb]

You can following the trace on the underside of the PCB.
Very likely you only need filling the holes with led after taking little protecting film / lack away or if like putting some thin copper wire thru the holes before soldering,

[cyber-junkie9]

Yes i got that but just need confirmation from someone so can do soldering stuff

[MattWestb]

I can soldering stuff.

IKEA E1743 hooked up for flashing and being sued as one Coordinator in ZHA and Tasmota Zigbee bridge and also for Zigbee sniffing with wireshark :-))
The pads is around the same spacing as the SM-011 module in Sonoff Zigbee Bridge.

[MattWestb]

If you is having one USB-Serial adapter you can soldering GND, RX and TX (and 3.3V if you like power the module from USB then flashing) and dont need modding the PCB.
You dont need doing flashing only seeing that the bootloader is reacting on "1" commands and sending C.
Look here for see how its looking in one terminal with the bootloader https://github.com/MattWestb/IKEA-TRADFRI-ICC-A-1-Module/tree/master/Flashing-MG#app-flashing App flashing:

[cyber-junkie9]

how its looking in one terminal with the bootloader

sir by any chance are you available on skype/discord ?

[digiblur]

They have all the same board version but some have a ROHS mention that were not present in first bathes

Noticed the one I flashed has the ROHS logo. No issues with it so far.

[flostingapplesauce]

Would OTA updating from Tasmota 8.5.1 to 9.2.0 be likely to cause any problems that anyone is aware of?

[bogorad]

Would OTA updating from Tasmota 8.5.1 to 9.2.0 be likely to cause any problems that anyone is aware of?

Did it on many devices, with no problems whatsoever.

[flostingapplesauce]

Thanks - do you mean many of these specific devices, though?

The brand new 9.2.0 has some real advantages, native HA integration being the loudest, but I put myself into the position of having no other Zigbee coordinator on hand, so I am treading lightly.

[bogorad]

Thanks - do you mean many of these specific devices, though?

Yes. However I misread your question - I've been using betas, 9.1.x.x - without problems. Will check 9.2 out now.

[flostingapplesauce]

Thanks mate, worked like a champ. 😇

[muebau]

Did somebody found a circuit diagram of this device?
I would like to use the HSPI. GPIO12 - GPIO15. The idea is to connect a CAN bus (MCP2515) to the SONOFF ZigBee bridge and build a Tasmota Zigbee NMEA2000 bridge.
This way ZigBee contact/temperatur/water/etc. sensors could be used to refit an old vessel with NMEA2000 and cheap sensors. It would be easy (kind of) for inexperienced users.

[s-hadinger]

Look here #8583 (comment)

GPIO12-GPIO15 are already used.

[muebau]

Oh thank you

[MattWestb]

The MCP2515 is having SIP interface :-(
If you was finding one with I2C you can soldering the 2 data/clock line on the EEPROM and share the I2C interface that should not being any problem then the EEPROM is not often used and they is on different addresses.

[muebau]

I guess as CAN is a relatively fast bus I2C is to slow. NMEA2000 would need 250 kbit/s and I doubt thats possible or stable with I2C

[MattWestb]

Its depends of the devices (hardware) and the (software) implanting of the drive in the hosts.
I is using one OLED display with in ESPHome with this setting and its updating very fast:

i2c:
   sda: GPIO4
   scl: GPIO5
   scan: false
   frequency: 3400000Hz

And Wikipedia is writing :

max speed : 5 Mbit/s | Corrected two graphs. This is the current standard.

[MattWestb]

Sorry its looks like wikipedia is having wrong but its more than enough for 250 kbit/s

https://www.i2c-bus.org/speed/

[crolaser]

i using many sonoff devices with tasmota but zigbee kill me after the flashing issue.i flashed zbbrige.bin file and all is ok .after flashing i see the device in ap mode like tosomota device and i access to them with 192.168.4.1 address and setup local wifi address.
then starts problems .device jumping every 3-4 second from IP address to AP mode (i see them now like ESP-E2C2F7).
It is impossible for any other step in flashing .I tray 3-4 time with flashing (tasmotizer and nodemcu ) but result is the same .Pleas help ?? thanks

[s-hadinger]

@crolaser
Wrong topic. Please reach out on Discord.