I’ve been racking my brain on this for a while and can’t seem to find a good answer so I figured I’d post here.
I’ve got Home Assistant running in a Proxmox LXC, and while most things are working fine Matter/Thread & IPv6 is making me want to put my head through a brick wall.
I’m able to add Matter-over-WiFi devices to HA fine, but adding Thread devices (whether they’re Matter over Thread or Homekit over Thread) to HA fails. I have no IPv6 options in Settings -->System–>Network.
Should’ve mentioned originally that I’ve got my Apple TV and Homepod’s Thread network set as the Preferred Network in the Thread Integration. These issues also persist with Homeklt Only Thread Devices like the Onvis Smart Button - after adding and removing from Apple Home the button becomes visible in HA to be added as a Homekit Device which I assume has to be visible via Thread as my HA host doesn’t have bluetooth.
My docker compose has the network mode for the HA container as host, I have IPv6 enabled in my daemon.json file, IPv6 is enabled in the LXC and in the PvE host itself, and the bridge for the LXC has an IPv6 address via DHCP from my router - yet running a docker network inspect reveals that the docker “host” network has ipv6_enabled=false.
I’m assuming this is the source of my issues adding Thread devices to my HA instance - is this something any of you have dealt with and does anyone have any guidance they can offer me? Any advice would be much appreciated.
__
EDIT: I found the solution, which was to run the following command in both the HA host LXC and the Proxmox instance itself on each interface/bridge through the chain - in my case I had to run it three times, once on eth0 in the LXC, then on the node itself: vmbr0 and `enp1s0.
I’m only running one node, so anyone with a cluster may have some more (or less) involved solution but I hope this helps someone who might be suffering from the same issue.
AFAIK, adding a Matter over Thread device needs a Thread Border Router. Do you have a Thread Border Router? Go to Settings → Integrations → Thread → Configure. Do you see a TBR in there? There are several devices which have TBR built into them. For example, I have Amazon Echo Gen4 which has TBR built into it.
Can’t believe I forgot to mention, but yes I do! I have both a 3rd Gen 128 GB Apple TV 4k and Homepod Mini that I currently use for Homekit and they are my “Preferred Network” in Home Assistant.
When trying to add my Onvis Thread Smart Button I added it to Apple Home, then removed it (which to my knowlege keeps it in the thread network) - at that point it became visible in HA as a Homekit device. It seems like HA can see into the Thread Network (the Onvis button only has thread and BT radios, and my HA host doesn’t have bluetooth on board) but can’t actually access the devices connected to it.
I am not familiar with Apple TBR devices, but here is how it works for Alexa.
I add a Govee Matter light to Alexa app first. Then in Alexa app, I select the Govee light and go to settings. There is an option in settings called Other Assistants and Apps. Clicking on that shows me a Matter code. Then I come back to HA and select Settings → Device → Add a Device → Add a Matter Device. When asked for code, I enter the code from Alexa app. That’s it.
Yeah, it’s essentially the same in Apple Home - you enter pairing mode and get a Matter code in the app, but again this seems to be more of a thread problem than it is a Matter problem considering my Govee Matter Lamp was able to be added to HA without a problem.
Matter over Thread definitely needs IPv6. I have always had IPv6 option in HA. The only other thing I remember is that I did not need a separate DHCPv6 server. The TBR supplies its own IPv6 addresses to the connected devices. Apologize for not being able to help further.
Yeah the Thread stack is only IPv6. It may be the case that the TBR is sending out device discovery on an IPv4 address (as well as IPv6), but I would think in general it should not be sending on IPv4.
Yeah I would have thought you would have this option regardless, but it maybe because the underlying IP stack has IPv6 disabled altogether.
My knowledge of compose is lacking, but let’s check to see what network “driver” the Docker container is using. docker network ls should show some network that uses the host driver. For the moment let’s assume the name of the network is also “host”. docker network inspect host should show that your container is using the host network (the network with a host driver).
In my HAOS based setup, it shows that the ha_core container is using the host network and the inspect host also shows that the “host” network’s settings are:
“Driver”: “host”,
“EnableIPv6”: false
What this all means is that the so called Docker network itself does not have to have IPv6 enabled as it is going to use the native “host”'s IP stack for IPv4 and IPv6.
If your setup looks to be correct, then I’m at a bit of a loss why your HA container doesn’t give you an IPv6 option.
Yep, my HA container is running in host which also has IPv6_enabled as false. I’ll have to spin up another VM and test some stuff out. Here’s a screenshot of what my Network settings page looks like.
There should be a couple of other cards above this one that shows the IPv4 and IPv6 settings … but since yours does not, it may be the case that HA Core does not support these other cards without HA Supervisor. I presume that you don’t have HA Supervisor, correct?
Rethinking this, its more of an issue with your Matter Server, since Matter/WiFi works, let’s confirm it is supporting IPv6, so in your HA UI, goto Settings->Devices->Device Tab find your Matter/WiFi device, and click on “Device Info” and see if shows an IPv6 address(es), if so is there one like “fdaf:blah-blah”? If it is just an “fe80:blah-blah”, then that may be the problem.
This confirms that your Matter Server is using IPv6 as it should be. The fe80 is the typical link-local address that all devices will have, the 2600 is a global address which is fine.
OK so somewhere along the way, you have provided HA with the Thread dataset/credentials of your AppleTV and HomePod and this leads me to think that these two Thread network TBRs and both are on the same Thread network.
So far so good! It means a device on the Apple Thread network got the Thread dataset/credentials, presummably from your iPhone and successfully joined the Apple Thread network and started advertising availability for HA Core’s Homekit integration to see.
You may have to add some information on the steps you are taking to commission a Matter Thread device. If you are using iOS HA Companion App, to do the commissioning, you’ll need to use the same one that was used to add the Homekit device as the iOS device has the Thread credentials that are needed to give to the Matter/Thread device. That iOS device will also need to be on the same WiFi/Ethernet network as your HA Core and Matter Server are on as it needs to talk to at least the Matter Server…
Is your matter server in the same vlan as your appleTV that acts as a border router?
I run ha as a docket container. I had to run matter server (since not supervised) as a separate container and put it in same vlan as appleTV. It took me a while to get it all working but the trick was.
Matter server and appleTV in same vlan, when commissioning a device whether shared via appleTV or directly to HA ensure phone in same vlan as appleTV/matter server.
I don’t have any VLANs or complex networking stuff going on w/ my network, just one network that everything is connected to. I’ve got the python matter server running in a separate container in host mode along with HomeAssistant.
I’ve tried it in both browser and from my phone that I initially used to add them to my Apple Home and get tthe same results, sadly.
services:
# python-matter-server
matter-server:
image: ghcr.io/home-assistant-libs/python-matter-server:stable
container_name: matter-server
restart: unless-stopped
# Required for mDNS to work correctly
network_mode: host
security_opt:
# Needed for Bluetooth via dbus
- apparmor:unconfined
volumes:
# Create an .env file that sets the USERDIR environment variable.
- ${USERDIR:-$HOME}/docker/appdata/matter-server/data:/data/
# Required for Bluetooth via D-Bus
- /run/dbus:/run/dbus:ro
# If you adjust command line, make sure to pass the default CMD arguments too:
#command: --storage-path /data --paa-root-cert-dir /data/credentials --bluetooth-adapter 0
This is just a copy of what was on the github, obviously having mapped the volume properly. I should also say that I can docker exec matter-server ping6 (Apple TV/Homepod IPv6) successfully, and the same for the HA container so it’s not like they can’t talk to each other at all.
services:
# python-matter-server
matter-server:
image: ghcr.io/home-assistant-libs/python-matter-server:stable
container_name: matter-server
restart: unless-stopped
# Required for mDNS to work correctly
network_mode: host
security_opt:
# Needed for Bluetooth via dbus
- apparmor:unconfined
volumes:
# Create an .env file that sets the USERDIR environment variable.
- ${USERDIR:-$HOME}/docker/appdata/matter-server/data:/data/
# Required for Bluetooth via D-Bus
- /run/dbus:/run/dbus:ro
# If you adjust command line, make sure to pass the default CMD arguments too:
#command: --storage-path /data --paa-root-cert-dir /data/credentials --bluetooth-adapter 0
sysctls: # Necessary for the container to receive the routes from the remote Thread network managed by my Google Nest Hub.
net.ipv6.conf.eth0.accept_ra: 2
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen: 64
net.ipv6.conf.eth0.forwarding: 1
Here is my compose using a macvlan adapter so I could get my matter-server in same vlan as appleTV devices.
version: "3.8"
services:
# python-matter-server
matter-server:
image: ghcr.io/home-assistant-libs/python-matter-server:stable
container_name: matter-server
restart: unless-stopped
# Required for mDNS to work correctly
networks:
macvlan20:
ipv4_address: 192.xxx.xx.x
ipv6_address: xxxx:xx::xxxx:xxxx:xxxx:xxxx
#ports:
# - 8080:8080
environment:
- TZ=America/Chicago
security_opt:
# Needed for Bluetooth via dbus
- apparmor:unconfined
volumes:
# Create an .env file that sets the USERDIR environment variable.
- /mnt/docker/matter-server/data:/data/
- /run/dbus:/run/dbus:ro
# Required for Bluetooth via D-Bus
#- /run/dbus:/run/dbus:ro
# If you adjust command line, make sure to pass the default CMD arguments too:
#command: --storage-path /data --paa-root-cert-dir /data/credentials --bluetooth-adapter 0
sysctls: # Necessary for the container to receive the routes from the remote Thread network managed by my Google Nest Hub.
net.ipv6.conf.eth0.accept_ra: 2
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen: 64
net.ipv6.conf.eth0.forwarding: 1
networks:
macvlan20:
external: true