Matter makes me drink. Heavily. Very Heavily

We’ve had a HAOS installation in place for several years. It’s running out of a VM on an ESXi server, has multiple USB devices passed through to it, does Z-Wave and Zigbee like a champ, pulls data over radio from three different RTL-based SDRs, and generally handles home automation tasks beautifully.

Except for Matter. I absolutely cannot get Matter to work, and have no idea what it is that I might be doing wrong. I’m now at the end of two weeks of fighting with it, and from of all of the documentation (official and otherwise) that I’ve read, cannot grasp what the problem(s) might be. By all measures, it should be working - but it’s not.

Configuration is as follows: Home Assistant OS, Core 2026.9.1, Supervisor 2026.09.0, Operating System 18.2, Frontend 20260826.6, Companion app 2026.9.0 (2026.2874). A Sonoff Dongle Plus MG24 running OpenThread firmware (flashed via the HAOS Sonoff Dongle Flasher app) version 2.4.4 is acting as the Thread border router, and the OTBR app is at version 3.1.2. Z-Wave and Zigbee adapters are a Sonoff PZG23 and 3.0 USB Dongle Plus, respectively. The Matter Server app as well as the Matter and Thread integrations are installed and apparently working. Everything across the system should be considered up-to-date and current as of the time of writing.

Here’s what happens when I attempt to add a device via QR code using the companion app:

Every single time, that’s all I get regardless of the device that is attempting to be commissioned. The app goes through both the ‘Contacting’ and ‘Setting Up’ phases, then errors out with this exact message. The logs have literally nothing in them - even when set to debug level - that indicates what the problem might be.

For reference, that screenshot was taken after again attempting to commission a freshly factory-reset Ikea Kajplats light bulb, model no. 106.114.96 with an E12 base. There are three other devices that have produced similar results: a pair of Ikea Timmerflotte temperature / humidity sensors (model no. 506.189.57) and an LG 65UT80 TV. I realise that the Timmerflotte sensors are known to be touchy, and having the TV added to Matter is a near-zero-priority consideration so have only used it as a test device with no intention of putting it into production in the future. The light bulb definitely needs to be functional in HA, though, because one of the roles it’s intended to fulfill is establishing the Matter RF mesh outside of the server closet - and the Timmerflottes will eventually need to route through it once it’s working. FWIW, placing the light bulb into Zigbee mode causes it to join the Zigbee mesh without issue and be controllable as expected via HA, so it is believed to be functional.

The nearest Ikea to us is three hours away in another State, so returning the devices (which were purchased in-store) and trying replacement items isn’t really a practical proposition. There’s no reason at this time to suspect that they’re not working correctly, however. Mentioning this because we’re in a fairly rural location, so obtaining other devices to potentially test with involves mail order and wondering which of their delivery targets Amazon will fail to meet this time.

I no longer have any Android devices, so can’t test if this may be an issue with the iOS Companion App. However, there is no reason to believe that it is at this time.

Being new to both Matter and Thread, it’s entirely possible that I’m missing something basic in configuration which is causing the issues that I’m seeing. The problem, though, is that the lack of information in the logs has me a) baffled since HA and its components are usually really good at logging their activity, and b) left in the dark as to where to go with troubleshooting at this point since I am inexperienced with Matter and thus have exhausted my knowledge on the subject.

Any help that can be offered would be greatly appreciated, and I am more than willing to provide any further information that may be necessary to assist in that regard.

Matter use IPv6 and mDNS.
Make sure IPv6 is enabled in HA and that your router and/or firewall do not block it.
mDNS is generally autoconfiguring itself, but it requires special setups if you are using VLANs, because the protocol is not designed to be routed.

2 Likes

Glad you mentioned this, because I neglected to :slightly_smiling_face:

The network here is multi-VLAN. HA has an interface in the IoT VLAN with IPv6 enabled and is passing traffic directly to and from that VLAN per tcpdump running on the firewall. That same VLAN is also extended out into WiFi, with IPv6 and mDNS confirmed to exist in the VLAN on both the wired and wireless sides.

And when you commission devices all devices, including phone and Matter device is in the same VLAN?

1 Like

As Wally shared, mDNS doesn’t play well with VLANs. There is plenty of information across this forum regarding the topic. In a nutshell

  1. The safest thing you can do is setup a reflector to reflect mDNS from IoT VLAN to your main LAN VLAN and vice versa. Safe, but can be difficult to setup/configure
  2. Another option, and a simple one to do, is to dual-home your HA instance on multiple networks. There are several users who are adamantly against this method as it can lead to other issues and safety concerns pending your setup and configuration. I won’t go into details, as again, there’s plenty of info about it in previous posts. User beware and do your due diligence.
  3. The easiest option, and one many prefer, is to accept that HA is designed to be on a flat network and to setup your network with no VLANs.

YMMV.

1 Like

Correct.

True, but that shouldn’t be necessary - as mentioned, HA has an interface in the IoT VLAN that the Matter devices also reside in. I’ve also confirmed that IPv6 and mDNS traffic is making it to the IoT VLAN from HA’s interface in that VLAN.

This is effectively how HA is currently configured. It’s not my first choice by any means, but neither is mDNS reflection since that has its own set of concerns.

VLANs aren’t the issue in this case, though, and that has been proven through traffic analysis. The compromises made in HA design and configuration in this environment remove that concern.

Well then, very good. If I had to shoot in the dark, I’d guess it’s an IPv6 issue. Have you confirmed link-local addresses are being dispersed from the router? That’s the key, I would think. It’s not the ISP provided IPv6 or the individual devices IPv6 that some provide that you want, it’s link-local, which pending your router (firmware) is setup on the network’s interface. Not the WAN or WAN6 interface.

