syssi / esphome-zb-gw03 Goto Github PK

View Code? Open in Web Editor NEW

61.0 8.0 16.0 31.44 MB

ESPHome custom firmware for the ZB-GW03 zigbee gateway

License: Apache License 2.0

ewelink eachen zb-gw03 zigbee-gateway esphome custom-firmware esphome-config hacktoberfest

esphome-zb-gw03's Introduction

esphome-zb-gw03

ESPHome custom firmware for ZB-GW03 eWeLink Ethernet Zigbee Gateway

Compatible hardware

ZB-GW03 Zigbee to LAN bridge/gateway based on Espressif ESP32 and a Silicon Labs EFR32MG21 Zigbee radio (CoolKit-Technologies "SM-011 V1.0" module).

Supported devices

ZB-GW03 eWeLink Ethernet Zigbee Gateway (ZB-GW03-V1.0, ZB-GW03-V1.2, ZB-GW03-V1.3, ZB-GW03-V1.4), also sold rebranded as:
- Eachen eWeLink ZigBee Smart Hub
  - https://ewelink.eachen.cc/product/eachen-ewelink-zigbee-bridge-pro-zbbridge-pro/
  - https://ewelinkcommunity.net/device-lists/zigbee/eachen-zb-gw03/
- SmartWise Zigbee Bridge Pro
  - https://www.okosabbotthon.hu/smartwise-zigbee-bridge-pro

Requirements

ESPHome 2024.6.0

Quick start guides

Known issues

None.

References

esphome-zb-gw03's People

Contributors

Stargazers

Watchers

Forkers

hedda louispires hilsonp jon6fingrs cptbucky biakss ntp3phat chaoticalex damdo otoussaint 23900 baeksj msj11231321 flppter adrusa jserrats

esphome-zb-gw03's Issues

No longer able to flash updated ESPHome versions: Error: Authentication invalid. Is the password correct?

I flashed this well over a year ago, worked great until about August last year when the ESPHome firmware no longer flashed successfully via OTA.

Building .pioenvs/zigbee/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin([".pioenvs/zigbee/firmware.bin"], [".pioenvs/zigbee/firmware.elf"])
Wrote 0xdc2d0 bytes to file /data/build/zigbee/.pioenvs/zigbee/firmware-factory.bin, ready to flash to offset 0x0
======================== [SUCCESS] Took 380.16 seconds ========================
INFO Successfully compiled program.
INFO Connecting to 10.0.0.31
INFO Uploading /data/build/zigbee/.pioenvs/zigbee/firmware.bin (836304 bytes)
ERROR Error auth result: Error: Authentication invalid. Is the password correct?

I tried playing around with the OTA Password field etc. but nothing seems to have worked and I am now stuck on an old version

substitutions:
  name: zigbee
  device_description: "ZB-GW03 eWeLink Ethernet Zigbee Gateway based Zigbee Coordinator"

packages:
  zb-gw03:
    url: https://github.com/syssi/esphome-zb-gw03
    ref: main
    files:
      - packages/core.yaml
      - packages/status_led.yaml
      - packages/green_led.yaml
      - packages/i2c.yaml
      - packages/button_zigbee_reset.yaml
      - packages/mdns.yaml
    refresh: 0s

# Enable Home Assistant API
api:
  encryption:
    key: "bQ30ENXTK+FZ+8X5ryGB0HTzoulLftOS8fiyHzMUbpg="

ota:
  password: "a6c199f4e53f394834c47b3b5e0bbedb"

# Enable logging
logger:

wifi:
  ssid: !secret wifi_ssid_iot
  password: !secret wifi_password_iot

  manual_ip:
    static_ip: 10.0.0.31
    gateway: 10.0.0.1
    subnet: 255.255.255.0

Will probably need to sort this out soon due to the deprecation of the ezsp and seems like xsp1989 is busy attempting a new firmware build

Ideally, I would not like to resolder again and prefer to be able to do an OTA of some sort.

Any recommendations?

no ACK at the end of flashing

converted my gateway from tasmota (stock 13.2, self upgraded to latest 13.3) and esphome works great.
then followed the zigbee flashing section, trying to flash fresher firmware, but regardless if I use more recent or the approved version, my upload looks like this

$ sx -vv -X -b --tcp-client 192.168.1.72:6638 ncp-uart-sw_7.3.1.0_115200.gbl
connecting to [192.168.1.72] <6638>

