OTBR Thread 1.4 update

[brisk topaz]

Does anyone know when it is planned to update the OTBR addon and ZBT-1 to Thread 1.4? Or even to Thread 1.5 which is already at the gates?

[brisk topaz]

https://www.matteralpha.com/how-to/how-to-build-a-thread-1-4-border-router
The Thread 1.4 firmware is already available for Espressif.

[native thistle]

How much does this matter when no one else has deployed Thread 1.4

[brisk topaz]

With Thread 1.4 there comes Enhanced Network Diagnostics that -among other things- will make it possible to show the Thread protocol/stack version of the devices in the mesh. An information, that is currently only accessible via the vendors.
Further, at least in my understanding, the Thread Border Routers should always be the first devices to support new Thread versions.

[brisk topaz]

Well, Samsung SmartThings now runs also on Thread 1.4.
https://www.matteralpha.com/news/smartthings-app-and-hub-got-matter-1-4-certifications

[sullen nest]

Matter 1.4 is not the same as Thread 1.4. Confusing, I know 😄

[sullen nest]

In addition to network diagnostics mentioned above:

• Enabling cloud connectivity. With technologies like NAT64 and DHCPv6-PD, Thread devices can now initiate communication to IP endpoints on the public Internet.
• Numerous smaller enhancements that may improve the performance of Thread.

[brisk topaz]

True that.

SmartThings finally adopts Thread

Additionally, the certification files reveal the inclusion of Thread Border Router (TBR) management, a significant update aimed at integrating SmartThings into existing Thread networks. Previously, SmartThings operated its own Thread network, leading to multiple, isolated networks within a home, which undermined the benefits of Thread’s mesh technology. The new TBR management feature should enable SmartThings to join existing networks created by devices such as Apple TV 4K, thus offering a more seamless user experience.

As the adoption of Thread is mentioned - not explicitly Thread 1.4 though - it can be assumed, that it is actually Thread 1.4. Thread 1.4 has already been released in September 2024, so there would be hardly any reason not to use it.

[eager walrus]

Hello

[solemn summit]

i mean, i dont doubt that stefan is testing it or whatever when he gets a chance, but it will be out when the base libary gets updated

you can follow it here:

https://github.com/openthread/openthread

[brisk topaz]

Is there any chance to get a highly informal indication of a planned release date for the next version of OTBR by Google from you? 😉

[red pollen]

"official" statement: "Just use main branch!"
https://github.com/orgs/openthread/discussions/10944
which is ridiculous, because if openthread themselves cannot provide such information, how is anybody supposed to release a stable product from openthread?
Except for maybe closely collaborating chip manufacturers, like Espressif with their re-released ESP32-C6 chip, as you can find out here:
https://www.threadgroup.org/Certified-Products
You will also be able to see, that (at the time of writing this) there is no such thing as SmartThings on Thread 1.4
And while we are at it, there also seems to be no single Apple product with any official Thread Certificate at all. None. Which might also explain the many issues HA users face when using multiple Apple TBRs or Apple TBRs in conjunction with OTBR run on HA.

Considering all this, I personally would conclude that the HA guys are pretty much on track with their releases, but it also documents a pretty sad state of affairs (thread 1.4 effectively being vapor ware in real products currently), which lead me to operate OTBRs on raspis compiled from main by myself which also is a road I don't actually recommend going down for anyone not creating a real product...

[sullen nest]

which is ridiculous, because if openthread themselves cannot provide such information, how is anybody supposed to release a stable product from openthread?
Because, as it turns out, silicon vendors chose to maintain their own branches. With the way certification works, it is easier for silicon vendors to operate in this way. With each SDK release, they pull the latest from OpenThread, run through certification testing, fix any issues they run into on the way (which, in many cases, are related to platform-specific drivers), and maintain the branch for SDK point releases.

And while we are at it, there also seems to be no single Apple product with any official Thread Certificate at all. None.
Apple products are certified. But listing on the Thread Group site is not required. Apple explicitly declines to list their products on Thread Group site.

[solemn summit]

Basically this, it will be ready when it’s ready, I don’t understand the hype for wanting to test a potentially buddy source SDK, like just wait for each vendor to update

[brisk topaz]

but it also documents a pretty sad state of affairs (thread 1.4 effectively being vapor ware in real products currently)

I fully agree with your view on the state of affairs and I'm sad to see that more and more Matter certified products are released without Thread support. Latest examples are Shelly's Gen4 devices that would have been really great Thread hubs. Some vendors like Nanoleaf even officially stopped releasing their products with Thread support only offering WIFI based Matter integrations in the foreseeable future.

My personal experiences with HA's OTBR addon are excellent so far, I didn't run into any connectivity or stability issues. In contrary, I am impressed how well the mesh organizes itself providing strong signals in every corner of my home. But my mesh also only consists of Eve devices, so this might not be the best reference.

Anyway, I am a big fan of the ideas and the concept behind Thread, so thanks, @sullen nest , to you and your colleagues for your development work. Still, I hope Google will allocate more resources to Thread development to shorten the release cycles.

[brisk topaz]

Well, "it will be ready when it's ready" is one of the top killer phrases related to development roadmaps. This only states that there is no roadmap and/or no control over it and/or no priority on the task. 😉 I personally think that there is a certain window of opportunity to introduce a new protocol standard and to prove its usefulness and reliability to the market. Once this window has passed, it will be hard to achieve a high rate of adoption in a reasonable timeframe, as alternatives and workarounds have already taken up its space.

[brisk topaz]

OTBR Thread 1.4 update

Apple will release Thread 1.4 with tvOS 26 which is currently in beta phase.

https://www.matteralpha.com/news/apple-tv-upgrades-to-thread-1-4-with-tvos-26-beta

Any new information if OTBR's Thread 1.4 is also on the horizon?

[solemn summit]

nice @south canopy 🙈

[south canopy]

🫣

OTBR1.4 is already a thing, check out my guide to build one and get it attached to HA for management

https://www.matteralpha.com/how-to/how-to-build-a-thread-1-4-border-router

[fresh forge]

Isn’t an ESP32/OTBR combination something that Home Assistant can sell us, like they already do it with the HA Yellow/Green, ZBT-1 and Voice PE?

I would buy some of them… 😃👍

[south canopy]

GLiNet TBR S20 is basically the same (ESP32-H2 & S3) with PoE support

Oh also the Tado TBR

[fresh forge]

Yes, but I would probably rather buy an HA device to support the team. Anyway... Do you have any experience with the GLiNet S20? Is there a Thread 1.4 update on the roadmap? If I remember correctly, someone here showed a nice Thread connection map from the GLiNet web GUI.

[south canopy]

Sadly no, they are not available in my region. Maybe the vendor would send me one for review someday; you can always support the team by subscribing to HA Cloud🙂

[fresh forge]

I am already subscribed… 😅

[brisk topaz]

At first: you all do a great job at Matter Alpha! I really like your regular articles - read them all!

Therefore I appreciate linking your OTBR article, but I know it. I run a Proxmox virtualized HA instance using a ZBT-1 for Thread. Thus I would rather wait for OTBR‘s next release to be incorporated into HA and updating my stuff. I was hoping for the Google guys here to give us at least a rough indication. They seem to have crammed up development resources lately, as more people have been committing on Github during the last weeks…

[red pollen]

GL-S20 is on 1.3 without TREL support. Same for Tado. Question would be if these can be flashed with plain OTBR according to the above documentation.

[brisk topaz]

Now also Ikea's Dirigera hub is supporting OpenThread 1.4. What is taking Google so long to finally release OTBR 1.4? Two years, in two days it will have been two full years since the last release! Almost every week new Matter equipment gets released that only supports Wifi, news articles get written that favor Wifi over Thread. C'mon guys!

https://www.matteralpha.com/explainer/ikea-adds-matter-controller-and-thread-support-integrating-third-party-matter-devices

[red pollen]

@south canopy do you know if the ZigBee radio on that thing can be turned off? That would make the dirigera hub one of the cheapest BRs on the market. Also, not having to rely on WLAN is great. I would also be interested, if the thing supports TREL (well it should, being on 1.4)

[south canopy]

I don’t think you can, and Dirigera is not cheap as the tariff increases

[south canopy]

Nest WiFi has 1.4, a dev told me today, but I don’t have one to test; Google is a major contributor in OpenThread.

From 2026, all new tbr must certified with 1.4 spec

[south canopy]

For S20, Yes you can, but need reconfigure all the pins, they are different board designs from the raw dev kit

[red pollen]

that unleashes a bunch of new questions in my head: 🙂
I want a standalone TBR. I don't want the Nest WiFi as an access point. So, can I turn the WiFi off? Second best: Could I use the WiFi to only bridge the thread network to the local LAN, not otherwise interfering with my existing Unifi setup. And: Can I do this with a bunch of them?

[brisk topaz]

Google Nest with Thread 1.4 is nice, but the Thread ecosystem finally needs the OpenThread 1.4 reference released by Google in order to convince hesitant manufacturers to jump on. The 2026 deadline sounds promising. As far as I can see only/mostly Google guys are currently committing on GutHub - so it‘s on them.

[brisk topaz]

It's cheap in the EU. 🫣

[fresh forge]

So, you want/need hardwired TBRs with Thread 1.4. AppleTV 4K 3rd Gen with tvOS 26. tvOS 26 is in beta at the moment and will be released in September this year. 😃

[red pollen]

Yaeh, I surely won't switch to Apple BRs. They failed too hard for me in the past, and it was too much of an effort to get to an OpenThread based stable thread set-up in my home.

[red pollen]

