I’d also recommend at least taking a look at a standalone border router based on OTBR such as GL.iNet GL-S20, currently under $50. This is fully compatible with the existing REST API so there is no need for v1.4 credential sharing support.
EDIT: I had an extra esp32-h2 lying around so I setup another OTBR to try this, and it would seem the app-in-the-middle is in fact required to use ePSKc for OTBR to retrieve credentials, it cannot get them directly from another TBR. You can however use OTBR to create an ePSKc for other TBRs to join (via an app).
One example I found is the below article demonstrating the IKEA DRIGERA app which lets you join an existing network using a passcode, or generate a passcode to add a new device (e.g. TBR). Unfortunately I can’t test it because I have enough border routers… But if someone has DRIGERA I would encourage them to try the the ot-ctl ba ephemeralkey PASSCODE command to see if the first command lets the DRIGERA join the OTBR mesh, or conversely, enter the passphrase provided by IKEA into the joiner command to join the IKEA mesh. UPDATE: the joiner command is radio-only so cannot see the mDNS announcements about the ePSKc. (again note that this requires OTBR supporting Thread v1.4 which, as of today, is only the docker version whereas HAOS add-on has a pending CR for support).
Why run the border router in a container under Linux? An Open Thread Border Router will run on and ESP32-S3. Espressive sells OTBRs for $10 each.
For a little more they will sell you an Ethernet daughter card that lets you route Thread to Eithernet
The device needs power. So you also need to add low-power phone charger and USB-C cble
There really is no reason at all to install a Thread radio or Thread USB dongle on you HA server. If the server has Ethernet then it can access your Thread network. If ther BR is Thread/WiFi then the data goes through the BR to your WiFi router, then to Ethernet and then to HA. If the BR is Thread/Ethernet then the data travels more directly.
Here is a link to the device, thery sell for $10, more or less depending on shipping ESP Thread Border Router | OpenThread. Be warned that “some assembly required.”
The Ikea article sheds a little bit of light on this, so thanks for pointing it out. After reading the article and perusing the Thread 1.4 spec, what I believe is happening is the following… perhaps a bit too long to read
I’ll use the article as an example, so let’s say there is an existing Dirigera TBR running an existing Thread network and their is a Dirigera App on a mobile device. For the moment let’s say the mobile device does not have any Thread credentials. The user then purchases a new ABC TBR and with it, they have a companion ABC App on the same mobile device.
To get the ABC TBR to join the existing Dirigera Thread network:
The User uses the Dirigera App and chooses the “Share network Credentials” option.
The Dirigera App then makes a request to the Dirigera TBR to generate an ephemeral key and from the key the Dirigera TBR provides the Dirigera App with a one-time-passcode. Whether the app does this in a proprietary way, or actually makes a Thread compliant DTLS connection to the Dirigera TBR, I don’t know. I did find that the regular meschcop._udp records have a new flag in 1.4 to indicate that the TBR is “ephemeral key capable” so its possible the Dirigera App listens for this and makes a DTLS connection to the Dirigera TBR.
After The Dirigera TBR generates the ePSKc/Passcode, Dirigera TBR puts itself into an “ephemeral key” mode, and then it starts sending out mesh-e._udp advertisements (this is new) which provides connectivity information to reach the Dirigera TBR only for an ePSKc session.
The user gets the OTP from the Dirigera app and copy/pastes the OTP into the ABC app (in the Thread spec this ABC App is called the “Candidate” and in the white paper it is sometime called the “Candidate (application)” ).
From the OTP, the ABC App generates an ePSKc key, and the ABC App then starts listening for these mesh-e advertisements and gets it and with the information from the advertisement it then makes a secure DTLS connection using the ePSKc key.
The Dirigera TBR checks and accepts the connection. The ABC App then requests the credentials and the Dirigera TBR provides them to the ABC App. Afterwards, the connection is torn down and the Dirigera TBR exits the “ephemeral key” mode and stops sending meschcop-e advertisements.
The ABC App stores these credentials within the mobile device (for future IOT device commissioning), and also provides these credentials to the ABC TBR (the Thread spec says this can be done in a vendor specific way), at which point the ABC TBR can now join the Dirigera Thread network.
Yes, this was my take as well, thanks for the clarification. Unfortunately there’s no “ABC App” for HAOS/OTBR to perform this type of join (my hopes doing it via CLI now dashed), and I’m not certain whether the HA app & OTBR even have the underlying infrastructure to put it on the roadmap, so it could be a while. In the mean time you have to “send credentials to HA” then “join preferred network” to get OTBR onto a third-party mesh.
My suspicion is that going in the opposite direction should work — that you can enter CLI commands on OTBR to create an ephemeral key passcode (i.e. without an app) and the IKEA app should be able to accept that code, obtain the credentials, and pass them to Drigera to join the OTBR mesh? I can at least confirm my OTBR does broadcast _mechcop-e._udp advertisements when I enter the ba ephemeralkey start secretkey command, but I don’t have a third-party v1.4-compatible border router to complete the join test.
No telling if/when this will work its way into the HA Thread UI, but this could be a much easier way to get third-party devices to join an existing HAOS/OTBR mesh once their associated apps support the ePSKc UX workflow like IKEA has.
