Bluetooth controller firmware for EFR32MGxx compatible with Home Assistant's new native Bluetooth integration?

[Hedda]

Could a Bluetooth controller firmware be built for EFR32 that is compatible with Home Assistant's native Bluetooth integration?

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

That is, could you build a Bluetooth controller firmware with Bluetooth Low Energy (BLE) support for ex. EFR32MG21 adapters?

Home Assistant 2022.8 August 2022 release now got first-class Bluetooth support (though still not got many integrations using it):

https://www.home-assistant.io/blog/2022/08/03/release-20228/#first-class-bluetooth-support

Read EFR32MG2x multi-protocol SoCs support Bluetooth but have not seen any Bluetooth adapter for computers based on them?

https://www.silabs.com/wireless/bluetooth

Silicon Labs mention Bluetooth 5, Zigbee, and Thread protocol stacks are provided for EFR32MG21, EFR32MG22, and EFR32MG24:

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs

Would be awesome if could flash existing 20 dBm EFR32MG21 adapters sold for Zigbee with "Bluetooth Long Range" firmware.

Home Assistant currently lists known working Bluetooth adapters based on BCM20702A1, RTL8761BU/RTL8761B, CSR8510A10:

https://github.com/home-assistant/home-assistant.io/blob/next/source/_integrations/bluetooth.markdown#known-working-adapters

PS: Home Assistant 2022.9 (September 2022) release will also add support for using multiple Bluetooth adapters at the same time:

https://github.com/home-assistant/home-assistant.io/blob/next/source/_integrations/bluetooth.markdown#multiple-adapters

[grobasoz]

Sure its possible. I've had a brief look at the options and tried a BT Home device based on ESP32 and looks straightforward enough...

[Hedda]

@agners Guess that if a Bluetooth firmware is built for EFR32MG21 adapters then HAOS might need a driver/firmware for it too?

"sl_bt" / "sl_bt_*" for Silabs Bluetooth controller devices if using Silicon Labs Bluetooth SDK v3.0 and v4.0 I think?

Example: home-assistant/operating-system#2123

[MattWestb]

I think using one +20dB EFR32MG21 as one general BT adapter is little wasted money then can baying one much cheaper that working out of the box with CE label (= China Export in some part of our globe and not EU certificated).

And doing one custom PCB with USB chip and firmware is not making it worth the money if not having one very special case for extra functions in the BT firmware.

[agners]

In the EFR32 case, the firmware would need to be flashed to the device persistently. So it is not the kernel which downloads the firmware.

I'd assume that the standard HCI via UART would be used, but this community thread suggests that this is not supported? On the other hand, this newer AN1328 seems it should, but would only support Bluetooth LE?

[agners]

I think using one +20dB EFR32MG21 as one general BT adapter is little wasted money then can baying one much cheaper that working out of the box with CE label (= China Export in some part of our globe and not EU certificated).

Yeah I agree, and those other adapters work just fine with BlueZ.

Afaik, Bluetooth on the EFR32 is mainly useful for devices, e.g. if you build a Matter bulb, having Bluetooth on the same radio allows to support the BLE on-boarding etc.

[Hedda]

wasted money then can baying one much cheaper that working out of the box

I think that $19.99 US-dollar for ITead's "Sonoff ZBDongle-E" is inexpensive for that looks to be a relatively good quality product:

• https://itead.cc/product/zigbee-3-0-usb-dongle/

Can alternatively from $9 in China get the EFR32MG21 based "easyiot" and "ZB-GW04" dongles based on "SM-011 v1.0" module:

• https://easyiot.aliexpress.com/store/5839056
• https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20220915235643&origin=y&SearchText=%22ZB-GW04%22&spm=a2g0o.detail.1000002.0
• https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20220915235721&SearchText=easyiot+dongle&spm=a2g0o.productlist.1000002.0

But more importantly, what if the performance of EFR32MG2x is better than the slightly cheaper BCM, CSR, and RTL based ones?

https://www.home-assistant.io/integrations/bluetooth/#known-working-adapters

Do you think that an EFR32MG21 based Bluetooth adapter could/would offer worse or better range and coverage those others?

[Hedda]

On the other hand, this newer AN1328 seems it should, but would only support Bluetooth LE?

EFR32MG21 SoC series (and EFR32MG24 SoC series) listings does mention "Compatible with Bluetooth 5, Bluetooth 5.1 and Bluetooth mesh specification", then they also list protocol support for "BLE" and "Bluetooth mesh", so guess depends on SDK and BT stack? -> https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs

[Hedda]

In the EFR32 case, the firmware would need to be flashed to the device persistently. So it is not the kernel which downloads the firmware.

Yes that was my thinking. Flash a EFR32MG21 based adapter with only a Bluetooth "controller" firmware in order to permanently make it into a dedicated Bluetooth USB adapter for Home Assistant Bluetooth. As alternative to "KNOWN WORKING ADAPTERS":

https://www.home-assistant.io/integrations/bluetooth/#known-working-adapters

So to clarify, I was not thinking about using it as a multiprotocol RPC adapter to use Zigbee and Thread at the same time.

[agners]

EFR32MG21 SoC series (and EFR32MG24 SoC series) listings does mention "Compatible with Bluetooth 5, Bluetooth 5.1 and Bluetooth mesh specification", then they also list protocol support for "BLE" and "Bluetooth mesh", so guess depends on SDK and BT stack? -> https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs

Figuring out what firmware is exactly needed and how it integrates with Linux/BlueZ is probably a big part of getting something done in that direction. I fear that its not straight forward. It might need custom drivers on Linux side and/or BlueZ to get full Bluetooth support. This doesn't come for free.

But more importantly, what if the performance of EFR32MG2x is better than the slightly cheaper BCM, CSR, and RTL based ones?

What if not? Then lots of effort for not much gain (pun intended 😅 )

Anyways, EFR32 & Bluetooth is currently not on my list of things I am planning to do.

[MattWestb]

Thanks Stefan !!

Gary is you interesting putting BT support for EFR32 hardware by digging in Silabs SDKs and getting the code working for genera purpus and doing all testing of the firmware and also very likely doing the Linux driver part ??

If doing BT mesh network with custom function for one large customer i thing its one business case for hard and software.

The cheapest BT5 USB stick i was finding on Amazon was is under 5€ with free shipping for prime and need selling many for that for paying all the time and efforts for "porting" BT to EFR32 devices that is costing more to manufacturing and bringing zero to the user.

[grobasoz]

I'm with Stefan on this, not seeing much need for an EFR32 based Bluetooth solution. I'd prefer to reserve any EFR32 modules for ZigBee SoC devices and Thread/Matter RCPs...

[Hedda]

Have you btw read about the new ”Zigbee Direct” specification (which as only applies to Zigbee Router firmware) -> zigpy/zigpy#1080

[grobasoz]

Yes - I saw the Zigbee Direct support had been ratified by CSA but didn't see it in the Silabs SDK release (4.1.3) yesterday or release notes.
Edit> Some of "us" have been doing this for a while already through custom clusters :)

[Hedda]

Don't think Zigbee Direct will be added to SDK until after CSA release Zigbee Revision 23 (R23) specification -> zigpy/zigpy#1081

I believe they only have announced demo for it so far? -> https://www.silabs.com/support/training/zgb-201-what-is-zigbee-direct

[MattWestb]

Im some time zones to late ;-(((

One Garry thing found:

• Updated compiler support to GCC 10.3-2021.10 and IAR 9.20.4

And some fixes for xGM240 devices (that i dont have) so mot much new but the GCC update can doing some good things in the end.

[grobasoz]

@MattWestb - I have been using IAR 9.30.1 for a while now and it works fine - just need to update the project at times. Also started moving all my code to EmberZNet V4.1.3 - just in case EmberZNet 3.x is dropped...
You sent me a message last night (for me) but I can't find it - sorry... where did you post the message?
Also started a discussion on a Coordinator project :)

[MattWestb]

Was not sending one message only that the time zone was making you was "finding" 4.1.3 before my then i was sleeping.

OTR things is elusive using GCC for projects with Open Thread.

One warning with 4.X EZSP (running CCP firmware and not native NCP / EZSP on the SOC): Looks like last gen IKEA devices is requesting one master key then requesting updating TC-Link Key and the TC is not answering the request and the device is leaving the network after 3 requests (= good behaving ZB3 device) and with EZSP 6.10.3.0 (NCP on the SOC) the device is requesting one TC-link Key and its working OK.

Have sniffing the node description response from the coordinator but both looks the same so its little strange.

[grobasoz]

I saw a similar issue on the Silabs Forum - but was not able to recreate it here...
Also here...

[MattWestb]

I think my problem is EZSP 4.x related and / or NCP / RCP but have not digging deep enough for finding the problem.
zigpy/zigpy#894 (comment)