OTBR Docker Container + Home Assistant setup?

[scyto]

I seem to be super confused and need help.

sometime later....
Answers where i arrived at a solution.

• I have home assistant running in a VM on proxmox - i don't want the RCP to be connected directly to the VM.
• I have a raspberry pi with docker.
• I use this pi for my zwave dongle and zigbee dongle - running zwave-js-ui and zigbee2mqtt containers
• This all works super well as this pi is in the center of the house.
• I have a public static ipv6 /56 i have subneted down into /64 - my lan uses a single /64 (some irrelevant vlans use other /64)

What i would like to do:

• run OTBR on the pi using docker
• have it correctly participate in my IPv6 network
• have thread nodes work as they should

My questions:

1. should the OTBR be advertising itself using mDNS on my LAN or just the mesh network?
   answer = both so use macvlan to do this

2. the container instructions don't give any real indication of how to store configuration state in a bind mount - how do i do this so things like the formed mesh are persistent across container delete?
   answer = the official OTBR container isn't designed to store state, the HA OTBR integration configures the RCP via API when added (and remembers the TLV data) - there are some issues with reliability of this if the container goes down. In theory the official OTBR container could be modified to redirect some key state files and to run ot-ctl command at start to reform the network - but this is a major refactor. It seems this OTBR container is not really designed for production but just test scenarios.

3. will the container have full functionality if docker bridge networking is used or should it be using host networking?
   answer = macvlan means mdns and all ports work, use this IMHO

4. should i be setting the mesh prefix to one of my /64 ?
   answer = i set it to one of my /64 and enable RA and my LAN devices can now ping the thread nodes on ipv6 - nice!

5. if i have /64 do i need NAT64 running?
   answer = i have no idea if it is running or not, but its all working

6. If i need to have OTBR advertising itself i will need to use host networking or macvlan on the pi, for the former is there an easy way to change the web server port
   answer = didn't matter in the end as i used macvlan and had no port conflicts. i note the -p option could be specified in the entrypoint script (would be nice for the container to be refactored to use variables, i might take a crack at if i have time)

7. my one thread device (aqara door sensor) keeps disapearing after a few hours - a press on the button makes it connect again, answer = good old fashioned signal issue, i need more devices to make more a more robust mesh

Can anyone provide guidance or direct me to a how to?
I guess i will be writing one.....

[scyto]

It's working! - though i am still confused about persisting state across container refreshes.... which i think is required for the mesh network to be reformed when the container is recreated?

any answers i think i have found have been updated in the OP

[scyto]

notes:

• i never got the commissioner working in OTBR web interface working, no idea why
  answer: devices that support matter commissioning don't seem to support thread commissioning; it is not required to support both

• i used the commissioner (add matter device) working via home assistant mobile app on android, as of writing this the iOS app is a dead end for adding matter / thread devices

[scyto]

this is my docker compose if anyone wants to critique (i created an external macvlan for the network)

services:
  otbr:
    container_name: otbr
    image: "openthread/otbr:latest"
    privileged: true
    restart: unless-stopped
    networks:
      - otbr_mvl
    sysctls:
      net.ipv6.conf.all.disable_ipv6: 0
      net.ipv4.conf.all.forwarding: 1
      net.ipv6.conf.all.forwarding: 1
      net.ipv6.conf.all.accept_ra_rt_info_max_plen: 64
      net.ipv6.conf.all.accept_ra: 2
    command: --radio-url spinel+hdlc+uart:///dev/ttyUSB1?uart-baudrate=460800
    devices:
      - /dev/ttyUSB1
    dns: 127.0.0.1

networks:
   otbr_mvl:
     external: true

[agners]

answer: devices that support matter commissioning don't seem to support thread commissioning; it is not required to support both

Exactly. Matter comes with it's own commissioning flow, which essentially transfers the complete Thread operational dataset to the device. That same flow is used for WiFi. So in a way, Matter standardized commissining for it's purpose.

i used the commissioner (add matter device) working via home assistant mobile app on android, as of writing this the iOS app is a dead end for adding matter / thread devices

Currently importing Thread credentials to the HA iOS App is not completely working, but it should be ready with the next release Core release (2024.7.x) 🤞

[scyto]

Interesting, i was forced to delete the OTBR container + replug the SkyConnect as it was non functional
as soon as the home assistant integration contacted the new container it started the RCP with some (but not all) my old radio details.
for example the on-mesh prefix changed but the PANID, NAME, Chanel were all the same - i am unclear if home assistant pulled this from somewhere and occurred the mesh for me, or if it was stored on the SkyConnect in someway

i guess its possible the new container used a previous volume....

it either used data on the RCP or home assistant store the previous network in thread AND persisted that even when i deleted the OTBR integration! i am trending to the latter.....

[scyto]

