Matter Unterstützung (Beta)

Nall-chan · 28. Februar 2026 um 15:50

Das entspricht dem ähnlichen Verhalten wie bei VoIP. Vermutlich ist Symcon schneller mit dem starten, als dass der Netzwerk Stack vom OS betriebsbereit ist.

Unter Android gibt es den Punkt.
Hast du iOS? Glaube da fehlt das noch @paresy ?

Ian · 28. Februar 2026 um 16:21

Ne, habe Android in diesem Falle.

Ja, da könnte etwas dran sein. War ich noch nicht drauf gekommen. Ich schaue mal ob ich etwas herausfinden kann.

paresy · 28. Februar 2026 um 16:24

Hast du die 9.0 der App drauf? Denn nur dort ist der Punkt da. Sollte bei beiden OS aktiv sein.

RA sind wichtig sofern, du kein IPv6 native Netzwerk hast. Und insbesondere wichtig, wenn du die TBRs brauchst. Da Shelly’s Matter over WiFi nutzen, sollte es eigentlich ohne Probleme über IPv4 laufen. In unseren Tests waren die Shelly Geräte eigentlich sehr zugänglich und zuverlässug (mit Ausnahme vom Wasserleak Sensor)

paresy

Ian · 28. Februar 2026 um 16:41

Die Logs scheinen eindeutig zu sein:
startet sehr früh im Boot über SysV-Init-Skript
Netzwerk-Interface ist UP, aber mDNS IPv6-Sockets noch nicht vollständig bereit
bindet deshalb manchmal nicht sofort korrekt an die Link-Local / ULA IPv6-Adressen und verursacht sporadische Probleme
Es liegt aber nicht am Netzwerkstack sind ist offensichtlich Timeing-Problem von Symcon

Schnelle Lösung:
Datei anlegen /etc/systemd/system/symcon.service
Inhalt:

[Unit]
Description=IP-Symcon
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStart=/etc/init.d/symcon start
ExecStop=/etc/init.d/symcon stop
RemainAfterExit=yes
TimeoutSec=5min

[Install]
WantedBy=multi-user.target

Mit „After=network-online.target“ und „Wants=network-online.target“ wird dafür gesorgt, dass symcon erst weitermacht, wenn alles bereit.

systemctl daemon-reload
systemctl enable symcon.service
systemctl disable symcon
systemctl restart symcon.service

Ich teste weiter ob sich das verhalten danach in wohlgefallen auflöst.

Oh, das wusste ich nicht. Wie kann ich die denn installieren auf ANdroid?

DerStandart · 28. Februar 2026 um 16:47

Der MYGGSPRAY hier hat zwischendurch mal wieder Bewegung gemeldet. Es ist aber nicht nachvollziehbar, wann er das tut und warum. Er meldet sich nach wie vor alle halbe Stunde, aber die Bewegung meldet er irgendwie nur 1x am Tag.

Was kann ich diesbezüglich tun?

AdrianS · 28. Februar 2026 um 18:01

Guten Abend zusammen,

der Fehler mit dem Secure Pairing failed war bei mir nach dem Update auf RC noch nicht weg, ich habe nun folgendes gemacht:

Per SSH auf den Linux Server, und folgenden Befehl ausführen:

sysctl net.ipv6.conf.ens3.accept_ra

Gibt dieser ra=0 zurück

Dann folgenden Befehl ausführen:

sudo nano /etc/sysctl.conf

in der Datei folgende Zeile hinzufügen:

net.ipv6.conf.ens3.accept_ra = 1

Speichern und am besten den Server Neustarten, dann sollte das im Normalfall klappen, so zumindest bei mir.

AdrianS · 28. Februar 2026 um 18:07

@paresy mir ist nur aufgefallen das dass Nuki wohl nur sperren und entsperren gibt. So ist das aktuell tatsächlich auf in Apple HomeKit, in Home Assistant gibt es allerdings:

Sperren
Entsperren (ohne Türe öffnen)
Türe öffnen

lässt sich das irgendwie einbinden? Mit aktuell nur sperren und entsperren ist das nur bedingt brauchbar, Matter müsste das eigentlich so unterstützen.

