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)
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.
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:
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.
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ā¦
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.
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
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?
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:
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.
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 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
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.
and these just happen to be the only ones we use.