Old Elelabs Zigbee radio modules

[MattWestb]

Pre advising of likely upcoming device support.
Elelabs Zigbee have 2 old radio modules with unknown firmware that is based on the EM357:
Elelabs Zigbee Raspberry Pi Shield EZBPIS and Elelabs Zigbee USB Adapter EZBUSBA.
I think your updater can manager the USB one but perhaps not the PI shield.
I have not finding any hardware info (i have not searching so well) so i dont knowing is the "Gary" standard firmware is working. Hopefully they have using Silabs reference design and its working out of the box.

I have one user with the famous IKEA battery draining with one of this but i cant recommending testing the new firmware then i dont have the knowledge to recovering it if its not working.
Is it possible reading the EM35Xs flash with SWD flasher and flashing it back if the upgrade is not working like with the EFR32 ones (dumping bin files and converting then to ELF files and flashing them back) ?

If hi is interested i have recommended hi asking in your git for advise.

Elelabs is also having one pair of EFR32MG1B modules that is also not have getting one updated firmware but primary not your problem and is making no sin abusing Gary with no user case firmware requests until some user is asking for it.
I putting them on on the list with not cocked firmware.

Its only one "information" that can being good to knowing and no need any work being done then its not being one user case of it.

Thanks for great work done !!

[walthowd]

They do support SWD and JTAG, see page 35 - section 4.7.6:
https://www.silabs.com/documents/public/data-sheets/EM358x.pdf

However, I've never personally dumped or flashed a EM3581 this way.

However, SWD is the standard procedure to get started on the ebyte modules, so perhaps others would have more experience.

[MattWestb]

I was thinking you was burning your Ecosmart A19 module with SWD !!

The EFR32MG1s is simple and can using one ESP8266 or STM32 and black magic probe for flashing and dumping the flash regions.
The last is the tuya ZBGW that i have dumped but not writing beck but with SWD its shall being very easy only converting the bin files to elf and flashing as i have done with my Billys.

Its looks like the EM35X is not supported by black magic probe so need one real J-Tag or clone for dumping / flashing them.

The problem if downloading on EZSP that is being flashed OK but have the wrong RX and TX pins its not so easy getting back if not knowing the bootloader pin (if the bootloadre is having it at all).

The good is that the devs normally is lazy using the reference design and then the pinout is Silabs standard and the the standard firmware is working (IKEA was not doing).

I hope Elelabs is replaying with the hardware pinout so we can getting its clear if they is standard or not and not making our user sad then braking there hardware.

I keeping you informed is i getting more interesting information.

[MattWestb]

The user have taking one look inside and its no EM357 its one EM3585 with PB 1 (RX), 2 (TX), 3 (CTS) and 4 (RTS) is connected to the USB chip.

Is that the standard pins that Silabs was using in the reference design ?

home-assistant/core#43969 (comment)

[MattWestb]

One question for our brave EM35X user:

Z2M have getting EZSP with protocol version 8 up and running and is beta stage. Koenkk/zigbee-herdsman#319

They have only testing with EFR32 and dont have any users with EM35X radio adapters.

Is some brave users that have getting EZSP 6.7.8.0 onboard they adapters willing testing if its working with EM35X hardware ??

If Silabs have making all OK it shall working without problems but need being verified.

[Hedda]

Z2M have getting EZSP with protocol version 8 up and running and is beta stage. Koenkk/zigbee-herdsman#319

Small correction; the new EZSP support in Zigbee2MQTT / zigbee-herdsman is only in "alpha" stage so still very much experimental.

I think that developers should maybe even said that it is "pre-alpha" as per https://en.wikipedia.org/wiki/Software_release_life_cycle

[MattWestb]

Sorry i was using the wrong terminology its not being flagged at all in Z2M = not existing and the "old" CormBee II is still experimental. That men not stable and dont have all function implanted (touch link and so on).

If making its easier is one Alpha not having all function / API implanted / fixed.
One Beta is having all functions / API implanted / fixed for the release but is not debugged and is need intense testing.

One stable release is only getting small bug fixes.

But in the end its up to the devs how they doing it.

Void Linux is using "rolling releases" and dont have version numbers only one matrix of packages they is using and the version of there package tool.

Better moving the "release problematic" to one discussion (ZHA and / or Z2M) and not spamming all issues on git.

And in the end its up to the devs recommending one stable version and if its not working they is getting the problems with the users.