Matter Commissioning Discovery Bug — _matterc._tcp vs _matterc._udp

Get Help Integrations
1

I'm running Hubitat C8 Pro with Matter 1.5 (beta) on the latest firmware and have identified what appears to be a bug in Hubitat's Matter commissioning discovery implementation.

The Issue:

Hubitat's Matter stack is querying for _matterc._tcp during commissioning discovery. Per the official Matter specification handbook ( handbook.buildwithmatter.com/how-it-works/discovery/#commissionable-discovery ), the correct DNS-SD service type for commissionable discovery is _matterc._udp — not _matterc._tcp.

I initially suspected the device manufacturer (BigA$$ Fans, Haiku L Series) of a nonconformance and contacted them directly. They correctly pointed me to the Matter handbook confirming _matterc._udp is the spec-defined service type. Their firmware is correct.

Evidence from Hubitat Matter Logs:

Every commissioning attempt follows the same pattern regardless of which fan I try or whether I manually enter the pairing code:

pairDeviceWithCode() called
Starting commissionable node discovery over DNS-SD
Discovery timed out
Stopping commissionable node discovery over DNS-SD
Failed to get device address.

The commissioning window IS open and the device IS advertising _matterc._udp correctly, which was confirmed via Aruba AirGroup mDNS cache inspection during active commissioning windows:

_matterc._udp.local PTR IN 4500 192.168.75.162
E71EA7626DD347BA._matterc._udp.local SRV/NBSTAT IN 120 192.168.75.162
E71EA7626DD347BA._matterc._udp.local TXT IN 4500 192.168.75.162

No _matterc._tcp record is ever advertised by the device, which is correct per spec.

The most definitive test was when Hubitat itself opened a commissioning window on an already-paired Haiku fan via OpenCommissioningWindow. I confirmed successful in logs with a generated pairing code then immediately called pairDeviceWithCode() with that code. Even in this scenario where Hubitat directly triggered the commissioning window and knows the discriminator, DNS-SD discovery still timed out. The device was live on the network and advertising _matterc._udp the entire time.

Additional Context:

  • One Haiku L fan was successfully paired to Hubitat previously (Node ID 3022), suggesting the issue may be intermittent or timing-dependent rather than a hard block
  • Network: Aruba Instant AP cluster, all Matter devices on VLAN 75 / 192.168.75.0/24, Bonjour proxying enabled and confirmed working for _matter._tcp operational records
  • Hubitat firmware: latest release with "Hardened Matter startup logic" applied
  • The Haiku fans commission successfully with Google Home which correctly handle _matterc._udp

Request:

Please verify that Hubitat's Matter commissioning discovery is querying for _matterc._udp as required by the Matter specification, and not _matterc._tcp. If the implementation is querying _matterc._tcp, this would explain the consistent discovery timeouts with any spec-compliant device that correctly advertises _matterc._udp.

Happy to provide full Matter logs, mDNS cache output, or additional diagnostics if helpful.

Thank you,
Eric

2

@Hubitat_Staff

3

Does the mean your hubitat hub and matter devices are on separate vlans? If yes do you have the same issue when you put them both on the same vlan?

Across home automation platforms I’ve seen a lot of issues with matter devices and vlans, mostly with unifi gear. Regardless of gear or network config it’s best to keep it simple, in this case put all matter devices on the same broadcast domain. If that works, it’s your network config and would match with most matter over wifi issues i’ve sean.

4

Agreed “KISS”. Everything is on the same L3 VLAN. A while ago, I had vlans segmented pretty heavily, but started getting a lot of issues with IOT gear, so I consolidated everything down to just one. Right now I have Lutron, Lifx, Hue, Kasa, Google, Alexa, Sonos, Meross, a handful of zwave and a bunch of zigbee.

5

Matter Details and logs from the hub would be beneficial.

IMG_1277
IMG_12771676×725 80.8 KB

6

If everything is on the same vlan, why is this enabled?

7

I would also double check that the device running the mobile app thats doing the matter commissioning is also on the same vlan..

IMG_1278
IMG_12781744×717 209 KB

8

Phone, fan and hub all on 192.168.75 network. all on same ssid running 2.4

not letting me upload images
Matter 1.5 (beta) is enabled

Overview

Status: Online
Fabric ID: BCAEB2A2ECEB93E7

Network

Hub IPv6 addresses

wlan0

fdb6:b7a8:520b:1a7b:aed9:29ff:fe09:b440

wlan0

fe80:0:0:0:aed9:29ff:fe09:b440

one fan joined and that was just random after deleting and readding a few times.

5/29/2026 13:10:57.585CTL[1167:1381] Stopping commissionable node discovery over DNS-SD
5/29/2026 13:10:57.585CTL[1167:1381] Discovery timed out
5/29/2026 13:10:27.583CTL[1167:21543] Starting commissionable node discovery over DNS-SD
5/29/2026 13:10:27.583CTL[1167:21543] Stopping commissionable node discovery over DNS-SD
5/29/2026 13:10:27.583CTL[1167:21543] Checking ICD registration parameters
5/29/2026 13:10:27.583CTL[1167:21543] Setting CSR nonce to random value
5/29/2026 13:10:27.583CTL[1167:21543] Setting attestation nonce to random value
5/29/2026 13:10:27.582CTL[1167:21543] pairDeviceWithCode() called
5/29/2026 13:08:28.403CTL[1167:1381] Stopping commissionable node discovery over DNS-SD
5/29/2026 13:08:28.403CTL[1167:1381] Discovery timed out
5/29/2026 13:08:21.757CTL[1167:1381] Discovered device does not have an open commissioning window.
5/29/2026 13:08:21.559CTL[1167:1381] Discovered device does not have an open commissioning window.
5/29/2026 13:07:58.401CTL[1167:21543] Starting commissionable node discovery over DNS-SD
5/29/2026 13:07:58.401CTL[1167:21543] Stopping commissionable node discovery over DNS-SD
5/29/2026 13:07:58.401CTL[1167:21543] Checking ICD registration parameters
5/29/2026 13:07:58.401CTL[1167:21543] Setting CSR nonce to random value
5/29/2026 13:07:58.401CTL[1167:21543] Setting attestation nonce to random value
5/29/2026 13:07:58.398CTL[1167:21543] pairDeviceWithCode() called
5/25/2026 11:18:03.205DIS[1167:1381] SRV record already actively processed.
5/25/2026 11:18:03.202DIS[1167:1381] SRV record already actively processed.
5/25/2026 11:18:02.986DIS[1167:1381] SRV record already actively processed.

9

Fixed that for you. You can upload images now.

10

Tagging @bcopeland

11

So i can view entries in airgroup on my iaps
This is me trying to join fan to hubitat
IAP01_downstairs# sh airgroup cache entries mdns | i 192.168.75.190
_api._tcp.local PTR IN 4500 192.168.75.190 foreign Fri May 29 13:04:19 2026
LivingRoom._api._tcp.local SRV/NBSTAT IN 120 192.168.75.190 foreign Fri May 29 13:04:19 2026
LivingRoom._api._tcp.local TXT IN 4500 192.168.75.190 foreign Fri May 29 13:04:19 2026
_http._tcp.local PTR IN 4500 192.168.75.190 foreign Fri May 29 13:04:19 2026
LivingRoom._http._tcp.local SRV/NBSTAT IN 120 192.168.75.190 foreign Fri May 29 13:04:19 2026
LivingRoom._http._tcp.local TXT IN 4500 192.168.75.190 foreign Fri May 29 13:04:19 2026
5443B20C0DFC.local A IN 120 192.168.75.190 foreign Fri May 29 13:04:19 2026
5443B20C0DFC.local AAAA IN 120 192.168.75.190 foreign Fri May 29 13:04:19 2026
_matterc._udp.local PTR IN 4500 192.168.75.190 foreign Fri May 29 13:45:39 2026
E920AF8BADFA86F9._matterc._udp.local SRV/NBSTAT IN 120 192.168.75.190 foreign Fri May 29 13:45:39 2026
E920AF8BADFA86F9._matterc._udp.local TXT IN 4500 192.168.75.190 foreign Fri May 29 13:45:39 2026
_matter._tcp.local PTR IN 4500 192.168.75.190 foreign Fri May 29 13:45:39 2026
2B7B6B2B84C69310-00000000CABFE1A0._matter._tcp.local SRV/NBSTAT IN 120 192.168.75.190 foreign Fri May 29 13:45:39 2026
2B7B6B2B84C69310-00000000CABFE1A0._matter._tcp.local TXT IN 4500 192.168.75.190 foreign Fri May 29 13:45:39 2026

12

Was able to get one fan joined up randomly last week (office). About 10 min ago, this one (zoe) decided to play nice. I have 2 more I’m trying to get added, but its hit or miss.

image
image1704×587 62 KB

13

This message should only appear if hubitat detects the device is capable of commissioning, but the device is not ready for it. Hubitat can’t currently put the device in paring mode and i don’t know all the timing, but what happens if you manually trigger pairDeviceWithCode first, then commission the device with the hubitat app? Prob VERY close to each other would be best.

What’s the other matter controller that you are triggering pairDeviceWithCode with?

I know this may feel like a cop-out but have you tried performing a factory reset on one of the devices?

14

yea, ive tried factory rest the fan. Im using the phone to comission the matter devices. I believe my thread router is either my google 4ktv or google hub. Process im using is phone (android) app –> google home –> add matter –> input fan matter code –> adds just fine. Then open fan in google home –> link apps & services –> copy code –> input into hubitat in phone app.

15

weird question… are the devices at least matter 1.3? I’m assuming yes, but just to double check.

17

OP didn’t reply, but I can confirm the product in question is Matter 1.2, not Matter 1.3.

18

I'm not sure. It's a Haiku L fan.

19

Unless support has reached out and provided better guidance… .153 was released with fixes for matter pairing. I genuinely hope this gets you going.

The reason i asked about the matter version is while multi-admin has been apart of the matter spec since 1.0, its had a lot of issues till 1.3. The multi-admin enhancements in 1.4 are really good, but 1.3 seams to be very solid. You can check the matter release notes to see what i mean.

Confirming if it’s a 1.2 multi-admin issue would suck, so unless youre feeling froggy i don’t recommend trying this.

Apple, Google and HA are all currently running matter 1.3. If it is a device level multi-admin issue, trying to add them to Apple or HA as well should produce similar results as adding it to Hubitat. Resetting the device and pairing it Apple should work but then adding it to google or HA should fail.

You're running aruba, so when you get bored and give it a shot… if you get results pointing to the device wont pair consistently to any second matter controller then i would push back with the vendor. Shy of that i’m at a loss.