Consider removing the ITEAD Sonoff ZBBridge from ZHA integration list of hardware as EZSP over WiFi-based bridges is often not stable

[Hedda]

Feedback

Consider removing ITEAD Sonoff ZBBridge hardware from the ZHA integration's list of known working Zigbee radio modules as the EZSP (EmberzNet Serial Protocol) interface is now infamous in the community for being unstable when using WiFi-based bridges.

https://www.home-assistant.io/integrations/zha/#known-working-zigbee-radio-modules

• ITEAD Sonoff ZBBridge (Note! This first have to be flashed with Tasmota firmware and Silabs EmberZNet NCP EZSP UART Host firmware)

To clarify; I'm not suggesting support be removed in code, I only mean that WiFi-only bridges for EZSP should not be listed as "known working" as that, in turn, could be interpreted as stable and recommended, which IMHO looks to be the opposite how it works in real-world scenarios. I think it would be unfair to go around telling all of those users to buy better WiFi hardware instead of just listing/recommending other Zigbee hardware for EZSP that does go over WiFi.

The argument is that having OTEAD Sonoff ZBBridge listed at the top of the list of known working Zigbee adapters for ZHA makes it read as equivalent to recommended hardware (if not the top recommendation), is causing long-term harm to the reputation of ZHA because many first-time ZHA users seem to have a horrible experience with stability on it if they not have a 100% stable WiFi with zero packet loss as well as low latency response. Understand that a problem is that most other applications do not require a 100% stable WiFi solution so most users will not know/discover that their WiFi setup is not stable enough for Sonoff ZBBridge until after they already bought it.

FYI, both ZHA and bellows readme have cryptic warnings about WiFi-based bridges/gateways but IMHO those are not enough:

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

"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://github.com/zigpy/bellows#warning-about-zigbee-to-wifi-bridges

"The reason Ember remote bridges over a Serial-to-IP proxy/forwarding-server is not recommended is that clients using the EZSP serial protocol requires a robust connection between the EmberZNet Zigbee stack running on EFR32 MCU and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a 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 which caused packet loss to occurred between the zigpy radio library and the Zigbee radio. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with Silicon Labs Ember based Zigbee radios."

Please do read all Sonoff Zigbee bridge stability complaints on HA's community forums -> https://community.home-assistant.io You see a lot of first time ZHA users are having a bad time with the Sonoff ZBBridge, most of which have later proven to be WiFi related.

https://community.home-assistant.io/t/sonoff-zbbridge-sonoff-zigbee-bridge-from-itead/187346
https://community.home-assistant.io/t/zigbee-errors/292478/
https://community.home-assistant.io/t/sonoff-zbbridge-suddenly-appears-offline-but-is-online-and-working/274296
https://community.home-assistant.io/t/sonoff-zigbee-bridge-lost-devices-when-in-zha-mode/238511
https://community.home-assistant.io/t/moving-from-usb-stick-to-sonoff-bridge-any-issues/276656
https://community.home-assistant.io/t/zbbridge-version-of-tasmota-9-3-1-in-sonoff-zigbee-bridge/285084/
https://community.home-assistant.io/t/sonoff-zigbee-bridge-couldnt-start-ezsp/291417
https://community.home-assistant.io/t/diagnose-zigbee-network-issue/261742
https://community.home-assistant.io/t/zha-component-sometimes-falls-off-and-devices-become-unavailable-for-no-apparent-reason/270616
https://community.home-assistant.io/t/experience-with-flashing-tasmota-on-sonoff-zigbee-bridge-devices-is-it-flawless-and-how-do-those-compare-with-aqara-zigbee-sensors/230025/
https://community.home-assistant.io/t/what-is-the-best-zigbee-coordinator-to-be-used-with-zha/271742

Currently, when ZHA end-users ask for support with Sonoff ZBBridge in the forums and post that get this NCP entered failed state. Requesting APP controller restart error message they will generally be told that they should cut their losses and instead buy a USB stick/dongle or an Ethernet (wired) bridge/gateway version instead if wanting to achieve a stable connection over EZSP between the Zigbee coordinator adapter and ZHA/bellows/zigpy.

