Sonoff ZBBridge - Sonoff Zigbee Bridge from Itead

Tags: #<Tag:0x00007f738fbca868>

Itead has just launched Sonoff ZBBridge which is an inexpensive Sonoff Zigbee Bridge which is based on a similar design as their Sonoff RF Bridge

https://www.itead.cc/sonoff-zbbridge.html

According to the teardown and notes on notenoughtech.com and cnx-software.com it sounds as if it is based on Silicon Labs EFR32MG21 (EFR32 Mighty Gecko) for Zigbee 3.0 radio module support and ESP8266 (ESP8266EX) for WiFi and bridge/gateway/controller software

By default it uses the eWelink cloud but hopefully we will sooner or later see support for third-party ESP8266 firmware from projects like Tasmota for local control. (Tasmota’s Zigbee2Tasmota sub-project has for example support acting as a Zigbee to MQTT bridge via a Texas Instruments CC2530 radio module similar to Zigbee2MQTT)

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

From the images it also looks like Itead is even reusing the same injection moulds as for the Sonoff RF Bridge 433 housing/enclosure, and popular third-party ESP8266 firmware projects like ESPHome, Tasmota, and ESPurna already has support for that existing Sonoff RF Bridge, including RF control.

https://www.itead.cc/sonoff-rf-bridge-433.html

https://www.itead.cc/wiki/Sonoff_RF_Bridge_433

4 Likes

Lets hope Theo picks it up and integrates in Tasmota :slight_smile:

5 Likes

Tasmota developers has now released a ”tasmota-zbbridge” firmware which can be flashed onto the Sonoff ZBBridge so that that WiFi Zigbee bridge can then be used as a Zigbee coordinator adapter for ZHA in Home Assistant. @digiblur posted a step-by-step guide on his blog here:

4 Likes

Has anyone been using this with Home Assistant yet? I just got one to tinker with and eventually replace my Zigbee stick (hopefully) so I can place it in a different location than my NUC running Home Assistant. I got it flashed and working with a few devices. No issues so far. I know the hacked firmware is somewhat new, but curious on stability.

Mine is ordered, but has not arrived yet.

I have had it running for a few weeks (before the code to flash the zigbee fw was in tasmota) with my testing HA environment and it has been solid. Bellows is getting some refactoring now to support more versions of the ezsp versions, the v8 fw that tasmota is using should work at some point (it partially works I used it first before the other version was available but it had some issues)

I got it connected to Zha and a few devices (lightbulb and a contact sensor) and both worked. Is there still some part that doesn’t work right that I should be aware of?

zha/bellows support was originally written for v4 ezsp firmware I believe. so there my be some bugs currently (Have not seen any) with the version available that is recommended for the ZBBrdge as it is version 5 i think. the restructuring should bring bellows up to support the more/most recent ezsp fw versions…

Ok thanks for the information. I might hold off a few weeks in moving my Zigbee stuff over.

FYI, digiblurDIY has now posted updated video with simplified step-by-step guide for solderless flashing

I moved my Zigbee devices over about a week ago and so far so food. 16 devices total including basic stuff like a bunch of open/close sensors, a motion sensor, and a few plugs. Everything paired up fairly easily and has been running smoothly since. Did a few tests like restarting Home Assistant with the hub still online, restarted the hub with Home Assistant still online, etc. and everything always comes back as it should. I dont have anything like Xiaomi, Hue, or other non-Vanilla Zigbee devices connected, so I did not get to check these.

1 Like

