[Matter] Device cannot be commissioned to Google Home through iOS

Question

skuang OP

Created Dec ’25

Replies 4

Boosts 1

Participants 3

Hi,

We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed.

Here is our test summary regarding the issue:

TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log

DoorWindow_2.0.1_Google_Success.txt

)

TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log

DoorWindow_2.0.1_Google_by_iOS_NG.txt

)

TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13

In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried:

Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails.
Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as expected and device pops up in Google home of iOS as well.

Could you help check what's the issue of TestCase2?

Append the environment of our testing:

NestHub 2 version

Google Home app version

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’26

Have you filed a bug on this and, if so, what's the bug number?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 2

skuang OP

Jan ’26

Thanks for your information, just created bug FB21539654 in Feedback

Please let me know if any other data or sources are needed.

0

Answer 3

MarcoKhoo OP

5d

is the issue fixed and may i know the root cause? Thank you

0

Answer 4

DTS Engineer OP

Apple

5d

is the issue fixed and may i know the root cause? Thank you

This particular issue was determined to be an accessory failure, caused by the developer reducing the "CHIP_IM_MAX_REPORTS_IN_FLIGHT" constant from it's default value of "4" to "2". The difference between the working and failing cases where then caused by small differences pairing implementation, which then altered the report timing. I don't know why they original reduced that constant but, in general, altering this sort of constant in a hardware implementation is something I would recommend against.

Part of the reason reference platforms exists is that, in practice, it's very difficult for platform and accessory implementors to create products the perfectly interoperate. Theoretically that's addressed by increasingly detailed specifications but anyone who's spent significant time reading a hardware specification knows that increased detail isn't necessarily all that helpful. Reference platforms help smooth out that process by providing a standardized implementation someone can build on without needing to understand exactly what the underlying specification requires. However, that also means that changes to that implementation need to be done VERY carefully since, in practice, platform vendors are actually testing and developing against the reference platform (since that's how most/all accessories "work"), NOT the theoretical specification.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0