mDNS timeout when commissioning matter over thread device (inovelli white switch)

[shrewd bolt]

After struggling with pairing on my phone, I am attempting over the webUI. Im the furthest ive gotten with pairing but am now seeing the following errors. Any idea what could be wrong with my network? My router is opnsense with ipv6 enabled and ubiquiti APs. all of my unifi mDNS related checkboxes are turned off. I am not sure if something in opnsense is configured improperly.

2024-12-05 13:10:58.494 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning with code using Node ID 8.
2024-12-05 13:11:03.620 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
2024-12-05 13:11:38.871 (Dummy-2) CHIP_ERROR [chip.native.DIS] Timeout waiting for mDNS resolution.
2024-12-05 13:11:52.868 (Dummy-2) CHIP_ERROR [chip.native.DIS] OperationalSessionSetup[1:0000000000000008]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout
2024-12-05 13:11:52.869 (Dummy-2) CHIP_ERROR [chip.native.CTL] Session establishment failed for <0000000000000008, 1>, error: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout.  Next retry expected to get a response to Sigma1 or fail within 60 seconds

...

2024-12-05 13:13:22.871 (Dummy-2) WARNING [chip.ChipDeviceCtrl] Failed to commission: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout
2024-12-05 13:13:22.871 (MainThread) ERROR [matter_server.server.client_handler] [140567978063440] Error while handling: commission_with_code: Commission with code failed for node 8.

nevermind i finaly got my first connection! It was a range issue with the thread adapter

Is there a downside to keeping this device paired manually through the web UI? Should I remove it and re add with mobile, or is it fine if added?

Do devices mesh, will this range issue get better as I pair switches?

[slim minnow]

If it’s added it’s added 😎

[slim minnow]

If these are hardwired switches then they should be able to function as routers, yes

[shrewd bolt]

Thank you

[spark mantle]

