SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread

b_nutzer

Salut,

@qlink said in SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread:

  - NET_ADMIN
  - NET_RAW

OTBR benötigt relativ tiefgreifende Eingriffe in Netzwerk-Angelegenheiten -- das möchte ja am Ende Routen setzen, um Traffic aus dem "normalen Netz" (Ethernet, WiFi) ins Thread-Netz routen zu können und umgekehrt.

Ich könnte mir vorstellen, dass diese beiden gedroppten Capabilities zu Schwierigkeiten führen. Wie verhält sich otbr, wenn Du das weg lässt?

Ansonsten ist die Meldung in otbr etwas unspezifisch -- eine Schreiboperation in die Netzwerk-Schnittstelle (also die Pipe, die socat zur Verfügung stellt) schlägt fehl. Kannst Du auch ggf. Dein "Dashboard" und die "Mode"-Ansicht mal screenshotten?

Qlink

@b_nutzer

ich hab die beiden Zeilen per # ausgeklammert.

Ergebnis ist leider dasselbe:

Starting otbr-agent ...

[NOTE]-AGENT---: Running 0.3.0-9cfb06a

[NOTE]-AGENT---: Thread version: 1.4.0

[NOTE]-AGENT---: Thread interface: wpan0

[NOTE]-AGENT---: Radio URL: spinel+hdlc+uart:///tmp/ttyOTBR?uart-baudrate=460800&uart-flow-control

[NOTE]-AGENT---: Radio URL: trel://eth0

[NOTE]-ILS-----: Infra link selected: eth0

[INFO]-RCP_HOS-: OpenThread log level changed to 4

53d.08:17:36.017 [W] P-SpinelDrive-: Wait for response timeout

53d.08:17:36.017 [I] P-SpinelDrive-: co-processor self reset successfully

53d.08:17:36.017 [C] Platform------: Write() at hdlc_interface.cpp:255: Input/output error

Hier das Dashboard

und hier Mode

b_nutzer

@qlink Danke für die Screenshots. Was gelernt! :)

Gleichzeitig: Das ist ja einigermaßen straight forward, erwartungsgemäß der EFR32-SoC für Thread geflasht, und der Port ist mit 6638 auch korrekt. Du hast den Container nicht nur "restarted", sondern hart neu erzeugt, oder?

Leider fällt mir sonst nicht mehr sehr viel ein ...

Dein docker-compose-Listing nutzt einen Hostname (RCP_HOST=SLZB-MR1.local) -- Du könntest noch versuchen, hier die IP-Adresse einzutragen?

Siehst Du in den Logs (Settings and Tools -> Log and debug) auf dem Stick denn irgendetwas von den Zugriffen durch Dein Synology? Bei mir sieht das so aus:

[26.09.2025 10:26:14] EventSender | [_handleNewClient] new client: 172.16.20.132
[26.09.2025 10:26:15] SocketServer | New client: 172.16.20.132 id: 0

Qlink

@b_nutzer

Ich hab den Host jetzt auf die entsprechende IP Adresse geändert.
Es hat sich dadurch tatsächlich auch die Fehlermeldung geändert:

Starting otbr-agent ...

[NOTE]-AGENT---: Running 0.3.0-9cfb06a

[NOTE]-AGENT---: Thread version: 1.4.0

[NOTE]-AGENT---: Thread interface: wpan0

[NOTE]-AGENT---: Radio URL: spinel+hdlc+uart:///tmp/ttyOTBR?uart-baudrate=460800&uart-flow-control

[NOTE]-AGENT---: Radio URL: trel://eth0

[NOTE]-ILS-----: Infra link selected: eth0

[INFO]-RCP_HOS-: OpenThread log level changed to 4

53d.16:33:49.193 [I] P-SpinelDrive-: co-processor reset: RESET_POWER_ON

53d.16:33:49.193 [C] P-SpinelDrive-: Software reset co-processor successfully

53d.16:33:49.270 [W] P-Netif-------: Failed to enable NETLINK_EXT_ACK: Protocol not available

53d.16:33:49.270 [C] Platform------: platformConfigureTunDevice() at netif.cpp:2037: No such file or directory

Sleeping for 2s to give socat time to come up ... Proceeding.

