openthread_border_router: Add support for network RCP radio

[tl-sl]

I am working on supporting Openthread on the SMLIGHT SLZB-06 range of network ethernet coordinators. This support will include both Silabs and TI variants.

Add support for network sockets using socat, similar to what is done in Silabs-Multiprotocol addon. Thus allowing the ethernet coordinators to be used with Openthread addon.

This has worked well in testing, however it currently requires an as yet unreleased firmware update fixing baudrates > 115200 on the SLZB-06x. This will be released soon however.

darkxst

[agners]

Hm, interesting. I guess this quickly calls for multiple OTBR instances 🙈

It seems those have ESP32 on it, have you considered running a BR on the ESP32 instead (https://github.com/espressif/esp-thread-br/)?

[tl-sl]

I guess this quickly calls for multiple OTBR instances

Yes I guess it sort of lends itself to that, lets start with just one though ;P

It seems those have ESP32 on it, have you considered running a BR on the ESP32 instead

Yes they are based on ESP32 with either EFR32MG21 or CC2652P SoCs , it should be possible to run the espressif BR on them. However the existing ESP32 firmware on these that provides the web UI etc is Arduino based, whereas the Thread stuff is all ESP-IDF, so would likely have to loose the web UI. I will likely look into this further later on, but for now is outside of the scope of my current projects.

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[darkxst]

This has worked well in testing, however it currently requires an as yet unreleased firmware update fixing baudrates > 115200 on the SLZB-06x.

Baudrate fixes for SMLIGHT side are now availabe in the SLZB firmware v2.1.0.dev release

[agners]

Generally looks good.

Has this been tested in practice? I wonder how time sensitive the RCP protocol is, and if tunneling it through WiFi works reliably in practice.

[tl-sl]

Has this been tested in practice? I wonder how time sensitive the RCP protocol is, and if tunneling it through WiFi works reliably in practice.

It has been tested over ethernet on the smlight adapters at 460800 baud, and seems to work well.

I not sure about Wifi, I havent tested this (and wifi is not particularly good on smlight adapters), but given the history of issues with wifi zigbee bridges, it may have issues there particularly with the slow esp32 wifi.

Perhaps there could be a recommendation to only use with ethernet bridges, of which there are quite a few options on the market these days.

[agners]

So checking back with OpenThread folks they told me that the RCP protocol is rather timing sensitive. Apparently the NCP model is less timing sensitive, but supposedly NCP isn't fully supported yet with the latest Thread version.

As you might have noticed, I am a bit hesitant merging this as it adds complexity and potential issues. Maybe it could be maintained/deployed in a fork of this add-on for now for testing 🤔

[agners]

One thing I just noticed: The new option network_device is missing in the translation yaml.

[tl-sl]

So checking back with OpenThread folks they told me that the RCP protocol is rather timing sensitive.

It seems to handle a direct ethernet link (same LAN) fine, but can imagine there could be problems over Wifi etc.

Maybe it could be maintained/deployed in a fork of this add-on for now for testing 🤔

I suppose could try and get some more widespread testing, especially on other devices such as the Tube's gateways etc which I dont have access to myself.

One thing I just noticed: The new option network_device is missing in the translation yaml.

Fixed this, I am sure I had done that previously but may have been lost in rebase somewhere

[agners]

Sorry, found another small issue.

The implementation is quite clean, and if we'll support NCP radios it will require something very similar (just with a slightly different URL). So adding it for RCP with the caveat you've added seems reasonable.

[scyto]

sorry for being dumb, (and technically asking in the wrong place), does this change mean if I run the OTBR add-on on my home assistant it can connect to a dongle (say the sky connect) plugging into a raspberrypi that is else where?

(currently I have the upstream otbr docker container on the pi)

[darkxst]

Your probably better off sticking with the OTBR running on the pi, however in theory you could setup ser2net on the pi and then use this feature.

[scyto]

Your probably better off sticking with the OTBR running on the pi, however in theory you could setup ser2net on the pi and then use this feature.

Thanks, i finally got the official OTBR running on the pi. Only issue is if the container goes down the otbr integration doesn't reform the network on the remote pi when the container comes backup. Workaround remove the otbr integration and readd it - then the network forms.

https://github.com/orgs/openthread/discussions/10311#discussioncomment-9744253 i assume this is not an issue with the addon-otbr container on as things can be orchestrated by the supervisor?

--edit--
ok, got ser2net working in a docker container on the pi, wow that was poke and hope - now on to testing :-)