If you don't have devices close enough to the thread border router to keep a reliable connection, I'd honestly recommend moving the thread border router (though if it's your HA box, that might not be simple). Other than that, there's not a whole lot of products to try. Maybe an Eve Energy (smart outlet) or a Nanoleaf Essentials bulb at an intermediate distance could help.

[elfin wolf]

nanoleaf bulb

bro i had a bulb literally refuse to factory reset

[spark mantle]

eh, i've had mostly ok results with them, at least once they got the 3.6 firmware which fixed a bunch of the thread routing stability issues.

[shrewd bolt]

it worked out once I got that first device connected, but the first one had to be ~1 meter from the skyconnect

[shrewd bolt]

I would implore some official guide be released for connecting with the web UI because something on the android side was causing a pairing issue but couldn't be narrowed down until I used the webUI

Additionally since googles matter implementation requires google services/elevated permissions I cannot use it in grapheneOS so I had to keep using my girlfriends phone

The "matter hints" forum post was helpful but I'm not sure what the instability they are pointing to is about. It works very well

[spark mantle]

yeah, pairing via the web ui is not the way it's intended to be used for most people. especially since in many cases you won't be able to pair devices "in place" with that - since it needs bluetooth to do network credential provisioning and can't use home assistant bluetooth proxies.

the issues seen in ha support when people do thread device setup from the phone are most commonly either that they don't have working google play services on android or that the network that the phone is connected to isn't on the same network as the thread border router (or otherwise their network is blocking mdns responses or ipv6 router announcements from the thread border router)

[shrewd bolt]

There should still be a guide that isn't a loosely worded forum post. Lots of users here don't have google play services, as this is the open source community after all. An open source protocol supported by an open source home automation system shouldn't need proprietary google services, especially if this is expected to be the standard going forward. Obviously this is due to googles involvement in the implementation of matter, but the web UI offers an easy solution. All of my devices are wall switches which are not movable and there were zero issues pairing with the webui after that first device. Hell, it worked better than using my girlfriends stock android phone.

If I was okay with proprietary services I would have just bought an Apple TV that works out of the box and not a skyconnect that's taken a month of troubleshooting to set up, that is also capable of connecting to a device from more than a meter away

At the very least it should be made very clear this is an option for those who do not use google services or have mobile phone access.

I originally followed the forum post just for troubleshooting as it recommends but what is the point if after my devices get added they function properly. Its a bit misleading. It is more of a last resort than troubleshooting

[elfin wolf]

the web ui does not offer "an easy solution" when your thread device is on the other side of the house from your home assistant server. thread meshes, but the commissioning process relies on a bluetooth connection, which does not. the web ui is ultimately not the correct solution which is why very little resources and documentation have been put into it.

some day in the far flung future it might be possible for Home Assistant to develop their own commissioning process built into the companion app that takes control over your mobile device instead of relying on those provided by Apple and Google but given that there's so much else that needs to be done and the work for a functional commissioning process has already been done by the mobile phone vendor, it's not reasonable for this to take priority

[shrewd bolt]

It worked fine for my devices across the house. You shouldn't expect any radio to pickup an initial device across that distance. I would rather have a functioning thread network than none at all, and would argue it should be a priority. The fact it hasn't had resources put into it is the exact issue I'm talking about. If it had time dedicated to it we wouldn't even be having this discussion.

Commissioning devices is the keystone the entire project is built on and should be fully fleshed out. Matter is useless if you are locking a large percentage of users out. Exclusive Mobile device commissioning is not the future

Hell, with the current status the skyconnect the issue of a device being across the house is irrelevant because my skyconnect itself had to be 1 meter away, if you read my posts. So how does my phone being near it fix that issue? It doesn't, with the current state of the project it merely serves to obfuscate issues.

[spark mantle]

there is no reason to have the skyconnect within 1m of the device being commissioned. You must have been hitting some network performance limitations specific to your environment.

supporting matter commissioning without mobile devices is very difficult, because currently the matter stack requires exclusive use of a bluetooth le adapter, and it is limited to being able to commission devices within bluetooth range.

priorities of the developers seem to be on making matter over thread work well for "most" users. Making use of the availability of matter commissioning provided by the platform of mobile devices significantly sped up the ability to get matter working, and allowed development focus to be put on things specific to home assistant itself.

[shrewd bolt]

According to many threads here I participated in troubleshooting, and the fact my network is now functioning proves this is not the case. The radio needed to be moved to commission the first device. The actual HA matter and discord support team has said this is the case on multiple occasions, you can simply search the discord. Its the first thread that pops up when you search this mDNS issue

BLE adapters costs $9, skyconnect costs ~$30? And a smartphone costs >$300. I fail to see how a ble adapter is a dealbreaker. This is already a DIY setup that requires the user to buy much hardware even just for a product like the yellow

I do not believe you could elaborate on how network issues would be causing range limitations that are solved after initial pairing. There is a reason many, many threads here talk about moving the stick for that first device.

What is the purpose of dismissing these issues? Matter is a beta product no one is claiming it functions perfectly under HA. support team and matter devs need to be aware of current issues and users thoughts on the matter

As for my specific environment, I run HAOS in a kvm with an opnsense router with ipv6 fully set up, no mdns forwarding, no vlans or other funny business, crossed my ts and dotted my is with stuff I've read over months in this thread with the pains of the kernel issues on Linux.

On the other hand, I'm facing the same issue HA yellow users have that is solved by moving the skyconnect closer to the first device. Notably, it seems it is other inovelli white users with this issue. I think it is extremely foolish to write this off as "unknown unique network issues" simply in order to strengthen your argument about the philosophy behind not supporting the webUI at this time.

Especially when the support for the web UI I'm asking for is just 3 lines of clarification about why it is not a good solution and a more visible post. Right now it is in a limbo where a user still can use it, and then be in a limbo wondering if their devices will continue to work properly after commissioning since the caveats were worded vaguely. If it really is as bad a solution as claimed its like offering the user a loaded gun

[spark mantle]

I agree that a more visible post would be helpful, but the reason that the web ui is not a good solution is very simple, as I've already explained - it requires a dedicated ble radio for the matter stack, and the devices being commissioned need to be close enough to communicate with over ble - which can have much shorter range than wifi or thread (with an established mesh).

at least unlike zigbee, thread devices will reliably re-mesh if they are moved after commissioning. so that's something.

the reason for using a mobile device to commission is that it lets you bring a bluetooth radio close to the device being commissioned, to overcome range or interference issues with the bluetooth radio specifically.

that said, mdns timeouts should be unrelated to bluetooth - ha's matter stack shouldn't be trying to resolve mdns until it has already provisioned network credentials via bluetooth. i guess that would indicate some sort of software (network routing?) issue between the matter stack and otbr, or if it really is dependent on range and affects people with the skyconnect/zbt-1 specifically, perhaps a design issue with the antenna on that adapter :/

i don't know what's been investigated in this issue by the devs so far, but i'd bet that more useful debug information about the device attempting to join the thread network and register services would probably be available from the OTBR logs rather than the Matter side.

[digital condor]

Just FYI - there is a 1.0.5 firmware update coming out apparently that fixes some connection issues with Innovelli white switches: https://community.inovelli.com/t/white-series-firmware-update-beyond-1-0-0/17826/3

[spark mantle]

there were a bunch of issues in the past with commissioning nanoleaf devices where the services wouldn't get registered (so you'd get mdns timeouts) which got fixed with device firmware updates too.

although I've also had similar problems caused by a thread border router bug - I'm running espressif's thread border router devkit, and by default their firmware build only supports 10 mdns services - if you exceed that (which it's pretty easy to do with just a few matter devices...) then it'll stop registering new ones :)