search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.29k stars 4.82k forks source link

[REQUEST] Tasmota firmware on Sonoff ZBBridge (Sonoff Zigbee Bridge) #8197

Closed Hedda closed 4 years ago

Hedda commented 4 years ago

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:

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)

timdonovanuk commented 4 years ago

Seconded! The actual name of this device is Sonoff BASICZBR3.

Jason2866 commented 4 years ago

Since Sonoff Zigbee Bridge uses a chip where no Open Source Router firmware variant exists, there will be no support for Zigbee2Tasmota

s-hadinger commented 4 years ago

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?

Hedda commented 4 years ago

Seconded! The actual name of this device is Sonoff BASICZBR3.

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;

Hedda commented 4 years ago

Are you sure the Sonoff Zigbee Bridge uses EZSP protocol?

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

timdonovanuk commented 4 years ago

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.

meingraham commented 4 years ago

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.).

hgelpke commented 4 years ago

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.

Hedda commented 4 years ago

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.

Hedda commented 4 years ago

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.

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.

Hedda commented 4 years ago

Since Sonoff Zigbee Bridge uses a chip where no Open Source Router firmware variant exists, there will be no support for Zigbee2Tasmota

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 ;)

Jason2866 commented 4 years ago

@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 or something completely different. I dont understand the comparision between RF Bridge and the Zigbee Bridge. The device do have nothing in common expect the case and using a ESP82xx chip for wifi. NotEnoughTech just did a unboxing. To be clear at the moment we just know what chips are inside NOTHING more. Everything else are just assumptions what might be, could be... We are going to try to get some. Maybe! something is possible.... Small side note. To make the RF Bridge a great device the firmware for the RF MCU is completely rewritten from scratch ("Portisch firmware"). This MCU is a small restricted CPU. Not comparable in any way to the complex CPUs used for Zigbee.

Hedda commented 4 years ago

@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.

Hedda commented 4 years ago

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

https://github.com/zigpy/zigpy-cc

Jason2866 commented 4 years ago

@Hedda why? There is no need for a workaround. Zigbee2Tasmota works fine

Hedda commented 4 years ago

@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:

Hedda commented 4 years ago

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.

Jason2866 commented 4 years ago

I know the Ebyte modules. This does not help anything, because we have no access to the EmberZNet PRO Zigbee Stack. It is only available if you buy the 500$ development board. There is a chance to get the Ebyte modules going with zigbee2Tasmota (if someone does the work) Ebyte does have no interest to sell a modified zigbee stack version This does not help with your request since we still dont know anything about Sonoff Zigbee Bridge used Zigbee Stack nor can we flash a different stack since there is simply none

Hedda commented 4 years ago

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:

https://github.com/xoseperez/espurna/issues/2224

and

https://github.com/Koenkk/zigbee-herdsman/issues/168

s-hadinger commented 4 years ago

Thanks @Hedda I have ordered mine from Itead but they announce a shipping date not before May 15. We can continue the discussion when we receive them and take a look at the actual firmware version in the EFR32 MCU.

Hedda commented 4 years ago

FYI @SillyDay don't own a E180-ZG120B but has tried to build a firmware for it as per discussion here:

https://github.com/Koenkk/zigbee-herdsman/issues/168

SillyDay GitHub repo for EFR32 firmware:

https://github.com/SillyDay/EFR32

Hedda commented 4 years ago

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:

https://translate.google.com/translate?sl=fr&tl=en&u=https%3A%2F%2Fzigate.fr%2Fdocumentation%2Fdescription-du-firmware-v2-xx%2F

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.

s-hadinger commented 4 years ago

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.

Hedda commented 4 years ago

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.

s-hadinger commented 4 years ago

I was comparing to the Zigate modules from your last message, not to Sonoff Zigbee bridge.

ascillato2 commented 4 years ago

Closing in favour of https://github.com/arendst/Tasmota/issues/8583

shanekuz commented 4 years ago

Hi everyone, im having an issue with my Sonoff ZBbridge posting MQTT to OPENHAB using the JSONPATH method.

I have a number of devices registered to the bridge but they all send updates on the same MQTT publish path.

When it publishes on this path tele/tasmota_zbGateway1/SENSOR = {“ZbReceived”:{“0x7294”:{“Device”:“0x7294”,“Name”:" Office_Temp",“Temperature”:23.88,“Humidity”:65.49,“Endpoint”:1,“LinkQuality”:157}}}

I get my temperature updated in openhab and it works fine until another device updates.

tele/tasmota_zbGateway1/SENSOR = {“ZbReceived”:{“0xFF6C”:{“Device”:“0xFF6C”,“Name”:" Wardrobe_PIR",“Illuminance”:6,“Occupancy”:1,“Endpoint”:1,“LinkQuality”:13}}}

Then OPENHAB sets the first value to NULL as it received the JSON payload but it had no entry for that device.

Does anyone have a workaround or maybe can we publish all states of all devices when the gateway publishes anything as a fix?
Maybe this could be a option you turn on as others will have this issue also im picking.

ascillato commented 4 years ago

Please, address this to the Tasmota Support Chat. The chat is a better and more dynamic channel for helping you. Github issues are meant for Tasmota Software Bug Reporting.

Please check the Contributing Guideline and Policy

Thanks.

Support Information

See Docs for more information. See Chat for more user experience. See Community for forum. See Code of Conduct