paresy · 28. Februar 2026 um 18:13

Nutzt HA auch die Matter Integration? Wir haben ein Nuki hier. Falls da was per „Trick“ möglich ist, schauen wir gerne rein.

paresy

AdrianS · 28. Februar 2026 um 18:15

Na das wäre wirklich klasse Ja in HA habe ich es auch per Matter over Thread eingebunden, ich hab nur bei Nuki auf der Homepage irgendwo gelesen das sie den Datenpunkt “öffnen” extra eingebaut haben.

Ian · 28. Februar 2026 um 18:18

Hmm, dass läuft immer noch nicht sauber. Habe mal ein Wochenprogrmm drauf gelegt um das genauer zu beäugen.

Irgendwann kam wieder ein Fehler.

Ein Symcon Restart hilft dann. Irgendwann bricht es aber wieder weg.

herbertf · 28. Februar 2026 um 19:04

Bei mir taucht auch in den Einstellungen der Symcon-App (die neue Version) der Bereich Matter nach wie vor nicht auf (Android und Apple) - Symcon ist auf 64 Bit Trixi: e455515bb601 vom 27.02.2026

Nall-chan · 28. Februar 2026 um 19:07

Und die ist welche Version?

Die Beta von der App installiert?

herbertf · 28. Februar 2026 um 19:11

Apple 8.1.5

Android auch: 8.1.5 vom 14.10.2025

Nall-chan · 28. Februar 2026 um 19:21

Da dann…
Das hier lesen und umsetzen

TiTan · 28. Februar 2026 um 19:28

Hallo Zusammen,

mit RC1 wollte ich auch mal die Matter Integration bei meinem Roborock Saros 10 testen. Leider schlug bei mir auch die Kopplung fehl - Secure Pairing Failed. Als ich dann aber gelesen habe, dass es mit RC2 funktionieren soll habe ich es gerade nochmals probiert. Leider keine Änderung.

Ich bin etwas ratlos zumal ich mir über die genauen Voraussetzungen für Matter nicht klar bin.
Kurz zum Setup: Ubuntu 24.04.4 als VM (kein Container) auf Synology RS.

Kernel sysctl Einstellungen habe ich soweit geprüft und sind korrekt - keine Firewall.
Roborock und Symcon befinden sich in eigenem VLAN zusammen mit AppleTV, welcher auch als TBR von Symcon gesehen wird. Im VLAN ist ein MLD Querier aktiv und der Router verteilt auch öffentliche IPv6 Adressen via RA.

Ich habe die Kopplung sowohl über den Code in der Roborock App wie auch über Apple Home probiert.

In beiden Fällen zeigt er mir noch nicht mal das Gerät im Symcon an (im Kopplungsdialog) - nach kurzer Wartezeit dann o.g. Fehlermeldung. Was mich auch verwirrt ist, dass im Symcon keinerlei Debug-Ausgaben zu Matter auftauchen. Nur unter /var/log/symcon/logging.log finde ich Einträge.

Mir gehen leider die Ideen aus was ich noch prüfen könnte.

Hier mal ein paar Ausgaben von Avahi (das ich zum test installiert habe), sowie ein Auszug vom Log:

daniel@symcon:~$ avahi-browse -a -t | grep matter
+   eth0 IPv6 7761F7094EACC5E1-00000000FAA481E9             _matter._tcp         local
+   eth0 IPv6 54C14EA3B096E4FD-00000000D309AFE3             _matter._tcp         local
+   eth0 IPv6 54C14EA3B096E4FD-000000008F3438EC             _matter._tcp         local
+   eth0 IPv4 7761F7094EACC5E1-00000000FAA481E9             _matter._tcp         local
+   eth0 IPv4 54C14EA3B096E4FD-00000000D309AFE3             _matter._tcp         local
+   eth0 IPv4 54C14EA3B096E4FD-000000008F3438EC             _matter._tcp         local
+   eth0 IPv6 D1876877C3996D45                              _matterc._udp        local
+   eth0 IPv4 D1876877C3996D45                              _matterc._udp        local

