-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add recommendation not to use WiFi based EZSP bridges to ITead Sonoff ZBBridge #406
Conversation
…unstable Remove the ITEAD Sonoff ZBBridge from the list of compatible hardware as it is now infamously unstable. - [ITEAD Sonoff ZBBridge](https://www.itead.cc/smart-home/sonoff-zbbridge.html) (Note! This first have to be flashed with [Tasmota firmware and EmberZNet firmware](https://www.digiblur.com/2020/07/how-to-use-sonoff-zigbee-bridge-with.html))
FYI, both ZHA and bellows readme have cryptic warnings about WiFi-based bridges/gateways but IMHO those are not enough: "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 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 |
I dont agree !! First Sonoff was having problems with the "EZSP Sonoff bug" that is fixed in EZSP 6.7.8.0. and then they was having some bad data settings in there firmware and have released one " EZSP 6.7.9.0 (that is one 6.7.8.0) that is fixing that. If have one good stable WiFi Sonoff is working very well then looking how many is being used around in HA systems. And bellows is handling comport problems very well and its being logged in HA log then having problem. Compering with 2 other "supported coordinators": CornBee I and II: Is around the same performance perhaps better FR part then the SM-011 module have bad configurated antenna filters. Many users having problem with USB 3 ports and other devices attached with USB that is braking the continuation. Using EZSP radios with GIPO UART or with socket over WiFi or Ethernet is working great and dont have the "docker comport connection problems" and also the WiFi is working better for the moment that one USB connected radio that having problem with docker port mapping. I suggesting putting one light warning on Sonoff and one large warning on CornBee but all shall being on the supported list. TI CC-2531 is also working but is on the boarder to being supported at all then its to week both CPU, RAM and Flash for putting the money on for on new user and its very likely the user is being very disappointed and not using Zigbee at all because being burned of bad advice from the devs. An Headda do you have testing using one coordinator over WiFi like tasmota or ESPHome ?? |
For my its better getting user feedback before removing one device that many user is using daily in there system and its one discussion of experiences of coordinator that can being used for getting feed back zigpy/zigpy#576 Also "recommending" is little dangerous than all radio hardware have there good and bad side and its depends of the user experience and user case how its working for the user in the real world. And the best is to collecting user experience so user an see how good / bad its working in real. |
Know that EZSP 6.7.9.0 is not available https://github.com/arendst/Tasmota/tree/development/tools/fw_SonoffZigbeeBridge_ezsp
Still, that can not solve issues with those people who do not have a 100% stable WiFi connection 24/7/365, and I think it would be unfair to go around telling all of those users to buy better WiFi hardware instead of just recommending other Zigbee solutions. Understand that a problem is that most other applications does 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.
Yes 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 bellows).
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 Note! Remember that this hardware recommendation is really aimed at new users and not at advanced/expert users like yourself. I think that new users are more likley to pick the cheap hardware listed at the top then do deep research about people experiences. |
Im very sorry but i cant saying to the tasmota devs wot they shall do or not but the supplier of the signed firmware have supplied one new firmware and is recommending it.
WiFi is trying resending packages that is not being OK but its making the latency being larger that can being bad. But is you is having so bad WiFi you shall not using it for one HA system at all and that the user must realize and learning fixing that.
Then you is very likely being hitted of the docker comport problems that is one plague for all USB connected devices the last months.
I still its better putting user experience in the discussion so user can see wot is good and bad and can making there own decision and not black listing or recommending specific hardware !! If you is living in US you need one good lawyer for getting you not paying users that is being fucker up of bad recommendations. |
While I don't disagree with your asssessment that beginner users or users with subpar wifi infrastructure may experience issues with wifi bridges, I would rather this be a warning to users rather than pulling support outright. In my case I have spent a lot of time and effort upgrading the home wifi with multiple APs and dedicated controllers. For some users it will make sense to use a wifi bridge (where the machine running ZHA is sitting in a closet with poor signal penetration). The choice should be there for users rather than us making the decision for them. |
To clarify; I'm not suggesting support be removed in code, I only mean that WiFi-only bridges should not be listed in readme files.
Again, we are not removing the option to use it here, we would only be delisting from the readme file as a recommended choice. It is right now listed at the very top under supported devices and many new users would probably read that as the #1 choice to buy. I am suggesting that this is only a documentation issue and I'm not asking for any code to be changed to remove the support. Yes bellows 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 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. |
Update ZHA integration documentation with info about ITead new dongle and Sonoff ZBBridge: Added the new "ITead Zigbee 3.0 USB Dongle (EFR32MG21) Model 9888010100045". Added a recommendation not to use Sonoff ZBBridge as EZSP WiFi bridge with ZHA.
Codecov Report
@@ Coverage Diff @@
## dev #406 +/- ##
=======================================
Coverage 99.94% 99.94%
=======================================
Files 44 44
Lines 3359 3374 +15
=======================================
+ Hits 3357 3372 +15
Misses 2 2
Continue to review full report at Codecov.
|
Update: Changed the PR to just add a small note recommendation not to use WiFi-based EZSP bridges to ITead Sonoff ZBBridge:
Tip! If still need a network-attached remote EZSP adapter then recommend instead use a (wired) Ethernet-based solution. Examples:
|
FYI, ZHA integration documentation for Home Assistant is now been updated with the same suggested "not recommended" note: https://www.home-assistant.io/integrations/zha/#known-working-zigbee-radio-modules
https://www.zigbee2mqtt.io/how_tos/how_to_connect_to_a_remote_adapter.html Again, we do not want to prevent anyone from using a Zigbee to WiFi bridge, but do not want to recommend them to new users. Quote posted by @dmulcahey in zigpy/zigpy#584 (reply in thread) and zigpy/zigpy#584 (reply in thread)
|
Closing and replacing with PR #413 |
Consider removing the Sonoff ZBBridge from bellows list of hardware as EZSP over WiFi-based bridges is now infamously unstable.
Argument is that having Sonoff ZBBridge listed in the readme file of bellows, which makes it read as equivalent to recommended hardware, is causing long-term harm to the reputation of zigpy and ZHA because many first-time users have a horrible experience with stability on it.
Currently, when zigpy and ZHA end-users ask for support with Sonoff ZBBridge they are 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 bellows/zigpy/ZHA.
I believe that not having it listed here would at least make some users stop pointing their fingers bellows/zigpy/ZHA developers.
It might be stable enough for people who have extremely stable WiFi, but is it a product that should be advertised for zigpy/ZHA?
Maybe just list a few wired Ethernet bridges/gateways under compatible hardware instead? ...in a separate pull request of course.
PS: For reference; I was actually the one who originally added ITead Sonoff ZBBridge to the list via PR #285 and zigpy/zigpy#447