Sending ncp-uart-sw_7.3.1.0_115200.gbl, 1819 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent: 1819/227kRetry 0: No ACK on EOT

Transfer incomplete

the hub works and zb2mqtt reports the stock firmware on the settings/about page

so, few questions

is the transfer really incomplete? if so, what am I doing wrong?
is the settings/about firmware version reliable?

Add WiFi support

I succesfully flashed the router-example to the GW (1.3).
But I'm using it exclusivelly over WiFi.
And only ethernet is working.
Trying to add a wifi section in the yaml file is generating an error:

ethernet: [source <unicode string>:38]
  
  Component ethernet cannot be used together with component wifi.
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO17_OUT
  phy_addr: 1
  power_pin: GPIO16

Could someone share working config with ethernet enabled?

May be I missing something - could someone share working yaml with ethernet enabled?

[REQUEST] Utilize "External Components" (for serial stream server and zeroconf) in ESPHome config

@syssi Suggest utilizing "External Components" (for serial stream server component and zeroconf component) in configuration.

External components feature was added in esphome 1.18

If you re-arrange your repo, the code can be pulled dynamically from the yaml.

Maybe add link to readme files for reference once adjust the repos -> https://esphome.io/components/external_components.html

This code repo has to have rearranged directories into like "components/esphome-stream-server" "components/zeroconf" so can be pulled dynamically from ESPHome yaml

oxan has done this in his repo for his "Stream server for ESPHome" -> https://github.com/oxan/esphome-stream-server

external_components:
  - source: github://oxan/esphome-stream-server

serial_server:

or if use esphome-serial-server from thegroove

external_components:
  - source: github://thegroove/esphome-serial-server

serial_server:

Same for Zeroconf if added

external_components:
  - source: github://thegroove/esphome-zeroconf

zeroconf:

PS: As an example can see how thegroove implemented external components in this experimental repo:

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

[REQUEST] Custom name in Zeroconf DNS records for unique or generic automatic network discovery by ZHA

@syssi Issue for discussion as know you already know that ZHA support network discovery (auto-detection) can work via Zeroconf.

What is missing is the use of a custom name in Zeroconf DNS record for unique or generic automatic network discovery by ZHA.

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

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/

As suggested there. Maybe change it to new a general “ezsp” prefix or suffix name 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).

Using "efr32" as the prefix or suffix name will not work in the long run as thinking a bit further ahead into the future since radio-adapters for the upcoming Matter over Thread radio adapters (with devices 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, incusing the EFR32MG21 chip, because the same models Silabs EFR32 chips also support both Zigbee and Thread (as well as other IEEE 802.15.4 based specifications too).

Therefor 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 specifying that it specifically is a “Zigbee” radio adapter(?), perhaps by utilizing the new ZeroconfServiceInfo feature in ZHA?

home-assistant/core#60266

home-assistant/core#60206

home-assistant/architecture#662

By the way, @thegroove also started working on an updated variant with Zeroconf support for ZHA automatic discovery:

thegroove/esphome-zbbridge#1

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

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

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

As an example see this draft WIP PR posted here:

home-assistant/core#58224

For the ZHA side only two files updated compared to in the dev branch of Home Assistant core:

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*"
    }
  ],

Cannot update with ESPhome after 2023.2.3 OTA

ESPhome updated to 2023.3.2 recently so I tried to update my gateway from 2023.2.3 firmware to 2023.3.2 firmware wirelessly.

Compiled and links fine
I get Error 104 when it tries to upload