daniel@symcon:~$ ip maddr show dev eth0 | head -n 50
2:      eth0
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:01
        link  33:33:ff:a8:ec:e4
        link  01:80:c2:00:00:00
        link  01:80:c2:00:00:03
        link  01:80:c2:00:00:0e
        link  01:00:5e:7f:ff:fa
        link  33:33:00:00:00:fb
        link  01:00:5e:00:00:fb
        link  01:00:5e:00:17:0c
        inet  224.0.23.12
        inet  224.0.0.251 users 2
        inet  239.255.255.250
        inet  224.0.0.1
        inet6 ff02::fb users 2
        inet6 ff02::1:ffa8:ece4 users 3
        inet6 ff02::1 users 2
        inet6 ff01::1

root@symcon:/home/daniel# cat /var/log/symcon/logfile.log | grep Matter
28.02.2026 19:45:53 | 00000 | MESSAGE | ModuleLoader         | # Matter Configurator geladen
28.02.2026 19:45:53 | 00000 | MESSAGE | ModuleLoader         | # Matter Controller geladen
28.02.2026 19:45:53 | 00000 | MESSAGE | ModuleLoader         | # Matter Device geladen
28.02.2026 19:46:59 | 34630 | MESSAGE | Matter Configurator  | Erstelle...
28.02.2026 19:47:02 | 35601 | MESSAGE | Matter Controller    | Erstelle...
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | ChipLinuxStorage::Init: Using KVS config file: /var/lib/symcon/matter_kvs
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key ExampleOpCredsCAKey0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key ExampleOpCredsICAKey0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key ExampleCARootCert0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key ExampleCAIntermediateCert0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: CTL          | Generating NOC
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | ChipLinuxStorage::Init: Attempt to re-initialize with KVS config file: /tmp/chip_kvs, IGNORING.
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_factory.ini
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_config.ini
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_counters.ini
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | Wrote settings to /tmp/chip_counters.ini
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | NVS set: chip-counters/reboot-count = 2 (0x2)
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | Got Ethernet interface: eth0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | Found the primary Ethernet interface:eth0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bind&listen port=0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bound to port=39023
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bind&listen port=0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bound to port=48654
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | TransportMgr initialized
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: FP           | Initializing FabricTable from persistent storage
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key g/lkgt
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: TS           | Last Known Good Time: 2023-10-14T01:16:48
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key g/fidx
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/n
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/r
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/m
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: FP           | Fabric index 0x1 was retrieved from storage. Compressed FabricId 0x67A9ED34C8CD8EC1, FabricId 0x0000000000000001, NodeId 0xFFFFFFEFFFFFFFFF, VendorId 0xFFF1
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key g/fs/c
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key g/gcc
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key g/gdc
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key g/gcc with size 4
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key g/gdc with size 4
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DMG          | Ember attribute persistence requires setting up
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: ZCL          | Using ZAP configuration...
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | Avahi Poller
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | Avahi Poller
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | Avahi Poller
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: DL           | Avahi server registering
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: CTL          | System State Initialized...
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/vvsc
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/r
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/r
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/n
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/r
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: FP           | Validating NOC chain
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: FP           | NOC chain validation successful
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: FP           | Updated fabric at index: 0x1, Node ID: 0xFFFFFFEFFFFFFFFF
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: TS           | Last Known Good Time: 2023-10-14T01:16:48
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: TS           | New proposed Last Known Good Time: 2021-01-01T00:00:00
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: TS           | Retaining current Last Known Good Time
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key g/sri
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key g/fs/c with size 7
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key f/1/m with size 9
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: FP           | Metadata for Fabric 0x1 persisted to storage.
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key f/1/n with size 248
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key f/1/i with size 231
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: TS           | Committing Last Known Good Time to storage: 2023-10-14T01:16:48
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key g/lkgt with size 8
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Deleted key g/fs/c
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: CTL          | Joined the fabric at index 1. Fabric ID is 0x0000000000000001 (Compressed Fabric ID: 67A9ED34C8CD8EC1)
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bind&listen port=5550
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bound to port=5550
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bind&listen port=5550
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | UDP::Init bound to port=5550
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: IN           | TransportMgr initialized
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/g
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Retrieving value for key f/1/k/0
28.02.2026 19:47:02 | 00000 | DEBUG   | Matter: SVR          | Storage: Stored value for key f/1/k/0 with size 97
28.02.2026 19:47:02 | 35601 | MESSAGE | Matter Controller    | Compressed Fabric ID: 67A9ED34C8CD8EC1
28.02.2026 19:47:06 | 00000 | DEBUG   | Matter: DL           | Avahi server registered
28.02.2026 19:48:17 | 00000 | DEBUG   | Matter: CTL          | Setting attestation nonce to random value
28.02.2026 19:48:17 | 00000 | DEBUG   | Matter: CTL          | Setting CSR nonce to random value
28.02.2026 19:48:17 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 19:48:17 | 00000 | DEBUG   | Matter: CTL          | Starting commissionable node discovery over DNS-SD
28.02.2026 19:48:47 | 00000 | DEBUG   | Matter: CTL          | Discovery timed out
28.02.2026 19:48:47 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 19:48:47 | 00000 | DEBUG   | Matter: TOO          | Secure Pairing Failed
28.02.2026 19:51:39 | 00000 | DEBUG   | Matter: CTL          | Setting attestation nonce to random value
28.02.2026 19:51:39 | 00000 | DEBUG   | Matter: CTL          | Setting CSR nonce to random value
28.02.2026 19:51:39 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 19:51:39 | 00000 | DEBUG   | Matter: CTL          | Starting commissionable node discovery over DNS-SD
28.02.2026 19:52:09 | 00000 | DEBUG   | Matter: CTL          | Discovery timed out
28.02.2026 19:52:09 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 19:52:09 | 00000 | DEBUG   | Matter: TOO          | Secure Pairing Failed
28.02.2026 20:08:16 | 00000 | DEBUG   | Matter: CTL          | Setting attestation nonce to random value
28.02.2026 20:08:16 | 00000 | DEBUG   | Matter: CTL          | Setting CSR nonce to random value
28.02.2026 20:08:16 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 20:08:16 | 00000 | DEBUG   | Matter: CTL          | Starting commissionable node discovery over DNS-SD
28.02.2026 20:08:46 | 00000 | DEBUG   | Matter: CTL          | Discovery timed out
28.02.2026 20:08:46 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 20:08:46 | 00000 | DEBUG   | Matter: TOO          | Secure Pairing Failed
28.02.2026 20:09:14 | 00000 | DEBUG   | Matter: CTL          | Setting attestation nonce to random value
28.02.2026 20:09:14 | 00000 | DEBUG   | Matter: CTL          | Setting CSR nonce to random value
28.02.2026 20:09:14 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 20:09:14 | 00000 | DEBUG   | Matter: CTL          | Starting commissionable node discovery over DNS-SD
28.02.2026 20:09:44 | 00000 | DEBUG   | Matter: CTL          | Discovery timed out
28.02.2026 20:09:44 | 00000 | DEBUG   | Matter: CTL          | Stopping commissionable node discovery over DNS-SD
28.02.2026 20:09:44 | 00000 | DEBUG   | Matter: TOO          | Secure Pairing Failed

root@symcon:/home/daniel# ip addr
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 fq_codel state UP group default qlen 1000
    link/ether 6a:67:05:a8:ec:e4 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 10.87.22.11/24 metric 100 brd 10.87.22.255 scope global dynamic eth0
       valid_lft 407sec preferred_lft 407sec
    inet6 2a01:41e1:2bc5:206:6867:5ff:fea8:ece4/64 scope global deprecated dynamic mngtmpaddr noprefixroute 
       valid_lft 2016642sec preferred_lft 0sec
    inet6 2a01:41e1:2bc5:200:6867:5ff:fea8:ece4/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591843sec preferred_lft 604643sec
    inet6 fe80::6867:5ff:fea8:ece4/64 scope link 
       valid_lft forever preferred_lft forever

Ausser dem Roborock und dem AppleTV gibt es m.E. keine Matter Geräte im Netzwerk.

Irgendwelche Ideen was ich noch probieren/prüfen kann?

herbertf · 28. Februar 2026 um 19:33

Besten Dank Nall-chan.

Habe ich gemacht und der Button ist jetzt da

Vermutlich habe ich einen Fehlkauf mit dem IKEA-Dirigera-Müll gemacht …

Ich habe einen MYGGBETT IKEA Fenstersensor partout nicht an das IKEA-Teil über die IKEA App anlernen können- ebenso auch nicht den Aquara Sensor FP300 .

Beides habe ich soeben auch nicht über die Symcon_app einbinden können

Mein komisches IPHONE hat aber ohne irgendeinen Hub/Controller beide obigen Teile problemlos in die Home APP (Mein Zu Hause oder so ähnlich) integrieren können.

Ohne bisher alles gelesen zu haben … muss Apple scheinbar auf dem Iphone einen Thread.Controller/bridge integriert haben …?

Vermutlich brauche ich einen neuen / besseren Thread-Controller - das komische IKEA DIng hat zumindest laut Symcon nicht mal eine IPv6 gezogen

Bin noch kein Freund von Thread

In meiner

/etc/sysctl.d/20-symcon-matter.conf

steht:

This file was autogenerated by Symcon

These options are required to make Matter work properly with

IPv6 that is required by Matter over Thread and associated

Thread Border Routers.

net.ipv6.conf.all.accept_ra=1
net.ipv6.conf.all.accept_ra_rt_info_max_plen=128
net.ipv6.conf.default.accept_ra=1
net.ipv6.conf.default.accept_ra_rt_info_max_plen=128
net.ipv6.conf.eth0.accept_ra=1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=128
net.ipv6.conf.lo.accept_ra=1
net.ipv6.conf.lo.accept_ra_rt_info_max_plen=128
net.ipv6.conf.ens3.accept_ra=1
net.ipv6.conf.ens18.accept_ra_rt_info_max_plen=128
net.ipv6.conf.lo.accept_ra=1
net.ipv6.conf.lo.accept_ra_rt_info_max_plen=128

paresy · 28. Februar 2026 um 19:49

@herberf Hast du evtl. einen AppleTV oder HomePod zu Hause? Dann hättest du bereits TBRs da.

paresy

Ian · 28. Februar 2026 um 19:52

@TiTan Hast du einmal versucht den Dienst neu zu starten?

systemctl restart symcon

Es gibt offensichtlich Timing-Probleme nach Start. Siehe meinen Beitrag zuvor.

TiTan · 28. Februar 2026 um 20:10

Ja - mehrfach. Mal nur den Dienst und mal die ganze VM aber immer dasselbe Verhalten.

Was mich halt wundert ist, dass Symcon das AppleTV anscheinend erkennt - was ja m.E. auch über mDNS läuft? Grundsätzlich scheint da also irgendwas zu funktionieren.

Das Koppeln des Roborock mit dem AppleTV klappt immer wieder auf anhieb sofern sich das iPhone im selben Netzwerk befindet… nur bei Symcon keine Spur.

paresy · 28. Februar 2026 um 20:21

Du kannst den Spezialschalter „MatterWatch“ aktivieren. Dann bekommst du mehr Infos.

Deine VM hat eine eigene IP-Adresse? D.h. die teil sich nicht die selbe IP wie die Synology selbst, oder? Sofern dein Robi eine IPv4 Adresse hat, sollte es generell auch über IPv4 laufen. IPv6 ist immer für Thread super wichtig. Ich vermute ein Ping geht auch von Symcon zum Roboter?

Ich habe gerade 2xKLIPPBOK, 1xMYGGBETT (frisch gekauft ) und einen JUNG Taster nacheinander bei mir eingelernt. Natürlich ohne Ärger Mein Setup ist eine SymBox, IPv6 aktiv, keine VLANs, HomePods von Apple als TBR und über die Symcon App unter iOS eingelernt.

paresy