Kannst du was damit anfangen ?

Im log vom SLZB Stick sehe ich, dass sich der otbr Container meldet:

[28.09.2025 18:21:57] SocketServer | New client: 192.168.30.26 id: 0

b_nutzer

@qlink Puh, das ist ja eine harte Nuss.

@qlink said in SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread:

53d.16:33:49.270 [W] P-Netif-------: Failed to enable NETLINK_EXT_ACK: Protocol not available
53d.16:33:49.270 [C] Platform------: platformConfigureTunDevice() at netif.cpp:2037: No such file or directory

Das sieht für mich aus, als hinge es damit zusammen, wie die Docker-Umgebung auf Deinem Synology aussieht -- otbr möchte ein tun-Device erzeugen, ich halte es für denkbar, dass das mit den von Dir als "macvlan" und "bridge" konfigurierten Netzen kollidiert. Wissen tue ich's nicht.

Ich nutze den Container im Host-Netzwerk:

    network_mode: host

Grüße

Qlink

@b_nutzer said in SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread:

@qlink Puh, das ist ja eine harte Nuss.

@qlink said in SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread:
53d.16:33:49.270 [W] P-Netif-------: Failed to enable NETLINK_EXT_ACK: Protocol not available
53d.16:33:49.270 [C] Platform------: platformConfigureTunDevice() at netif.cpp:2037: No such file or directory                                                                                                                                                                            
Das sieht für mich aus, als hinge es damit zusammen, wie die Docker-Umgebung auf Deinem Synology aussieht -- otbr möchte ein tun-Device erzeugen, ich halte es für denkbar, dass das mit den von Dir als "macvlan" und "bridge" konfigurierten Netzen kollidiert. Wissen tue ich's nicht.

Ich nutze den Container im Host-Netzwerk:
    network_mode: host
Grüße

Ich hab mal etwas gegoogelt und mit folgender Anleitung das tun device auf der Synology installiert:

https://memoryleak.dev/post/fix-tun-tap-not-available-on-a-synology-nas/

Damit schaut das otbr log folgendermaßen aus:

Starting otbr-agent ...
ipset v6.34: The set with the given name does not exist
[NOTE]-AGENT---: Running 0.3.0-9cfb06a
[NOTE]-AGENT---: Thread version: 1.4.0
[NOTE]-AGENT---: Thread interface: wpan0
[NOTE]-AGENT---: Radio URL: spinel+hdlc+uart:///tmp/ttyOTBR?uart-baudrate=460800&uart-flow-control
[NOTE]-AGENT---: Radio URL: trel://eth0
[NOTE]-ILS-----: Infra link selected: eth0
[INFO]-RCP_HOS-: OpenThread log level changed to 4
54d.06:35:20.320 [I] P-SpinelDrive-: co-processor reset: RESET_POWER_ON
54d.06:35:20.320 [C] P-SpinelDrive-: Software reset co-processor successfully
54d.06:35:20.397 [W] P-Netif-------: Failed to enable NETLINK_EXT_ACK: Protocol not available
54d.06:35:20.398 [I] P-Netif-------: Sent request#1 to set addr_gen_mode to 1
54d.06:35:20.398 [I] P-Resolver----: Got nameserver #0: 127.0.0.11
00:00:00.108 [I] CslTxScheduler: Set frame request ahead: 7605 usec
00:00:00.108 [I] ChildSupervsn-: Timeout: 0 -> 190
00:00:00.108 [I] TrelInterface-: Enabled interface, local port:55235
00:00:00.109 [I] RoutingManager: Initializing - InfraIfIndex:190
00:00:00.109 [I] InfraIf-------: Init infra netif 190
00:00:00.109 [N] RoutingManager: No valid /48 BR ULA prefix found in settings, generating new one
00:00:00.110 [I] Settings------: Saved BrUlaPrefix fd6f:b62d:e57a::/48
00:00:00.110 [N] RoutingManager: BR ULA prefix: fd6f:b62d:e57a::/48 (generated)
00:00:00.110 [I] RoutingManager: Generated local OMR prefix: fd6f:b62d:e57a:1::/64
00:00:00.110 [I] RoutingManager: Generated local NAT64 prefix: fd6f:b62d:e57a:2:0:0::/96
00:00:00.110 [N] RoutingManager: Local on-link prefix: fdde:ad00:beef:cafe::/64
00:00:00.110 [I] InfraIf-------: State changed: NOT RUNNING -> RUNNING
00:00:00.110 [I] P-MdnsSocket--: Successfully opened IPv4 socket
00:00:00.110 [I] P-MdnsSocket--: Successfully opened IPv6 socket
00:00:00.111 [I] P-MdnsSocket--: Enabled
00:00:00.111 [I] MulticastDns--: Auto-enabling on infra-if-index 190
00:00:00.111 [I] RoutingManager: Enabling
00:00:00.111 [I] Nat64---------: IPv4 CIDR for NAT64: 192.168.255.0/24 (254 addresses)
[INFO]-HELPER--: Set state callback: OK
00:00:00.111 [I] Nat64---------: State: Disabled -> NotRunning
00:00:00.111 [I] BbrLocal------: Add Domain Prefix: ::/0, NotFound
00:00:00.111 [I] BbrLocal------: Add BBR Service: seqno (71), delay (5s), timeout (3600s), InvalidState
[WARN]-UTILS---: ../../src/rest/network_diag_handler.cpp:1294 lacking some attributes for deviceId be206e758d99b8ee
00:00:00.112 [I] Settings------: Saved BorderAgentId {id:43d872cf9b0eefc3599073227201bf24}
[WARN]-UTILS---: ../../src/rest/network_diag_handler.cpp:1238 cannot get LeaderData while detached
[WARN]-UTILS---: ../../src/rest/rest_devices_coll.cpp:233 - AddItem - be206e758d99b8ee
[INFO]-REST----: RestWebServer listening on 0.0.0.0:8081
[INFO]-APP-----: Co-processor version: SL-OPENTHREAD/2.4.2.0_GitHub-7074a43e4; EFR32
00:00:00.114 [I] Notifier------: StateChanged (0x42038210) [MLAddr NetData PanId NetName ExtPanId BbrState Nat64]
00:00:00.114 [I] BbrLeader-----: PBBR state: None
00:00:00.114 [I] Bbr-----------: Start listening on port 61631
00:00:00.114 [I] Bbr-----------: Backbone TMF subscribes ff32:40:fdde:ad00:beef:0:0:3: OK
00:00:00.114 [I] BbrManager----: Start Backbone TMF agent: OK
00:00:00.126 [I] Platform------: Execute command `ipset flush otbr-ingress-allow-dst-swap` = 256
00:00:00.126 [I] Platform------: Got an error when executing command `ipset flush otbr-ingress-allow-dst-swap`: `Resource temporarily unavailable`
00:00:00.126 [W] Platform------: Firewall - failed to update ipsets: Failed
00:00:00.126 [I] P-Netif-------: NAT64 CIDR updated to 192.168.255.0/24.
00:00:00.126 [I] P-Netif-------: Sent request#2 to delete route 192.168.255.0/24
00:00:00.126 [I] P-Netif-------: Deleting route for NAT64
00:00:00.126 [I] P-McastRtMgr--: Disable: OK
00:00:00.126 [I] RouterTable---: Route table
00:00:00.126 [I] TrelDiscoverer: Registering service otTRELbe206e758d99b8ee._trel._udp
00:00:00.126 [I] TrelDiscoverer:     port:55235, ext-addr:be206e758d99b8ee, ext-panid:dead00beef00cafe
00:00:00.127 [I] MulticastDns--: Adding host address 192.168.30.26

Das sieht doch schonmal nicht so schlecht aus oder was meinst du ?

Was mir jetzt allerdings noch nicht klar ist: Wie kann ich den SLZB-MR1 jetzt mit dem iobroker Matter Adapter verheiraten ?
Oder wie bekomme ich mein Nuki Ultra mit dem SLZB-MR1 verbunden ?

b_nutzer

@qlink said in SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread:

Das sieht doch schonmal nicht so schlecht aus oder was meinst du ?

In der Tat!

Was mir jetzt allerdings noch nicht klar ist: Wie kann ich den SLZB-MR1 jetzt mit dem iobroker Matter Adapter verheiraten ?
Oder wie bekomme ich mein Nuki Ultra mit dem SLZB-MR1 verbunden ?