Interesting, i was forced to delete the OTBR container + replug the SkyConnect as it was non functional as soon as the home assistant integration contacted the new container it started the RCP with some (but not all) my old radio details. for example the on-mesh prefix changed but the PANID, NAME, Chanel were all the same - i am unclear if home assistant pulled this from somewhere and occurred the mesh for me, or if it was stored on the SkyConnect in someway

i guess its possible the new container used a previous volume....

it either used data on the RCP or home assistant store the previous network in thread AND persisted that even when i deleted the OTBR integration! i am trending to the latter.....

I answered the previous question - the network data is stored with the thread integration, however it + otbr integration do not gracefully handle the OTBR container disappearing, i found this was what i had to do if i update the container:

1. docker compose down on the container
2. docker compose pull
3. docker compose up
4. remove the OTBR integration from hass (do not remove the thread integration)
5. re-add the OTBR integration

After that the network would be reformed. Unclear if this is a bug or a feature.

[agners]

Interesting, i was forced to delete the OTBR container + replug the SkyConnect as it was non functional
as soon as the home assistant integration contacted the new container it started the RCP with some (but not all) my old radio details.
for example the on-mesh prefix changed but the PANID, NAME, Chanel were all the same - i am unclear if home assistant pulled this from somewhere and occurred the mesh for me, or if it was stored on the SkyConnect in someway

Currently, the OTBR integration in Home Assistant is single instance. But it does assume that single instance has a persistent storage. The OTBR (or more specifically, the ot-br-posix) implementation stores by default it's information under /var/lib/thread. Besides the pure network configuration, there are also border router specific settings stored there. E.g. a unique border router ID, or, as you found, the (generated) on-mesh prefix. This is pretty much default "ot-br-posix" behavior. What Home Assistant does, is configuring a so called Thread dataset. For that we use the REST API (which we extended to support configuring datasets, see e.g. openthread/ot-br-posix#1682. There are a couple of more PRs driven by the HA team).

After that the network would be reformed. Unclear if this is a bug or a feature.

So no, the current behavior is really how it is intended to work. What you essentially cause by not making /var/lib/thread persistent is in essence a BR factory reset...

I'd recommend to make /var/lib/thread a Docker volume.

FWIW, this is the script/line which makes sure that the location is presistent for the HA OpenThread Border Router add-on.

[scyto]

@agners

I have one remaining confusion - why store container state at all when the hass OTBR integration seems to have enough data to reform the network with a fresh container (as i have seen it do when i readd it after tearing down the official OTBR container [not addon]) it seems hass is already storing some sort of state (TLV + other stuff?) irrespective of what the container stores in its bind mount?

As i understand more what configures what, i can then think more about how to fork and refactor the official container or fork a standalone version of the addon-otbr container that removes the supervisor stuff... my gut says do the latter....

[scyto]

based on the suggestion in this thread home-assistant/addons#3532 (comment) i am now trying another approach:

• run ser2net in docker on the remote machine where the RCP is - this will allow socat running in the hass addon-otbr container to connect over the network to the RCP on the remote pi.
• connect the OTBR addon to that RCP by configuring it to use network device (not yet fully documented in the hass docs)
• matter and otbr integration as normal (point integration at http://homeassistant.local:8081)

ser2net compose file (runs on the remote pi)

version: '3.4'
services:
  ser2net:
    container_name: ser2net
    image: ghcr.io/jippi/docker-ser2net
    restart: unless-stopped
    network_mode: host
    volumes:
      - /home/pi/ser2net/data/ser2net.yaml:/etc/ser2net/ser2net.yaml
    devices:
      - /dev/ttyUSB1

set2net.yaml file

%YAML 1.1
---

define: &banner Connected to port \N(\d)\r\n

connection: &con1
      accepter: tcp,8000
      connector: serialdev,/dev/ttyUSB1,460800N81,local
      options:
              banner: *banner

otbr-addon yaml config
notes:

1. you have to pick a device even though it is not used, this is why you see ttyUSB3 used
2. I could only do this config by yaml, the UI didn't seem to work
3. note the firmware flasher doesn't support this configuration
4. the ip address is the ip address of the pi running the docker container

device: /dev/ttyS3
baudrate: "460800"
flow_control: true
autoflash_firmware: true
otbr_log_level: notice
firewall: true
nat64: false
network_device: 192.168.1.176:8000

[scyto]

this approach has the advantage of ensuring the mesh formation happens if everything is rebooted

[agners]

Honestly, I am not a huge fan of the ser2net solution. Thread is already IP level, so why first forward to another IP participant. The RCP protocol is somewhat timing sensitive, so you might run into surprises.

[scyto]

Honestly, I am not a huge fan of the ser2net solution. Thread is already IP level, so why first forward to another IP participant. The RCP protocol is somewhat timing sensitive, so you might run into surprises.

me neither - its why my pi runs zwavejs2mqtt and zigbee2mqtt using docker on it... the reason is a)it puts the radios in the center of the house and not next to an RF noisy rack and b)when i started i had no easy way to have USB ports on my hass VM as at the time i used hyper-v

