Time to list EmberZNet firmware older than EmberZNet 6.7.x + adapters based on EFR32MG1x and older as "deprecated" in readme and upstream?

[Hedda]

Suggest consider deprecating all Zigbee 1.2 based firmware and older adapter hardware that was not designed to run newer firmware.

Directly related to this zha issue:

• [SUGGESTION] Add deprecation notice / legacy warnings to logs to flag older firmware and obsolete radio adapter hardware zha#601

For reference, Silicon Labs was obtaining Zigbee 3.0 certifications for hardware platforms using EmberZNet 6.7.0 firmware. The CSA certification database shows Zigbee 3.0 certification entries based on EmberZNet 6.7.0 certified on February 26, 2020.

Consider listing adapters older than EFR32MG2x + firmware older than EmberZNet 6.7.x as "deprecated" in readme and upstream ZHA integration docs?

• https://github.com/zigpy/bellows/blob/dev/README.md

Meaning change so readme and ZHA docs clearly states/sais "deprecated" (instead of just saying that it is "supported but not recommended").

• https://www.home-assistant.io/integrations/zha#compatible-hardware
  • https://www.home-assistant.io/integrations/zha#recommended-zigbee-radio-adapters-and-modules
    • https://www.home-assistant.io/integrations/zha#other-supported-but-not-recommended-zigbee-radio-adapters-or-modules

That is, without changing any code, just change official listing of support for EFR32MG1x, ETRX35x and Ember 35xx and similar older adapters + old EmberZNet firmware as being officially "deprecated" since a specific date, as deprecation warning.

Reason and arguments to deprecate Zigbee 1.2 coordinator that such old firmware and older Zigbee Coordinator adapter with slower MCU that have much less resources can lead to end-users having a bad experience which they might unfairly blame on the ZHA integration or the zigpy project.

Preferably also consider deprecation warning a such warning for such Zigbee Coordinator adapter in Home Assistant's ZHA UI. That way users will have been warned and you will have the option to remove support later when and if you like.

• Add deprecation warnings to logs stating Silabs firmware older than EmberZNet 6.7.x is deprecated and recommend user to upgrade firmware.

• Add deprecation warnings to logs stating bellows radio adapter hardware older than EFR32MG2x (i.e. all EFR32MG1x, ETRX35x and Ember 35xx ) is deprecated and recommend migrate to newer Zigbee Coordinator hardware.

• Make old firmware deprecated and old hardware be flagged in Home Assistant's ZHA UI as deprecated.

PS: This might be easier to communicate if could deprecate all Zigbee 1.2 based firmware in all zigpy radio libraries at the same time(?), including XBee and ZiGate which have said that want to formally deprecated in upcoming Home Assistant release to then remove later:

• Deprecate XBee and ZiGate zha#436

  • Time to list Z-Stack 1.2 firmware and adapters based on CC253x as "deprecated" in readme and upstream? zigpy-znp#276

  • Time to list ConBee 2 / RaspBee 2 and older adapters + old deCONZ firmware as "deprecated" in readme and upstream? zigpy-deconz#276

  • Time to list EmberZNet firmware older than EmberZNet 6.7.x + adapters based on EFR32MG1x and older as "deprecated" in readme and upstream? #726

---

Further arguments for adding such deprecation notice / legacy warnings in ZHA and zigpy radio libraries

While zha and zigpy will of course continue to supporting older Zigbee end-devices, zha/zigpy develpers might now want to seriously consider clearifying that using legacy Zigbee Coordinatior firmware and adapter hardware which was made to only support the Zigbee 1.2 specification should not be endorsed or encuraged in any way, and best way forward is probably to declare all those as deprecated.

Note! The suggestion here is not to actually remove support at this point, but only to warn about deprecating/deprecated firmware and radio adapter hardware. The goal with tis is to guide new and existing users towards using newer firmware and more modern radio adapter hardware that you plan to support long term, and discourage the use of those that will be phased out sooner rather than later because they are old and obosolete. This will help give users a better user experience and hopefully also mean fewer support issues due to old firmware and/or old hardware.

What deprecation notice / legacy warnings mean in this case in the simplest terms here is to activly recommend against using older firmware versions and old legacy radio adapter hardware that is no longer updated/maintained by the manufacturers (or in some cases have even been officially made end-of-life by the manufacturer). Preferably should also be officially listing deprecating in Home Assistant's ZHA integration documentation as well as the readme files for each zigpy radio library.

So while this project has always strived to run on almost all hardware, to keep the project moving forward and not having to support older legacy firmware and hardware forever you must sometimes make difficult decisions to deprecate old firmware and hardware, even if it is just on paper. In practice deprecation notices / legacy warning like this will only affect a small percentage of users, and ZHA users can already relativly easily upgrade or migrate to newer hardware. Even though they will be officially deprecated, you are giving existing users time to migrate to newer firmware and hardware.

Ultimatly this should help to reduce both technical debt by enabling you to eventuelly phase out old code, addressing security vulnerabilities in old firmware, while still allowing for graceful migrations, preserving backward compatibility until it will no longer be necessary to keep legacy support, benefiting both developers and end-users.

This will indirecttly also effect deprecate all firmware and radio adapter hardware not capable/suitible or designed for effectivly supporting firmware for the Zigbee 3.0 specification.

[MattWestb]

Pleas done messing things up with EZSP !!!
First you must knowing what Zigbee 3 is (and @Adminiuga was asking you for some years ago and you was and still dont knowing it) !!
I agree that Zigbee HA 1.X and ZLL1.X shall being desperate but your versioning of EZSP is not holing up.
From Silabs very old reseal note:

1 Release Highlights
1.1 Version 6.2.3.0 GA:
• Enhanced Zigbee 3.0 Compliance
– Green Power Proxy Basic updates
– Added Touchlink support
– Additional Clusters support

And wath i knowing IKEA was using it very log for LL and ZB3 firmware in there device that all was certificated.