Da bin ich jetzt leider raus -- ich nutze wie gesagt Home Assistant, dort gibt es zunächst eine "OpenThread Border Router"-Integration, der man IP/Port des otbr (in diesem Fall localhost:8081) mitgibt; anschließend kann man in der "Thread"-Integration ein Thread-Netzwerk anlegen und den OTBR diesen Netz hinzufügen. Für iobroker weiß ich das leider nicht :(

Viel Erfolg!

fir3drag0n

@b_nutzer cool, danke für deinen Container. Funktioniert damit jedes Gerät von Smlight?

Ich nutze nämlich auch Home Assistant als docker und war enttäuscht, dass die Geräte bisher nicht einbindbar waren. Hab es bisher mit einem separaten Open thread border router Von espressif gemacht.

Wird denn ipv6 voll unterstützt?

b_nutzer

@fir3drag0n said in SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread:

@b_nutzer cool, danke für deinen Container. Funktioniert damit jedes Gerät von Smlight?

Davon würde ich ausgehen, aber ich kann dazu nur sagen: Ich nutze einen SLZB-07MG24 (USB) sowie einen SLZB-06M (via Ethernet); andere scheinen mit einem SLZB-MR1 erfolgreich zu sein.

Ich nutze nämlich auch Home Assistant als docker und war enttäuscht, dass die Geräte bisher nicht einbindbar waren. Hab es bisher mit einem separaten Open thread border router Von espressif gemacht.

Wird denn ipv6 voll unterstützt?

Ich bin nicht ganz sicher, worauf Deine Frage nach IPv6 zielt. Aufgabe von Thread ist es, IPv6-Traffic (konkret eben Matter-Traffic) zu transportieren; das tut selbstverständlich.

Geht es Dir darum, den Thread-Stick per IPv6 zu erreichen? Spannende Frage, musste ich auch sofort mal ausprobieren -- tut. Warum würdest Du das wollen?

Oder soll der OTBR von seinem Matter-Controller per IPv6 erreicht werden? Das hab ich jetzt nicht probiert, würde es aber erwarten. Zu welchem Ziel dieses?

... oder darum, im IPv6-Netz transparent zu sein? Ja, ich kann von meinem Arbeitsplatz-Rechner per IPv6 eine "Onvis"-Matter-over-Thread-Steckdose anpingen, dabei nimmt der Traffic also den Weg über den otbr.

Letzteres würde vermutlich ein Original-otbr-Container unterbinden -- der möchte allerhand Firewall-Regeln setzen; das hab ich nicht übernommen, ich finde nicht, dass ein Docker-Container das Firewalling seines Hosts verdrehen sollte.

markus397

Hallo,
ich habe auch einen SLZB mr1 im Netzwerk und Zigbee läuft. Der Matter Adapter ist auch aktiv, aber bisher nur für Alexa. Thread (EFR32MG21)habe ich am Stick aktiv, aber wie binde ich den in IOBroker ein? Mir ist das bisher schleierhaft und möchte auch nicht blind Geräte kaufen zum anlernen was dann nicht geht. Ich stehe komplett auf dem schlauch bei Thread.

Qlink

SLZB per Netzwerk in iobroker einbinden geht scheinbar nicht. Das geht nur mit Home Assistant.

MartinP

Was die Beschränkung der Überschriftenlänge so hervorbringt....

Da muss man ja mehrmals lesen, um zu Verstehen, was gemeint ist.

markus397

geht er denn überhaupt im Iobroker? also wenn man ihn per USB anschließen würde, hat da jemand schon was hin bekommen? Border Router die unterstützt werden habe ich nämlich aktuell noch nicht.

Homoran

@markus397 sagte in SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread:

Border Router die unterstützt werden habe ich nämlich aktuell noch nicht.

der Stick ersetzt ja keinen notwendigen Border Router.
Du kannst den Stick möglicherweise zum Bau eines OTBR verwenden

Community Forum

NEWS

SLZB-MR1 über PoE mit OTBR auf Docker für Matter over Thread

Support us

672

32.7k

82.3k

1.3m