Release v2.1.3 — April 1, 2026

[jnilo1]

New features and bug fixes. Upgrade path:

./flash_install_rtl8196e.sh gateway_ip

New features

• LED dual brightness mode: both LEDs now support a dim mode for nighttime use. Configure with /userdata/etc/leds.conf (MODE=dim or MODE=bright). Switch without rebooting:

  echo MODE=dim > /userdata/etc/leds.conf
  /userdata/etc/init.d/S11leds start

  The LAN LED brightness is controlled via the Ethernet ASIC (led_mode sysfs), the STATUS LED via software PWM (leds-gpio-pwm driver, 0-255). serialgateway and otbr-agent respect the mode automatically. Credit: @jlayec (#78).

• Thread Channel Manager: otbr-agent is now built with OT_CHANNEL_MANAGER and OT_CHANNEL_MONITOR (+14 KB). Enables ot-ctl channel manager change <ch> for graceful channel changes across the Thread mesh. Credit: @MaxRower (#74).

Bug fixes

• IPv6 mDNS announcing only IPv4 address: S70otbr enabled IPv6 forwarding which silently disabled Router Advertisement processing (accept_ra drops to 0). The gateway never acquired a GUA via SLAAC, so mDNS only announced the IPv4 address. Fixed: accept_ra=2 on eth0. Credit: @Thelvaen (#77).

• LAN LED dim after custom firmware install: the LAN LED is hardwired to the switch ASIC LED output (not GPIO). The Ethernet driver now configures LEDCREG in LEDMODE_DIRECT after reset, restoring full-brightness link/activity indication as in the stock firmware.

Full changelog

• RTL8196E CHANGELOG
• EFR32 CHANGELOG

[MaxRower]

Just flashed a gateway with otbr on it, but:

Lidl Zigbee Gateway v2.1.3 - J. Nilo - 2026-04-01
~ # ot-ctl channel manager 
Error 7: InvalidArgs
~ # 

Another question: Is there a way to change the IP of the boot loader? Remote upgrades would always need a local computer there otherwise. With a local IP, it would work fine via VPN.

[MaxRower]

Ok, it seems, this depends on the state of the gateway? Flashed a second one, where otbr is the only one in the network, and it succeeded.

Lidl Zigbee Gateway v2.1.3 - J. Nilo - 2026-04-01
~ # ot-ctl channel manager change 25
Done
~ # ot-ctl channel manager
channel: 25
auto: 0
Done

[MaxRower]

BTW, LEDs are looking nice now!

[Thelvaen]

I had some stability issue with otbr on it (had to reboot it everyday to keep my Ikea devices attached to it), not sure what was the issue there, so I went back to Zigbee, with Z2M & HA, and it works just fine ;)

[MaxRower]

I had some stability issue with otbr on it (had to reboot it everyday to keep my Ikea devices attached to it), not sure what was the issue there, so I went back to Zigbee, with Z2M & HA, and it works just fine ;)

We need to determine the cause of that!

[Thelvaen]

was the issue there, so I went back to Zigbee, with Z2M & HA, and it works just fine ;)

Yeah, but doing tests takes time, and breaking everything every other day does not have a really good WAF so ...

[jnilo1]

Update: Thread channel change now works from the Home Assistant UI.

Go to Settings → Devices & Services → Thread → Configure, select the border router, and change the channel. The change propagates across the mesh automatically (takes ~5 minutes).

This required patching the ot-br-posix REST API at build time: upstream recently switched JSON keys from PascalCase to camelCase, but Home Assistant's python-otbr-api (< 2.9.0) still expects PascalCase. The patch is applied automatically by build_otbr.sh and will be skipped when no longer needed.

[jnilo1]

Ok, it seems, this depends on the state of the gateway? Flashed a second one, where otbr is the only one in the network, and it succeeded.

I had to fix it after the initial v2.1.3 announcement so perhaps you uploaded the "old" version with your first trial. Make sure to check the md5sum of your otbr-agent. Should be:
otbr-agent v2.1.3 (with channel manager + PascalCase REST API)
md5: fbeba1a16fcb5a791341ec68d2ef1854

[jnilo1]

We reproduced this on our side. It's a Home Assistant bug: after a channel change, HA does not update the Thread dataset TLV in its cache (/config/.storage/thread.datasets). The actual channel is correct on the gateway — only HA's display is stale.

You can verify the real channel:

ot-ctl channel

Workaround: simply delete the cache file and restart HA — it will re-fetch the dataset from the OTBR with the correct channel:

rm /config/.storage/thread.datasets
# restart HA

This only deletes HA's cached view of the Thread network — the actual Thread credentials and dataset are stored on the gateway (/userdata/thread/) and are not affected.

[MaxRower]

Since the update, second gateway with the two BILRESAs seems stable, HA still sees the two remotes!
Time to test the failover with two border routers again.

[MaxRower]

Failover test: I killed serialgateway on the OT-RCP gateway, OTBR still running on the host. After a few minutes, all devices were available again.
After restarting the Host with HA, but without OTBR, everything is still available in HA. So I will keep OTBR on the host down, and see, if the gateway with OTBR is stable in the long run.
HA shows the lidl gateway as the only border router.

[jnilo1]

Great failover test @MaxRower and thanks for documenting this! Good to see the Thread mesh re-converges on the Lidl gateway within minutes after the host OTBR goes down.

Please keep us posted on long-term stability with the gateway as the sole border router — especially if you notice any device drops or need to reboot (similar to what @Thelvaen reported). Uptime + number of Thread devices would be useful data points.

Jacques

[Thelvaen]

I'll try to do more tests & provide logs, but that won't happen before this week end at best.

[psolyca]

Thanks again for your work ^^
I did not update yet.
All my domotic stuff are in a "Harry Potter room under the stairs" so I do not need LEDs and it's consumming ^^;
Could you add a MODE=off in S11leds ?

[jnilo1]

Done in #80