search

ksjh / silabs-firmware-builder

Silicon Labs firmware builder
13 stars 2 forks source link

[SUGGESTION] Elelabs hardware adapters support for Silicon Labs Firmware Builder? #17

Open Hedda opened 1 year ago

Hedda commented 1 year ago

@ksjh and @darkxst while I don't actually have any Elelabs hardware myself would still like to suggest that you guys consider looking into extending patches to this repo to include Elelabs EFR32 based hardware too as that be great for other users that do have their hardware.

FYI @giannello submitted a patch to upstream Nabu Casa but was told to put that into a forked project instead -> https://github.com/NabuCasa/silabs-firmware-builder/pull/8

Note that there is also a directly related feature request that I submitted to Elelabs here -> https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/issues/37

Please, you can find more details about the specific configuration and pins used for their different hardware in these three projects:

Currently sold supported products based on Silicon Labs microcontrollers:

Previously sold supported products based on Silicon Labs microcontrollers:

PS: @NilsBohr from Elelabs has in the past been willing to donate Elelabs USB dongles and GPIO adapters shipped as free hardware samples to some developers who contributed to open-source projects that directly or indirectly depend on and utilize Elelabs hardware.

giannello commented 1 year ago

https://github.com/giannello/silabs-firmware-builder

Already done :) tested on both ELR023 and ELU013

The projects you listed do not specify the pins to be used, but by looking at the FCC ID I was able to find the documentation of the module used in the shield: https://fccid.io/2AOE23BV3/Users-Manual/User-Manual-4411591 The pinout is described there, and it works for both the shield and the USB stick.

I'm currently running the RCP MultiPAN firmware on my HA installation, and works like a charm image

Hedda commented 1 year ago

https://github.com/giannello/silabs-firmware-builder

Already done :) tested on both ELR023 and ELU013

Nice! "elelabs-support" branch for reference -> https://github.com/giannello/silabs-firmware-builder/tree/feature/elelabs-support

The projects you listed do not specify the pins to be used, but by looking at the FCC ID I was able to find the documentation of the module used in the shield: https://fccid.io/2AOE23BV3/Users-Manual/User-Manual-4411591 The pinout is described there, and it works for both the shield and the USB stick.

I believed that the readme files for some of those projects did describe needed pins(?):

https://github.com/zha-ng/EZSP-Firmware/blob/master/Elelabs-ELU013/README.md

https://github.com/zha-ng/EZSP-Firmware/blob/master/README.md

https://github.com/grobasoz/zigbee-firmware/blob/master/EFR32%20Series%201/README.md

https://github.com/grobasoz/zigbee-firmware/blob/master/MG1B232/README.md

Hedda commented 1 year ago

Btw, Elelabs recommend custom zigpy/bellows configuration for Home Assistant ZHA integration if use their own firmware:

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/blob/master/README.md#integration

Not sure if applies when this firmware as those use other configuration default values are probably way different? Ex:

https://github.com/zha-ng/EZSP-Firmware/blob/master/Elelabs-ELU013/README.md

darkxst commented 1 year ago

I think it makes sense to include other devices that are essentially 'community supported'. So as to have a central repository for these builds, rather than being spread over numerous forks! Obviously testing becomes a bit of a problem as there are more devices (I dont have any Elelabs devices for example). Agners concerns about patches breaking on SDK bumps are valid also, but right now its really only the pin configuration patch that varies between builds.

Not sure how many other forks are floating around at this stage but noticed @tube0013 has one for his devices.

The RCP Multipan builds will probably become quite popular as word gets out that Silabs Multiprotocol add-on can work with all these other dongles too!

Btw, Elelabs recommend custom zigpy/bellows configuration for Home Assistant ZHA integration if use their own firmware:

That might be specific to their firmware builds. All those values are set higher in these builds. You can adjust to smaller table sizes etc at runtime, but increasing to larger sizes will fail (for some settings atleast).

As it is setup currently, all EmberZnet (EZSP) builds get the same config. It would become a bit messy to provide device specific configs in the current build system.

That said bellows might be clobbering some of these settings as well. https://github.com/zigpy/bellows/issues/543

RCP multipan builds get configured by Zigbeed from within Silabs Multiprotocol addon so none of these settings are in the RCP firmware.

Hedda commented 1 year ago

I think it makes sense to include other devices that are essentially 'community supported'. So as to have a central repository for these builds, rather than being spread over numerous forks! Obviously testing becomes a bit of a problem as there are more devices (I dont have any Elelabs devices for example).

That would be very nice, similar to grobasoz's repo (which he builds manually) -> https://github.com/grobasoz/zigbee-firmware/

Agners concerns about patches breaking on SDK bumps are valid also, but right now its really only the pin configuration patch that varies between builds.

Yeah noticed it does not yet offer different Ember configuration parameters. See somewhat related request -> https://github.com/NabuCasa/silabs-firmware-builder/issues/13

As it is setup currently, all EmberZnet (EZSP) builds get the same config. It would become a bit messy to provide device specific configs in the current build system.

Would be great if could adapters could have separate manifest files with Ember config parameters that are used when building.

Not sure how many other forks are floating around at this stage but noticed @tube0013 has one for his devices.

Ah, so he does -> https://github.com/tube0013/silabs-firmware-builder (missed as not replied to https://github.com/tube0013/tube_gateways/discussions/129)

darkxst commented 1 year ago

Would be great if could adapters could have separate manifest files with Ember config parameters that are used when building.

Certainly possible, but a bit annoying that parameters could be configured in one of 3 different places, depending on what they are:

image

Hedda commented 1 year ago

Would be great if could adapters could have separate manifest files with Ember config parameters that are used when building.

Certainly possible, but a bit annoying that parameters could be configured in one of 3 different places

I do not have the skills to code a solution myself but posted a feature request to upstream for reference -> https://github.com/NabuCasa/silabs-firmware-builder/issues/14

giannello commented 1 year ago

I think it makes sense to include other devices that are essentially 'community supported'. So as to have a central repository for these builds, rather than being spread over numerous forks! Obviously testing becomes a bit of a problem as there are more devices (I dont have any Elelabs devices for example). Agners concerns about patches breaking on SDK bumps are valid also, but right now its really only the pin configuration patch that varies between builds.

:+1: Fully agree. This leads to an organizational question - who will own this? I'd suggest to either create a dedicated github organization, or to piggyback on zha-ng (even if OpenThread is not really Zigbee...).

Elelabs devices: I can test them, ELR023 is my daily driver, and can OpenOCD my way out of a wrong firmware.

Not sure how many other forks are floating around at this stage but noticed @tube0013 has one for his devices.

Enough to call for a consolidation of the efforts :D

The RCP Multipan builds will probably become quite popular as word gets out that Silabs Multiprotocol add-on can work with all these other dongles too!

Hope so, but this will require running zigbeed, and will take some time before all the other projects will adjust to this. Support for EZSP firmware should stay there until all the major consumers (zigpy/zigbee2mqtt/openhab/...) switch to the multiprotocol approach - which might never entirely happen, because zigbeed/cpcd are not open source...

darkxst commented 1 year ago

Fully agree. This leads to an organizational question - who will own this? I'd suggest to either create a dedicated github organization, or to piggyback on zha-ng

I'd lean towards creating a new dedicated github organisation. Something that doesnt have ZHA or Home Assistant in the name ;)

Support for EZSP firmware should stay there

I don't imagine EZSP will go away anytime soon, the multiprotocol approach is a compromise in a way, I'm sure plenty of users will stick to separate dongles for Zigbee and Thread.

Hedda commented 1 year ago

I'd lean towards creating a new dedicated github organisation. Something that doesnt have ZHA or Home Assistant in the name ;)

Btw, for reference, a few popular projects that also support/use Silicon Labs Zigbee EmberZNet NCP (EZSP) based adapters are:

This leads to an organizational question - who will own this? I'd suggest to either create a dedicated github organization, or to piggyback on zha-ng

An option could maybe be if you could convince Nabu Casa to move the upstream repository from https://github.com/NabuCasa/silabs-firmware-builder project to https://github.com/home-assistant so that the Home Assistant organization would be the owner instead of Nabu Casa + allow you guys to be admins and maintain it there.

Alternatively, perhaps better yet would be to move it to the zigpy organization at https://github.com/orgs/zigpy as that also host ex. https://github.com/zigpy/open-coordinator-backup and is more independent from Home Assistant, and as noted this is a project that could be used by many projects other than Home Assistant.

Anyway, if the https://github.com/NabuCasa/silabs-firmware-builder repository could be moved to another organization on GitHub, away from Nabu Casa organization, the then Nabu Casa in turn could simply fork that so that they would no longer be upstream and instead Nabu Casa would just have a downstream fork in which they could make only work as a stable fork for Home Assistant SkyConnect and Home Assistant Yellow.

If that could work then hope that they will consider doing the same for universal-silabs-flasher and sl-web-tools repos too as I think it makes more sense those too belonging to some other organization on GitHub rather than the Nabu Casa organization on GitHub.

Please do not get me wrong, I still think it would a good idea for the Nabu Casa organization to maintain its own stable forks of those downstream that would specifically be made to only be rock solid for products made by Nabu Casa, just as I think that it would also be a good idea that Elelabs and ITead maintained their own downstream forks.

In short, I simply believe it would be better if the upstream repo could be made flexible to support more hardware models and adapters than those made Nabu Casa, and that means that they probably need more people than Nabu Casa employees working on it.

I don't imagine EZSP will go away anytime soon, the multiprotocol approach is a compromise in a way, I'm sure plenty of users will stick to separate dongles for Zigbee and Thread.

+1 There are just as many arguments for using separate dedicated radio adapters as for using a single RCP multi-PAN adapter.

darkxst commented 1 year ago

I guess it depends to what extent Nabu Casa want to support multiple adapters etc. Its a fairly simple build process currently, and if we were to add support for manifests etc, it might diverge a fair bit from the current code base.

would also be a good idea that Elelabs and ITead maintained their own downstream forks

The build system as it currently stands, works quite well if you only building for a single target. For example iTead who basically only have 2 very similar products to build for, it would be fine as is. Its a bit lacking though when trying to build for many different adapters, Elelabs probably falls into this category, having different products on different generations of Silabs chips.

Universal-silabs-flasher, is already device agnostic. Its heavily coupled with the nabu casa specific meta data, but this is mainly used only for validation and efficiency purposes (and any firmware built with silabs-firmware-builder will have this metadata anyway). You can however flash any valid .gbl firmware, I guess it falls short in support of other (older) formats such as .ebl though.

Hedda commented 1 year ago

I guess it falls short in support of other (older) formats such as .ebl though.

FYI, related to that noticed puddly has a PR to add EBL parsing in universal-silabs-flasher -> https://github.com/NabuCasa/universal-silabs-flasher/pull/11

darkxst commented 1 year ago

I did some initial work towards building from manifests and allowing override configs. Its in this branch for now https://github.com/darkxst/silabs-firmware-builder/blob/manifestjs/manifests

As an example zbdonglee.json overrides some config from the defaults (in defaults.json)

params are really just global configuration items that apply to all three firmware types.