I just tried the command on my HAOS, and just glancing at the output, it looks to be about the same as yours.
I’ve created the HA container and the matter-server container as described on Advanced Raspberry Pi installations - Home Assistant and python-matter-server/docs/docker.md at 8cdce6298060aa25ddd99da10a58826f2c894afe · home-assistant-libs/python-matter-server · GitHub
docker-compose.yml for the home-assistant container:
# cat docker-compose.yml
services:
homeassistant:
container_name: home-assistant
image: "ghcr.io/home-assistant/home-assistant:stable"
volumes:
- ./config:/config
- /etc/localtime:/etc/localtime:ro
- /run/dbus:/run/dbus:ro
restart: unless-stopped
privileged: true
network_mode: host
docker-compose.yml for the matter-server container:
# cat docker-compose.yml
services:
matter-server:
container_name: matter-server
image: "ghcr.io/home-assistant-libs/python-matter-server:stable"
restart: unless-stopped
network_mode: host
security_opt:
- apparmor=unconfined
volumes:
- ./data:/data
- /run/dbus:/run/dbus:ro
My Raspberry PI supports the following IP addresses:
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:6a:02:80 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.15/24 brd 192.168.0.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 2a02:8070:2485:9060:e7c5:35c0:4f43:9c88/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7104sec preferred_lft 3504sec
inet6 fe80::192b:3cb9:aa15:6cb/64 scope link
valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:50:6f:a2:af brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 2001:db8:1::1/64 scope global nodad
valid_lft forever preferred_lft forever
inet6 fe80::42:50ff:fe6f:a2af/64 scope link
valid_lft forever preferred_lft forever
4: br-7f3b1e3c8011: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:1b:7d:bc:1b brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-7f3b1e3c8011
valid_lft forever preferred_lft forever
5: br-d186fbed5721: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:09:91:de:fc brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-d186fbed5721
valid_lft forever preferred_lft forever
inet6 fe80::42:9ff:fe91:defc/64 scope link
valid_lft forever preferred_lft forever
30: vetha194134@if29: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-d186fbed5721 state UP group default
link/ether 16:f1:8e:38:00:73 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 169.254.143.110/16 brd 169.254.255.255 scope global noprefixroute vetha194134
valid_lft forever preferred_lft forever
inet6 fe80::7ebc:e691:d525:5c58/64 scope link
valid_lft forever preferred_lft forever
32: vethd0094b3@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 6a:82:f3:67:6a:14 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet 169.254.82.120/16 brd 169.254.255.255 scope global noprefixroute vethd0094b3
valid_lft forever preferred_lft forever
inet6 fe80::f6ba:fded:89e9:e133/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::6882:f3ff:fe67:6a14/64 scope link
valid_lft forever preferred_lft forever
And the raspi can be reached under the IPv6 address:
#ping6 2a02:8070:2485:9060:e7c5:35c0:4f43:9c88
PING 2a02:8070:2485:9060:e7c5:35c0:4f43:9c88 (2a02:8070:2485:9060:e7c5:35c0:4f43:9c88) 56 data bytes
64 bytes from 2a02:8070:2485:9060:e7c5:35c0:4f43:9c88: icmp_seq=1 ttl=255 time=0.348 ms
64 bytes from 2a02:8070:2485:9060:e7c5:35c0:4f43:9c88: icmp_seq=2 ttl=255 time=0.262 ms
Use IPv6 networking | Docker Docs describes in general howto create an IPv6 network. Should I add the following lines to the HA compose file or the Matter compose file?
networks:
ip6net:
enable_ipv6: true
ipam:
config:
- subnet: 2001:db8::/64
Because the containers are being specified with parameter network_mode: host
this tells the container to use the host’s OS/Stack for networking. Since you are showing that your Pi’s OS has IPv6 addresses are showing up, then the containers with host network mode will use these addresses as well. So, no I don’t think you need to create a separate docker network.
I’ve figured out to activate the docker logs. When I try to add a matter device I get the following errors (starting at 2024-12-27 22:57:37.071):
2024-12-27 22:56:21.699 (MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Logging...
2024-12-27 22:56:21.700 (MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Controller Stack...
[1735340181.769652][1:1] CHIP:CTL: Setting attestation nonce to random value
[1735340181.770233][1:1] CHIP:CTL: Setting CSR nonce to random value
[1735340181.772251][1:1] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
[1735340181.772965][1:1] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_factory.ini
[1735340181.774245][1:1] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_config.ini
[1735340181.774821][1:1] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_counters.ini
[1735340181.775415][1:1] CHIP:DL: writing settings to file (/data/chip_counters.ini-jDi5yj)
[1735340181.775993][1:1] CHIP:DL: renamed tmp file to file (/data/chip_counters.ini)
[1735340181.776039][1:1] CHIP:DL: NVS set: chip-counters/reboot-count = 15 (0xF)
[1735340181.776916][1:1] CHIP:DL: Got Ethernet interface: eth0
[1735340181.777340][1:1] CHIP:DL: Found the primary Ethernet interface:eth0
[1735340181.778426][1:1] CHIP:DL: Failed to get WiFi interface
[1735340181.778450][1:1] CHIP:DL: Failed to reset WiFi statistic counts
2024-12-27 22:56:21.779 (MainThread) INFO [chip.storage] Initializing persistent storage from file: /data/chip.json
2024-12-27 22:56:21.780 (MainThread) INFO [chip.storage] Loading configuration from /data/chip.json...
2024-12-27 22:56:22.063 (MainThread) INFO [chip.CertificateAuthority] Loading certificate authorities from storage...
2024-12-27 22:56:22.063 (MainThread) INFO [chip.CertificateAuthority] New CertificateAuthority at index 1
2024-12-27 22:56:22.065 (MainThread) INFO [chip.CertificateAuthority] Loading fabric admins from storage...
2024-12-27 22:56:22.066 (MainThread) INFO [chip.FabricAdmin] New FabricAdmin: FabricId: 0x0000000000000001, VendorId = 0xFFF1
2024-12-27 22:56:22.066 (MainThread) INFO [matter_server.server.stack] CHIP Controller Stack initialized.
2024-12-27 22:56:22.068 (MainThread) INFO [matter_server.server.server] Starting the Matter Server...
2024-12-27 22:56:22.078 (MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetching the latest PAA root certificates from DCL.
2024-12-27 22:56:25.155 (MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetched 64 PAA root certificates from DCL.
2024-12-27 22:56:25.156 (MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetching the latest PAA root certificates from Git.
2024-12-27 22:56:25.564 (MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetched 2 PAA root certificates from Git.
2024-12-27 22:56:25.567 (MainThread) INFO [chip.FabricAdmin] Allocating new controller with CaIndex: 1, FabricId: 0x0000000000000001, NodeId: 0x000000000001B669, CatTags: []
2024-12-27 22:56:25.861 (Dummy-2) CHIP_ERROR [chip.native.DIS] Failed to advertise records: src/inet/UDPEndPointImplSockets.cpp:416: OS Error 0x02000065: Network is unreachable
2024-12-27 22:56:25.870 (Dummy-2) CHIP_ERROR [chip.native.DL] Long dispatch time: 301 ms, for event type 2
2024-12-27 22:56:25.889 (MainThread) INFO [matter_server.server.vendor_info] Loading vendor info from storage.
2024-12-27 22:56:25.903 (MainThread) INFO [matter_server.server.vendor_info] Loaded 271 vendors from storage.
2024-12-27 22:56:25.903 (MainThread) INFO [matter_server.server.vendor_info] Fetching the latest vendor info from DCL.
2024-12-27 22:56:26.202 (MainThread) INFO [matter_server.server.vendor_info] Fetched 270 vendors from DCL.
2024-12-27 22:56:26.202 (MainThread) INFO [matter_server.server.vendor_info] Saving vendor info to storage.
2024-12-27 22:56:26.213 (MainThread) INFO [matter_server.server.device_controller] Loaded 0 nodes from stored configuration
2024-12-27 22:56:26.228 (MainThread) INFO [matter_server.server.server] Matter Server successfully initialized.
2024-12-27 22:57:37.071 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning with code using Node ID 50.
2024-12-27 22:57:47.239 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:261534369 on exchange 52690i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-12-27 22:57:50.437 (Dummy-2) CHIP_ERROR [chip.native.SC] PASESession timed out while waiting for a response from the peer. Expected message type was 33
2024-12-27 22:58:07.094 (Dummy-2) CHIP_ERROR [chip.native.CTL] Discovery timed out
2024-12-27 22:58:07.095 (Dummy-2) CHIP_ERROR [chip.native.ZCL] Secure Pairing Failed
2024-12-27 22:58:07.096 (Dummy-2) WARNING [chip.ChipDeviceCtrl] Failed to establish secure session to device: src/controller/python/ChipDeviceController-ScriptDevicePairingDelegate.cpp:89: CHIP Error 0x00000003: Incorrect state
2024-12-27 22:58:07.098 (MainThread) ERROR [matter_server.server.client_handler] [547770971680] Error while handling: commission_with_code: Commission with code failed for node 50.
I’ll see if I can find any useful information on the error messages.
I have now tried using the HA OS instead of the HA container. With the HA OS, I can successfully connect my Nanoleaf and Eve devices to the HA via the Tado Bridge X.
I will have to take another look at the IPv6 configuration of my Raspberry.
After a complete reinstallation of the Rapsberry, I can also add my devices with Matter over Thread to the HA container.
The new OS is based on Debian 12 “Bookworm” (previously Debian 11 “Bullseye”). The IP addresses - especially the Docker addresses - now look completely different and a little tidier.:
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:6a:02:80 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.15/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
valid_lft 793330sec preferred_lft 793330sec
inet6 2a02:8070:2485:9060:e94e:3dd9:f9f5:aad4/64 scope global dynamic noprefixroute
valid_lft 7032sec preferred_lft 3432sec
inet6 fe80::9335:9547:fd8:4383/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: br-f73d33489fa9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:01:6d:c0:45 brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-f73d33489fa9
valid_lft forever preferred_lft forever
inet6 fe80::42:1ff:fe6d:c045/64 scope link
valid_lft forever preferred_lft forever
4: br-2b0179c146c4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:9a:8e:97:8f brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-2b0179c146c4
valid_lft forever preferred_lft forever
5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:51:d3:61:55 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:51ff:fed3:6155/64 scope link
valid_lft forever preferred_lft forever
7: veth143e8cd@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 3a:58:1f:98:10:be brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::3858:1fff:fe98:10be/64 scope link
valid_lft forever preferred_lft forever
17: veth0b705f4@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-f73d33489fa9 state UP group default
link/ether 32:0b:0e:bc:ab:10 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::300b:eff:febc:ab10/64 scope link
valid_lft forever preferred_lft forever
19: veth397644d@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-f73d33489fa9 state UP group default
link/ether 42:32:77:70:87:f9 brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet6 fe80::4032:77ff:fe70:87f9/64 scope link
valid_lft forever preferred_lft forever
Most likely your setup is not properly processing IPv6 ND RIO. The Running Matter Server in Docker docs have OS requirements linked, which has some details about what is required to communicate with Thread devices from an IPv6 level.
Otherwise, Home Assistant OS should be an excellent option (disclaimer: I am one of the OS devs ).
Edit: Ah sorry, I see it works now. Yeah most likely you are using NetworkManager now which does things correctly these days.
Thanks for the tip, I was going crazy (I had IPV6 disabled)
Did you do anything differently when you set the RPi up a second time? I’m not using the same hardware (I’m running Proxmox on a minipc) but I am having what look like very similar issues running HA in docker.