🎉 New: zigbee-on-host support with OpenThread RCP firmware

[jnilo1]

A new firmware option is now available for your favorite gateway: 26-OT-RCP — an OpenThread RCP firmware that works with https://github.com/Nerivec/zigbee-on-host, the amazing open-source Zigbee stack developed by @Nerivec

Why zigbee-on-host?

Unlike the previous RCP-UART firmware which requires Silicon Labs' proprietary zigbeed, zigbee-on-host is:

• Fully open-source — no proprietary binaries
• Integrated in Zigbee2MQTT 2.x as the zoh adapter
• Community-driven — contributions welcome!

Quick Setup:

Flash the firmware via J-Link/SWD:

commander flash firmware/ot-rcp.gbl --device EFR32MG1B232F256GM48

ℹ️ Only hardware flashing (J-Link) has been tested. UART/Xmodem flashing via universal-silabs-flasher might work but hasn't been tested.

Then configure Zigbee2MQTT:

  serial:
    port: tcp://192.168.1.xxx:8888
    adapter: zoh
    baudrate: 115200

That's it!

Status

Successfully tested with a Xiaomi LYWSD03MMC temperature sensor. The firmware uses 115200 baud with hardware flow control over TCP via serialgateway.

⚠️ Note: zigbee-on-host is still under active development. Not recommended for production environments. Check https://github.com/Nerivec/zigbee-on-host for updates and to report issues.

Links

• https://github.com/jnilo1/hacking-lidl-silvercrest-gateway/tree/main/2-Zigbee-Radio-Silabs-EFR32/26-OT-RCP
• https://github.com/Nerivec/zigbee-on-host

[psolyca]

Do we need to repair devices ?

[jnilo1]

As I said in my post: zigbee-on-host is still under active development. Not recommended for production environments.

[Nerivec]

For testers, there's a takeover script in the repo:
https://github.com/Nerivec/zigbee-on-host?tab=readme-ov-file#cli--utils
Should allow taking over a previous zstack or ember network (others untested).

[psolyca]

As I said in my post: zigbee-on-host is still under active development. Not recommended for production environments.

Yes but, being able to use our devices as-is could be easier for testing and going forth and back to ember.

I've seen the script and have a look ^^ thanks

[MaxRower]

I tried to build the firmware, but it terminates with the following error:

Building app.c
Building autogen/sl_device_init_clocks.c
Building autogen/sl_event_handler.c
Building autogen/sl_ot_init.c
Building autogen/sl_uartdrv_init.c
make: *** Keine Regel vorhanden, um das Ziel „/home/mmcm/devel/hacking-lidl-silvercrest-gateway/silabs-tools/gecko_sdk/protocol/openthread/libs/libsl_openthread_efr32mg1x_gcc.a“, benötigt von „build/debug/ot-rcp.out“, zu erstellen. Schluss.
make: *** Auf noch nicht beendete Prozesse wird gewartet …
Building main.c

Any clues, what's wrong here?

[MaxRower]

Ok, flashed the prebuilt firmware, via universal-silabs-flasher, it did seem to work, at least the probe command output looks reasonable?

2026-01-08 20:32:11.799 lifebook universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2026-01-08 20:32:13.810 lifebook universal_silabs_flasher.flasher INFO Probing ApplicationType.EZSP at 115200 baud
2026-01-08 20:32:24.331 lifebook universal_silabs_flasher.flasher INFO Probing ApplicationType.EZSP at 460800 baud
2026-01-08 20:32:34.852 lifebook universal_silabs_flasher.flasher INFO Probing ApplicationType.SPINEL at 460800 baud
2026-01-08 20:32:34.878 lifebook universal_silabs_flasher.flasher INFO Detected ApplicationType.SPINEL, version 'SL-OPENTHREAD/2.4.7.0_GitHub-fb0446f53' (2.4.7.0) at 460800 baudrate (bootloader baudrate None)

[MaxRower]

z2m 2.7.2 with zoh does run here, but pretty unstable. It restarts itself often, pairing of an older IKEA LED1545G12 bulb took several attempts until it did work. IKEA plug E160x/E170x/E190x and dial ICTC-G-1 did work on the first attempt. The windfront GUI shows "WebSocket: Reconneting" very often.

LQI values are very low compared to the 7.5.1 ember firmware. 20-40 vs >150.

BTW zoh cannot be selected during onboarding.

[MaxRower]

Next test to get Thread running seems to be successful with https://hub.docker.com/r/bnutzer/otbr-tcp as the standard Open Thread Border Router does not support RCP via TCP.
Thread network shows up in Home Assistant, but without any Thread devices to test, I have to stop here, until I can get one.

[reey]

@jnilo1 I can confirm that flashing via universal-silabs-flasher works.

I can also confirm that running this together with the Home assistant OpenThread border router addon works and I was able to pair devices/perform OTA updates of these devices.

Any plans to e.g. add https://github.com/openthread/ot-br-posix to the firmware in order to have a self sustaining Thread border router? I guess the hardware should be powerful enough as even an esp32 is able to act as a thread border router (https://github.com/espressif/esp-thread-br)?

[jnilo1]

Hi @reey, thanks for confirming the universal-silabs-flasher workflow and for the positive feedback on the OpenThread Border Router addon integration — great to hear it's working well for you!

Regarding your suggestion to embed ot-br-posix directly into the gateway firmware: it's an interesting idea, but I think it's outside the scope of this project for several reasons.

The comparison with ESP32 is a bit misleading — Espressif's esp-thread-br is a highly optimized, purpose-built implementation for their SDK, not the full ot-br-posix stack. The RTL8196E we're dealing with here is a constrained MIPS Lexra SoC with limited RAM, and ot-br-posix comes with heavy dependencies (mDNSResponder/Avahi, D-Bus, etc.) that would be painful to cross-compile and would likely result in poor performance anyway.

The good news is: the current architecture already works nicely! As @MaxRower demonstrated, you can run an external OTBR (like bnutzer/otbr-tcp or the Home Assistant addon) that connects to the gateway's RCP over TCP. This approach is cleaner, more maintainable, and lets the Thread stack run on hardware with proper resources.

So for now, I'd recommend sticking with the RCP + external OTBR setup. If you really need a fully standalone Thread border router, dedicated hardware (like a Thread dongle or a Raspberry Pi) would be a better fit.

Thanks again for the suggestion though! 🙂

[jnilo1]

Following @reey's suggestion about integrating ot-br-posix directly on the gateway, I've now made a cross-compilation build script available for the RTL8196E.
See #49
Feedback is very welcome - stability, memory usage, compatibility with Matter controllers (Google Home, Apple Home, etc.).

[jnilo1]

Hi all,
Significant updates in ot-br setup in the new v1.2.1 release