Plus, it doesn't make sense for me to have TBRs built into devices that are not purpose-built for the best BR experience. I had to carefully consider where to put my BRs in order to get good coverage, and I can tell that in all places where I have placed a BR, a display, speaker or anything else that would be the main purpose of the device is of no use (plus, it is only accidentally carrying a half-assed and badly supported BR implementation just because).
I also don't get why everyone and their dog is so eager to put outdated BRs into their TVs, fridges, water-pumps and what not, just to give no support, and with no to just few updates. It also doesn't make sense to pave ones home with too many BRs from different vendors (while they interoperate only poorly), given that as per thread spec the whole network (that ideally would consist of just one partition) can carry only 32 routers in total. So the network has to down-vote all of those futile BRs that try to play a role in the concert but instead would only contribute to dissonance, effectively turning each and every of those down-voted BRs into waste.

[fresh forge]

Which issues did you have with Apple BRs? I have my Apple Thread network working without issues since more than a year. I have 7 Apple TBRs (2 hardwired AppleTVs, 5 HomePods), 40 mains-powered Full Thread Devices, and 27 battery-powered Minimal Thread Devices. I only have issues, when I integrate the HA OTBR.

[mystic beacon]

The HA OTBR is significantly behind the latest from Apple, which was the first to effectively use TREL and updated pretty consistently. The best of a lot of less than stellar offerings available today, IMO. Particularly if you just buy a couple and place them haphazardly as most do.

Can't dispute the futility of putting Matter controllers in TV consoles and other high $ devices where the primary function will outlive the capability of the TBR.

[brisk topaz]

Fully agree. A BR should only fulfill this single role and be optimized to that. Especially with regards to updates in order to stay at the head of the pack. I don't need it to be a dedicated device though, running it virtualized is fine too.

[old hamlet]

I don't have a problem with Apple TBRs lately either.

[brisk topaz]

Ikea is not only pushing Matter-over-Thread-BR-wise but also Matter-over-Thread-device-wise. Promising!
https://www.theverge.com/smart-home/701697/ikea-matter-thread-new-products-new-smart-home-strategy

[mystic beacon]

Matter in general so far following the Gartner hype cycle and Amara’s law.

[brisk topaz]

True. Where do we stand?

[solemn summit]

4

2 was on matter 1.0/1.1 and

nanoleaf and eve issues around early last year-ish

[mystic beacon]

Just heading out of 3 on the upslope to 4

[mystic beacon]

Just need thread 1.4 or greater to become ubiquitous and wireless and generic wired routers/AP to handle ipv6 mDNS (or just get out of its way and not try to handle or block it) to be really getting into the upswing.

[brisk topaz]

Yeah, the availability of Thread 1.4 on all major platforms could indeed be the path to enlightenment. I really hope that the manufacturers will also update their devices otherwise we will fall back to disillusionment.

[mystic beacon]

I don't have too high of hopes that all manufacturers overbuilt in the overhead/excess space to handle greater than matter 1.5/thread 1.4. On a beta team and at least one manufacturer using current SOC is having to contemplate firmware space/update constraints moving to Matter 1.4.
https://www.reddit.com/r/Inovelli/comments/1ltdldr/comment/n1quath/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[brisk topaz]

Which is almost laughable, given that storage and memory space now cost virtually nothing.

[mystic beacon]

well Inovelli, likely has an order of magnitude more endpoints & clusters than anyone else in the matter over thread space so they will be among those testing boundaries of whats possible with hardware the SOC manufacturers recommend as capable off the shelf. Also they and everyone else is learning what those requirements are real-time without any prior experience/knowledge out there.

[brisk topaz]

Hm, I see your point. Nevertheless, longevity and future viability of household appliances are not new concepts. And especially the need for regular firmware updates - especially for standards that are under heavy development - should have been easily foreseeable. As well as customers’ expectations to get future-proof devices that will not have to be thrown into the garbage every two years. Don’t you think that could have been expected?

[old hamlet]

Yes, up to 3,2 MB flash for MG26.

[mystic beacon]

Yes should be expected. They upgraded to the MG24 (from the MG21 - they used to handle the comparable zigbee firmware which still has more functionality built in) that had just been released and was the best available SOC from their supplier at that time for future proofing. Something like the MG26 was not an option.

Might just be a potential issue/worry based on being burned in the past that never materializes.

[brisk topaz]

A little off-topic, but anyway: Is there an indication when the HA crew will release the Matter 1.4.2 update for the Python Matter Server Add-on? I checked for a beta version, but there’s none.

[old hamlet]

You should check twice:
https://github.com/home-assistant-libs/python-matter-server/pull/1184

[brisk topaz]

Hm, strange. In the Python Matter Server Add-on configuration, the option "Use the latest beta version" is activated, but the version is still 8.0.0. Checking for updates comes up with nothing. Am I missing something?

[old hamlet]

It seems to me that the version displayed with a beta version is not the right one. Better check the logs

[brisk topaz]

Yes indeed. SDK Wheels shows Version: 2025.7.0. Thanks for the hint!

[mystic beacon]

