Sonoff ZBBridge Pro w/ Tasmota - is Serial to IP over WiFi an issue?

Configuration Zigbee
1

I have a pretty robust home network, is the Serial to IP issue a big deal with Zigbee bridges like Sonoff ZBBridge Pro? Do they drop off the network continually and does Home Assistant recover gracefully or does it require a reboot?

Thanks.

2

There are lots of posts documenting the well known issues with the original ZBridge, and a specific recommendation against using such WLAN connected controllers in the documentation.

Here’s just one:

I don’t know about the ZBridge Pro, as the experience of the original was so terrible, and the experience of the Sonoff USB 3.0 so good, I see no reason to use anthyhing other than a directly connected device. If you have concerns about radio range, install a few cheap IKEA wall switches to act as Zigbee routers (and read how a mesh radio network works).

The Search feature on the forum can be very helpful!

3

Hi, I recently got one Sonoff ZB Bridge Pro and done the testing below.

In short, the serial to TCP get error from HA ZHA integration as below:

[zigpy_znp.uart] Connecting to socket://10.1.4.4:8888 at 115200 baud
[zigpy_znp.uart] Opened socket://10.1.4.4:8888 serial port
[zigpy_znp.uart] Connected to socket://10.1.4.4:8888 at 115200 baud
[zigpy_znp.api] Toggling RTS/DTR pins to skip bootloader or reset chip
[zigpy_znp.api] Sending request: SYS.Ping.Req()
[zigpy_znp.api] Sending CC253x bootloader skip bytes
[zigpy_znp.api] Sending request: SYS.Ping.Req()
[zigpy_znp.api] Received command: SYS.Ping.Rsp(Capabilities=<MTCapabilities.APP_CNF|GP|UTIL|ZDO|AF|SYS: 1625>)
[zigpy_znp.api] Radio is alive: SYS.Ping.Rsp(Capabilities=<MTCapabilities.APP_CNF|GP|UTIL|ZDO|AF|SYS: 1625>)
[zigpy_znp.nvram] Detecting struct alignment
[zigpy_znp.api] Sending request: UTIL.AssocFindDevice.Req(Index=0)
[zigpy_znp.api] Received command: UTIL.AssocFindDevice.Rsp(Device=b'\xFE\xFF\x00\x20\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF')
[zigpy_znp.nvram] Detected struct alignment: True
[zigpy_znp.api] Sending request: SYS.NVLength.Req(SysId=<NvSysIds.ZSTACK: 1>, ItemId=<ExNvIds.TCLK_TABLE: 4>, SubId=0)
[zigpy_znp.api] Received command: SYS.NVLength.Rsp(Length=20)
[zigpy_znp.api] Sending request: SYS.NVRead.Req(SysId=<NvSysIds.ZSTACK: 1>, ItemId=<ExNvIds.TCLK_TABLE: 4>, SubId=0, Offset=0, Length=20)
[zigpy_znp.api] Received command: SYS.NVRead.Rsp(Status=<Status.SUCCESS: 0>, Value=b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xFF\x00\x00\x00')
[zigpy_znp.nvram] Read NVRAM[NvSysIds.ZSTACK][ExNvIds.TCLK_TABLE][0x0000] = b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xFF\x00\x00\x00'
[zigpy_znp.api] Detected Z-Stack 3.3
[zigpy_znp.api] Connected to socket://10.1.4.4:8888
[zigpy_znp.api] Sending request: SYS.ResetReq.Req(Type=<ResetType.Soft: 1>)
[zigpy_znp.api] Request has no response, not waiting for one.
[zigpy_znp.uart] Closing serial port
  1. Both the HA and Sonoff ZB Bridge Pro are located at the same LAN without any network limitation. I can see the successful connection from HA:
MQT: stat/ZB_bridge_pro01/RESULT = {"TCPBaudrate":115200}
TCP: Starting TCP server on port 8888
TCP: Got connection from 10.1.4.1
TCP: Got connection from 10.1.4.1
  1. I have tried out using Zigbee2MQTT integration, also failed on timeout.
serial:
  port: tcp://10.1.4.4:8888

Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)

  1. I even tried on another new built HA vm: Error on ZHA integration

  2. Reload SonoffZBPro_coord_20220219.hex: Error on ZHA integration

FLH: Starting verification of HEX file
FLH: Verification of HEX file OK
FLH: cc2652_flasher rx=23 tx=19 rst=15 bsl=22
FLH: Flashing started (takes 5 minutes during which Tasmota is unresponsive)
FLH: Flashing completed: OK
FLH: Flash crc32 0x000000 - 0x2FFFF = bytes('1598929A')

In the end, used MQTT discovery for HA directly, currently are running well without any issue.

4

Certainly, on the non-Pro ZBridge the protocol was very unreliable, to the point where the fix was a credit card and hammer! :slight_smile: