Ik ben de afgelopen dagen bezig geweest om Matter (en Thread) werkend te krijgen in Home Assistant. In de lokale IKEA had ik namelijk nog wat Zigbee spulletjes meegepakt, maar vooral mijn vrouw was erg gecharmeerd van de nieuwe
ALPSTUGA luchtkwaliteitssensor. Vandaar dat we ook maar wat Matter spulletjes hadden ingeladen

. Ik had mijn vrouw in de winkel al gewaarschuwd dat het wellicht niet zo
straight forward zou zijn als Zigbee of Z-Wave en daar heb ik (helaas) toch gelijk in gekregen.
Ik heb misschien niet de meest conventionele setup, maar ook geen hele vreemde. Samenvattend komt het neer op:
- Home Assistant Container op host A
- Containers met hardware interfacecs zoals Zigbee2MQTT, Z-WaveJS op host B
- Een Ubiquiti UniFi Dream Router 7 als router
Ik heb wat VLAN's, maar dat is momenteel meer voor de semantische scheiding. Firewall regels zijn er amper. Verder zijn de twee nodes gekoppeld via (meerdere) Docker netwerken. Wederom is hier redelijk vrij baan.
Eerst ben ik begonnen om IPv6 aan te zetten op mijn netwerk. Ik krijg van KPN een eigen /48 en die heb ik dus mooi ingezet. Dat was, na wat restarts her en der, redelijk vlug in kannen en kruiken.
Daarna heb ik mijn oude Conbee II geflashed met de
Thread firmware 
. Echt top dat deConz dit ter beschikking stelt

.Echter kreeg ik de eerder genoemde sensor met geen mogelijkheid gekoppeld

. Na een halve dag aanklooien heb ik dat daarom voorlopig laten gaan...
Ik heb toen besloten om mijn
Google Nest Hub 2 als border router in te zetten. Alhoewel ik geen fan ben van dat apparaat, heb ik in ieder geval een solide basis. Thans vind ik het geen gekke aanname dat hierop Thread en Matter 'gewoon werkt'. En dat klopte ook

. Maar niet in Home Assistant
Daarom heb ik besloten alle betrokkenen - tegen mijn zin in - in 1 VLAN te plaatsen. Maar dat loste niets op. In Avahi Browse en in de Home Assistant Zeroconf browser zag ik wel netjes matter en matterc (commission) records langs komen. Er was dus wel ergens contact... De gewraakte sysctl instellingen had ik ook al toegepast - althans dat dacht ik

- maar ik ben gister gestopt met het vermoeden dat de communicatie tussen de Matter container en het apparaat niet zou werken. Alleen waar dan

??
Telkens kreeg ik dezelfde foutmelding:
code:
1
2
3
4
5
6
7
8
9
| 2025-12-21 15:15:26.368 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:24388i with Node: <0000000000000000, 0> S:0 M:45482056] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2025-12-21 15:15:30.302 (Dummy-2) CHIP_ERROR [chip.native.SC] PASESession timed out while waiting for a response from the peer. Expected message type was 33
2025-12-21 15:15:42.806 (Dummy-2) CHIP_ERROR [chip.native.CTL] Discovery timed out
2025-12-21 15:15:43.720 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:24389i with Node: <0000000000000000, 0> S:0 M:45482057] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2025-12-21 15:15:47.802 (Dummy-2) CHIP_ERROR [chip.native.SC] PASESession timed out while waiting for a response from the peer. Expected message type was 33
2025-12-21 15:16:00.578 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:24390i with Node: <0000000000000000, 0> S:0 M:45482058] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2025-12-21 15:16:05.303 (Dummy-2) CHIP_ERROR [chip.native.SC] PASESession timed out while waiting for a response from the peer. Expected message type was 33
2025-12-21 15:16:18.778 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:24391i with Node: <0000000000000000, 0> S:0 M:45482059] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2025-12-21 15:16:22.803 (Dummy-2) CHIP_ERROR [chip.native.SC] PASESession timed out while waiting for a response from the peer. Expected message type was 33 |
Alhoewel ik mijn containers eigenlijk wil ontsluiten met ipvlan / macvlan heb ik de Matter container - wederom tegen mijn zin in - aan het host netwerk gehangen. En ook alle privileges gegeven. Het moet toch geen rechtenprobleem zijn hè