the only reason i went down this path is when running the OTBR official container if i tear down the container and put it back up the network doesn't reform unless i remove and readd the OTBR integration - without knowing the code, to the architecture philosophy the team has, my initial thought is it would seem like the OTBR integration should poll the OTBR rest API periodically and reform the network if needed?

when i do it with ser2net the containers on HA are super reliable at reforming the network (no surprise there)

[scyto]

update, this has been running reliably since i impelemented, way easier than trying to bend the official OTBR container to my will

[scyto]

random question: why do the home assistant folks disable mdns in their OTBR add-on when it is required by the thread specification for all border routers....

[agners]

random question: why do the home assistant folks disable mdns in their OTBR add-on when it is required by the thread specification for all border routers....

Can you be more specific? The OTBR add-on should announce itself using the _meshcop._udp service just like any other BR.

How do you determine that mDNS is disabled in the add-on?

FWIW, the OTBR add-on uses the mDNSResponder (so no AVAHI).

[scyto]

random question: why do the home assistant folks disable mdns in their OTBR add-on when it is required by the thread specification for all border routers....

Can you be more specific? The OTBR add-on should announce itself using the _meshcop._udp service just like any other BR.

How do you determine that mDNS is disabled in the add-on?

FWIW, the OTBR add-on uses the mDNSResponder (so no AVAHI).

hmm, well i don't see it advertising itself and i think i confused the no AVAHI with no mDNS... hold on...
well that's strange, it didn't appear at all last night on the discover app on iOS, even after leaving the app open for hours... this morning it does - ok i was wrong - which i am glad about, lol.

[agners]

What i would like to do:

• run OTBR on the pi using docker
• have it correctly participate in my IPv6 network
• have thread nodes work as they should

Just want to put that out here, especially for other folks comming here: We work hard to build exactly that, as an out-of-the-box working solution: Home Assistant OS + OpenThread Border Router add-on provides a well tested and known working platform. It is built ontop of Linux + Docker, and comes with the Supervisor (roughly HA specific "container" manager). And we seek always for contributors, as our system certainly isn't perfect 😉

That said, I do understand, there is fun and value in building something like that from scratch. Not judging, just sayin 😄

I'll answer to things/question in here in more details per answer/topic.

[scyto]

thanks! yes this was first about asking for help, then as i went on the fun adventure capturing what i learn, as it might help others, but it lets me get my thoughts straight too. no value judgement here on the add-on OTBR container vs this one - just want to get to something that is reliable and does what it needs to, and this thread is just a stream of conciousness, lol

also happy to contribute - i already did a minor PR on docs, lol, as for code unlikely unless it is day 1 python stuff, on docker stuff - there i can help, i have containers i have created with a few pulls...

and thanks for answering, i really appreciate it!

[agners]

In general, from what I can tell, the container offered by this upstream project is really more meant for development/testing. The fact that by default Thread network settings are not stored shows that.

That said, ideally I would like to offer a "pure" container to run a OTBR for the Home Assistant community, for those using Core container and Matter container installations. Ideally, I'd like to use that container then as base for the add-on. We have a similar setup for Matter: The python-matter-server project offers a pure container, and this pure container is then also turned into an add-on.

Maybe we could even go a step further and adjust/synchronize with the upstream openthread/otbr container 🤔

[scyto]

I agree, that was my assessment too - designed to work with their guide on fake RCPs and devices they include on the site, no more

i have some skills with docker containers, minimal to no programing skills (i can fix others basic python stuff sometimes, but not create from scratch) i will give some thought to how I can contribute.

[jwhui]

In general, from what I can tell, the container offered by this upstream project is really more meant for development/testing.

Yes, development/testing was the original use case. But as adoption increases, more people are now trying to use it in real deployments.

Maybe we could even go a step further and adjust/synchronize with the upstream openthread/otbr container 🤔

This would be great. It would be great if we could maintain a container that targets the deployment use case.

[tierrie]

Hoping that both of you continue development of the OTBR as a Home Assistant container. I've a similar set up as scyto in that I run HA in docker using Docker Compose via Portainer. My Zigbee2MQTT and Mosquito are all containers. The OS is Ubuntu running as a VM on baremetal ESXi. My Zigbee radios are PoE SMlights.

One blocker is this OTBR in a docker. @scyto , you mentioned writing a doc. Any chance that happened?

[scyto]

A doc, at some point, i's basically what i documented above somewhere in a post above

radio > rPi running docker > container running set2net > network > OTBR integration on home assistant configure for network mode

[tierrie]

Which docker image did you use? The official image that's designed for testing or did you somehow get the HAOS one to run in a docker?

Any chance you'd commit your docker to Github?