INFO Reading configuration /config/esphome/zb-gw03-coordinator.yaml...
INFO Updating https://github.com/syssi/esphome-zb-gw03@main
INFO Reverting changes to https://github.com/syssi/esphome-zb-gw03@main -> 06937b87edf59b7afa84f06d3dffa870b38335ba
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO2 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO12 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO15 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Compiling app...
Processing zb-gw03-coordinator (board: esp-wrover-kit; framework: arduino; platform: platformio/espressif32 @ 5.2.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- WiFi @ 2.0.0
|-- ESPmDNS @ 2.0.0
|-- Update @ 2.0.0
|-- Wire @ 2.0.0
Compiling /data/zb-gw03-coordinator/.pioenvs/zb-gw03-coordinator/src/main.cpp.o
Linking /data/zb-gw03-coordinator/.pioenvs/zb-gw03-coordinator/firmware.elf
RAM:   [=         ]  10.7% (used 34944 bytes from 327680 bytes)
Flash: [===       ]  32.6% (used 597981 bytes from 1835008 bytes)
Building /data/zb-gw03-coordinator/.pioenvs/zb-gw03-coordinator/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin(["/data/zb-gw03-coordinator/.pioenvs/zb-gw03-coordinator/firmware.bin"], ["/data/zb-gw03-coordinator/.pioenvs/zb-gw03-coordinator/firmware.elf"])
Wrote 0xa2510 bytes to file /data/zb-gw03-coordinator/.pioenvs/zb-gw03-coordinator/firmware-factory.bin, ready to flash to offset 0x0
========================= [SUCCESS] Took 9.24 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of zb-gw03-coordinator.local
INFO  -> 192.168.29.47
INFO Uploading /data/zb-gw03-coordinator/.pioenvs/zb-gw03-coordinator/firmware.bin (599312 bytes)
Uploading: [=                                                           ] 2% 
ERROR Error sending data: [Errno 104] Connection reset by peer

How do I overcome this?

Krs

Mark

Watchdog heartbeat timeout

@syssi first of all thank you for making this Esphome firmware possible for the zb-gw03.

I moved from a Sonoff Zbbridge where I had sometime some connection stability problems looking for a more reliable solution.
Unfortunately this seems totaly unstable, with bellows reporting a lot of watchdog heartbeat timeouts in the log.

It eventually stops working with HA reporting errors like this:

Error doing job: Exception in callback ThreadsafeProxy.__getattr__.<locals>.func_wrapper.<locals>.check_result_wrapper() at /usr/local/lib/python3.9/site-packages/bellows/thread.py:97
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/bellows/thread.py", line 98, in check_result_wrapper
    result = call()
  File "/usr/local/lib/python3.9/site-packages/bellows/ezsp/__init__.py", line 258, in frame_received
    self._protocol(data)
  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

which I read are tipical in the ZB to WiFi bridges.
So it looks like a connection problem, but HA PC and the bridge are connected via the same switch, and the bridge is never reported to be unavailable.

Toggling the Zigbee Reset switch solves the issue, but this problems occurs say every hour or two.
Any clue?
Thanks for your help.

[Feature Request] Compatibility with "SONOFF Zigbee Bridge Pro" (ZBBridge-P) based on ESP32 and CC2652P

This request comes a little ahead of its time since this ITead Sonoff ZBBridge-P is not available to buy yet, but it will be soon ;)

https://community.home-assistant.io/t/itead-sonoff-zbbridge-p-coming-soon-a-new-cc2652-and-esp32-based-sonoff-zigbee-bridge-and-sensors-from-itead-leaked-via-fcc/378924

UPDATE! ZBBridge-P (a.k.a. "ZB Bridge-P") has now been released as "SONOFF Zigbee Bridge Pro" as is now available for purchase:

https://itead.cc/product/sonoff-zigbee-bridge-pro/

FCC leak shows the upcoming Sonoff ZBBridge-P v1.1 Zigbee Bridge coming from ITead will be based on ESP32 and CC2652P.

https://fccid.io/2APN5ZBBRIDGEP

Wondering if can be hacked with ESPHome into a network-attached remote Zigbee adapter for ZHA (and Zigbee2MQTT)?

Internal pictures posted from FCC show using an unannounced Texas Instruments CC2652P (CC2652P1) MCU chip based “SM-031 v1.1” radio module which must be made by CoolKit (the company that makes their EFR32MG21 based “SM-011 V1.0” module).

ESP32 has replaced the ESP8266/ESP8285, and it also looks like added an onboard clock-battery too, presumably for RTC (Real-Time Clock)?

https://fccid.io/2APN5ZBBRIDGEP/Internal-Photos/Internal-Photos-5613131

FFC also leaked new Sonoff branded Door/Window Sensor, Motion Sensor, Temp/Humidity Sensor, and a Button as wireless Zigbee devices, all with the same CCC2652P (CC2652P1/CC2652P1F) chip which +20 dBm capable power amplifier is really overkill for battery-operated sensors and should on theory use more battery power than if they would have used the compatible CC2652R or CC2652RB.

Sadly it looks like even this new variant of Sonoff ZBBridge still uses Wi-Fi instead of a wired Ethernet network like the newer ZB-GW03:

https://community.home-assistant.io/t/zb-gw03-ewelink-ethernet-zigbee-gateway-now-hacked-with-tasmota-zbbridge-so-can-be-used-via-mqtt-or-as-a-remote-zigbee-adapter-with-home-assistant-zha-and-zigbee2mqtt/341223

Ethernet is preferred by DIY users who flash Tasmota or ESPHome in order to use it as a remote Zigbee adapter with ZHA or Zigbee2MQTT because tunnelling serial communication over a serial stream server connection and the serial APIs of the Zigbee stacks are not robust/stable over WiFi as assume a direct connection, which is why both ZHA and Zigbee warns against using WiFi-based networked-attached Serial-to-IP Zigbee bridges/gateways/adapters:

https://www.home-assistant.io/integrations/zha#warning-about-wi-fi-based-zigbee-to-serial-bridgesgateways

https://www.zigbee2mqtt.io/advanced/remote-adapter/connect_to_a_remote_adapter.html

According to digiblur who broke this news, these are slated to be released in March of 2022:

https://www.digiblur.com/2021/12/new-sonoff-zigbee-bridge-and-sensors.html

Not sure if this is intended to permanently replace the popular ITead Sonoff ZBBridge

https://community.home-assistant.io/t/sonoff-zbbridge-sonoff-zigbee-bridge-from-itead/187346

As I understand ITead have not abandoned Silicon Labs yet but it is just that Silabs chip stocks have suffered worse than most other companies during the still currently ongoing worldwide chip shortage.

PS: Assume it will use the same firmware for CC2652P as “Sonoff Zigbee 3.0 USB Dongle Plus”:

https://community.home-assistant.io/t/sonoff-zigbee-3-0-usb-dongle-plus-by-itead-is-based-on-texas-instruments-cc2652p-can-now-be-ordered-for-10-99/340705/283

error conection

Hi, if I don't program the module and connect it to zigbee home automation in HA, everything works for about 2-3 days, then esphome starts to report in the log:

INFO ESPHome 2023.8.3
INFO Reading configuration /config/esphome/zigbee-gate.yaml...
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO2 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO12 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO15 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Starting log output from 192.168.100.6 using esphome API
INFO Successfully connected to 192.168.100.6
[20:22:07][I][app:102]: ESPHome version 2023.8.3 compiled on Sep  6 2023, 20:55:58
[20:22:07][I][app:104]: Project syssi.esphome-zb-gw03 version 1.0.0
[20:22:07][C][status_led:019]: Status LED:
[20:22:07][C][status_led:020]:   Pin: GPIO15
[20:22:07][C][logger:301]: Logger:
[20:22:07][C][logger:302]:   Level: DEBUG
[20:22:07][C][logger:303]:   Log Baud Rate: 115200
[20:22:07][C][logger:305]:   Hardware UART: UART0
[20:22:07][C][i2c.idf:061]: I2C Bus:
[20:22:07][C][i2c.idf:062]:   SDA Pin: GPIO33
[20:22:07][C][i2c.idf:063]:   SCL Pin: GPIO32
[20:22:07][C][i2c.idf:064]:   Frequency: 50000 Hz
[20:22:07][C][i2c.idf:067]:   Recovery: bus successfully recovered
[20:22:07][I][i2c.idf:077]: Results from i2c bus scan:
[20:22:07][I][i2c.idf:083]: Found i2c device at address 0x50
[20:22:08][I][i2c.idf:083]: Found i2c device at address 0x58
[20:22:08][C][uart.idf:122]: UART Bus:
[20:22:08][C][uart.idf:123]:   Number: 1
[20:22:08][C][uart.idf:124]:   TX Pin: GPIO2
[20:22:08][C][uart.idf:125]:   RX Pin: GPIO4
[20:22:08][C][uart.idf:127]:   RX Buffer Size: 256
[20:22:08][C][uart.idf:129]:   Baud Rate: 115200 baud
[20:22:08][C][uart.idf:130]:   Data Bits: 8
[20:22:08][C][uart.idf:131]:   Parity: NONE
[20:22:08][C][uart.idf:132]:   Stop bits: 1
[20:22:08][C][switch.gpio:068]: GPIO Switch 'zb-gw03 Zigbee nRST'
[20:22:08][C][switch.gpio:076]:   Inverted: YES
[20:22:08][C][switch.gpio:091]:   Restore Mode: always OFF
[20:22:08][C][switch.gpio:031]:   Pin: GPIO13
[20:22:08][C][switch.gpio:068]: GPIO Switch 'zb-gw03 Zigbee Download Mode'
[20:22:08][C][switch.gpio:076]:   Inverted: YES
[20:22:08][C][switch.gpio:091]:   Restore Mode: always OFF
[20:22:08][C][switch.gpio:031]:   Pin: GPIO12
[20:22:08][C][template.switch:068]: Template Switch 'zb-gw03 Zigbee Reset'
[20:22:08][C][template.switch:091]:   Restore Mode: always OFF
[20:22:08][C][template.switch:057]:   Optimistic: NO
[20:22:08][C][restart:068]: Restart Switch 'zb-gw03 Restart'
[20:22:08][C][restart:070]:   Icon: 'mdi:restart'
[20:22:08][C][restart:091]:   Restore Mode: always OFF
[20:22:08][C][ethernet:221]: Ethernet:
[20:22:08][C][ethernet:363]:   IP Address: 192.168.100.6
[20:22:08][C][ethernet:364]:   Hostname: 'zigbee-gate'
[20:22:08][C][ethernet:365]:   Subnet: 255.255.255.0
[20:22:08][C][ethernet:366]:   Gateway: 192.168.100.1
[20:22:08][C][ethernet:375]:   DNS1: 192.168.100.1
[20:22:08][C][ethernet:376]:   DNS2: 0.0.0.0
[20:22:08][C][ethernet:397]:   MAC Address: A0:B7:65:57:A4:9B
[20:22:08][C][ethernet:402]:   Is Full Duplex: YES
[20:22:08][C][ethernet:407]:   Link Speed: 100
[20:22:08][C][ethernet:224]:   Power Pin: 16
[20:22:08][C][ethernet:226]:   MDC Pin: 23
[20:22:08][C][ethernet:227]:   MDIO Pin: 18
[20:22:08][C][ethernet:228]:   Type: LAN8720
[20:22:08][C][ethernet:229]:   PHY addr: 1
[20:22:08][C][mdns:112]: mDNS:
[20:22:08][C][mdns:113]:   Hostname: zigbee-gate
[20:22:08][C][ota:093]: Over-The-Air Updates:
[20:22:08][C][ota:094]:   Address: 192.168.100.6:3232
[20:22:08][C][api:138]: API Server:
[20:22:08][C][api:139]:   Address: 192.168.100.6:6053
[20:22:08][C][api:143]:   Using noise encryption: NO
[20:22:53][D][api:102]: Accepted 192.168.100.5
[20:22:53][W][api.connection:097]: 192.168.100.5: Reading failed: BAD_INDICATOR errno=11
[20:23:07][D][api:102]: Accepted 192.168.100.5
[20:23:07][W][api.connection:097]: 192.168.100.5: Reading failed: BAD_INDICATOR errno=11
[20:24:07][D][api:102]: Accepted 192.168.100.5

