I’ve been attempting to use my SONOFF ZBDongle-E to create a Thread network to add my Nanoleaf bulbs to. I’m relatively new to home assistant so if there’s mistakes being made here I apologize in advance.
Here’s a list of all the hardware being used in my setup:
HP T620 running a single node Kubernetes cluster with Kubevirt for managing VMs alongside my regular containerized apps
SONOFF ZBDongle-E flashed with multipan firmware via web flasher redirected to Home Assistant OS KVM via usbredirect
Physical USB to Ethernet network adapter redirected to Home Assistant OS KVM via usbredirect
TP Link Omada home network with IPV6 enabled
Currently I’ve done the following:
Configured and launched a Home Assistant OS KVM via my kubernetes cluster.
Redirected all relevant USB devices to the KVM, confirmed their presence with both lsusb and by checking the home assistant hardware page.
Ensured that home assistant is using the redirected network adapter as default, and confirmed that the silicon labs multiprotocol addon is following that selection.
Confirmed that the OTBR is creating a wpan0 interface within the KVM.
Confirmed that the border router is appearing to other devices on the network by using the Service Browser app on my phone.
Here’s where the issues start, I’ve tried to pair my existing Nanoleaf thread bulbs to the network that should be created by the addon in home assistant. When I open the Nanoleaf app and go to the thread settings I can first see that it’s discovered the network and it prompts me to pair my existing bulbs. After pressing this button it loads for a bit before prompting me to allow network access, then it states that the devices will join the network after some time. However this doesn’t happen, and there doesn’t seem to be any new logs that appear in Home Assistant that state something attempted to connect. Once this connection fails a new network appears in the Nanoleaf app named NEST-PAN-C302, this network will then appear in Home Assistant until a reboot.
Screenshots for each step are below, alongside the logs for the Silicon Labs Multiprotocol addon, as well as the output of ip a for the wpan0 network within the Home Assistant VM.
s6-rc: info: service banner successfully started
s6-rc: info: service universal-silabs-flasher: starting
[14:20:36] INFO: Flashing firmware is disabled
s6-rc: info: service universal-silabs-flasher successfully started
s6-rc: info: service cpcd-config: starting
[14:20:38] INFO: Generating cpcd configuration.
s6-rc: info: service cpcd-config successfully started
s6-rc: info: service cpcd: starting
[14:20:39] INFO: Starting cpcd...
WARNING in function 'main' in file /usr/src/cpc-daemon/main.c at line #186 : Running CPCd as 'root' is not recommended. Proceed at your own risk.
s6-rc: info: service cpcd successfully started
s6-rc: info: service zigbeed: starting
s6-rc: info: service otbr-agent: starting
s6-rc: info: service zigbeed successfully started
[14:20:39:221585] Info : [CPCd v4.3.1.0] [Library API v3] [RCP Protocol v4]
[14:20:39:221768] Info : Git commit: 133b29678b3d0bc7578e098d2f46b4d5bcd2ebb4 / branch:
[14:20:39:221774] Info : Sources hash: ff8300587e7e4ab1def7a89a272c0baef32f9eb3bff9b0ba06b94e655d652367
[14:20:39:221782] WARNING : In function 'main' in file /usr/src/cpc-daemon/main.c at line #186 : Running CPCd as 'root' is not recommended. Proceed at your own risk.
[14:20:39:223223] Info : Reading cli arguments
[14:20:39:223257] Info : /usr/local/bin/cpcd
[14:20:39:244197] Info : Reading configuration
[14:20:39:244224] Info : file_path = /usr/local/etc/cpcd.conf
[14:20:39:244229] Info : instance_name = cpcd_0
[14:20:39:244232] Info : socket_folder = /dev/shm
[14:20:39:244236] Info : operation_mode = MODE_NORMAL
[14:20:39:244239] Info : use_encryption = false
[14:20:39:244242] Info : binding_key_file = /etc/binding-key.key
[14:20:39:244245] Info : stdout_tracing = false
[14:20:39:244248] Info : file_tracing = false
[14:20:39:244251] Info : lttng_tracing = false
[14:20:39:244254] Info : enable_frame_trace = false
[14:20:39:244257] Info : traces_folder = /dev/shm/cpcd-traces
[14:20:39:244260] Info : bus = UART
[14:20:39:244262] Info : uart_baudrate = 460800
[14:20:39:244266] Info : uart_hardflow = false
[14:20:39:244269] Info : uart_file = /dev/ttyACM0
[14:20:39:244272] Info : fu_recovery_pins_enabled = false
[14:20:39:244275] Info : fu_connect_to_bootloader = false
[14:20:39:244278] Info : fu_enter_bootloader = false
[14:20:39:244280] Info : restart_cpcd = false
[14:20:39:244283] Info : application_version_validation = false
[14:20:39:244286] Info : print_secondary_versions_and_exit = false
[14:20:39:244289] Info : use_noop_keep_alive = false
[14:20:39:244292] Info : reset_sequence = true
[14:20:39:244295] Info : stats_interval = 0
[14:20:39:244298] Info : rlimit_nofile = 2000
[14:20:39:244302] Info : ENCRYPTION IS DISABLED
[14:20:39:244305] Info : Starting daemon in normal mode
[14:20:39:260644] Info : Connecting to Secondary...
[14:20:39:449928] Info : RX capability is 256 bytes
[14:20:39:449970] Info : Connected to Secondary
[14:20:39:529575] Info : Secondary Protocol v4
[14:20:39:633588] Info : Secondary CPC v4.3.1
[14:20:39:681691] Info : Secondary bus bitrate is 460800
[14:20:39:783512] Info : Secondary APP vUNDEFINED
[14:20:39:783705] Info : Daemon startup was successful. Waiting for client connections
[14:20:40] INFO: Starting zigbeed...
[14:20:41] INFO: Setup OTBR firewall...
[14:20:41] INFO: Starting otbr-agent...
otbr-agent[307]: [NOTE]-AGENT---: Running 0.3.0
otbr-agent[307]: [NOTE]-AGENT---: Thread version: 1.3.0
otbr-agent[307]: [NOTE]-AGENT---: Thread interface: wpan0
otbr-agent[307]: [NOTE]-AGENT---: Radio URL: spinel+cpc://cpcd_0?iid=2&iid-list=0
otbr-agent[307]: [NOTE]-ILS-----: Infra link selected: enp5s0u1
otbr-agent[307]: 49d.17:13:47.494 [C] Platform------: mCpcBusSpeed = 115200
[14:20:41:374660] Info : New client connection using library v4.3.1.0
[14:20:41:412250] Info : New client connection using library v4.3.1.0
[14:20:41:428331] Info : Opened connection socket for ep#12
[14:20:41:428772] Info : Endpoint socket #12: Client connected. 1 connections
[14:20:41:484766] Info : Endpoint socket #12: Client connected. 2 connections
otbr-agent[307]: 00:00:01.461 [N] RoutingManager: BR ULA prefix: fd9d:77d4:f150::/48 (loaded)
otbr-agent[307]: 00:00:01.464 [N] RoutingManager: Local on-link prefix: fdab:bf42:273c:19e3::/64
otbr-agent[307]: 00:00:01.693 [N] Mle-----------: Role disabled -> detached
s6-rc: info: service otbr-agent successfully started
s6-rc: info: service otbr-agent-rest-discovery: starting
s6-rc: info: service otbr-web: starting
s6-rc: info: service otbr-web successfully started
otbr-agent[307]: 00:00:02.029 [N] Platform------: [netif] Changing interface state to up.
[14:20:46] INFO: Starting otbr-web...
otbr-web[405]: [INFO]-WEB-----: Running 0.3.0
otbr-web[405]: [INFO]-WEB-----: Border router web started on wpan0
Listening on port 9999 for connection...
Accepting connection.
[14:20:47] INFO: Successfully sent discovery information to Home Assistant.
s6-rc: info: service otbr-agent-rest-discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
otbr-agent[307]: 00:00:27.445 [N] Mle-----------: RLOC16 7c00 -> fffe
otbr-agent[307]: 00:00:27.452 [W] Platform------: [netif] Failed to process request#5: Unknown error -95
otbr-agent[307]: 00:00:27.882 [N] Mle-----------: Attach attempt 1, AnyPartition reattaching with Active Dataset
otbr-agent[307]: 00:00:34.385 [N] RouterTable---: Allocate router id 31
otbr-agent[307]: 00:00:34.387 [N] Mle-----------: RLOC16 fffe -> 7c00
otbr-agent[307]: 00:00:34.393 [N] Mle-----------: Role detached -> leader
otbr-agent[307]: 00:00:34.401 [N] Mle-----------: Partition ID 0x295da2d9
otbr-agent[307]: 00:00:34.500 [W] Platform------: [netif] Failed to process request#6: Unknown error -17
otbr-agent[307]: [NOTE]-BBA-----: BackboneAgent: Backbone Router becomes Primary!
21: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc11/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fd9d:77d4:f150:1:3339:97e6:f680:1a0e/64 scope global nodad
valid_lft forever preferred_lft forever
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc10/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc38/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc00/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:0:ff:fe00:7c00/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:6835:9a26:ac7b:3f7d/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::c21:7701:9c3:8175/64 scope link nodad
valid_lft forever preferred_lft forever
Still running into issues but I have a bit more additional context to provide.
When the wpan0 interface appears within the Home Assistant OS KVM I’m able to ping any of the addresses it lists from within the VM. However if I try and ping any of the IPs from the rest of my network only one of the addresses ever works.
21: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc11/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fd9d:77d4:f150:1:3339:97e6:f680:1a0e/64 scope global nodad
valid_lft forever preferred_lft forever
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc10/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc38/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:0:ff:fe00:fc00/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:0:ff:fe00:7c00/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fdaa:5324:9170:9134:6835:9a26:ac7b:3f7d/64 scope global nodad deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::c21:7701:9c3:8175/64 scope link nodad
valid_lft forever preferred_lft forever
Out of the addresses listed there the only one I’m able to ping is fd9d:77d4:f150:1:3339:97e6:f680:1a0e
Looking at my TP Link Omada web panel though I don’t actually see any IPv6 addresses associated with the Home Assistant KVM. Unfortunately I don’t have a whole lot of context as to where the breakdown is happening here. But if there’s anyone who has experience with getting Thread running on an Omada network I feel like that might be where the issue is.
Not sure how much I can help as there are lots of things that can go wrong, but at a high level it looks like your QEMU/KVM based HA VM is probably working correctly.
I’m working a little bit from memory, but I have seen cases from users where the NanoLeaf App may or may not work with an HA based OTBR. I have used the App myself and commissioned a device successfully only to have Matter turn around and fail the interview process. Anyway I believe the NanoLeaf App has to get the full Thread dataset from HA before it can commission a Thread device onto an HA Thread network. Looking at your screenshot of the “home-assistant” network, it only has the Extended PAN ID. If I recall correctly, it also should have the channel, network key, and overall Dataset, so I suspect HA has still needs some more setup.
Does the HA Thread Integration see the HA based OTBR and is it the “preferred” network?
EDIT: It looks like there’s some new logs that popped up in the Silicon Labs Multiprotocol add-on since I last posted, and the errors seem to be mirrored in the Matter add-on as well.
otbr-web[405]: [INFO]-WEB-----: Running 0.3.0
otbr-web[405]: [INFO]-WEB-----: Border router web started on wpan0
Listening on port 9999 for connection...
Accepting connection.
[14:20:47] INFO: Successfully sent discovery information to Home Assistant.
s6-rc: info: service otbr-agent-rest-discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
otbr-agent[307]: 00:00:27.445 [N] Mle-----------: RLOC16 7c00 -> fffe
otbr-agent[307]: 00:00:27.452 [W] Platform------: [netif] Failed to process request#5: Unknown error -95
otbr-agent[307]: 00:00:27.882 [N] Mle-----------: Attach attempt 1, AnyPartition reattaching with Active Dataset
otbr-agent[307]: 00:00:34.385 [N] RouterTable---: Allocate router id 31
otbr-agent[307]: 00:00:34.387 [N] Mle-----------: RLOC16 fffe -> 7c00
otbr-agent[307]: 00:00:34.393 [N] Mle-----------: Role detached -> leader
otbr-agent[307]: 00:00:34.401 [N] Mle-----------: Partition ID 0x295da2d9
otbr-agent[307]: 00:00:34.500 [W] Platform------: [netif] Failed to process request#6: Unknown error -17
otbr-agent[307]: [NOTE]-BBA-----: BackboneAgent: Backbone Router becomes Primary!
WARNING in function 'server_push_data_to_endpoint' in file /usr/src/cpc-daemon/server_core/server/server.c at line #1667 : Unresponsive data socket on ep#12, closing
[15:09:16:697000] WARNING : In function 'server_push_data_to_endpoint' in file /usr/src/cpc-daemon/server_core/server/server.c at line #1667 : Unresponsive data socket on ep#12, closing
[15:09:16:699567] Info : Endpoint socket #12: Client disconnected. 1 connections
Default: DNS Message from 10.0.0.15:50783 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:50783 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:50783 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:57531 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:57531 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:57531 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:47342 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:47342 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:47342 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:45966 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:45966 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:45966 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:60351 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:60351 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:60351 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::c4b9:52ff:fe54:17f1/vethf6503c4/23
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::c4b9:52ff:fe54:17f1/vethf6503c4/23
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::c4b9:52ff:fe54:17f1/vethf6503c4/23
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::c4b9:52ff:fe54:17f1/vethf6503c4/23
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::c4b9:52ff:fe54:17f1/vethf6503c4/23
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::c4b9:52ff:fe54:17f1/vethf6503c4/23
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5c71:96ff:fe4a:4651/vethc1deb87/25
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5c71:96ff:fe4a:4651/vethc1deb87/25
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5c71:96ff:fe4a:4651/vethc1deb87/25
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5c71:96ff:fe4a:4651/vethc1deb87/25
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5c71:96ff:fe4a:4651/vethc1deb87/25
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5c71:96ff:fe4a:4651/vethc1deb87/25
otbr-agent[307]: 4d.17:03:33.412 [W] Platform------: failed to send ICMPv6 message: Network is unreachable
otbr-agent[307]: 4d.17:03:33.412 [W] RoutingManager: Failed to send RA on infra netif 3: Failed
otbr-agent[307]: 4d.17:03:33.786 [W] Platform------: [netif] Failed to process request#12: Unknown error -95
otbr-agent[307]: 4d.17:03:33.797 [W] Platform------: [netif] Failed to process request#13: Unknown error -95
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 10.244.0.37/enp1s0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5a19:b4e4:61f6:b0e/enp5s0u1/3
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5a19:b4e4:61f6:b0e/enp5s0u1/3
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 10.244.0.37/enp1s0/2
otbr-agent[307]: 4d.17:03:34.538 [W] Platform------: failed to send ICMPv6 message: Cannot assign requested address
otbr-agent[307]: 4d.17:03:34.539 [C] RoutingManager: RsSender: Failed to send RS 1/3: Failed
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 10.244.0.37/enp1s0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 10.244.0.37/enp1s0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5a19:b4e4:61f6:b0e/enp5s0u1/3
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 10.244.0.37/enp1s0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5a19:b4e4:61f6:b0e/enp5s0u1/3
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 10.244.0.37/enp1s0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface 10.244.0.37/enp1s0/2
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::5a19:b4e4:61f6:b0e/enp5s0u1/3
otbr-agent[307]: 4d.17:03:37.898 [W] Platform------: [netif] Failed to process request#14: Unknown error -17
otbr-agent[307]: 4d.17:03:49.924 [W] Platform------: [netif] Failed to process request#15: Unknown error -17
Default: DNS Message from 10.0.0.15:47495 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:47495 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:47495 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:48448 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:48448 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:48448 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:57556 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:57556 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 10.0.0.15:57556 to 224.0.0.251:5353 length 4 too short
Default: DNS Message from 172.30.32.1:5353 to 224.0.0.251:5353 length 4 too short
Just as an FYI, when you see an error concerning the “endpoint”, it is usually concerning connectivity with the SkyConnect. In your first set of logs, the endpoint seems to be fine, but in your last set of logs, the endpoint has an error. I think a unplug/replug of the stick and restart the SiLabs multiprotocol should fix it.
I can’t quite figure out some things, but this one I think may indicate a problem with the Ethernet connection, but again I’m not sure. The OTBR wants to use the Host’s Ethernet interface for sending IPv6 Router Advertisements and other IPv6 communications to the local network (which include HA Core). It sorta looks like this is not working
Yeah that seemed to be the issue, I went ahead and tried with another dongle as well just to see if this was an issue with the Sonoff unit and not something with my KVM. No luck on that front though.
I think what’s most likely at this point is there’s an issue with my TP-Link Omada setup, unfortunately though there’s not a lot of documentation available on getting Omada to play nicely with Thread. Which makes sense as it’s more of a business solution for the most part.
I’m going to see if I can increase the logging coming out of my router to see if it actually gets any of these pings. Because I can access the HomeAssistant UI from both IPv4 and IPv6 addresses on my network. So that shouldn’t really be the issue, and I can confirm that the OTBR/Silabs plugins are selecting the correct network interface so that shouldn’t be causing an issue either. I may give things a try with a physical unit running just HomeAssistant OS or by running OTBR in Docker to see if that resolves the issue.
I’ll post an update in this thread if I make any more progress, just in case there’s someone else out there having a similar issue to me in the future.
So I’ve messed around with a few settings here and there and also swapped out the hardware a bit.
I’ve managed to get some of my bulbs paired, and they don’t seem to disconnect at all which is good!
The steps I followed were:
Add the bulbs to the Nanoleaf app using bluetooth, then use the app to upgrade their firmware to the latest version.
Restart the Matter addon, then restart the OTBR addon.
When the NEST-PAN network appears in the Nanoleaf app and Home Assistant UI, change that to the primary network in home assistant and delete the old network that gets generated on first boot.
Use the home assistant border router for credential generation and again restart both addons in the order listed above.
Try to add the bulbs to your thread network in the Nanoleaf app, this should now succeed.
Remove the bulbs you want from the Nanoleaf app by resetting them (turn off and on the light switch until the lights flash red three times)
Close the Nanoleaf app so it doesn’t try and re-pair to the bulbs.
Open the Home Assistant app on Android and start adding a matter device, follow the prompts until the device is added.
If the device fails to add at any step of the way then restart the addons again and do another reset of whatever bulb failed to add, this can take several attempts. Once the bulb is added to home assistant though it doesn’t seem to ever lose connection.
So that’s where I’m at now, it’s a bit rough but once I get things paired they seem to work pretty well. If nothing else they’re very fast to respond to requests in the UI.
For reference the dongle I’m now using is this: Home - nRF52840 MDK USB Dongle running OpenThread which I flashed using the relevant extensions in VS Code.
I am also running home assistant in kubernetes (however, I am not running it within a virtual machine and instead just running the core container along with Multus CNI with a macvlan adapter configured) and trying to get my original sonoff dongle connected to home assistant with Silabs multipan, so I can get both a zigbee and matter network.
I had a few questions about your setup as I’m struggling to get this to work:
I noticed you ended up changing to the NRF dongle instead of the original sonoff - were you originally planning on using the sonoff to run both a matter and zigbee network/does your current set up support running both types of networks?
Did you follow any particular documentation to get your initial matter network created in home assistant and within kubernetes? As I’m not running home assistant operating system, I was of the understanding that I had to run some kind of silicon labs multi-pan container and connect to my sonoff dongle there (I’m not sure if your NRF dongle supports running both types of networks without requiring an intermediary software) - however, I noticed that you mentioned that you are using the HA operating system and I am tempted to just move to using KVM and kubevirt if it just makes things easier and that’s what you recommend.
Thanks so much in advance and I am happy to answer any follow-up questions if needed.
Unfortunately around the end I was kinda just throwing things at the wall to see what would stick - I’d recommend following the instructions I used to get things working with the nRF dongle and see if that gives you any success as it could have been just the steps I was following.
The biggest change I made excluding the dongle swap out was telling home assistant to use the thread network that the Nanoleaf app was insistent existed. Once I did that then the bulbs were willing to pair, albeit with a few retries on some of them.