@brisk topaz that is expected behavior - #1368077978319327323 message

[brisk topaz]

Thanks for pointing me to this super interesting Matter binding thread! Things seem to be really moving forward!

[full violet]

I successfully bound an Inovelli VTM31-SN > VTM36 (dimmer switch to fan/light canopy module). Man what a relief to finally have them working together natively and no longer reliant on the controller. Thanks so much for your work here @proper escarp!

I'm experiencing the same issue as vesalius posted above, where virtual changes via HA are not being bound to the target node. If there's anything I can do to help test/debug it, please let me know.

[mystic beacon]

This message should like be in the bindings thread. 🙂 I have been told what I thought was an 'issue' is unfortunately expected behavior:

FYI - the bindings are supposed to be ignored when the device is controlled remotely.  This is how the Matter standard works.
 
When controlled remotely, you are acting on a Dimmable Light device (type 0x0101) (in the case of VTM31) or On/Off Light (type 0x0100) (in the case of the VTM30) on Endpoint 1 of the hardware.
 
Bindings, however, are controlled through a Dimmer Switch device (type 0x0104) which is a type of controller on Endpoint 2 of the hardware which is coupled to an actuator - i.e., the paddle.
.
So, controlling endpoint 1 by a remote command does not affect endpoint 2 as endpoint 2 actions are initiated by actuator (paddle) controlled.  They remain logically separated. If you want to control both endpoint 1 as well as the devices that endpoint 2 is bound to, the solution is to set out all of the devices in the remote command. This allows you to continue to have control over individual devices via remote operations, while being able to use actuator-controlled bindings.
 
This relationship between endpoints and actuator devices explained (though vaguely and only at a high level) in the introduction to Section 6 of the Matter Device Library Specification Version 1.4 and in Section 6.6.5 of that document. In any case, though the specs. are vague, the definitive answer is that the public Matter development SDK controls this behavior.

[full violet]

oops, thought that's where i was 🤣

[brisk topaz]

Silicon Labs just released MG24's firmware update to Matter 1.4 - that's great news! This will raise the bar for many vendors.

https://www.matteralpha.com/how-to/silicon-labs-upgraded-arduino-library-to-matter-1-4

Looks like 2025 is a good year for pushing the standard forward.

[south canopy]

I heard some TBR 1.4 updates was originated in Simplicity SDK upgrade

[old hamlet]

You can check the changelog here: http://github.com/SiliconLabs/arduino/releases/tag/3.0.0

[south canopy]

Thx, I was referring to the vendor-wise upgrades for end devices

[brisk topaz]

Does this mean that HA will only be able to release Matter 1.4.2 with the Matter Server Addon after the OTBR by Goolge Addon will have been released providing Thread 1.4? Or do I misunderstand how Matter 1.4.2 „enforces“ Thread 1.4?

https://www.matteralpha.com/industry-news/matter-1-4-2-brings-wi-fi-only-setup-and-enhanced-base-experience

[old hamlet]

Regarding 'Wi-Fi only setup'?

[brisk topaz]

No, I mean in general. The article states that "Matter 1.4.2 actually enforces the Thread 1.4 requirement slightly ahead of the policy from the Thread Group, which mandates that all TBRs must be 1.4 certified for new certification starting in 2026." This sounds like that Matter 1.4.2 (certification) - at least for a matter server and border router - is only possible if also Thread 1.4 is provided. Meaning that the combination of Matter 1.4.2 and Thread 1.3 is not allowed/certified anymore. As anybody seems to know when the Thread 1.4 release of HA's OTBR by Google Addon - currently running Thread 1.3 - will happen, this would prevent a release of Matter 1.4.2 until an unknown point in the future. But maybe I have misunderstood the constraint.

[old hamlet]

This is only for certification

HA Matter controller (beta version) is already build using 1.4.2 version SDK.

But it doesn't mean Matter 1.4.2 features are enabled. It only allow to implement it in the code.

[brisk topaz]

Ok, thanks for the insight. So, I understand there is no "technical" enforcement by e.g. a version check. But it means that the "Open Home Foundation" products can't get Matter 1.4.2 certified unless HA also provides a Thread 1.4 (O)TBR addon.

[old hamlet]

Which OHF products are you talking about?

[brisk topaz]

For example OHF Matter Server/Home Assistant Green (Matter 1.3 certified)…

https://csa-iot.org/csa_product/open-home-foundation-matter-server/

… and Home Assistant (Matter 1.3 certified).

https://csa-iot.org/csa_product/home-assistant/

[old hamlet]

Those two are for Matter controller (client) part

This is not for TBR.

[south canopy]

IMHO, The new requirement was specifically for Matter TBR (a device type under NIM). It’s managed by Matter.

Vendor specific TBRs or standalone ones are less relevant to Matter.

[red pollen]

Exactly, TBRs don't necessarily have to be matter devices. But if a vendor wants their TBR to be a matter device as well and wants their TBR to be matter 1.4.2+ certified then they have to make sure the TBR component is at least Thread 1.4.

