Skip to content
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 ConBee 3 and move ConBee/RaspBee 2 to not recommended #31839

Closed
wants to merge 1 commit into from

Conversation

Hedda
Copy link
Contributor

@Hedda Hedda commented Mar 11, 2024

Proposed change

Add ConBee 3 as recommended radio + moved the older ConBee/RaspBee 2 radios to the not recommended section.

Also moved Elelabs retired radio adapters/modules to the not recommended section as no longer available for sale.

Type of change

  • Spelling, grammar or other readability improvements (current branch).
  • Adjusted missing or incorrect information in the current documentation (current branch).
  • Added documentation for a new integration I'm adding to Home Assistant (next branch).
  • Added documentation for a new feature I'm adding to Home Assistant (next branch).
  • Removed stale or deprecated documentation.

Additional information

  • Link to parent pull request in the codebase:
  • Link to parent pull request in the Brands repository:
  • This PR fixes or closes issue: fixes #

Checklist

  • This PR uses the correct branch, based on one of the following:
    • I made a change to the existing documentation and used the current branch.
  • The documentation follows the Home Assistant documentation standards.

Add ConBee 3 as recommended + moved ConBee/RaspBee 2 to the not recommended section.

Also moved Elelabs retired adapters to the not recommended section.
@home-assistant home-assistant bot added the current This PR goes into the current branch label Mar 11, 2024
Copy link

netlify bot commented Mar 11, 2024

Deploy Preview for home-assistant-docs ready!

Name Link
🔨 Latest commit cd08e47
🔍 Latest deploy log https://app.netlify.com/sites/home-assistant-docs/deploys/65eee2b03588380008010cb3
😎 Deploy Preview https://deploy-preview-31839--home-assistant-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link
Member

@frenck frenck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on what?

@home-assistant
Copy link

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

@home-assistant home-assistant bot marked this pull request as draft March 11, 2024 10:54
@Hedda
Copy link
Contributor Author

Hedda commented Mar 11, 2024

Based on what?

There are several factors why but in summery the ConBee II / RaspBee II Zigbee Coordinator adapters are based on an older outdated chip with too little flash storage and RAM so it will never get a new firmware that will native support for Zigbee 3.0 and ZGP (Zigbee Green Power), thus ConBee II / RaspBee II should be considered a legacy Zigbee Coordinator adapter similar to radio adapters based on the CC253x (CC2530/CC2531) from Texas Instruments:

  • ConBee II / RaspBee II does not support having a Zigbee 3.0 network so the network it forms is a Zigbee Home Automation 1.2 network and that means that all devices will connect in backwards compatible mode which has lower security, (so ConBee III will be the first deconz radio adapter to be native Zigbee 3.0 compatible).
  • ConBee II / RaspBee II old Zigbee stack will not be able to support ZGP (Zigbee Green Power) devices that will soon be added to ZHA/zigpy, (and also there the new ConBee III will be the first deconz radio adapter to be native Zigbee 3.0 compatible).

Dresden Elektronik specifically mention those two in their marketing materials for ConBee 3 -> https://phoscon.de/en/conbee3

What’s new

The shipping firmware supports Zigbee 3.0 and Zigbee Green Power devices. An OpenThread Border Router firmware is offered as an alternative application.

  • modern SiLabs EFR32MG21 micro controller
  • custom Zigbee 3.0 and Zigbee Green Power firmware
  • Bluetooth Low Energy (BLE) for future Thread and Matter applications
  • integrated push button for service functions

Also, ConBee II / RaspBee II is no longer getting firmware updates at all, with latest firmware released on the18th of March 2019:

In addition, no ConBee/RaspBee radios currently (including the new ConBee III) have support for commissioning Zigbee 3.0 devices via “Install Code” (or “QR Code”) via the ‘zha.permit’ service has as that has far only been implemented for ‘ezsp’ (Silicon Labs EmberZNet) or ‘znp’ (Texas Instruments) radio type in ZHA, so users having these will be limited compared to users of new Silabs and TI adapters:

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

Support for “Install Code” (and “QR Code”) for ConBee/RaspBee's including even the new ConBee II is missing support in the zigpy-deconz radio libraries for zigpy](https://github.com/zigpy/) because it is either still missing in the manufacturer’s firmware commands/APIs or there is no public documentation for the manufacturer's deconz serial protocol. See references:

zigpy/zigpy-deconz#214

and

dresden-elektronik/deconz-serial-protocol#20

