FYI, syssi now added step-by-step instructions for how-to flash ZB-GW03 with ESPHome firmware:
He even included instructions for how to perform backup and restore of the original firmware.
1 Like
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.
Anyone experiencing the same behaviour?
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.
It looks like the stream-server component doesnât work well on recent esphome versions. If you use esphome 2021.9.3 the serial bridge is rock-solid.
1 Like
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):
https://drive.google.com/file/d/1H-M5CTh_XGGVl2te4vHLQ5SfGPHL6yCS/view?usp=sharing
This is the signed routing firmware used by ZBB, the usage method is the same as the unsigned firmware.
You think Tasmota/ESPHome can send basic commands to it to initiate paring/joining and restart/reset?
xsp1989 post update on router firmware in [REQUEST] Zigbee Router firmware for EFR32MG21 in Sonoff ZBBridge by ITead? ¡ arendst/Tasmota ¡ Discussion #11536 ¡ GitHub
âThis firmware can ground the PA00 5S into pairing mode, and ground the RST to restart routing. UART is used to transmit data transparently.â
and
âThere is also another version of the routing firmware that can control the join network through a proprietary serial port protocolâ
Ideas around this is also discussed for ITeadâs Sonoff ZBBridge hacked with Tasmota/ESPHome here:
https://github.com/arendst/Tasmota/discussions/11536
https://github.com/thegroove/esphome-zbbridge/issues/3
https://github.com/syssi/esphome-zb-gw03/issues/12
https://github.com/xsp1989/zigbeeFirmware/issues/2
https://github.com/xsp1989/zigbeeFirmware/issues/16
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.
Checkout âHow to Convert the Sonoff Zigbee Bridge into a Router / Repeaterâ blog article by @digiblur
https://www.digiblur.com/2022/02/convert-sonoff-zigbee-bridge-to-router-repeater.html
1 Like
How to use the router firmware with the ESPHome node:
1 Like
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)
Any ideaâs? I am a bit lost here!
Did you follow his two separate update posts as well and not just the original post by thehelpfulidiot ?
https://thehelpfulidiot.com/a-wired-sonoff-zigbee-alternative â ORIGINAL POST
https://thehelpfulidiot.com/update-a-wired-sonoff-zigbee-alternative â UPDATE 1 (ZHA fix)
https://thehelpfulidiot.com/update-2-a-wired-sonoff-zigbee-alternative â UPDATE 2 (Zigbee2MQTT fix)
What he has not covered which might be a good idea is to try upgrading to Tasmota 11.0.0 (or not?)?
https://tasmota.github.io/docs/Upgrading/#migration-path
https://github.com/arendst/Tasmota/releases/tag/v11.0.0
http://ota.tasmota.com/tasmota/release/
http://ota.tasmota.com/tasmota32/
You could also test posting same to here:
https://github.com/arendst/Tasmota/discussions/12764
Why? Do you not have your ZB-GW03 on the same local subnet segment as your Home Assistant OS?
PS: There is newer experimental/untested firmware available for the SM-011 Zigbee module here:
https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/ZigbeeBridge_SM-011
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.
Please make sure to use ESPHome 2021.9.3. Can be installed (temporary) by: pip3 install esphome==2021.9.3
1 Like
Thanks, will try that - what are the issues in 2022.2 which 2021.9 does not have? So far (24 hours) no issues.
Am on Hass OS though so no pip. Will try a docker instance instead.
If you see this
File "/usr/local/lib/python3.9/site-packages/bellows/ezsp/protocol.py", line 138, in __call__
frame_name = self.COMMANDS_BY_ID[frame_id][0]
KeyError: 520
or these lines
2021-12-31 10:26:01 WARNING (MainThread) [bellows.zigbee.application] Watchdog heartbeat timeout:
2021-12-31 10:26:16 WARNING (MainThread) [bellows.zigbee.application] Watchdog heartbeat timeout:
2021-12-31 10:26:31 WARNING (MainThread) [bellows.zigbee.application] Watchdog heartbeat timeout:
at your home-assistant.log you hit this issue: https://github.com/syssi/esphome-zb-gw03/issues/8
Downgrading helps in this case. If you donât see the issue in the next 7 days itâs probably solved.
1 Like
Technically you donât need to install Tasmota in HA at all if only use it as a remote Zigbee Coordinator.
Zigbee module UART TX/RX pins â serial stream server â TCP/IP network â socat â ZHA
In this case, Tasmota (or ESHome) is there to act as a serial server to access the serial Zigbee module. The serial server is only a relay/proxy which is used to blindly tunnel raw serial communication data.
That is, as far as ZHA (or Zigbee2MQTT) is concerned it does not know that it is a remote adapter as it only connect to a serial port (via socat) so it does not know or case if it is local or remote serial port.
(Perhaps the most well known serial stream server is the ser2net daemon for Linux).
Because of this, there can be issues with remote Zigbee Coordinator adapters as the serial protocol that they use are not designed to be robust and assume that the connection is always connected and stable.
This is why WiFi connected remote Zigbee Coordinator adapters are not recommended, as if your Wi-Fi network is unstable so it delays or drops packages the serial communication will fail. See comments:
Warning! The EZSP protocol requires a stable connection to the serial port. With ITEAD Sonoff ZBBridge connecting over the WiFi network it is expected to see NCP entered failed state. Requesting APP controller restart in the logs. This is a normal part of the operation and indicates there was a drop in communication between ZHA and Sonoff bridge.
https://www.zigbee2mqtt.io/advanced/remote-adapter/connect_to_a_remote_adapter.html
WARNING WiFi-based Serial-to-IP bridges are not recommended as the serial protocol does not have enough fault-tolerance to handle packet loss or latency delays that can normally occur over WiFi connections.
PS: Texas Instruments ZNP serial protocol is however a little more robust than Silicon Labs EZSP.
Eureka, it works.
For other relative new users; use the tip on one of the linked websites (as linked by helpfull idiot) to open 2 tasmota screens: 1 for console, 1 for updating the .ota firmware. I overlooked that tip and apperantly my .ota firmware didnât work (wrong file signature error) which I didnât see without the console feedback. I also realized I too quickly closed console screens while it was still loading my backlog inputs. In other words, wait 10s to make sure nothing happens any more after youâve input a command.
The wrong file signature error had something to do with choosing wrong module (i believe it is 0), but ended up bricking the GW03 messing around choosing the wrong one (no idea I what I was doing at the time).
So I started with a clean slate (needed to unbrick the GW03 anyway) by flashing the GW03 again:
follow the instructions:
Flashing GW03 with most stable firmware (.bin file) as linked by helpfulidiot, created by vahempio, including instructions:
Above link has the âZHAâ fix as referenced by helpfulldiot, but also gives you step by step the right backlogs that correspond with the firmware (I originaly mixed/matches both websites tutorials).
This also includes updating the .ota file. make sure you confirm the firmware is actually updated (I got a fail to see in my second window with tasmota console), but no fault/error given on the firmware update screen
Once that runs, go to the digiblur link to setup (How to use the Sonoff Zigbee Bridge with Home Assistant - Tasmota) to setup zigbee home automation from step #7
2 Likes
Thanks, I stuck with my version for the time being to check stability. Did not come across your mentioned errors in my log.
I am running fw based on your yaml template built on esphome 2022.02 since 23 Feb without HA reboot. No major errors except for the below which did not negatively impact performance/user experience, on average 2-3 times per day (which is much better than the errors caused by the tasmota version):
Logger: homeassistant
Source: util/async_.py:129
First occurred: 23 February 2022, 16:39:29 (19 occurrences)
Last logged: 10:09:04
Error doing job: Exception in callback SerialTransport._call_connection_lost(None)
Traceback (most recent call last):
File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.9/site-packages/serial_asyncio/__init__.py", line 417, in _call_connection_lost
self._serial.close()
File "/usr/local/lib/python3.9/site-packages/serial/urlhandler/protocol_socket.py", line 104, in close
time.sleep(0.3)
File "/usr/src/homeassistant/homeassistant/util/async_.py", line 166, in protected_loop_func
check_loop(func, strict=strict)
File "/usr/src/homeassistant/homeassistant/util/async_.py", line 129, in check_loop
raise RuntimeError(
RuntimeError: Detected blocking call inside the event loop. This is causing stability issues. Please report issue
$ grep call_connection home-assistant.log
2022-02-27 20:59:09 ERROR (bellows.thread_0) [homeassistant] Error doing job: Exception in callback SerialTransport._call_connection_lost(None)
File "/srv/homeassistant/lib/python3.9/site-packages/serial_asyncio/__init__.py", line 417, in _call_connection_lost
$ grep call_connection home-assistant.log.1
2022-02-25 22:59:35 ERROR (bellows.thread_0) [homeassistant] Error doing job: Exception in callback SerialTransport._call_connection_lost(None)
File "/srv/homeassistant/lib/python3.9/site-packages/serial_asyncio/__init__.py", line 417, in _call_connection_lost
$
I can find the same errors (just less often) in my log. The uptime (esphome sensor) of my device is around 23 days. Conclusion: The device doesnât crash. Just the network connection drops every now and then. In my case the setup is able to recover and doesnât require any manual restarts.