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?
As reported in syssi github I just bought a zb-gw03 bridge and flashed it directly with Esphome firmware (and 6.7.8 zigbee firmware).
I’m using Esphome 2021.12.1
I moved from a Sonoff zbbridge where I had sometimes NCP errors (non frequently but they happened); I used bellow’s backup feature to move to the new adaper without having to repair all the devices, and it worked smoothly.
Unfortunately the bridge is turning out to have network errors, with a lot of watchdog heartbeat timeouts, and bellows keyerror 520 which require every hour or two to trigger a zigbee reset.
I’m struggling to understand where the problem is, the HA PC and the bridge are connected through the same switch, and it is never reported by Esphome to be offline or not available.
Looks like I found the solution. Flashing the bridge with the custom tasmota firmware solves the issues, so it’s all about ESPhome.
My idea is the stream-server component used in syssi firmware doesn’t work very well with recent versions of ESPhome. In my case I used v.2021.12.1 and the stream-server was randomly connecting and disconnecting, while the ESPhome api were always up and running.
FYI, xsp1989 has uploaded a signed Zigbee Router firmware for ITead’s Sonoff ZBBridge which could possibly make it a Tasmota/ESPHome connected Zigbee Router (instead of as a Zigbee Coordinator):
PS: Have not tried this myself as I got rid of my ITead Sonoff ZBBridge because being WiFi-based it did not work any good as a remote Zigbee Coordinator, but might reconsider buying one if it worked as a Zigbee Router device that can be paired/joined and restarted/reset remotely via Tasmota and/or ESPHome. So that Tasmota/ESPHome is basically only used to initiate virtual join/pair button and restart/reset the device similar to a remote power-cycle it hangs.
First all my thanks to all who have provided their 2 cents to bring device to a higher level.
Secondly, I currently get stuck in the process of adding the GW03 to Zigbee Home Automation, in Home Assistant, running in VM on Unraid. Steps taken and its success:
1.I have managed to flash the GW03 with the newest bin file (pre-compiled, downloaded) as linked by thehelpfulidiot (erkoc - vahempio).
2.added the template as per instructions on Github (vahempio)
3. updated the zigbee firmware to 6.7.9_115200.ota
4.disabled wifi as per instructions on Github
5. remapped Zigbee Tx/Rx pin as per instructions
6. Added TCP zigbee server as per instructions
In my router I have forwarded port 8888 both internally and externally. I have given the GW03 a fixed IP-address as well. However fault is both in dynamic as well as fixed IP address. I have changed IP address a few times to test, same result
I can ping and access the GW03 on it’s address 192.168.178.63, so that seems to be up and running.
obviously I have rebooted the GW03 a few times and as stated I can access the GW03 directly by filling in it’s IP address.
Current setup:
Unraid server on a HP Proliant server
Home Assistant runs in VM on Unraid
Home assistant does recgonize other ethernet devices (i.e. kwh/gas usage meter)
Please let me first off all explain, I am nowhere an advanced user of network/IT. I am keen to learn as I see it is worth my time and efforts to be future proof to learn matters associated with Domotica.
I have literally spend 100’s of hours watching youtube and stroll around on fora to grap and learn the whole idea of running my own server (unraid, plex, FTP, VPN and now Home Assistant) because I truly believe to be independent of commercial cloud solutions.
In other words, please be patient with me, I am learning, but surely making decisions that don’t make sense. Networking/server IT has always a weak point for me, so trying to progress!
to come back to your replies (thank you for that):
my understanding on his webpage is that from update 12/5 there is no difference any more (no necessary ZHA fix), unless I am misreading his statements.
I quote:
Happy to hear if I’m wrong (trust me, I am used to it).
He also refers to the ‘fixed’ bin file where user erkoc experiences instability (predominantly disconnects). I have followed his steps (same as thehelpfullidot, aside from a different compiled bin file), I quote:
Now your last statement gets interesting, and this probably highlights my inexperience/ignorance:
Perhaps I should install Tasmota first in HA…I am still not fully conversant how all these sub-layers (if I can call it that) are related to each other and what their depenancies are, but can see I might have missed a step. I’ll spend some time setting that up first (mind you this is a clean, first install of HA).
I’ll report back when that is up and running before I continue my complaint!
last but not least:
I wasn’t sure if it was needed; inexperience I guess and wanted to make sure blocked ports were not the problem. But yes, the GW03 is in same subnet (192.168.178.xx)
I had similar issues. You may want to double check if the 8888 port is open (port scanner); the guidance in the blog (helpful idiot) did not work for me and I adjusted rule01 as follows which solved my issues:
backlog rule1 on system#boot do backlog wifi 0 endon on system#boot do TCPStart 8888 endon; rule1 on
It’s by the way not needed to have them in the same subnet, many users have esp/tasmota devices on a separate NoT vlan which works as long as your firewall rules allows ha to reach your ZigBee device. To rule out firewall issues though good to test it first on the same subnet.
As a side note - After using it for a few months I found the tasmota setup to be very unstable. Yesterday I switched to esphome (@syssi 's setup) so far much more stable serial connection.