If mean the Elelabs Zigbee USB Adapter ELU013 and Elelabs Zigbee Raspberry Pi Shield ELR023 then those not only no longer being sold but they are also based on older Silabs EFR32MG13P chip that will not get latest firmware, so even though supported I do not think t should be listed as recommended as then new buyers will make mistake purchasing them and not be able to update to the same newer firmware versions as the EFR32MG21 that the other listed Silicon Labs adapters are based on.

PS: Off-topic but a tip that owners of the ConBee II can after migrated away from it repurpose it as a Thread Border Router with an official OTBR firmware released by dresden-elektronik for the very purpose of not having it turn into e-warse for those replacing it with a newer adapter with Zigbee 3.0 and ZGP support.

@frenck
Copy link
Member

frenck commented Mar 11, 2024

ConBee II / RaspBee II old Zigbee stack will not be able to support ZGP (Zigbee Green Power) devices that will soon be added to ZHA/zigpy, (and also there the new ConBee III will be the first deconz radio adapter to be native Zigbee 3.0 compatible).

So, this is handling a future change and thus already changing a recommendation on something that isn't there?

Dresden Elektronik specifically mention those two in their marketing materials for ConBee 3 -> phoscon.de/en/conbee3

That is not related to ZHA support.

I don't get how this change on a recommendation by Core is driven by a community contribution. It is up to them to decide what to support. IMHO, this should be driven by our maintainers and by actual code changes that affect these.

I, therefore, think this PR should be closed for now.

../Frenck

@Hedda
Copy link
Contributor Author

Hedda commented Mar 11, 2024

So, this is handling a future change and thus already changing a recommendation on something that isn't there?

No, ZGP is just one aspect and not largest so I am sorry that even mentioined it which confused this, instead "Zigbee 3.0"support and its higher security is a much more important factor.

Fact is that ConBee II / RaspBee II has just like the original ConBee / RaspBee always been a legacy adapter because it has never supported "Zigbee 3.0". Same as the even older CC253x (CC2530/CC2531) from Texas Instruments, the ConBee II / RaspBee II does only support Zigbee 3.0 devices by them joining in their backward compatibility mode.

Lagecy adapters will still supported in ZHA but they should not be listed under "recommended" in ZHA docs, because while users can still connect Zigbee 3.0 devices to an older Zigbee Coordinaor they will not use the Zigbee 3.0 security protocol like they will if the user has a Zigbee 3.0 Coordinator.

I don't get how this change on a recommendation by Core is driven by a community contribution. It is up to them to decide what to support. IMHO, this should be driven by our maintainers and by actual code changes that affect these.

While I agree with what you are saying please understand that this is not related to any code change in ZHA. It is the ConBee II / RaspBee II firmware (i.e. the Zigbee NCP stack running on that chip) that has never supported Zigbee 3.0 and never will, that has really nothing to do with the ZHA integration but is a limitation with the older adapter running an old Zigbee stack in its firmware.

The point is that Zigbee Coordicantor like ConBee II / RaspBee II and CC253x (CC2530/CC2531) should not be listed as "recommended" in ZHA docs because even though existing users can continue to use it and it will continue to work, new users should not unknowingly get fooled into buying a Zigbee Coordinator just because ZHA docs list an old adapter as "recommended".

So the problem is that ConBee II / RaspBee II is currently specifically listed as "recommended" on the ZHA docs page and because of that people who are new to Home Assistant will go out and buy that old adapter that should have been listed as "not recommended".

You could maybe compare this to not recommending running a new software application on an old laptop that only supports an operating system that is no longer getting security updates, as even though the new software application will probably work fine from the end-users perspective that old laptop should not specifically be listed recommended because the users does not get as good security.

This is not a the type change that is driven by a code change in Home Assistant or ZHA but by an external factor as the manufacturer hardware and firmware have gotten outdated is no longer getting updates.

Right now, the ZHA docs page is listing ConBee II / RaspBee II as "recommended" when should be listed in the under "OTHER SUPPORTED BUT NOT RECOMMENDED ZIGBEE RADIO ADAPTERS OR MODULES"

@frenck
Copy link
Member

frenck commented Mar 11, 2024

Thanks for your response; however, my stance remains the same. Supported devices (and their recommendations), in this case, are not defined by the community but by this project.

Therefore, I'm going to close this PR for now.

../Frenck

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
current This PR goes into the current branch
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants