ZB-GW03 eWeLink Ethernet Zigbee Gateway now hacked with Tasmota and ESPHome so can be used via MQTT or as a remote Zigbee LAN adapter with Home Assistant's ZHA integration or Zigbee2MQTT

It is probably better ask on Tasmota’s Discord first even though they also have other support channels:

https://discord.gg/Ks2Kzd4

https://github.com/arendst/Tasmota/discussions

https://www.reddit.com/r/tasmota/

https://groups.google.com/g/sonoffusers

Did you also follow @thehelpfulidiot updated guides posted as separate posts instead of updated old?

https://thehelpfulidiot.com/update-a-wired-sonoff-zigbee-alternative ← UPDATE 1

https://thehelpfulidiot.com/update-2-a-wired-sonoff-zigbee-alternative ← UPDATE 2

That is, don’t just read and follow his original post but also make sure to follow the update posts as too!

https://thehelpfulidiot.com/a-wired-sonoff-zigbee-alternative ← ORIGINAL POST

PS: Btw, note @thehelpfulidiot replied to all help questions posted as comments to those blog posts.

1 Like

yes tried everything, I see that my router offers IP address, but ZB-GW03 just not taking, I will try with another simple router

Maybe also try connecting through another switch and direct to the router to test different combinations.

If auto-negotiate is still causing issues then it is good to try both with and without a switch in between.

Usually when auto-negotiate port speed does not work then will need to force a specific speed on both sides, meaning that it is sometimes not enough to only force speed on the router/switch port as would normally also need to force the same specific speed inside the client device config/settings as well.

FYI, ITead now released Silabs EmberZNet 6.10 (v6.10.3) firmware for their EFR32MG21 USB dongle:

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle

Not tested but will probably work on ZB-GW02, ZB-GW03, ZB-GW04, and Sonoff ZBBridge as well?

I understand they all use same radio board design based on “SM-011 V1.0” radio module by CoolKit:

https://github.com/zigpy/zigpy/discussions/586

xsp1989 also announced the good news is that a router firmware “will be released soon” here:

https://github.com/xsp1989/zigbeeFirmware/issues/18

1 Like

I’ve prepared a small project to provide a working esphome configuration for the ZB-GW03:

Rebooting HA and/or the Zigbee gateway doesn’t cause issues. I’ve tested the setup with ncp-uart-sw_6.7.8_115200.ota and ZHA (socket://IP:6638, 115200 baud, “software” flow control). I’m happy about any feedback.

1 Like

@syssi Nice! FYI, there’s a related feature request for ESPHome Zigbee serial remote adapters here:

https://github.com/esphome/feature-requests/issues/688

Guess you were already aware of ESPHome based config that thegroove did for Sonoff ZBBridge(?):

https://github.com/thegroove/esphome-zbbridge

thegroove also started working on updated variant with Zeroconf support for ZHA automatic discovery:

https://github.com/thegroove/esphome-zbbridge/issues/1

https://github.com/thegroove/esphome-zha-ezsp-zeroconf

https://github.com/thegroove/esphome-zeroconf

https://github.com/thegroove/esphome-zeroconf/issues

More information and discussion on the Zeroconf discovery idea concept for ZHA here:

https://community.home-assistant.io/t/zha-automatic-network-discovery-of-zigbee-coordinator-bridges-gateways-ethernet-wifi-network-adapters-that-support-zeroconf-or-ssdp/293300/

Auto-discovery would be awesome! I will give it a try if it is supported by HA out of the box. It is hard to identify what’s solved and what’s work in progress.

1 Like

Thanks for pointing to thegrooves zbbridge project. I will compare both ser2net implementations. I like the binary sensor which isn’t available at the stream_server implementation of oxan.

1 Like

@thehelpfulidiot Instead of switching between module 2 and module 3 (at tasmota) it could be enough to pull the nRST GPIO of the zigbee module after boot up once:

The zigbee module of my ZB-GW03 stops at the bootloader (on every fresh boot). To boot the zigbee firmware a nRST is required.

Not supported out-of-the-box for as need to use custom name so Zeroconf discovery can forward to ZHA. So far it is only out-of-the-box supported by “tube” gateways as that name is forwarded to ZHA.

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

Perhaps add “EZSP” for Silabs based Zigbee adapter (and “ZNP” for Texas Instruments based Zigbee adapters) as generic name(s) that could be used by ZHA as a general discovery method for all these?

As an example see this draft WIP PR posted here:

https://github.com/home-assistant/core/pull/58224

Only two files updated compared to in the dev branch of Home Assistant core:

https://github.com/Hedda/home-assistant/blob/bd3867159e8be82aad1ead38940d26d45472b143/homeassistant/generated/zeroconf.py#L79

    "_esphomelib._tcp.local.": [
        {
            "domain": "esphome"
        },
        {
            "domain": "zha",
            "name": "tube*"
        }
    ],
    "_esphome_ezsp_bridge._tcp.local.": [
        {
            "domain": "zha",
            "name": "esphome_ezsp_bridge*"
        }
    ],

https://github.com/Hedda/home-assistant/blob/bd3867159e8be82aad1ead38940d26d45472b143/homeassistant/components/zha/manifest.json#L25

"zeroconf": [
    {
      "type": "_esphomelib._tcp.local.",
      "name": "tube*"
    },
    {
      "type": "_esphome_ezsp_bridge._tcp.local.",
      "name": "esphome_ezsp_bridge*"
    }
  ],

With the exception of using a unique custom hostname and service name that is yours, can maybe test the concept by just by copying latest ESPHome configs for zeroconf from tube_gateways by tube0013 as it is so far only whitelisted Zigbee gateways already supported in the ZHA integration component inside Home Assistant core repository:

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

https://github.com/tube0013/tube_gateways/tree/main/esphome

https://github.com/tube0013/tube_gateways/blob/ed3d541a29890699a6e8e9550af44c537712751d/V2_tube_zb_gw_cc2752p2/ESPHome/tube_zb_gw_cc2652p2v2.yml

https://github.com/tube0013/tube_gateways/blob/7bde5f09852b95fd98d146f659464678bd6ce2f9/tube_zb_gw_efr32/Firmware/ZigBee%20Module/V2_tube_zb_gw_cc2752p2/ESPHome/tube_zb_gw_cc2652p2v2.yml

Alright. I’ve introduced the auto-discovery (by abusing the tube* prefix for now):

1 Like

Nice! At least it can be tested as a Zeroconf proof-of-concept for ZHA borrowing the “tube*” prefix name.

As suggested above. Maybe change it later to new a general “ezsp” prefix or suffix names for generic ESPHome based Zigbee remote adapters using Silabs Zigbee radios, and respectively “znp” as a new general prefix or suffix names for generic ESPHome based Zigbee remote adapters using Texas Instruments Zigbee radios.

Totally agree. At the moment the zha component evaluates the efr32 of the service name to select the correct radio_type. The radio_type of the zeroconf payload isn’t picked up at the moment (if I don’t miss something).

1 Like

Just bought one of these ZB-GW03!

What is currently the most stable setup over LAN? Would love to know!

Also, is it possible to hook up multiple and put them in the same ZigBee network (mesh them)?

Thanks in advance.

AFAIK a zigbee network can have one coordinator only. If you use multiple coordinators you create multiple networks. A repeater at a zigbee network is called “router” and doesn’t require ethernet connectivity. Most wired (!= battery powered) zigbee device acts as an router. This doesn’t apply to some light bulbs.

hmm, maybe then even try to think a bit further ahead into the future since radio-adapters for the upcoming Matter over Thread radio adapters (with devcices based on Matter over Thread becoming available next year) as those will also be based on the exact same Silicon Labs “EFR32” multi-protocol MCU and radio modules because the same models Silabs EFR32 chips also support both Zigbee and Thread (as well as other IEEE 802.15.4 based specifications too).

I think using “ezsp” instead should work since Thread radio-adapters for Matter will use OpenThread firmware that uses the the Spinel protocol instead, however if would like to be absolutely sure that only adapters that have Zigbee firmware flashed then might need to add more DNS records in Zeroconf mDNS to for specify that it specifically is a “Zigbee” radio adapter(?), perhaps by utilizing the new ZeroconfServiceInfo feature in ZHA?

https://github.com/home-assistant/core/pull/60266

https://github.com/home-assistant/core/pull/60206

https://github.com/home-assistant/architecture/discussions/662

While a Zigbee router does not require Ethernet or WiFi connectivity, it would still be very nice to have an optional Zigbee router firmware for ZB-GW03 (and Sonoff ZBBridge) as with them running ESPHome it would give you the option to remotely initiate a reset/restart the MCU/radio if you have any issues with that specific Zigbee router device. Not being able to remotely reset Zigbee router devices that have hung is otherwise an issue and a pain if you have loads of devices or if the units are installed in wall sockets so not easy to get to and reset manually.

FYI, in related news, you should know that xsp1989 who builds the firmware for the “SM-011” module inside ZB-GW03 (and Sonoff ZBBridge) announced that he is working on Zigbee router firmware for these.

https://github.com/xsp1989/zigbeeFirmware/issues/16

Would be awesome if could have several of these and run Zigbee coordinator firmware on one and Zigbee router firmware on the others, that way you do not have to have idle hardware lying around if you want a spare as backup in case one breaks. So the one with the Zigbee coordinator fails then you reflash one of your Zigbee routers that have the same hardware and restore a backup of your Zigbee coordinator to it. See this related feature request with ideas related to Zigbee coordinator backups:

https://community.home-assistant.io/t/zha-integration-to-do-nightly-backup-of-both-zigbee-coordinator-adapter-dongle-stick-and-zigbee-database/357558

Tip regardless of setup, make sure you have backups + preferably spare hardware. See link above!

With the limitation of only one Zigbee coordinator per Zigbee network being hard limit set in the Zigbee specification standard, your Zigbee coordinator becomes a single-point-of-failure and a very important component in your home automation setup.

Recommend regularly backup your Zigbee coordinator, and alsorecommend buy a spare Zigbee coordinator so that you have it at home that you can restore your backup to in case of hardware failure.

Even though you can create multiple Zigbee networks with multiple Zigbee coordinators (again with the limitation of only one Zigbee coordinator per Zigbee network) it is worth adding that the ZHA integration in HA does currently not support multiple Zigbee coordinators at all, even if they each was only connected to one Zigbee network on their own.

FYI; Zigbee Router firmware for EFR32MG21 adapters has now been released by xsp1989 on GitHub.

From readme it sounds tested with ITead Zigbee 3.0 USB Dongle and an SM-011 based USB adapter.

The same “SM-011 V1.0” Zigbee radio modules by CoolKit Technologies is also used inside some Zigbee gateways/hubs like ZB-GW03 eWeLink Ethernet Zigbee Gateway sold by EACHEN and SmartWise as well as the popular ITead Sonoff ZBBridge, so could perhaps be that the same Zigbee Router firmware could maybe also be used on the SM-011 Zigbee module in all or some of those products as well? However, suspect ZB-GW03 and/or Sonoff ZBBridge require signed firmware?

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle/RouterForDongle

https://github.com/xsp1989/zigbeeFirmware/blob/710a60451f6631cad46f5d5107b65198558709c3/firmware/Zigbee3.0_Dongle/RouterForDongle/README.md

https://github.com/xsp1989/zigbeeFirmware/issues/16

https://github.com/xsp1989/zigbeeFirmware/issues/2

1 Like