The other part of Zigbee 3 is the stack version implemented and then we are talking Zignee PRO with different version and the latest global used is Zigbee PRO 2023 that making the base behavior of the network like force updating trust center link keys plus (that is supported from R18 if i remember right.

On the hardware side is one very old Ember 35xx radio with good performance and one moderate updated NCP firmware is working more then well and updating to one MG2X or MG3X is not making it better only getting more CPU, RAM and flash but the radio is still on the same level (around +100 dB revising and can transmission enough power OK. Only plus for the new one is you can running thread (MG2X) and matter over thread of having more RAM (not MG21).

For EZSP i saying its up to the devs how long they like / can supporting the very old protocol's in bellows but it shall not being any problems.

On the more technical side is it not helping upgrading the coordinator then devices is the network is not compatible for the new functions like updating link key, end device timeout request, passive broadcast ack (only sending broadcasts ones if all neighbors have rebroadcast the frame) and so on. Also how many modern routing devices have GP-proxy implemented that is moderate im many years but most is skipping it.

Also you need doing your fact collecting better with Zigbee 3 certification:

Firmware Version EmberZNet 6.5.0
Hardware Version EM35xx Family
Certificate ID ZIG19002ZCP27173-24
Certified Date 03/04/2019

https://csa-iot.org/csa_product/em358x-em359x-27/

The same is for EFR32MG1x Family (Series 1).
= non of your "fact" is valid !!!
So start reading the and understand that Standard Zigbee was starting with Zigbee HA 1.X and ZLL.
Then Zigbee PRO was released and on top of that Zigbee 3 was implemented with different revisions and network standards so saying that ZHA shall only supporting coordinators with Zigbee 3 stack is little week but better saying coordinator shall supporting Zigbee PRO (HA and ZLL out) is OK but useless.

I think our Puddly is the only one that can saying if we shall doping some old versions of EZSP then its blocking further development of ZHA in the future but i think its no need doing it (as all of our EZSP is using hashed link keys and not storing link keys in NVM that can being very limited in most firmware also very new MG2X/3X).

[puddly]

Bellows is structured to abstract away all of the coordinator version differences. There really isn't any downside to continuing to supporting EZSPv4 and all of the older firmwares. They work fine and are are missing only a few tiny features. You also can't really buy old coordinator hardware at this point so if you decide to use one, you know what you're getting into 😄.

And who knows, maybe an OpenThread firmware could be built for these older radios. You could then run them with https://github.com/zigpy/ziggurat/ with no downsides.

[MattWestb]

I think the most bad things in very old EZSP stacks is routing problems and cant temporary changing IEEE (only burning the chip) thats making it not easy merger networks to other adapters. Also very much low levels bugs is fixes in the Zigbee stack but some of the very old versions is working better then newer ones then Silabs implanting more undocumented futures (bugs) that is not in the old firmware and have taking long time to being addressed.

RUST !!

And no Python or coffee for our Puddly ?!?!?
Converted your drinking to Tea ??? 😄

By the way Thread 1.3 RCP is ruing great on Billy (MG1P) and also 1.4 is working so shall not being any problems using hosted Zigbee like we was doing with Multiprotocoll and not having the problems that ZGP was fighting with thread packages but very likely no support for EM35xx chips then need other compilers and its not supported by Silabs in later SDKs for Thread RCP.

[Hedda]

My point is not to remove support in the code, but to clearly inform users that they can get a generally worse user experience when using unmaintained "deprecated" firmware and older hardware (old hardware which is by the way clearly marked as "obsolete" by the manufacturer).

So I am talking about perceived user experience when comparing using older firmware on old hardware verses new firmware on new hardware.

Trying to look at it from the Open Home Foundation point-of-view you do not want users of ZHA to have a poor overall impression that some end-users might have when interacting with ZHA and Home Assistant simply because they looked at a list which say that older firmware and old hardware is fully supported and choose to get or keep using obsolete equipment with unmainatained firmware and thene possibly blame the Home Assistant and ZHA software instead of understanding that their old firmware and hardware might be the root cause to their bad experience

So I am only suggesting to add the word "deprecated" to old firmware and hardware, (but not remove code support in the libraries), because I believe that would help explain to users that their choice of firmware and hardware is not optimal and they might just get an overall better experince in the long term with less issues that make them blame the ZHA integration and Home Assistant as a product.

(As a bonus effect the Open Home Foundation could possibly also sell more of the Home Assistant Connect ZBT-2 adapter).

I do not think that they is any denying that older firmware means that it will not cntain general bug fixes in newer Zigbee stack SDK/firmware.

(Obviously having a Zigbee 1.2 network instead of a Zigbee 3.0 network also means lower security, though that is probably a low-risk factor).

Older Zigbee Coordinator hardware adapters with older radio chips do in in fact have higher susceptibility to noise.

Most older Zigbee adapters also suffer from limited onboard RAM and often only have built-in antenna.

[MattWestb]

I think we is not interpreting "deprecated" in the same way.
For my is one dead product that is not supported and can stop working next HA update or later then the devs is like to killing it with very short notice.
Putting old hard and firmware / stacks as "not recommended" is very OK but still some old stacks is very stable for normal use and shall not being putted on the list.
Your writing of the radio hardware is not valid if looking on old and new hardware.
One example on very bad RF hardware is all sheep ESP32 modules that is having maximal one capacitor mounted and the reference design have 5 or more (depends of how good filter for out of bad interference).
Comparing them with one old EM35X dongle / module that have one true HF transformer and R/T switch and very good LNA and dissent antenna is still one of the best hardware you can have as-long you is not using external high preform antennas.
(one more bad example first gen Sonoff MG21 stick . . Miss tuned radio and not good implemented RF design and so on)
Most importing is good radio hardware and enough RAM for running the firmware and as long we is running NCP its no large problems as we have well working firmware for them but old hard ware are not made for running Matter over thread (that MG21/22 cant doing with its modern hardware).

Also one very good example on bad modern product is IKEA Kajplats E14 and GU10 (E27 is little better) that have so bad antenna implementation and making them nearly working at all as thread router also in some decimeter distance (The plugs is very good but is using different chip and netter hardware module).

And as you saying Zigbee 3 i think only some % of all users of ZHA and Z2M is in true Zigbee 3 mode then only one tuya device and its degraded the networks security and mesh functionality like having one SED that like setting pull interval and its parent is not supporting it = battery drain and more network traffic and is not > R18 the TC link key is the well known one that is very normal for not certificated devices.

For my its enough but i dont see any user enchantments by labeling well working hard and firmware "deprecated" and its better writing more in the wikipages so user can getting real information and can using it for making good depressions for there systems.

By the way my ZBT-2 in the test system that shall have very good hard(and soft)ware is not able making one working mesh network with 24 devices instead its 80% one star network (only one router is having links to other routers and the rest only the coordinator) so one old EM / MG1 modules is doing it without problem and i think you is not knowing way.

[Hedda]

I think we is not interpreting "deprecated" in the same way.

The word literary means "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative". Quote taken from Merriam-Webster Dictionary:

• https://www.merriam-webster.com/dictionary/deprecate

Again, to first announce something "deprecate" does not mean that you have to remove the code that makes it works. Instead posting a such notice only means that you are informing your intension that you plan officially not offer official support. See this real-world use case example:

• https://www.home-assistant.io/blog/2025/05/22/deprecating-core-and-supervised-installation-methods-and-32-bit-systems

That is by the wayt a perfecty use case example because the Home Assistant Core and Home Assistant’s Supervised installation methods are still possible, the code has not been changed (it is even used by core developers), but it means that officially not supported. Unofficially you can still use it and it will probably work just fine, but given the public deprecation notice the users should not have expectation of support.

So it practice it is only slightly stronger working than just putting "it is not recommended", so publishing a deprecation notice is more like a less verbose way of saying "This is not recommended and we do no longer offer official support but the code has not been changed so you can still use it at your own risk if you like but if you have any issues then do not expect help so you probably want to upgrade sooner rather than later" 😜

[pipiche38]

What is the benefit to tell it is deprecated ... Honestly I don't see it . It would make sense if there are some developement and support effort to keep it, but if it is not what exactly is the benefit ?

[Hedda]

The point is to discourage the use of older hardware and older firmware, and instead encourage the use of newer/better alternatives which can give some user a overall better user experience. Please note that even if using old hardware or old firmware do not affect you personally, the userbase for the ZHA intgration in Home Assistant is at currently at least 500,000 installations (26.1% today according to https://analytics.home-assistant.io/integrations/ of the whole Home Assistant installations https://analytics.home-assistant.io/ ).

So even if only a small procentage of those have intermittant issues caused by using old hardware or old firmware it can still have an large impression effect on the percieved user experience and word of month if those users are vocal about haing poor experineces. Which is something that in my opionion is unessesary when it can be completly avoid simply by publicly suggesting via a deprecation notice that while all users of old hardware and firmware do not need to upgraded, it is highly recommended that they upgrade to newer hardware and firmware.

I do not understand the benefit of not listing old hardware and old firmware as deprecated when as suggested not actually changing or removing the code for it, the adapters will continue to work as-is, and the cost for each end-user of upgrading to newer hardware is very small today when they can buy a perfectly good new modern Zigbee Coordinator USB dongle based on EFR32MG21 for around $25 (US), or the currently best Zigbee Coordinator USB adapter in the world, ZBT-2, for less than $50 (US) which indirectly help employ zigpy/zha developers.

Fact is that manufacturerer (Silicon Labs) have themselved declared older hardware as obsolete and it is also a fact that firmware for older chips are unmaintained today and are not feature complete by todays modern standards (i.e. do not support Zigbee 3.0 secure provisioning for device pre-commissioning), and more importantly being built with older SDKs the firmware will have unfixed bugs for known issues that are fixed in newer SDK/firmware version, but the SDK/firmware is no longer being actively developed by the manufacturerer (Silabs).

Again, I am to not suggsting that anything be removed in the code, instead I am only suggesting that end-users should be be made informed of the fact if they are not running recommended hardware or recommended firmware.

IMHO this is not much different from puddly wanting to deprecate XBee and ZiGate, and even less impactful since code will not be removed:

Originally posted by @puddly in zigpy/zha#436

The XBee and ZiGate radios should be formally deprecated in an upcoming Home Assistant release and then removed in six months.

The radio firmwares for these devices are not feature complete, have unfixed bugs, and are no longer being actively developed.

[MattWestb]

One last bad example you was posted is the 32 bit HA that was completely killed after the "experiencing date".
Was having one small RK3223 box running 32 bit Armbian ubutu 2024 LTS and HA Suprevices. Was getting problem with storage in January and was copy one backup from earlier 2025. Reformatting and installing Arbian Ubuntu 32 bit 2024 LTS and install HA supreviced. Can install the backup but its halting then the suprevior is not updated. Updating the suprovisor and cant install the backup then its blocker of the updated supevisor so deprecated in HA terms = killed / dead system.

Listing recommended and not recommended hard and firmware is the best and no need killing devices that is working well for users. If the user like getting better experience then do one hard ware upgrade and dont try fix somthing that is not broken (expedition made for Puddly!!).

If Puddly is ending XBee and ZiGate radios is very OK removing then its no way getting them working OK.
The same shall being for old TI hardware that is running old Zigbee HA that cant handling network security at all and old EZSP as long protocol V4 is enough for ZHA working OK and not limiting the development is shall stay like that and perhaps rising the ribbon in the future then its needed but its one later problem.