[brisk topaz]

Thanks — that’s how I understood it as well. Are there any vendors offering a dedicated Matter hub without a TBR? All the hubs I’m aware of combine both, which means the “Matter 1.4.2+/Thread 1.4” constraint would still apply.

[south canopy]

A hurting truth, vendors usually only apply certification for the matter software part or don’t do certification for controllers at all

[red pollen]

I don't think it immediately applies: None of those multi-purpose devices expose their border routers as matter devices as in "the TBR becomes a node of a matter fabric" -- you won't even find a matter code on any of those. So technically the TBRs are not controlled my the Matter controller that (accidentally) also lives on that device. Albeit of course, there might be an orchestration layer present for both of them.

This specific addition to the Matter 1.4.2 spec in my mind only makes sense for a very specific set of devices: border routers that can be commissioned via matter (this a parallel development to the thread PAN merge flow in thread 1.4 btw. And I think they try create an umbrella here for these two flows)

[south canopy]

There are two such devices as far as I know, but they just got certification

[red pollen]

Also, this make me hope we will see more "TBR only" devices in the future. So to deploy them throughout my home without sacrificing the one or the other functionality that happens to be baked in as well.

[brisk topaz]

Everytime I think that I understood the overall concept I realize that I didn't. 😉

[red pollen]

@south canopy Ooohh, is that an updated version of the GL-S20 ?

[south canopy]

same one, but the version I have comes with REST API

[red pollen]

so, it's essentially the beta firmware?

[red pollen]

which ones would that be?

[south canopy]

An epaper display, and Aqara S100 touchscreen switch US

[south canopy]

https://dl.gl-inet.com/release/iot/beta/s20otbr/2.0.1
It's a beta firmware

Compared to v2.0.0-R1, this version added Openthread REST API and can access to Home Assistant.

[red pollen]

Let's hope they update to thread 1.4 someday

[south canopy]

no such a plan at the moment as far as I know

[brisk topaz]

Let's also hope they release OTBR with Thread 1.4 someday.

[red pollen]

Well, yes. On the other hand, it doesn't take a certificate or a release tag to build a working 1.4 (O)TBR, as a number of examples already show (e.g. IKEA). And in my experience the OpenThread main branch is actually quite solid. (In my setup having one 1.4 OTBR in the mix and promoting it to the leader role already made a huge difference.)

[brisk topaz]

Agreed. If there was an easily installable OTBR „beta“ version provided by HA - like they do with the python-matter-server - I also would give it a try. But unfortunately there isn’t and I don’t want to compile one.

Nevertheless, OT(BR) is the reference and a beacon for the status quo of the Thread standard. Only an official release gives vendors the confidence to use it in mass production they need to warrant for. And imho a release that is more than two years old, does not give that confidence - at least not to vendors that lack their own development team able to release and maintain their own Thread implementation. Like IKEA.

[red pollen]

They do provide docker builds though.
https://openthread.io/guides/border-router/build-docker
You would have to add a bit to make it survive reboots.

But not sure if these contain the platform mDNS stuff. On the other hand, the very latest ones might have the new OT built-in mDNS stack enabled. If so, you would be good to go.

[brisk topaz]

As the Thread group set Thread 1.4 as a requirement for new certifications starting with 2026, my hope is that Google will release OTBR with Thread 1.4 before the end of this year. In any case.

[silent rune]

If anybody is interested in helping (I'm not sure I have the full skills - I've worked on integrations before, but not add-ons!), I'm interested in trying to update the existing OTBR add-on to OTBR 1.4, and do a corresponding thread 1.4 update for the ZBT-1. I think there are 3 sub-projects:

1. Create the updated OTBR 1.4 add-i n and set it up as a community repository (or as a PR to the existing OTBR) based on the existing code here: https://github.com/jvmahon/home-assistant-addons/tree/master/openthread_border_router
2. Update the OTBR integration here if needed: https://github.com/home-assistant/core/tree/dev/homeassistant/components/otbr
3. Build ZBT-1 firmware to support Thread 1.4 and set up the OTBR to do the update. I think the following might be a good starting point: https://github.com/darkxst/silabs-firmware-builder

Direct message me if you think this is something you'd be interested in helping with.

[round narwhal]

oh, does it need new firmware?

have to workout how to use the nRF sdk again

I have been working on updating the border router for a seprate issue to fix some mdns issues(the gms thread stuff doesnt properly do mdns, so servers have to announce TXT records) which break its use on android in subtle ways here https://github.com/miawgogo/addon-test

(bringing this up as its almost doing the same thing)

(some things are broken, the web UI doesnt fully work~~, and home assistant doesnt think it can control it~~ that was because the intergration for my previous one existed still)

(paring devices works quckly due to mdns working correctly)

[odd hull]

ah, that's switching it to use the mDNS stack bundled in openthread rather than external mDNSResponder? neat to hear that it's working better. Hopefully that can be applied to the upstream otbr add-on.

seems like with newer versions of esp-idf, their thread border router component is claiming to be thread 1.4 - i wonder if that's all on the thread border router side or if it also required an update to the rcp firmware for the radio.

[south canopy]

The OTBR that HA hosts has extra patches from the HA team I think? I heard the source is buggy from a TBR maker

[silent rune]

I am not 100% sure that a firmware update is needed for the ZBT-1 to be used with OTBR 1.4. I was assuming that, since thread 1.4 is relatively new, that existing firmware might be at the 1.3 level and might need to be updated. I may be wrong about that, but it might be good to update to latest SDK to incorporate further developments / refinements / bug fixes.

These Silicon Labs OpenThread SDK notes: https://docs.silabs.com/sisdk-release-notes/latest/sisdk-ot-release-notes/sisdk-ot-sdk-release-notes suggest that there are new thread 1.4 features in the Version 2.7.0+ Simplicity SDK; my understanding is the existing ZBT-1 device firmware is based on the older Gecko SDK, so there may be something there that needs updating.

[round narwhal]

yeah, its mainly just the channel scanning one that HA has included

[odd hull]

the only thing i see in that changelog relevant to the rcp firmware is bugfixes. looks like one of them is important since it fixes a compatibility issue when using a newer host openthread version to talk to the rcp. But there's no obvious new features in the rcp firmware - most of the listed thread 1.4 stuff is implemented in the border router.

[south canopy]

That’s basically a vendor TBR implementation I assume? If packed in chipset sdk

[odd hull]

yeah, vendor tbr implementation. i'm not familiar with silicon labs, but the espressif version is normally done by pairing two socs (one doing wifi or ethernet and running the border router, the other one with rcp firmware as a thread radio)

[south canopy]

Yea I had experience with the ESP demo kit

I can ask SL about this, since most dongles HA uses are from SL

[odd hull]

if there is a new rcp firmware required for thread 1.4, hopefully that's reflected as new reported capabilities in the spinel protocol so there can be a clear error reported for an rcp with missing features.

[round narwhal]

looking at NRFs docs on what enchanced network diagnostics is, most of it looks like its implemented in the openthread stack, rather than the RCP https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/thread/overview/supported_features.html#enhanced_network_diagnostics

[odd hull]

i don't see anything obvious in spinel, the most recently added new feature is https://github.com/openthread/openthread/commit/444d1dd6bc62ccf2a471890a2c55ee2a1a7c56a8 which doesn't seem related to anything in thread 1.4

[silent rune]

Good, so maybe this is as simple as updating the otbr version to the latest commit and changing it to thread 1.4.

[silent rune]

So then it sounds like you are already doing an OTBR 1.4 update that can be used as a Home Assistant Add-On - is that correct?
If so, then presumably there is no good reason for me to start one of my own (unless you suggest what you are doing is really so different).

[round narwhal]

i wasn't really intending the updated add-on for public consumption, it was more a experimentation one i had setup and shared it here for what ive managed to build so far

[round narwhal]

currently whats broken is:

• Communication to the internet over ipv6, the nat64 mangle works fine

[round narwhal]

that is thread 1.4 related and is complicated TM

thread 1.4 needs dhcp6-pd to get a mesh GUA, but dhcpcd needs systemd which home assistant delibretly avoid using it doesnt, i just have to install it manually

[odd hull]

haos uses networkmanager to configure the network connections, but i'm not sure whether it can or how to make it request a prefix

oh, huh, apparently networkmanager gained support for prefix delegation in version 1.54. Probably needs a bit of work to set it up, and figure out how to get the delegated prefix and assign it to the thread network :/

[odd hull]

an interesting thing about dhcp6-pd is that it potentially helps the cross-subnet thread case, since most routers that are able to provide delegated prefixes will set up a route for the delegated prefix as a side-effect.

[south canopy]

The main branch of OTBR should be in dev instead of 1.4 milestone right?

[brisk topaz]

That would be great! Do you intend to coordinate your efforts with Nabu Casa so your OTBR 1.4 Addon/ZPT-1 firmware could become an „official beta version“ comparable to the beta of the „python-matter-server“ Addon?

[round narwhal]

yeah, im running into this now, network manager is already running on the DHCPv6 port so i cant run dhcpcd in the container :P The best way probably would be to orginise some communication between the container and home assistant to allow it to dynamically request a prefix.

this is probably something more for the actual maintainer of the addon to do as its a sweeping change across multiple components that will need architeture

[odd hull]

Yeah, would require changes to supervisor to provide an API to request a delegated prefix, and managing those by telling networkmanager to ask for a delegated range big enough to fit all the requested ranges.

Might even need changes in the otbr POSIX code itself to handle communicating with an external service for finding out what ipv6 ranges to use.

[round narwhal]

its actualy not made many modifications there, it seems to largely setup radvd on the wpan interference

and uses that to announce the prefix into the mesh

im going to try something, as i have just had an idea

(all very jank manual subnet assisgnments in OpenWRT)

basicly, ignore DHCPv6 for now and just setup static routing and prefix and add a option to the addon to input a mesh gua

[round narwhal]

Looking into it, network manager only asks and delegate a prefix if there is a seprate interface that can have its mode set to shared, so i dont think it'll work

[odd hull]

Ah, that's unfortunate. You'd really want to be able to tell it to request a prefix but do nothing with it, and let you see the prefix it got over dbus.

[round narwhal]

there really needs to be a 3rd network type for addons that uses mac bridges so that they can get their own interface

or a larger project to replace Network Manager as it makes too many assumptions about the type of device its running (a desktop)

Asked for a thread discussion in #1346914401508392980

[round narwhal]

running into maintainer apathy, so might be a bit stuck

[odd hull]

it probably would be possible to do everything that home assistant needs with systemd-networkd, but it would be quite a lot of dev work to make that change :/

should note that to the best of my understanding, unless i'm misreading things, thread 1.4 requires either dhcp6-pd or nat64, but not necessarily both.

the goal is to provide some way for thread devices to route traffic to the internet, and i guess they don't care if that's via ipv6 or ipv4? :/

[red pollen]

Honestly, I believe that most set-ups will end with more then one TBR in the mix. To me TBRs are to thread devices what access points are to WiFi devices, but with a different RF technology. Just as you connect your notebook to your network via a WiFi access point, you would connect your light bulb to your network via TBR. Yes, I know, this is an oversimplification, but it serves the point I am trying to make: So like with access points you want to be able to place TBRs strategically to get the best coverage possible. To this end, and while we don't have TBRs in a lot of other vendors' access points, what the market is missing, are good single purpose TBRs. So I can place them, where they provide good connectivity, and not be placed accidentally in some speaker, smart display or TV set... (or even my Home Assistant box, that I already placed, where I would get good ZigBee/Z-wave or what not coverage)
So with NabuCasa already in the hardware business, that would be a killer thing to have: A small competitive device just to host the TBR software. And because it would just serve this single purpose, we could strip everything that's currently needed in HA to facilitate and align the hosting of multiple containers, and tweek the OS platform towards the needs of an openthread TBR.
Oh my, I guess, I just got carried away.

OK, what I probably meant is not to bother with an OTBR add-on within HA, but find a way to scale these still following the philosophy of HA.

[round narwhal]

im not sure how network manager would use it, but it may be possible to use both

https://wiki.archlinux.org/title/NetworkManager#DHCP_client

[brisk topaz]

Hm, I really like my Proxmox virtualized HA instance creating my Thread mesh via OTBR Addon and USB-passthrough ZBT-1. It would be great - at least for me - if this setup could cover all my (future) needs concerning Thread.

[round narwhal]

yeah, im thinking as an interim measure whilst the addon is in a bad state is running the border router on a raspberry pi

[round narwhal]

amazons eero actually does have Thread Border Routers in the eero 7 line

[red pollen]

Yeah, but for reasons I am stuck with unifi, so that is not an option for me at least.

[red pollen]

Which actually works pretty well. And from which I can tell that you don't necessarily have to upgrade the RCP firmware (at least for silabs based chips like ZBT-1)

[round narwhal]

couldnt get the automatic RADVD method working, so had to use ot-ctl prefix add [prefix] paros which is :P

but it did mean i could ping google from my devkit

[red pollen]

To my understanding you don't have to fiddle with an extra RADVD. OTBR already handles RA as part of its core.

[round narwhal]

yeah

although looking at the scripts that get installed when you enable DHCP-PD, it configures radvd

not sure why

[red pollen]

Oh wow, this really look like a mess..

looking at script/_dhcpv6_pd_ref alone gives me headaches, parts of the configuration "are not fully understood, but seem neccessary by experimentation". Others are known to break mDNS.

I wonder if that still holds true with the new openthread internal mDNS implementation (which just got better yesterday)

[round narwhal]

also noting that the RCP firmware contains OPENTHREAD_CONFIG_IP6_SLAAC_ENABLE

[round narwhal]

i wonder if one of the following instructions resets the noipv6rs option internally to DCHPCD

    case O_IPV6RS:
        ifo->options |= DHCPCD_IPV6RS;
        break;
    case O_NOIPV6RS:
        ifo->options &= ~DHCPCD_IPV6RS;

Just to check my logic, the reason its working twice is because its flipping it on then off

(that code block is from dhcpcd)

[round narwhal]

nah

that would ensure its set off

hmm

[red pollen]

From looking at whats going on in the openthread repo, I always believed 1.4 is the main branch.

[brisk topaz]

This is also my understanding.

[round narwhal]

I was looking arround at the OT stuff again, there is actually 2 ways of it doing DHCPv6:

• OT_DHCP6_CLIENT which is a internal one which seem to be the prefered one
• DHCPV6_PD_REF is the one used by the refrence image

I also had my home network slightly missconfigured

[red pollen]

So what is the outcome? does it work for you now "out of the box"? I mean, I imagine there should probably be some manual prefix assigning somewhere anyway with GUAs?

[round narwhal]

not sure

[silent rune]

As an update, I won't be working on updating the OTBR to Thread 1.4 update. First issue - I gave it a try, but every time I tried to install it, I had a manifest error. Second - I no longer need it. Originally, I was motivated to try an update because my thread network of over 100 devices was in a constant state of route recalculation with devices dropping off the network and very few devices were being promoted to router status. Often, only the OTBRs themselves would appear as router nodes. So, I tried an experiment - I have about 40 Eve devices (Motionblinds, outlets, plugs) that allow setting of the transmit power level. I had them set to "High" power tansmit. I changed them all to "Default" and my thread network stabilized, devices all joined properly, and more nodes got promoted to router status, and everything works fine.

So, lesson learned, don't use Eve matter devices in High power transmit mode. My theory on this is that it creates a asymmetric line - with the Eve products able to reach the OTBRs/routers, but the OTBR/routers transmittbeing less ing with less power and being less reliable reaching the node, so the connection is unstable. By using a more moderate ("Default") power level, I'm guessing the OTBR/routers and nodes are better able to determine a reliable routing path. Oh, and both my Apple TVs and Home Assistant OTBRs have joined into a single network - before, that wasn't happening, or the Apple TVs would drop off and form their own network.

[full violet]

I've been experiencing similar issues with my Thread network since May. I've been able to "fix it" it for short bursts but it always comes back. Switched from Skyconnect to a SLZB06M and it worked for a couple weeks before it started doing the connectivity dance again--devices going online and offline like a game of whack-a-mole. I even tried factory resetting and starting a new network, but by the 4th node they started dropping offline already. I don't have any Eve devices, just Inovelli.

[silent rune]

I also have many Inovelli devices and have suggested they also try testing different power levels to check network stability.

[brisk topaz]

Xmas comes early this year!
Thread Reference 2025-06-12 has been released an hour ago! 🙌🏼🥳

https://github.com/openthread/openthread/releases/tag/thread-reference-20250612

[fresh forge]

Apple has rowed back. While they initially used Thread 1.4 in their tvOS 26 betas, Thread 1.3 is now being used again. Official Apple OS 26 was released yesterday. Thread 1.4 is probably not ready yet.

[old hamlet]

They probably encountered problems that have been fixed in the version released yesterday. We will probably have to wait for the April version now.

[south canopy]

or hopefully first dev beta of 26.1?

[old hamlet]

Maybe for the April release

[brisk topaz]

Let’s hope HA will update the OTBR Addon soon. The HA community would be anyway much more capable to test Thread 1.4 under real life conditions. Don’t you think?

Let‘s also hope Google will go for shorter release cycles from now on. Two years are simply too long, especially as Thread will gain more traction with e.g. Ikea‘s product releases in the queue.

[red pollen]

Sigh - hoped for one maintenance task less. sticking to self-built T14BR™ on RPi as the leader of the BR herd for another couple of months...

[silent rune]

Just curious - what April release are you referring to?

[old hamlet]

iOS. New types/features are often published in April, as is the case with RVC Matter.

[solemn summit]

they seem held back on the stagnent development on fuchsia, especally with a large majority of the team being cut a few months ago

i mean, they do seem to be slowly improving things

[brisk topaz]

If you follow the commits on GitHub, there is only one person working full-time on the code and almost committing every day. A few others commit from time to time. This is especially surprising, as Thread has been positioned as one of the pillars of Matter based home automation. I am also wondering, why nobody else from the Thread alliance is providing additional resources or at least (co)finances them.

All the more kudos to the Google guys who made the last release possible - against some odds. 👏

[solemn summit]

Iirc most of the thread alliance Is people who just do it do it on the side, and arnt actually paid at all/a small amount

[old hamlet]

Still Thread 1.3.0 for beta 26.1. We'll have to wait longer.

[vivid bay]

for self-built T14BR do you links to how you did this? i would like to try it out my self.

[vivid bay]

looks like last week OT relase new version, and if reading it correctly it fully 1.4 supported.

https://github.com/openthread/openthread/releases/tag/thread-reference-20250612

[red pollen]

I usually just use latest main from the otbr repo, but interesting that there is a release tag now. I compile it directly on an RPi 3B+. There is a corresponding release tag for the ot-br-posix repo as well, btw.
I essentially follow this documentation https://github.com/openthread/ot-docs/blob/main/site/en/guides/border-router/build-native.md
but have since tweaked the compiler options a bit.

[brisk topaz]

Is there only a master branch for the OTBR Addon?

I just scrolled around a bit to see if the OTBR Addon was worked on, but there’s no dev branch, only the master.

[red pollen]

I don't know, I was referring to this https://github.com/openthread/ot-br-posix OTBR repo.