I believe that not having it listed here would at least make some users stop pointing their fingers ZHA/bellows/zigpy developers.

It might be stable enough for people who have extremely stable WiFi, but is it a product that should be advertised for as known working / recommended hardware ZHA?

Maybe just list a few (wired) Ethernet bridges/gateways under compatible hardware instead?

Note! Remember that this hardware recommendation is really aimed at new users and not at advanced/expert users. I think that new users are more likely to pick the cheap hardware listed at the top than do deep research about people experiences.

Disclaimer: I have in the past used Sonoff ZBBridge by ITead flashed Tasmota with ZHA in Home Assistant but since switched to USB-sticks (first I moved to Elelabs USB adapter but have since moved to Electrolama's zzh, so I am currently not even using EZSP).

PS: For reference; I was actually the one who originally added ITead Sonoff ZBBridge to the list via PR #14124

URL

https://www.home-assistant.io/integrations/zha/

Version

No response

[frenck]

I'm not sure this is a documentation issue. The integration supports it. Are you asking to remove support from it from the integration?

[probot-home-assistant]

Hey there @dmulcahey, @Adminiuga, mind taking a look at this feedback as its been labeled with an integration (zha) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[Hedda]

I'm not sure this is a documentation issue. The integration supports it. Are you asking to remove support from it from the integration?

No, I am suggesting that this is only a documentation issue and I'm not asking for any code to be removed from the integration.

Yes the integration technically supports it because an IP-to-Serial server just tunnels the EZSP (EmberZNet Serial Protocol) over a socket but that does not mean that using that interface over WiFi is a stable solution that should be recommended, and the reason for that is EZSP (EmberZNet Serial Protocol) is not a robust protocol in the way that it appears not to be designed to handle the type of packet loss that can often occur on home WiFi networks.

It technically works but it does not work well for many and it is nothing that can be solved with code. Support for it should not and can not be removed from the code as it uses the same method and protocol is used for EZSP (wired) Zigbee-to-Ethernet bridges as well EZSP USB dongles and EZSP GPIO and Serial modules, and those options are stable as do not rely on a WiFi bridge.

Recommending an open discussion on whether or not the ZHA integration documentation should list any Silicon Labs (EZSP) based Zigbee-to-WiFi bridges when they been proven that the EmberZNet Serial Protocol is not robust enough to handle any packet loss.

In my opinion, saying that a 100% stable WiFi connection is needed to use a Serial-to-IP proxy server for EZSP just hides the inherent architecture faults in the proprietary EZSP (EmberZNet Serial Protocols) which has a problem with poor fault-tolerance handling of packet loss and message latency delays.

Again, in my opinion, the root cause of the problem here is that Silicon Labs who are the authors of the EZSP serial protocol has not designed it to be fault-tolerant enough to handle the types of faults and errors that occur if you do not have a 100% stable connection, which is something that simply can not be guaranteed when tunnelling a serial protocol using a Serial-to-IP proxy server over a WiFi network.

The best solution would be if Silicon Labs could improve future versions of the EZSP protocol to have better fault-tolerance for packet loss and message latency delays, but since we can not depend on Silicon Labs to take action on that is just easier to recommend using WiFi-based bridges for EZSP in a Serial-to-IP proxy server setup to achieve a remote Zigbee adapter. Just telling everyone to fix their WiFi to hide these issues the EZSP protocol should not be the general recommendation.

PS: As an alternative, I did submit a PR for a clearer warning in ZHA integration docs about EZSP WiFi-bridges but that was rejected.

[frenck]

Just a simple warning as in: "Not recommended" next to the stick will do. We don't need a lot of discussion or documentation around that.

[Adminiuga]

There's an existing warning already. Closing this issue.

[Hedda]

Just a simple warning as in: "Not recommended" next to the stick will do. We don't need a lot of discussion or documentation around that.

FYI, a PR submitted #17179

[mrneutron42]

Thanks for adding this language.
I think it was a good idea to warn people of the wifi-Zigbee bridge instability, so they waste months trying to figure out why the Sonoff Zigbee Bridge doesn't deliver stable Zigbee operation.