Yep, the firewall is sending out IPv6 link-local packets as expected. To clarify, the network design here is not relying on ISP equipment past the ONT - we have full control of the environment from the point of handoff.

Alright then. Have you tried clicking buttons on the device in question during the pairing process? I’ve encountered the same-type of situation with zigbee in this regard. Some of these low-powered devices can enter it’s sleep cycle within seconds of being placed in pairing mode. So you have to keep pushing buttons to keep the device awake.

I’ve run into that as well with both Zigbee and Z-Wave devices, but don’t believe it to be the case here. The light bulb is permanently-powered and capable of acting as a routing node, so shouldn’t be going to sleep. Now, I could see it potentially happening with the temperature / humidity sensors since they’re battery-powered, but given that I’m also attempting commissioning immediately after full resets, the devices should be awake and ready to pair at that point.

FWIW, I’ve also been able to confirm via SDR that the devices are emitting RF when expected during the commissioning process. Hitting the button to keep the sensors awake has been tried, but with no apparent change.

That’s quite a conundrum. Are you using iOS or Android to attempt the pair? I’ve seen feedback against using the Web UI and to only use mobile (companion app), but I’ve also seen some issues and negative feedback about Android in the last few months.

iOS. The Web UI enforces the use of the Companion App for commissioning Matter devices (a QR code scan is effectively all but mandatory), so there isn’t really a good way around it. Where possible, Matter pairing codes have also been tried, but the end result’s the same.

FWIW, the Desktop App also directs the user to the mobile device version for commissioning.

There is no desktop app. Only mobile ones.
When talking about commissioning through HA then it is through the web interface of the Matter Server app.

1 Like

This is not correct. The desktop app (which is functionally-equivalent to the mobile apps) is installed here under macOS Sequoia via Homebrew:

casm@lolbawx ~ % brew info home-assistant
==> home-assistant ✔ (Home Assistant): 2026.9.0,2026.2874
Companion app for Home Assistant home automation software
https://companion.home-assistant.io/
Installed (on request)
/usr/local/Caskroom/home-assistant/2026.9.0,2026.2874 (189.5MB)
  Installed using the internal formulae.brew.sh API on 2026-09-02 at 13:26:52
From: https://github.com/Homebrew/homebrew-cask/blob/deaac7cfad96179f38ccd9ac0b6fd3062cbadd5d/Casks/h/home-assistant.rb
==> Requirements
Required: macOS >= 13 ✔
==> Artifacts
Home Assistant.app (App)
==> Analytics
install: 215 (30 days), 671 (90 days), 2,598 (365 days)
casm@lolbawx ~ % 

The Matter Server app can be used under either the desktop or mobile Companion apps, though some features may only be available on desktop or mobile depending on the features’ needs.

It is not equivalent to it. It is the mobile app.
MacOS just makes it possible to run it through an internal VM.

This is a case that clearly shows it was a bad mistake to r name addons to apps.
The Matter Server app is what earlier was called an addon, so it is not a companion app feature. It is a HA app.

Right, but from an end-user perspective, it’s a desktop app running on a desktop OS. Either way, splitting hairs over it doesn’t serve to move things forward.

100% agreed. The rationale behind the renaming always seemed like change for the sake of change with no real benefit and some significant downsides attached.

Correct, and this demonstrates very well why that change of nomenclature was a mistake. The ability to clearly delineate between an HA app (add-on) and the app that is used to access and control HA (Companion) has been significantly reduced, even when the person referring to them is well aware of the distinction.

Have you seen this link: How to add a matter over thread device - Configuration / Matter/Thread - Home Assistant Community

The credentials on my phone were the issue when I started and drank heavily too! :slight_smile:

1 Like

Thanks for that - it is one of the ones I read through in the process of trying to diagnose what’s going on, but re-checked it just in case and everything lines up.

Having said that, I’ve been out of town for the past couple of days and won’t be back for a couple more so can’t check on this right now, but I may have found something worth chasing down. It’s somewhat oblique and I can’t guarantee that it’s the cause of the issues, but it has caught my eye.

Basically, there are seven USB devices passed through from the host to the HAOS VM. Four are plugged into a 4-port USB 2.0 hub, three are plugged into another identical USB 2.0 hub. One hub is attached to a USB 2.0 port on the host - but the other appears to be attached to a USB 3.0 port. And USB 3.0 ports are notorious for causing issues with RF-centric devices connected to them.

Three guesses which USB port the hub that the OTBR dongle is hanging off of is attached to. Hint: it’s not the USB 2.0 one :winking_face_with_tongue:

What’s set me down this line of enquiry is that the OTBR dongle happens to share a hub with the one SDR that has flaky, works-when-it-seemingly-feels-like it performance that I’ve been trying to figure out for a while. This has led me to speculate that, at some point in the radio portion of commissioning a device, RFI from the USB 3.0 port that the OTBR dongle ultimately hangs off of is causing it to have a brain fart and fail to complete the process.

Is it a long shot? Possibly. But given that RF-based devices and USB 3.0 ports are known to not always get along, it’s worth correcting. If nothing else, it’ll at least clean up a hardware config that shouldn’t be the way that it is. And I’l take full responsibility for this state of affairs, because it probably happened when the second USB 2.0 hub was added: USB extension cables were also upgraded at the same time, and I’m willing to bet that one of the hubs just got plugged into the wrong port as part of that process.

Anyway, it’ll take physical access to the machine to move the hub onto the correct port, and I won’t have that for a couple of days. More news after the reconfig.