"Something went wrong" when commissioning through Android app

[agners]

When trying to commission a device through the Android App sometimes simply "Something went wrong" is returned.

Note: There might be multiple issue behind that particular error, but this outlines what I've been able to reproduce here.

There are two ways to on-board a Matter device to Home Assistant using Android:

1. Waiting for the half-screen pop-up to appear, then choose the Home Assistant app
2. Open the Home Assistant App, then adding a Matter device by navigating to Settings > Devices & services > Devices > Add Device > Add Matter device

When using method 2, the Android app uses the matter/commission_on_network WS command is used. The passcode is passed to this endpoint, no further information. The Matter Server (SDK) then searches for any commissionable device on the network, and (presumably) picks the first it hears about. This of course could be a different one.

Furthermore, a BR might cache DNS-SD entry for a commissionable device (any BR runs a SRP server, which caches service announcements on behalf of Thread devices). Now if a Thread device got reset during commissioning at one point, such a stale entry might linger around for up to 2h (in my particular test case).

I've noticed this by checking the service announcements during a failed commissioning attempt. Two announcements were present:

$ sudo dns-sd -B _matterc._udp local
Browsing for _matterc._udp.local
DATE: ---Wed 13 Dec 2023---
19:45:23.143  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
19:45:23.143  Add        3   2 local.               _matterc._udp.       14C551B182BE1DB4
19:45:23.143  Add        2   2 local.               _matterc._udp.       9FD5C3686D913371  

And it turned out that in this case the second announcement was from a stale Thread device from the OTBR Add-on:

(I've run this command for debugging from within the container)

$ ot-ctl srp server service
...
9FD5C3686D913371._matterc._udp.default.service.arpa.
    deleted: false
    subtypes: _V4447,_T65535,_S15,_L3840
    port: 5540
    priority: 0
    weight: 0
    ttl: 7200
    lease: 7200
    key-lease: 680400
    TXT: [VP=343434372b38313934, DT=3635353335, SII=35333030, SAI=353530, T=30, D=33383430, CM=30, RI=303230304539314145334235424534423833304331314237334346463637464334423335, PH=3336, PI=]
    host: 86579A470F4CE412.default.service.arpa.
    addresses: [fd82:c9e9:5cb7:1:3b2a:c0f6:fcfd:7e61]

[agners]

It seems we get the information from the CommissioningRequestMetadata object at https://github.com/home-assistant/android/blob/5d779a27aa98bd5f075c843537a46a71be8ba387/app/src/full/java/io/homeassistant/companion/android/matter/MatterCommissioningService.kt#L61. We could get more specific information there e.g. the device location (IP) directly. With that we'd not need to rediscover the device on the Matter Server side.

[marcelveldt]

If we get some more info of the device, we could so a call to "get discoverable nodes" first

[agners]

I first considered using CommissionIP since we have the IP. But it is deprecated, and talking with Tennessee, he says the preferred way is to discover the device again from the server instead of reaching out to the IP directly (I guess the outcome of a mDNS request might be different in certain setups, so doing another request from server side is the better approach).

The CommissioningRequest object returns a DeviceInfo object (see https://developers.home.google.com/reference/com/google/android/gms/home/matter/commissioning/DeviceInfo), which returns the long discriminator. We can filter by that using CommissionOnNetwork with DiscoveryFilterType.LONG_DISCRIMINATOR.

[jpelgrom]

FWIW, the DeviceInfo doesn't guarantee that it includes a discriminator (emphasis added):

The device's discriminator, if known, used to discriminate between Matter device beacons to identify the target device.

Let me know if you want a build of the app with specific changes for the on network commissioning.

[agners]

The discriminator is a static per device unique value. I expect Google just passes the one they learned from the QR code or manual pairing code there, so I'd guess that value is there. We'll have to try it out.

What I am not sure about is if and how we can distinguish between a short and a long discriminator. It does matter for the device as we need to tell the CommissionOnNetwork API which one to filter for. Reading the Discriminator docs I don't think there is a way to know for sure 😢

If we can't learn from the Android API, then we probably just pass the discriminator as integer to the backend for now, and see how to go about it there.

I am guessing that we get 0x300 (768) as short discriminator, if the discriminator is 0x348 (the long discriminator example of 840 from the spec). If that is the case, then we can just mask the lower 8-bit and if they are zero, assume a short discriminator.

So we'd introduce the following websocket API in Core:

@websocket_api.websocket_command(
    {
        vol.Required(TYPE): "matter/commission_on_network",
        vol.Required("pin"): int,
        vol.Optional("discriminator"): int,
    }
)

[agners]

Let me know if you want a build of the app with specific changes for the on network commissioning.

Yeah if you can create a build which passes the discriminator as outlined above would be perfect 👍

[agners]

The Matter server logs look something like this (this capture has some additional hacked in log entries):

2023-12-13 17:48:05 core-matter-server matter_server.server.device_controller[1166] INFO Fetching certificates...
2023-12-13 17:48:05 core-matter-server matter_server.server.helpers.paa_certificates[1166] INFO Fetching the latest PAA root certificates from DCL.
2023-12-13 17:48:06 core-matter-server matter_server.server.helpers.paa_certificates[1166] INFO Fetched 0 PAA root certificates from DCL.
2023-12-13 17:48:06 core-matter-server matter_server.server.helpers.paa_certificates[1166] INFO Fetching the latest PAA root certificates from Git.
2023-12-13 17:48:06 core-matter-server matter_server.server.helpers.paa_certificates[1166] INFO Fetched 0 PAA root certificates from Git.
2023-12-13 17:48:06 core-matter-server matter_server.server.device_controller[1166] INFO Commissioning new device on network using Node ID 33 setup_pin_code 60617843.
2023-12-13 17:48:36 core-matter-server chip.CTL[1166] ERROR Mdns discovery timed out
2023-12-13 17:48:36 core-matter-server matter_server.server.device_controller[1166] WARNING Commission on network failed for node 33
2023-12-13 17:48:36 core-matter-server matter_server.server.client_handler[1166] ERROR [548017525264] Error handling message: CommandMessage(message_id='97901fa041c34d3e82e6f8d9e9a00d43', command='commission_on_network', args={'setup_pin_code': 60617843})
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/client_handler.py", line 188, in _run_handler
    result = await result
             ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/device_controller.py", line 242, in commission_on_network
    raise NodeCommissionFailed(
matter_server.common.errors.NodeCommissionFailed: Commission on network failed for node 33

[satmandu]

I would also be happy to use such a build... since I am having the same issue:

home-assistant/addons#3359

[jpelgrom]

Yeah if you can create a build which passes the discriminator as outlined above would be perfect 👍

Looking at it again, it looks like we confused who creates each object... The CommissioningRequest is created and sent by the app when it wants to start commissioning. Adding a discriminator seems to be a way to limit which devices can be commissioned.

After scanning completes, the app receives a CommissioningRequestMetadata object from the system. This does not include the discriminator, but only passcode + network location (IP) + device descriptor (PID/VID). Unless the app sets a discriminator before commissioning, I don't see how it'd get it from Android.

[agners]

Hm, right, so CommissioningRequest is before any communication has been made with the device? 🤔

I guess this API is mainly meant for device manufacturer. They would limit the device to their PID/VID. It is weird though that CommissioningRequestMetadata does not contain a discriminator then. 🤔