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.
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.
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.
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.
@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.
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?
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:
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).
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?
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.
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:
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?