Hi.
I’m having some instability with the ZigBee network using the Sonoff bridge with tasmota-zbbridge.bin](http://ota.tasmota.com/tasmota/release/tasmota-zbbridge.bin).
I have about 15 Zemismart switches here, the first 5 were very easy to pair, then a great instability started and the devices did not synchronize with the bridge and I don’t know why.
Here is the Logs

0xf38a:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=121 command_id=1>
[0xf38a:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0xf38a:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0xf38a:1:0x0019] No OTA image is available
[0x0edf:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=89 command_id=1>
[0x0edf:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0x0edf:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0x0edf:1:0x0019] No OTA image is available
Device 0x5479 (00:15:8d:00:04:62:6a:50) left the network

And here is another one

Here is the Log Device 0x5479 (SECRET) joined the network Skip initialization for existing device 00:15:8d:00:04:62:6a:50 Device 0x5479 (SECRET) joined the network Skip initialization for existing device [00:15]:8d:00:04:62:6a:50 [0x5479] Cancelling old group rescan [0x5479:zdo] ZDO request ZDOCmd.Device_annce: [0x5479, SECRET, 142] [0x5479:11:0x0004] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=173 command_id=2> [0x5479:11:0x0004] ZCL request 0x0002: [16, []] [0x5479:11:0x0004] No handler for cluster command 2 [0x5479:11:0x0004] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=175 command_id=2> [0x5479:zdo] ZDO request ZDOCmd.Node_Desc_req: [0x0000] [0x5479:zdo] Unsupported ZDO request:ZDOCmd.Node_Desc_req

@JorgeSPNeto Probably wrong forum here to report bugs that require debug logs, suggest post a new issue on https://github.com/home-assistant/core/pulls instead

I find this sonoff ZBridge very interesting for the price, any more feedback? Is it working great with HA?
What about other ZB devices? Is there a list of compatible devices?

The integration page contains an overview of the supported device types.

Under the hood it uses the zigpy library and its ZHA Device Handlers I believe and on GitHub you find a list of supported hardware:

Personally I paired already 4 Xiaomi Aqara contact sensors and one Aqara Cube.

Hope this helps.

There is no list of compatible devices because practically all devices that follow the Zigbee Home Automation specification devices should be compatible, (only exception today is alarm-panels as the ZHA component do not support those yet).

Assume that all devices should work and just test all your devices and hope for the best. If some device/devices does not work when you need to submit a bug-report with debug-logs.

The fact is that not all Zigbee devices follow the specifications in which cases workaround need to be implemented in code. Most high-level issues with Zigbee Home Automation compatibility can be fixed by writing a “quirk” (translating Python script) for the ZHA Device Handler library. Low-level issues have to be dealt with by implementing workarounds in the upstream zigpy library or the radio libraries for your Zigbee coordinator. Read:

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

ZHA exception and deviation handling

Zigbee devices that deviate from or do not fully conform to the standard specifications set by the Zigbee Alliance may require the development of custom ZHA Device Handlers (ZHA custom quirks handler implementation) to for all their functions to work properly with the ZHA integration in Home Assistant. These ZHA Device Handlers for Home Assistant can thus be used to parse custom messages to and from Zigbee devices.

The custom quirks implementations for zigpy implemented as ZHA Device Handlers for Home Assistant are a similar concept to that of Hub-connected Device Handlers for the SmartThings Classics platform as well as that of Zigbee-Shepherd Converters as used by Zigbee2mqtt, meaning they are each virtual representations of a physical device that expose additional functionality that is not provided out-of-the-box by the existing integration between these platforms.

1 Like

No that is not a list of supported hardware but a list of devices that need a “quirk” (because they do not follow the Zigbee specification). Most devices do however not need a “quirk” and just work fins without quirk-fixes via ZHA Device Handlers.

Thank you for the clarification. I assume that it at least works with these quirks since they are developed :blush: and these just happen to be the only ones we use.

Hopefully most things work out of the box and not too many quirks are needed. I’m glad we have the concept of the ZHA Device Handlers :+1:

Those just looking for general ideas on which Zigbee devices to buy I recommend all these huge lists:

https://zigbee.blakadder.com

https://www.zigbee2mqtt.io/information/supported_devices.html

https://github.com/ioBroker/ioBroker.zigbee/wiki/Supported-devices

https://phoscon.de/en/compatible

A few other implementations have similar concepts so it can also possible to port quirks from them, ex:

I moved my whole Zigbee network to one of these about 2 weeks ago and so far its run flawlessly. The hardest part was just re-pairing my devices, but since then, rock solid. I’ve accidentally unplugged it once and restarted Hass a million times. Everything comes back every time with no issues.

I used to have a Zigbee stick on my NUC running Home Assistant which was located down in my basement. The mesh network was OK, but not an ideal location for the main stick. Now that I’m on the ZBBridge, I moved it to the top of a closet upstairs (its wifi and it just needs micro USB power). Things seem snappier, but I dont know that I could prove that. If nothing else, the location change alone helped with too many hops on some devices.

1 Like