search

zigpy / zigpy-znp

TI CC2531, CC13x2, CC26x2 radio support for Zigpy and ZHA
GNU General Public License v3.0
144 stars 39 forks source link

List CC2530 and CC2531 under "Legacy support" and comment them with "not recommended"? #115

Open Hedda opened 2 years ago

Hedda commented 2 years ago

Suggest to move CC2530 and CC2531 compatibility listing in both zigpy-znp README.md and Home Assistant's ZHA integration to a "Legacy support" subsection catagory under compatible hardware and comment them with a "not recommended" explanation as CC2530 and CC2531 based adapters should not be mistaken by beginners or new Zigbee users as a recommendion to purchase.

Or what do you think?

Zigbee2MQTT community have recently added such "not recommended" comments to their supported adapters lists with arguments that while CC2530 and CC2531 based Zigbee coordinator adapters will still work in many scenarios with only a few Zigbee adapters they are from now on officially no longer recommended by the Zigbee2MQTT community at all since they use outdated chips that are obsolete for Zigbee 3.0 and their older firmware which is no longer being maintained by TI.

https://github.com/zigpy/zigpy-znp/blob/dev/README.md#hardware-requirements

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

The point here is to discourage new users from going out and buying CC2530 and CC2531 based adapters, (which they continue to do, presumably because they remain the most inexpensive and most readily available Zigbee coordinator adapters out there).

Thus might be a good idea for zigpy-znp and Home Assistant's ZHA integration to update compatibility lists in documentation by adding a clear recommendation that CC2530 and CC2531 are not recommended in a "production" environment (since not powerful enough and firmware upgrades or bug-fixes had no longer been provided by the manufacturer for a long time now). Hopefully, this will indirectly encourage new users/beginners to instead buy newer CC26x2 and CC13x2 based adapters instead.

References:

https://www.zigbee2mqtt.io/guide/adapters/#not-recommended

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/README.md#im-using-a-cc2530-or-cc2531-which-firmware-should-i-use

Note that Zigbee2MQTT community is now even listing CC2538 as "not recommended" in favour of newer CC26x2 and CC13x2 based adapters instead in order so that new users do not go out and blindly buy old CC2538 hardware as their first Zigbee coordinator just because it is listed as compatible hardware.

PS: puddly also posted this comment in #48 about CC2538 around a year ago "The last Z-Stack update for it was released more than two years ago and it will not support the newer route discovery features that improve network stability because the version of Z-Stack that it's stuck with supposedly has glitches."

Hedda commented 2 years ago

README.md for zigpy-znp added "not recommended" notes for CC2538 but maybe stronger worded discouragement is needed?

https://github.com/zigpy/zigpy-znp/blob/dev/README.md#hardware-requirements

CC2530 and CC2531 is compatible with zigpy-znp however not recommended due to slow old hardware and end-of-life firmware.

Hardware requirements

USB-adapters, GPIO-modules, and development-boards flashed with TI's Z-Stack are compatible with zigpy-znp:

Hedda commented 2 years ago

FYI, submitted a PR for ZHA docs with a "not recommended" comment for all CC253x -> https://github.com/home-assistant/home-assistant.io/pull/21226

The problem is ZHA docs list it as supported so many new users still buy them -> https://www.home-assistant.io/integrations/zha/

Again, primarily just want to deter new buyers to purchase CC253x based adapters as keep hearing explanations and anecdotes from many new users in the community still buying them after just quickly looking at the list of compatible adapters in the ZHA docs and then going to Amazon online and picking the least expensive compatible Zigbee coordinator without doing any further research about the hardware or firmware.

pipiche38 commented 2 years ago

Honestly for the CC2538/CC2592 I don't see what is the issue. if the Hardware is old - and of life this is not the zigpy-znp issue. Now if the hardware because it is old do not support some features that are needed I would then understand.

Hedda commented 2 years ago

The main problem is the fact that at least CC2530 and CC2531 MCU chips are underpowered for modern use with many devices.

if the Hardware is old - and of life this is not the zigpy-znp issue.

While that is true, the problem is support and false bug reports as well as first-impression feedback/reviews from beginner users just starting out when the new end-users still keep buying CC2530/CC2531 based adapters as an impulse buy on a whim simply because of those listed as compatible the CC2530/CC2531 based ones are least expensive and most available worldwide.

Those end-users are normally not met with positivity from more experienced community members who will usually tell them "buy a new adapter and do not use CC253x" which is throwing away time and money for those new users and a perhaps fair that they then go and tell their friends that the community have a bad attitude which is not friendly to new users.

Yes you could say that users who don't do research are lazy but that does not stop them from spreading rumours online that zigpy based implementations do not work properly, forgetting to mention that the reason might be the obsolete hardware they bought because it was cheap.

Please understand that I am not trying to solve a technical problem here but instead solve an educational issue, as in trying to educate or scare new users to not buy CC2530/CC2531 so that they do not make a mistake due to them being uninformed which that will give them a bad experience that could lead to them not continuing to use zigpy based implementations or worse, bad talk zigpy based implementations to others so that end result is a smaller userbase, which perhaps leads to fewer developers.