What one needs to do is to “Share” the device that has already joined the Echo Matter/Thread to HA. I have not done this myself, but other users report that you go to the Alexa App, and choose the Matter device you want to share, and there you should find some option to share it with other assistants (or something like that) and it should provide you with a sharing code. Then you go to HA and add the device as a Matter device.
Lots of people here confusing Thread and Matter. They are two separate things.
For example, I don’t want multi-admin. I want to control via HA what Amazon and Google can see and control.
I want HA to be my Matter controller.
However, I want all my TBR’s to on these same Thread network. I started with Apple Homepod and Google Hubs, after a couple of updates they finally joined the one network after I got rid of the absolutely awful SkyConnect which constantly caused problems on the thread network (no I wasn’t running multi-proticol). Eventually tried a Sonoff USB and worked as expected. I also have a Nanoleaf shapes TBR.
So the Homepod mini is gone from the network. Added an echo 4th gen and it will not join the existing network that has the Sonoff based OTBR, two google hubs and the Nanoleaf.
Does anyone actually know how to get the echo to join the existing thread network, it is running thread 1.3 based software.
None of the major TBR vendors to my knowledge provide a UI for changing the Thread dataset (credentials) of their border routers. It’s like buying a WiFi router and having it pick your WAP password and not only hide it from you, but never let you change it. It’s nuts, and hopefully it improves someday.
I’ve read accounts that if your phone has a single dataset stored in its keychain/services database, then some TBRs (HomePods and Google, but unsure about Amazon) might grab that dataset when setting up new TBRs with that phone, thus joining the existing network. If you get this method to work, please share your experience.
2 Likes
Thanks for your response.
As I mentioned, I have multiple vendors on the same network. None of which I needed a UI intervention for. Just added an Aqara G5 Pro camera and it too happily joined the existing thread network.
Just an FYI, some users are experiencing problems with multiple TBRs (seems TREL is the concern). Here is a link if interested.
Also, another FYI which you may already know about, Thread v1.4 is suppose to improve/standardize a way to share Thread network credentials so that a new TBR can join an existing Thread network. Not so helpful now, but perhaps in the months ahead.
1 Like
Thank you
I have absolutely no problems with my thread network since my SkyConnect went in the bin.
My current thread network is made up off a Sonoff USB with OTBR on HA, two google hubs, Nanoleaf shape, recently added an Aqara G5 Pro and just removed a Homepod Mini. Perhaps it helps that I am an RF engineer with very strong networking skills.
The cited problems with multiple TBRs have had nothing to do with RF, and rather with poor feature specification. It’s a protocol issue that even Apple has had to implement workarounds.
However, I’m glad you got all your TBRs working on the same mesh, given that, as of Thread v1.3, there is no standard for them to all share/know the same dataset credentials. My earlier point is that, lacking a standard, every vendor is basically winging it, and without a UI, you lack the tools to change their arbitrary decision.
1 Like
Never said they did but having a stable networks is predicated on stable RF. It doesn’t matter what happens on the wired network if the RF isn’t right. Just see the example of zigbee. Many people struggle where others manage perfect networks. It is a shared medium.
As for slow progress on Thread specifications, with people like my friend Jonathan Hui involved there is little wonder. He has always been more about selling these sizzle over sorting the meat and potatoes. Always smoke and mirrors when he is involved.
So making progress on this looking at the meshcop detail for the Amazon it is only running thread 1.1.1. it tells me when asked that it is on the latest firmware however checking on the Amazon support site it isn’t running the latest.
Anybody know how to force an update on an Echo 4th Gen?
1 Like
Hi, is there any update on this?
I got the exactly same issue as OP reported.
I only have an Alexa echo as thread border router. It is shown as “Other networks” in the Thread integration on HA.
I’ve connected my new IKEA matter over thread devices to my Alexa echo whichs works fine. But I can’t add them as Matter device in HA with a Sharing code from the alexa app (same timeouts on my matter server as posted before).
Is there a way to get the devices into HA?
I don’t need them in the alexa app, I just want to have them in HA but using my echo as TBR as I don’t have any other TBR.
This topic solved the issue for me:
https://community.home-assistant.io/t/matter-server-docker-container-on-synology-nas-home-assistant-core
I am running HA and matter-server in docker on a Synology NAS.
“The Synology DSM kernel is missing the CONFIG_IPV6_ROUTE_INFO kernel option, which prevents it from automatically processing IPv6 Router Advertisements for subnets that Matter devices use for communication.”
Running this repo from @psynikal as docker container fixes this issue:
I can now finally use my Echo as TBR and use the sharing code from the Alexa App to add the matter device to HA.
1 Like
Hey @CrazyO I am similarly trying to set up an Echo as TBR for HA running in a Synology. I am trying to set up this repo as a docker container but I am running into some issues where the docker image keeps shutting down immediately. if you dont mind, would you be able to give me a step by step of how you cloned the repo and installed it into container manager?
I basically cloned the repo into my desktop as a .zip, then transferred the zip to a folder where i have the rest of my docker files in the Synology Nas, unzipped it and using SSH i navigated to the folder and ran sudo ./run.sh which gave me an error raise ValueError("Interface '%s' not found !" % dev) seems like it didnt find the interface ovs_eth2, but it did add the image to Container Manager and it ran the container but it closed the container right away, i tried with interface eth0 but that didnt work either.
did you do anything different to set up yours by any chance? Or maybe @psynikal would you happen to know what could be happening?
I’m using docker compose which is called Project in Synology container manager.
My project mainfolder is /volume1/docker/homeassistant.
I’ve created a subfolder /ipv6routes in which I’ve extracted the repo.
This is my docker compose which will use the dockerfile from the /ipv6routes subfolder:
services:
homeassistant:
container_name: homeassistant
image: "homeassistant/home-assistant:stable"
volumes:
- /volume1/docker/homeassistant/config:/config
- /etc/localtime:/etc/localtime:ro
- /run/dbus:/run/dbus:ro
restart: unless-stopped
privileged: true
network_mode: host
environment:
TZ: Europe/Berlin
devices:
- /dev/ttyACM0:/dev/ttyACM0
matter-server:
image: ghcr.io/matter-js/python-matter-server:stable
container_name: matter-server
restart: unless-stopped
network_mode: host
security_opt:
- apparmor:unconfined
volumes:
- /volume1/docker/homeassistant/matter-server:/data/
- /run/dbus:/run/dbus:ro
route-listener:
build:
context: ./ipv6routes
dockerfile: Dockerfile
container_name: ipv6-route-listener
network_mode: host
cap_add:
- NET_ADMIN
- NET_RAW
volumes:
- ./ipv6routes:/app
environment:
PYTHONUNBUFFERED: "1"
command: /bin/sh bin/start.sh -i eth0
Hope that helps @SanjiRaid