esp-thread-br
esp-thread-br copied to clipboard
espressif
Enable TREL from menuconfig (TZ-425)
Hi
I'm using this project as a base to make a network extender of the thread network with multiple partitions. According to Thread 1.2, the border routers of both partitions should communicate over TREL. In the build log, I see that the TREL-related libraries are compiled, but the trel command is not available in the CLI. Moreover, in menuconfig there is no options to enable/disable TREL.
The sdkconfig.defaults does contain code to able TREL (CONFIG_OPENTHREAD_TREL=y), but this flag is removed in sdkconfig by the build system.
Is the omission of TREL intentional? Can I easily add it as an additional option to the build system? So far, I've been unsuccessful to get it working locally. Thanks!
Sorry, we does not support this feature now, this configuration is a remained one which we add the supports for the legacy version of TREL. On the removing legacy TREL feature PR, we forget to remove this config in the sdkconfig.defaults.
Hi, a new MDNS feature is needed. For the esp-mdns, it does not support a listening mode, just like avahi-browse -a. We have already sync this feature requirement to MDNS group, and it is under developing.
@opieters Want to note that even without TREL, the Thread devices in two separate partitions could still communicate with each other, as long as the Thread BRs are in the same local network, it can be achieved by the Bi-directional IPv6 Connectivity feature in Thread 1.3.0 Border Router.
TREL is a feature defined in Thread 1.2, but it's not a certification ready feature in Thread 1.3.0 yet. The BR certification in Thread 1.3.0 mainly covers the Matter application requirements, and ESP Thread BR solution is already Thread 1.3.0 certificated component.
Could you let us know your use case and why TREL is required?
Thank you for the update. We are currently using TREL to extend the coverage of our Thread network using several embedded-linux devices. These devices contain significant processing power, which is not required to simply extend the network (as the density of connected devices is quite low). Consequently, we are evaluating the use of an ESP-based BR to extend the network, in a more cost-effective way.
Since the current implementation already uses TREL, we would initially look into this type of connection to have a more consistent structure / simplify the software.
The devices use a propriety protocol, so we are not looking into matter at the moment.