and the zigbee home automation integration says that the settings failed and it is no longer possible to connect to the module in the HA log, there is this `error:zigbee-gate @ 192.168.100.6: Connection error occurred: zigbee-gate @ 192.168.100.6: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (Home Assistant 2023.9.1).

20:36:07 – (VAROVÁNÍ) runner.py - zpráva se poprvé objevila v 9. září 2023 12:18:52 a zobrazuje se 3431x
Couldn't start application
20:35:21 – (CHYBA) /usr/local/lib/python3.11/site-packages/zigpy/application.py - zpráva se poprvé objevila v 9. září 2023 13:37:31 a zobrazuje se 1627x
Config entry 'socket://192.168.100.6:6638' for zha integration not ready yet; Retrying in background
20:19:13 – (VAROVÁNÍ) config_entries.py
Config entry 'socket://192.168.100.6:6638' for zha integration not ready yet; Retrying in background
20:18:46 – (VAROVÁNÍ) config_entries.py - zpráva se poprvé objevila v 10. září 2023 22:55:36 a zobrazuje se 3x
Error handling request
10:30:45 – (CHYBA) /usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py - zpráva se poprvé objevila v 9. září 2023 12:50:45 a zobrazuje se 5x

please help

[REQUEST] Zigbee Router configuration for ESPHome on ZB-GW03

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

I think that this firmware image should also be compatible with ZB-GW03 as it too uses "SM-011 V1.0"?

Do you think that ESPHome could send basic commands to Zigbee Router firmware to initiate paring/joining and restart/reset?

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.

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

Idea around this is also discussed for ITead's Sonoff ZBBridge hacked with Tasmota/ESPHome here:

arendst/Tasmota#11536

thegroove/esphome-zbbridge#3

xsp1989/zigbeeFirmware#2

xsp1989/zigbeeFirmware#16

I 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, and never bought a ZB-GW03, but might reconsider buying these 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.

Flashing from Tasmota

I have a zb-gw03 that came already flashed with Tasmota 13.2.0 (from Aliexpress). Can I flash esphome directly from the Tasmota firmware upgrade? If yes, perhaps it would be nice to add some short instructions for this case? As far as I read here, it seems flashing the zigbee module is also not necessary in this case.

Also if I can ask here - it seems most files are about 2 years old, were there no updates necessary? And are there any plans regarding the deprecation of ezsp?

Thanks

ZB-GW03-V1.4

Is the current firmware suitable for version 1.4?

How can pairing be started?

What does this do exactly?

I bought one of the GW03 hubs and came over to this repo from the HA community.
However, it's really unclear what this does.
A short description in the README of what it does and what to expect from it (and what not) would be great!

Improve the "Flash the Zigbee module" section of the documentation

Was able to get the code onto the device up to the point where I need to download the zigbee firmware.

I'm not sure what the instructions refer to with all the code below the "download and reset button" but when i do that step, nothing happens.

If i hit the download it gives me this in the log

[22:58:39][D][switch:013]: 'zb-gw03 Zigbee Download Mode' Turning ON.
[22:58:39][D][switch:037]: 'zb-gw03 Zigbee Download Mode': Sending state ON

If i hit the reset after I get this....no zigbee radio firmware downloads?

[22:59:56][D][switch:017]: 'zb-gw03 Zigbee nRST' Turning OFF.
[22:59:56][D][switch:037]: 'zb-gw03 Zigbee nRST': Sending state OFF

I also don't even get the temperature sensor data

Here is the full "download of the zigbee firmware" step output.

[23:16:00][D][switch:013]: 'zb-gw03-coordinator Zigbee Download Mode' Turning ON.
[23:16:00][D][switch:037]: 'zb-gw03-coordinator Zigbee Download Mode': Sending state ON
[23:16:00][D][switch:013]: 'zb-gw03-coordinator Zigbee Reset' Turning ON.
[23:16:00][D][switch:013]: 'zb-gw03-coordinator Zigbee nRST' Turning ON.
[23:16:00][D][switch:037]: 'zb-gw03-coordinator Zigbee nRST': Sending state ON
[23:16:00][D][switch:017]: 'zb-gw03-coordinator Zigbee nRST' Turning OFF.
[23:16:00][D][switch:037]: 'zb-gw03-coordinator Zigbee nRST': Sending state OFF
[23:16:05][D][switch:017]: 'zb-gw03-coordinator Zigbee Download Mode' Turning OFF.
[23:16:05][D][switch:037]: 'zb-gw03-coordinator Zigbee Download Mode': Sending state OFF
[23:16:05][D][switch:013]: 'zb-gw03-coordinator Zigbee Reset' Turning ON.
[23:16:05][D][switch:013]: 'zb-gw03-coordinator Zigbee nRST' Turning ON.
[23:16:05][D][switch:037]: 'zb-gw03-coordinator Zigbee nRST': Sending state ON
[23:16:05][D][switch:017]: 'zb-gw03-coordinator Zigbee nRST' Turning OFF.
[23:16:05][D][switch:037]: 'zb-gw03-coordinator Zigbee nRST': Sending state OFF

Any help?

Low Transmission Power

While troubleshooting a problem i was facing, in the configuration.yaml i enabled ZHA logs and i noticed that the radio module was set with a very low Tx power (8).
2021-01-25 09:04:00 INFO (MainThread) [bellows.zigbee.application] Node type: EmberNodeType.COORDINATOR, Network parameters: EmberNetworkParameters(extendedPanId=cc:cc:cc:cc:e3:ab:00:78, panId=0x3498, radioTxPower=8, radioChannel=25, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)

And in some HA discussion i saw that some users having the same parameter set to 20. I think that is related to the Zigbee firmware that i flashed from https://github.com/arendst/Tasmota/raw/development/tools/fw_SonoffZigbeeBridge_ezsp/ncp-uart-sw_6.7.8_115200.ota, is that correct?
I was wondering if there were any "new" firmware with higher Tx power or maybe some way to change it myself.

Is here the rigth place to ask? Or maybe the github of the firmware developement?

Add a section to the docs how to use Zigbee2MQTT

I currently run a docker host which has Home Assistant, ESPHome, Zigbee2MQTT and Mosquitto Broker to name the important bits. Zigbee devices are predominantly attached to a ConBee II that is attached to the server and mounted to Zigbee2MQTT, though I've now added the GW-03 also, with a 2nd Zigbee2MQTT instance, same broker.

The "Add the ESPHome node to Home Assistant" section in the docs is slightly different for me as I don't use the HASS integration and haven't fixed an mDNS issue that sees me chasing static IPs 🥺

The "Connect the device to the ZHA integration of Home Assistant" section in the docs has all the information except that for Zigbee2MQTT you can either go to the application itself and setup the adapter as follows:

I will have configured via the config files however, which is an entry of the following:

serial:
  port: tcp://192.168.1.100:6638
  adapter: ezsp

Official docs can be found here: https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html

If you like I can take a stab at a PR to list out both ZHA and Zigbee2MQTT options?

Originally posted by @cptbucky in #18 (comment)

Unable to connect to HA anymore

After working amazingly well for the last couple of months, last night I realized it stopped working.

HA could no longer connect to the device; I did many power cycles of the device as well as of HA.
HA recently got an OS update to 10.0, which I might still suspect is the problem for me.

I have now tried accessing the device over ZHA, Z2MQTT and both just do not connect to the device at all.

Z2MQTT Logs:

[12:36:34] INFO: Preparing to start...
[12:36:34] INFO: Socat not enabled
[12:36:35] INFO: Starting Zigbee2MQTT...
Zigbee2MQTT:info  2023-04-21 12:36:37: Logging to console and directory: '/config/zigbee2mqtt/log/2023-04-21.12-36-37' filename: log.txt
Zigbee2MQTT:info  2023-04-21 12:36:37: Starting Zigbee2MQTT version 1.30.3 (commit #unknown)
Zigbee2MQTT:info  2023-04-21 12:36:37: Starting zigbee-herdsman (0.14.103)
Zigbee2MQTT:error 2023-04-21 12:36:37: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2023-04-21 12:36:37: Failed to start zigbee
Zigbee2MQTT:error 2023-04-21 12:36:37: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2023-04-21 12:36:37: Exiting...
Zigbee2MQTT:error 2023-04-21 12:36:37: Error: spawn udevadm ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:285:19)
    at onErrorNT (node:internal/child_process:485:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

ZHA Logs:

2023-04-21 08:40:36.103 WARNING (MainThread) [homeassistant.components.zha.core.gateway] Couldn't start EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1, Telegesis coordinator (attempt 1 of 3)
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 205, in async_initialize
2023-04-21 08:40:42.310 WARNING (MainThread) [homeassistant.components.zha.core.gateway] Couldn't start EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1, Telegesis coordinator (attempt 2 of 3)
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 205, in async_initialize
2023-04-21 08:40:45.510 WARNING (MainThread) [homeassistant.components.zha.core.gateway] Couldn't start EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1, Telegesis coordinator (attempt 3 of 3)
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 205, in async_initialize
2023-04-21 08:40:45.512 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry socket://10.0.0.131:6638 for zha
File "/usr/src/homeassistant/homeassistant/components/zha/__init__.py", line 122, in async_setup_entry
await zha_gateway.async_initialize()
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 220, in async_initialize
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 205, in async_initialize

Any other ideas?

The device was working flawlessly and I am still able to flash new Firmware to it over Wifi with ESPHome

Z2M Deprecated driver 'ezsp' currently in use

Hi @syssi,

First, thanks for putting everything together to make things easier for newbies like myself. I've noticed a warning in the Zigbee2MQTT logs that looks like this:

[2024-08-12 02:40:24] warning: 	zh:ezsp: Deprecated driver 'ezsp' currently in use, 'ember' will become the officially supported EmberZNet driver in next release. If using Zigbee2MQTT see https://github.com/Koenkk/zigbee2mqtt/discussions/21462

I read through that discussion, but I couldn't find any non-serial Ember firmware for the zb-gw03. It seems they mostly tested the serial Zigbee adapters. Is it possible to switch from ezsp to ember on the zb-gw03? Would the flashing process remain the same, using telnet and lsx, but uploading a .gbl file instead of a .ota? Any help is much appreciated.