EFR32MG21 and CC2652P usage

[lacrimal]

Hi,

Have EFR32MG21 and CC2652P (both Sonoff), trying to use them with not-edge version of Z2M. While CC2652P work simply solid, it has smaller transmit power. From other hand EFR32MG21 works perfectly with ZHA but in Z2M it drops devices and have problems with pairing - for example gl-c-002p has serious problems with pairing and mode change. Sometimes I need to do weird stuff with dongle and Z2M to force it to pair with EFR.
I know that EFR support in Z2M is completely experimental and that is cause of my question.

Considering stability, should I return EFR and wait for better support using stable CC2662P or switch to Z2M edge with EFR and return CC?

[jerrm]

Right now, keep the 2652 stick. You can change the tx power to the same +20db as the "E" - https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html

But... that link is a little out of date. I think the current default is +9db.

I have doubts +20db offers much real world improvement.

[lacrimal]

Now something surprising - after moving to Z2M latest-dev - all problems are gone with EFR32MG21, pairing, re-pairing, switching disconnecting devices and connecting them back, and ... gl-c-002p mode change - everything works just fine.
Now I'm confused.

[yotsimitsu]

Hi, just a quick question, is the ‎GL-C-002P fully supported on Z2M? I wasn't able to find it in supported device and this thread is the only mention of it in here.

[lacrimal]

GL-C-002P is just combination of different devices as you cycle 'modes' , so it can represent itself as 006p or 009p.
More, Z2M reacts on mode change 'on the fly'. It was mentioned at least 3 times here on Z2M GitHub.

[yotsimitsu]

Ok, that makes sense and explains why I didn't find it in supported devices.
When I searched Github this was the only mentioned of this device that showed up.
Thank you

[dash042]

so should we get the EFR32MG21 or the CC2652P?

[jerrm]

I guess my best summary would be CC2652P is probably best TODAY. ER32MG21 might be better long term.

Hopefully migration between the two will be made more user friendly and it won't be a big deal to move between sticks.

[Koenkk]

CC2652P = recommended, EFR32MG21 = experimental. So get a CC2652P .

[seblu]

I bought an EFR32MG21 few weeks ago and I have a lot of problem with it. Sometimes devices disappear from database (like #15299), sometimes the docker process goes rogue and use all the memory leading to OS crash.
It worked fine until I added devices that were sending unexpected frames.

So, I ordered CC2652P.

[freefos]

What is the status of the EFR32MG21 or is the CC2652P still the right choice?
Currently deciding between SLZB-06 and SLZB-06M.

[jerrm]

Still no z2m native backup/restore for EFR32. Based on that alone I'd still go with CC22652P.

[Hedda]

Hopefully migration between the two will be made more user friendly and it won't be a big deal to move between sticks.

+1 hoping that ezsp adapter and deconz adapter in zigbee-herdsman will get both backup and restore feature, same as the z-stack adapter

PS: FYI, see this other existing discussion for third-party tool for workaround to migrate between different types of radio adapters -> #16478

[willieee802]

does it require repairing when switching from efr32 to 2652P adapter ?

[Hedda]

It depends, see #16478

but also see #23020

[lacrimal]

Shortly - is EFR32MG21 still considered experimental ?

[Hedda]

Not experimental if using the newer ”ember” driver (adapter) in Zigbee2MQTT and supported EmberZNet firmware which is currently version 7.4.x

https://www.zigbee2mqtt.io/guide/adapters/emberznet.html

Note that the older ”ezsp” driver (adapter) that never made it out of experimental stage is now obsolete and deprecated.

https://www.zigbee2mqtt.io/guide/adapters/

Also note that newer EmberZNet 8.x.x firmware is still experimental (and older than 7.3.x not supported at all with the new ”ember” driver).

[lacrimal]

That's quite nice, since noticed info about ezsp deprecation - switched to new driver :-)

[Hedda]

Oh, and Multi-protocol / Multi-PAN RCP firmware is not currently supported either due to the various issues associated with it. So need to make sure you are using EmberZNet NCP firmware (and not RCP Multiprotocol firmware), which you probably are since EmberZNet NCP firmware has always been the standard, (unless you bought a SkyConnect dongle and been experimenting with Thread and multiprotocol).