. Hiermee bleef ik echter hetzelfde resultaat houden. Maar toen ik de routing table op de hoste checkte viel mij op dat deze ook de Matter IPv6 range niet bevatte:
alex@Brickhouse:~$ ip -6 route
2a02:c123:baab::/64 dev enp3s0 proto kernel metric 256 expires 86359sec pref medium
2a02:c123:baab:3::/64 dev enp3s0.41 proto kernel metric 256 expires 86279sec pref medium
2a02:c123:baab:5::/64 dev enp3s0.10 proto kernel metric 256 expires 86348sec pref medium
default via fe80::1c0b:8bff:fe44:2665 dev enp3s0 proto ra metric 1024 expires 1759sec hoplimit 64 pref high
default via fe80::1c0b:8bff:fe44:2665 dev enp3s0.41 proto ra metric 1024 expires 1679sec hoplimit 64 pref high
default via fe80::1c0b:8bff:fe44:2665 dev enp3s0.10 proto ra metric 1024 expires 1748sec hoplimit 64 pref high
Vanuit
deze reactie op GitHub kwam ik op het idee om rdisc6 uit te proberen. Misschien dat ik daar wat meer informatie uitkreeg. Deze heb ik vervolgens geïnstalleerd en geprobeerd...
alex@Brickhouse:~$ sudo apt-get update
alex@Brickhouse:~$ sudo apt-get install ndisc6
alex@Brickhouse:~$ sudo rdisc6 -m -w 1500 enp3s0
Soliciting ff02::2 (ff02::2) on enp3s0...
Hop limit : 64 ( 0x40)
Stateful address conf. : No
Stateful other conf. : No
Mobile home agent : No
Router preference : high
Neighbor discovery proxy : No
Router lifetime : 1800 (0x00000708) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Prefix : 2a02:c123:baab::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 86400 (0x00015180) seconds
Pref. time : 86400 (0x00015180) seconds
MTU : 1500 bytes (valid)
Source link-layer address: 1E:0B:8B:44:26:65
Recursive DNS server : 2a02:c123:baab:2:b00b::53
Recursive DNS server : 2a02:c123:baab:3:b00b::53
DNS servers lifetime : 1800 (0x00000708) seconds
from fe80::1c0b:8bff:fe44:2665
Niets dus. Echter is dit ook de 'verkeerde interface'.
Ik had dus ook een ipvlan (en macvlan om te testen) aangemaakt met een
tagged vlan volgens de Docker documentatie:
alex@Brickhouse:~$ docker network create -d ipvlan \
--subnet=192.168.10.0/24 \
--gateway=192.168.10.1 \
-o parent=enp3s0.10 iot-vlan
Laten we die dan ook eens polsen...
alex@Brickhouse:~$ sudo rdisc6 -m -w 1500 enp3s0.10
Soliciting ff02::2 (ff02::2) on enp3s0.10...
...
Hop limit : undefined ( 0x00)
Stateful address conf. : No
Stateful other conf. : No
Mobile home agent : No
Router preference : medium
Neighbor discovery proxy : No
Router lifetime : 0 (0x00000000) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Route : fdc3:fe75:f89a:1::/64
Route preference : medium
Route lifetime : 1800 (0x00000708) seconds
from fe80::523c:ff3f:fead:b0eb
Daar kreeg ik twee entries terug. Een met een zeer vergelijkbaar resultaat, maar ook de route naar... het Matter over Thread netwerk

. Dat wist ik uit de Zeroconf browser:
De vraag was nu 1) waarom deze niet in de routing tabel staat en 2) hoe ik deze in de container kan krijgen.
Het antwoord op vraag 1 was heel erg flauw. Zoals in de
Matter documentatie zeer duidelijk staat zijn er (minimaal) twee OS aanpassingen verplicht:
- net.ipv6.conf.wlan0.accept_ra=1
- net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen=64
Kort door de bocht staat hier een instelling voor
netwerk,
ipv6,
configuratie, interface
wlan0,
accepteer
router
advertisments en
accepteer
router
advertisments met een
maximum
prefix
lengte van
64. Waarbij dat laatste een adresuimte is van IPv6. En ik heb zoals eerder genoemd een andere netwerk interface.
Maar die instellingen had ik gezet!
op de primaire interface... 
. En dat is dus onvoldoende om het werkend te laten zijn in deze setup

. Nu we het weten kunnen we het echter oplossen

.
# enp3s0 Matter instelling
alex@Brickhouse:~$ sysctl -w net.ipv6.conf.enp3s0.accept_ra=1
alex@Brickhouse:~$ sysctl -w net.ipv6.conf.enp3s0.accept_ra_rt_info_max_plen=64
# enp3s0.10 vlan Matter instelling
alex@Brickhouse:~$ sysctl -w net.ipv6.conf.enp3s0/10.accept_ra=1
alex@Brickhouse:~$ sysctl -w net.ipv6.conf.enp3s0/10.accept_ra_rt_info_max_plen=64
En voila.. Een minuutje later werd de routing table bijgewerkt zoals verwacht
alex@Brickhouse:~$ ip -6 route
2a02:c123:baab::/64 dev enp3s0 proto kernel metric 256 expires 86398sec pref medium
2a02:c123:baab:3::/64 dev enp3s0.41 proto kernel metric 256 expires 85890sec pref medium
2a02:c123:baab:5::/64 dev enp3s0.10 proto kernel metric 256 expires 85893sec pref medium
fdc3:fe75:f89a:1::/64 via fe80::523c:ff3f:fead:b0eb dev enp3s0.10 proto ra metric 1024 expires 1642sec pref medium
De host heeft nu dus toegang tot het Matter via Thread netwerk via de Google Nest Hub. En nu dit dan in de container krijgen.
Ik heb niet de voorkeur voor Network Host mode, maar het lijkt nu even niet anders te zijn. Het is vast mogelijk om het op een andere manier op te zetten, en de kans is vrij groot dat ik hier nog eens naar ga kijken. Maar voor nu wil ik het even werkend hebben zodat ik kan gaan spelen met mijn nieuwe hardware

. Daarvoor gebruik ik dan deze Compose:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| services:
matter:
container_name: matter
image: ghcr.io/matter-js/python-matter-server:8.1.2
restart: on-failure:4
network_mode: host
# Required for mDNS to work correctly
security_opt:
- apparmor:unconfined
cap_add:
- NET_ADMIN
volumes:
- /opt/appdata/matter:/data
- /etc/localtime:/etc/localtime:ro
tty: false
stdin_open: false
tmpfs:
- /tmp:rw,noexec,nosuid,nodev,size=512m
pids_limit: 128
logging:
driver: json-file
options:
max-size: "10m"
max-file: "1" |
Echter is het iot-vlan netwerk van eerder dus wel nog nodig omdat deze in het juiste VLAN zit (10). Het kan ook via Docker om, maar wederom wil ik het nu even werkend hebben

.
De volgende stap voor mij wordt nu om een eigen border router wederom toe te voegen zodat ik wat meer bereik heb. En wat dingen weer terugbouwen zoals ik het wil hebben

. We blijven lekker
[
Voor 100% gewijzigd door
alex3305 op 21-12-2025 17:29
]