[REQUEST] Tasmota firmware on Sonoff ZBBridge (Sonoff Zigbee Bridge) #8197
Comments
|
Seconded! The actual name of this device is Sonoff BASICZBR3. |
|
Since Sonoff Zigbee Bridge uses a chip where no Open Source Router firmware variant exists, |
|
I would love to make it possible. I didn't know the protocol was documented and there was an exiting implementation (bellows). Let me try to grab one of those and see if it's possible or not. Ideally having Z-Stack running on the same chip would be easier, but not possible. Are you sure the Sonoff Zigbee Bridge uses EZSP protocol? |
No the name of this new Sonoff Smart Zigbee Bridge is "Sonoff ZBBridge" (Model: M0802070001). Sonoff "BASICZBR3" is just the Zigbee version if Sonoff BASIC BR3 Smart Switch. FYI, listed Zigbee based devices today on Itead website are;
|
What I am sure of is that the Zigbee radio module is EFR32MG21 (EFR32 Mighty Gecko) from Silicon Labs and that features a firmware that features an API via serial communication protocol that they call "EZSP" (short for "EmberZNet Serial Protocol") and that interface that seems to be well documented.
Not sure about the version of EZSP serial protocol but that is what EFR32 ("Wireless Gecko EFR32" series) uses by default for Zigbee. I would guess that Itead is using the latest EmberZNet SDK on their EFR32MG21 as it supports a Zigbee 3.0 stack. I don't know but should assume that the bellows library might be using an older version of the EZSP serial protocol interface as it lists devices that are using EmberZNet PRO ZigBee Protocol Stack on ETRX35x/EM35x Zigbee Modules (Silicon Labs Ember series which include ETRX351 and ETRX357). Hopefully it has not changed too much. bellows is at least very stable using it through zigpy with Home Assistant's ZHA component |
|
Ah sorry, my mistake. I'm not sure why you'd want Tasmota running on what is essentially a hub. Unless I'm misunderstanding, Tasmota is for controlling end point devices (such as BASICZBR3). Isn't this like asking for Tasmota for an Intel Nuc? If you want a more powerful opensource bridge zigbee2mqtt supports more powerful zigbee sticks than just CC253x now. |
|
A similar device is the Sonoff RF Bridge... which is a Tasmota supported device. Changing the Wi-Fi portion of the Zigbee bridge would likely expand the capabilities of the OEM device and add all of the Tasmota features (inter-device communications & control, rules, etc.). |
|
Based on the preview video from NotEnoughTech on youtube, it also seems locked to their zigbee devices and doesn't have third party support a la deconz or z2m. Opening it up would add an ideal open source router for cheap. |
|
I want to use Tasmota on Sonoff ZBBridge as a Zigbee to WiFi bridge/gateway similar to Zigbee2mqtt. Using Tasmota on Sonoff ZBBridge as a Zigbee bridge/gateway just like the Zigbee2Tasmota project: Again it is already possible today to use Tasmota as a Zigbee bridge via the Zigbee2Tasmota subproject by connecting it to a Texas Instruments CC2530 Zigbee module (instead of a sensor) to control Zigbee devices and act as a Zigbee 2 MQTT bridge (practically giving it the same function as Zigbee2mqtt): Sonoff ZBBridge is basically a complete prepackaged and very inexpensive hardware solution for that same function. Sonoff ZBBridge has an integrated ESP8266 (ESP8266EX) and a separate Zigbee module on the same board. The main difference is compared to the existing Zigbee2Tasmota project is that Sonoff ZBBridge does not use a TI CC2530 module (with a chip from Texas Instruments CC253x series with a Zigbee HA 1.2 stack) radio module but instead an EFR32MG21 (with a chip from Silicon Labs EFR32 series with a Zigbee 3.0 stack) radio module. The Zigbee stack on these chip modules has an API that can be controlled via serial communication but they do use different serial protocol. So this is really, in essence, a request to a Zigbee2Tasmota subproject to add support for the different serial protocol that Silicon Labs EFR32 series uses to control the Zigbee stack on it. zigpy organization has open-source Python libraries which could maybe be ported to achieve this? bellows is specifically a library that supports serial interface communication with Silicon Labs chips: zigpy-cc & zigpy-znp are libraries that supports serial communication with Texas Instruments chips: They also have libraries which support serial communication with XBee, ZiGate & deCONZ modules:
The zigpy library itself can abstract all these radio libraries for higher-level support in a unified way: Again, slightly related is it is also already possible to use Tasmota as an RF-bridge/gateway on the somewhat similar device models called "Sonoff RF Bridge" which let Tasmota act as an RF-bridge/gateway for Radio Frequency devices on the 315MHz and 433MHz bands. So these types Sonoff RF bridges devices have also already been 'hacked' to run Tasmota. |
That is not completely true. It is not specifically locked down to only support Sonoff Zigbee devices, however, of course, Itead will prioritize to good support for their own devices (just like manufacturers of other Zigbee bridges/hubs/gateways does). That is, Itead will not go out of their way to lock it down so that it only supports their own devices. Itead has already stated that this Zigbee bridge will also support third-party Zigbee devices as well. Sure that might mean that more and more devices get added with more and more future software upgrades, but that is also the case with any Zigbee bridge, including the existing Zigbee2Tasmota subproject, Zigbee2mqtt, and deCONZ software. It should also be noted that NotEnoughTech did his review on a very early preview version. |
Not sure what you mean or why you are so quick to shot down this idea. I don't really know much about either of these but I think you neither must have the full picture about both of these specific modules or how these are communicated with. Using these Silicon Labs chips should be the same scenario as using Texas Instruments chip with open source software like Tasmota. As I understand it from some quick research, there is no open-source router firmware for Texas Instruments chips either, instead, you flash them via a firmware which consists of binary blobs and config files. This is the same for the Silicon Labs chips. Why does Tasmota need the full firmware source code for either of these Zigbee chips just to control the module over their serial interface from Tasmota? ...to compare, Zigbee2mqtt for example recently added support ConBee/RaspBee radio modules and those do not even have an SDK, instead, they managed to add support through their serial interface because that is documented. Also, the ZHA integration for Home Assistant has now through the zigpy library support for multiple Zigbee modules from different manufacturers without any firmware source code as it achieves that through radio libraries which can each communicate with the different serial interface protocols supported those Zigbee modules. Please also note that the Zigbee chip is on its own separate module so Tasmota should not have to contain or replace the full Silicon Labs chip firmware(?). Hopefully, you might not ever have to reflash the firmware on the Silicon Labs chip(?). It might be enough to only replace the ESP8266 firmware with Tasmota and add support for communicating with the Silicon Labs chip over its serial interface(?). However, if it comes to that a new firmware is also needed on the Silicon Labs chip. The firmware is usually produced by using an SDK (which probably has example/sample code for Zigbee applications too), and, again as I understand it, this is normally the same for Texas Instruments chips and Silicon Labs chips. The SDK pack the binary blobs (which has Zigbee stack) and the config files (that to simplify as just text files with a configuration of how to use the stack). Then to communicate with these chips you use a UART or serial interface. Here is what is practically different when using the other manufacturer of Zigbee chips as all manufacturers use different serial protocols, however, both these manufacturers do a good job at documenting those protocols. Anyway, Silicon Labs has a good history of working with open-source software community. So I think it is way to early to say "there will be no support for Zigbee2Tasmota" unless you just say so on principle. Regardless you should never say never ;) |
|
@Hedda from TI the zigbee stack is free availiable. The zigbee stack from Silicon labs is NOT free available. All you said is not proven. You dont know if ITEAD uses EZSP protocol or maybe a variant |
|
@Jason2866 Yes, I mean; could be, maybe, is possible, ...but definitely not "there will be no support for Zigbee2Tasmota" unless someone like yourself shoots down the idea on pure principle before proven. |
ascillato2
added
the
feature request (devs?)
|
One workaround for Home Assistant users could be to simply present a Zigbee radio module as a remote adapter to Home Assistant's ZHA (their Zigbee Home Automation integration component)? You could use something like ser2net to allow ZHA to remote connect to it via serial over network, like: Then you need a radio library for zigpy that works with the EZSP protocol used by Silicon Labs EFR32 Hopefully, their bellows radio library should already be compatible or could be made to be if updated zigpy devs already do something similar to connect remotely with ESP8266 based "ZiGate Pack WiFi"
As proof-of-concept you could do this with a CC2530 remote to zigpy-cc from a ESP8266 using ser2net |
|
@Hedda why? There is no need for a workaround. Zigbee2Tasmota works fine |
|
@Jason2866 This is a request for Tasmota support on Sonoff ZBBridge, and no, Zigbee2Tasmota does not currently work fine with the Silicon Labs EFR32 based Zigbee radio module inside the Sonoff ZBBridge. For Tasmota to be able to utilize that Silicon Labs EFR32 based Zigbee radio module inside the Sonoff ZBBridge it would either need to implement a native library for the EZSP (EmberZNet Serial Protocol) serial protocol communication with that or as another idea to solve the end-user problem of using that that Silicon Labs EFR32 based Zigbee radio module inside the Sonoff ZBBridge it could as a workaround for a different type of serial server service to indirectly connect a remote Zigbee adapter by implementing some kind of serial port forwarding feature (like example ser2net) which could forward the serial port as a serial-port bridge/gateway to example the bellows library running on the same computer as Home Assistant with ZHA. Ex: ZHA component (Home Assistant) -> zigpy -> bellows -> Tasmota with ser2net on Sonoff ZBBridge Suggesting workarounds similar to the Ser2Net concept just to remotely share that Silicon Labs EFR32 based Zigbee radio module inside Sonoff ZBBridge to an external radio library like ex. bellows for zigpy: |
|
Almost any ESP8266 development board (like a NodeMCU or a Wemos D1 Mini) with a Silicon Labs EFR32MG based Zigbee module like the Ebyte E180-ZG120B would just about be about the equivalent to having a hacked Sonoff ZBBridge, so such a setup could be used as a development environment. E180-ZG120B (and the older E180-ZG120A) modules are sold on eBay and Aliexpress at low prices. Example: Ebyte also makes an inexpensive development board called "E180-ZG120B-TB" made for testing it.
This development is sold for less than $9 US-dollar on Aliexpress or about twice that on eBay UK:
Note! Ebyte is now making two EFR32MG12 based modules called E180-ZG120A and E180-ZG120B The downside to using such setup instead of Sonoff ZBBridge is that the E180-ZG120B module will likely not come preloaded with firmware so have to build EmberZNet PRO Zigbee Stack firmware with coordinator device type config and flash firmware to the E180-ZG120B module first. |
|
I know the Ebyte modules. This does not help anything, because we have no access to the |
Hedda
changed the title
Hedda
changed the title
|
If there is a will then there is a way. For those interested in a more friendly discussion about the same concept in an alternative firmware, including building EmberZNet firmware for Ember based devices (like Ebyte EFR32MG12 based modules or the Silabs chip inside the Sonoff ZBBridge), check out: and |
|
Thanks @Hedda |
|
FYI @SillyDay don't own a E180-ZG120B but has tried to build a firmware for it as per discussion here: SillyDay GitHub repo for EFR32 firmware: |
|
FYI, as per related request https://github.com/zigpy/zigpy/issues/405 I just learned that there is an existing ESP8266-based networked-attached Zigbee-adapter called "ZiGate Pack WiFi adapter" which has a new v2.0 firmware that archives the requested function of a UART-to-TCP/IP (for Serial-port to WiFi-bridge function) using "ESP-LINK from Jeelab" software, in addition, using ESP-LINK also adds mDNS zeroconf to allow automatic network discovery and configuration: Description of functions that using ESP-LINK will add to v2.0 firmware for ZiGate Pack WiFi adapter:
As I understand it, all ZiGate hardware look to be modular in design and the "ZiGate Pack WiFi adapter" is really just an optional ESP8266 based "dumb" UART-to-TCP/IP (for Serial-port to WiFi-bridge function) for the standard "ZiGate TTL adapter" that allows users to connect to it remotely using TCP/IP over your home LAN (Local Area Network) instead of plugging it directly to your computer via the optional USB adapter. Specifically, please see the picture of "ZiGate Pack WiFi adapter" https://zigate.fr/produit/zigate-pack-wifi-v1-3/ compared to the picture of "ZiGate TTL USB adapter" https://zigate.fr/produit/zigate-ttl/ Thus "ZiGate Pack WiFi adapter" allows ZHA users to have a networked Zigbee adapter setup like this: ZHA <–> zigpy/zigpy-zigate <–> TCP/IP over LAN <–> ZiGate-WiFi <–> UART <–> ZiGate Radio Suggesting this now as I just learned from @doudz there that the new v2.0 version of the ZiGate Pack WiFi adapter firmware contains "ESP-LINK from Jeelab" software which among other things adds mDNS and UART WiFi Bridge support over TCP. As I understand, version v1.x of the firmware for the ZiGate Pack WiFi adapter basically only contained a simple UART/serial-port server forwarding service ( serial server software that just acts as a dumb Zigbee to WiFi bridge for zigpy-zigate), while the new version v2.x also has more advanced features (which does not need to used) it still also contain a simple UART/serial-port server forwarding service, but now mDNS also makes it easier to discover the adapter on your local network. Now it would be awesome if the ZHA integration component for Home Assistant from an end-user perspective supported just as an easy detection and configuration of network networked-attached Zigbee coordinator adapters, like the Sonoff ZBBridge and the ZiGate Pack WiFi adapter. I would therefore also suggest using some kind of Zero-configuration networking (zeroconf) method, like for example mDNS, (as mDNS is already in use in Home Assistant Core), to make the ZHA integration component for Home Assistant automatically detect, connect, and configure compatible networked-attached Zigbee coordinator adapters like the "ZiGate Pack WiFi adapter" as that is otherwise already supported by the zigpy-zigate radio library for zigpy. |
|
Thanks for this detailed information. However I'm not sure to understand in what way it is of Tasmota concern. The devics above are much more expensive than a Wemos D1 + CC2530. I'm still looking forward to playing with Sonoff Zb bridge as soon as they start shipping. |
|
For starters, CC2530 based modules do not support Zigbee 3.0 (CC253x only support Zigbee 1.2). For Zigbee 3.0 you need CC2538, CC26X2, CC13x2 if Texas Instruments, or EFR32 if Silicon Labs. Then you forgot to add up the total cost for ESP8266 + Zigbee 3.0 module + power-supply + box. So if comparing apples and oranges then cheapest DIY solution based on Texas Instruments example:
You might get a complete CC2538 based DIY solution for a little less but it is going to be hard to compete when the finished hardware that Itead is selling Sonoff ZBBridge just cost $16.90 US-dollars. CC2538 does, however, contain a less powerful radio than Silabs EFR32MG21 used in Sonoff ZBBridge. Comparing apples and apples then cheapest DIY solution based on Texas Instruments example:
But again CC2652R still has a less powerful radio than EFR32MG21, so really need a CC2652P or CC1352P module (P for PA = Power Amplifier) to compete with the signal strength of the EFR32MG21. |
|
I was comparing to the Zigate modules from your last message, not to Sonoff Zigbee bridge. |
|
Closing in favour of #8583 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ascillato2
added
the
requested feature (hold over)
Have you looked for this feature in other issues and in the docs?
Yes.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
No.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Please consider porting Tasmota/Zigbee2Tasmota to the new Sonoff Zigbee Bridge (Sonoff ZBBridge).
Sonoff ZBBridge could be the perfect hardware for a local Zigbee to WiFi bridge/gateway if it was not for the case that it needs to be hacked to flash other firmware on its built-in ESP8266, like Tasmota.
The idea here with Tasmota on Sonoff ZBBridge would be to replace the complete firmware on the ESP8266 MCU SoC with the Tasmota and hopefully leave the EFR32 Zigbee MCU SoC Zigbee coordinator firmware as it is (as hopefully that already have the correct standard firmware that you need).
Itead has just launched Sonoff ZBBridge as an inexpensive Sonoff Zigbee Bridge which is somewhat based on a similar concept/idea as the Sonoff RF Bridge (which I believe your firmware already has support for?).
According to the teardown on notenoughtech.com it sounds as if it is based on Silicon Labs EFR32 (Mighty Gecko) for Zigbee 3.0 radio module support and ESP8266 ("ESP8266EX") for WiFi and bridge/gateway/controller software
As you know, Tasmota does something similar with Zigbee2Tasmota but by connecting an ESP8266 to a Texas Instrument CC2530 module instead however it too is using a serial communication protocol, see:
From the images in notenoughtech.com teardown, it even looks like Sonoff are reusing the same injection moulds as for the Sonoff RF Bridge housing/enclosure which Tasmota already supports
EZSP (EmberZNet Serial Protocol) interface that Silicon Labs uses is also well documented and already used by open source projects, see example Home Assistant's ZHA integration component via zigpy and bellows:
https://github.com/zigpy/bellows
https://www.home-assistant.io/integrations/zha/
https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2017/05/25/build_an_ezsp-spiho-2VE8
https://www.silabs.com/documents/public/user-guides/ug100-ezsp-reference-guide.pdf
Z Smart System also has a Java device driver for Ember based serial dongles (among other dongles):
For reference, Z Smart System also has a sniffer library written in Java which uses same serial interface:
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
The alternative today is to build your own Zigbee2Tasmota bridge with a ESP8266 and a TI CC2530 module, but that is not a complete hardware solution and the Zigbee module included in Sonoff ZBBridge is much more powerful than TI CC2530, plus the EFR32 based module in the Sonoff ZBBridge supports Zigbee 3.0 while TI CC253x only supports Zigbee Home Automation (HA) 1.2
Additional context
Add any other context or screenshots about the feature request here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: