iOS + bridge-app - accessories always unreachable

[plan44]

tldr; is bridge-app supposed to work with current iOS betas?

Problem

• unmodified lighting-app is working smoothly with current iOS beta (from 2022-08-23), commissioning and operation.
• unmodified bridge-app from the same connectedhomeip checkout can be commissioned by iOS beta, is recognized as a bridge with all bridged endpoints correctly, but after that all accessories remain "unreachable". The bridge-app' log output shows periodic reporting activity (from the home hub), and no errors other than those caused (and internally suppressed) by report response chunking.

Question

Should the bridge-app work ok with iOS already, or are there known problems/things missing in the iOS implementation that just prevent it to work at this time?

Just asking as it is very hard to triage between maybe having a data dependent problem in my iOS/HomePod setup vs. basically "implementation for bridges just not there, yet".

[bzbarsky-apple]

@nivi-apple

[nivi-apple]

@plan44 There has been a recent fix for this issue but I am not sure which build its going to go into. Could you please share which iOS beta build you have so I can check on my side. Also could you kill the Home app and restart the Homepod to see if you can reach the lightbulb. This is a workaround. if it works please let me know. Also if you could attach a sysdiagnose from the iphone and the homepod that would help me debug (in case its a different issue that what we see). Thanks

[plan44]

@nivi-apple

There has been a recent fix for this issue

Just to make sure, you don't refer to #21834? This had very similar symptoms, but it's not what I'm looking at now (unlike before #21834 was resolved, the homehub now starts communicating with the bridge DUT).

Could you please share which iOS beta build

• iPadOS 16.1 (20B5027f) on the commissioning iPad
• on the HomePod: the beta that installed along with iPadOS 16.1, unfortunately no easy way to get the full version info (or I'm not clever enough to find it)
• Apple TVOS 16.0 (20J5371a), used that for re-testing, see below

Also could you kill the Home app and restart the Homepod [...]

That's my standard procedure before every new test already 😉.

[...] to see if you can reach the lightbulb.

As said, using the lighting-app example, everything works (Lightbulb is reachable + works).
It's just the bridge-app that does not work (which adds several lightbulbs, switches and temperature sensors, all immediately becoming non-responding immediately after commissioning)

Unfortunately, at this time I only have a HomePod at the office which is very difficult to get logs at all and impossible to see them live. But I have an AppleTV at home - so I just retested and the issue is the same. But here I can watch it in the console.app.

What I found is that it gets stuck in a cycle consisting roughly of:

• homehub issues a wildcard subscription at the root of the bridge
• homehub gets a full report of all endpoints
• homed issues a lot of No characteristic found for attribute report: endpoint:x cluster:y type error messages [Update: these are not the problem, these occur with the lighting-app as well. Just unmapped properties, I guess - probably flagged as errors because these should be mapped eventually?]
• later it says Unable to find HAP service type for deviceType 14 (Matter Bridge) and ...19 (Matter Bridged Device) [Update: these do not appear in the lighting-app, of course, because the simulated bulb is not a bridge. Maybe failing to map these additional device types on the bridge endpoints somehow kills the entire endpoint?]
• shortly after, the homehub again issues a new identical wildcard subscription - with the side effect that this cancels the previous subscription in the bridge app, which later leads to a timeout because the homehub seems still waiting for the original subscription id.
• this continues forever, about once every 30 seconds.

I can share the full log from the AppleTV's homed process if that helps.

[plan44]

@nivi-apple Update: I removed the device type matter brdiged device 19 from the actual light endpoints, leaving only 257 matter dimmable light to see if it makes any difference - it does not.

In general, I realized that the bridge-app stopped working with the commissioner (iPad OS 16.1) getting aware of the concept "bridge". Before, the bridge-app was recognized as just a "accessory" with multiple subdevices. Since 16.1, the Home.app sees it as a "bridge" and treats it UI-wise like the HomePod hosted home hub (listed under "Home Hubs and Bridges" in Settings). Only the bridged devices appear as accessories. Could it be that the homehub side of things is not yet in sync with these changes?

[plan44]

@nivi-apple Maybe it's not the right time to ask, Apple's release department is probably far out doing other things right now 😉

But still - any news on this? Is a fix in the pipe and will eventually land in the next 16.1 beta?

Both official chip example bridge-app as well as my real bridge I'm working on are not testable any more since August 26th, as described above.

I just rebuilt and re-tested everything with the latest connectedhomeip changes to make sure I did not miss something fixed at that end - but the problem remains the same (Commissioning works, but then the HomeHub re-issues the same wildcard subscription roughly once every 30 seconds, and all bridge devices are "not responding" in the Home.app, see above).

[nivi-apple]

@plan44 Thanks you for all your responses. They are pretty helpful. We have the changes to fix this in the next release. I am not sure about the timeline for that but I am pretty sure you will get a fix for it. The way bridges are set up w.r.t endpoints had changed in the Matter spec and we adapted to the new changes. The older release doesn't have those changes. Please keep me posted once you try this with the new release. Thanks for your patience :). Please let me know if you have further questions.

[nivi-apple]

Detailed answer :) -

Both official chip example bridge-app as well as my real bridge I'm working on are not testable any more since August 26th, as described above.
Earlier the bridge aggregate node was on endpoint 0 same as the root node and our code was enumerating bridges based on that. The beta release you have has this version of the code. The matter spec changed the bridge aggregate node to endpoint 1 (rather a non-zero endpoint) and the new code has adapted to that. The fix should be available soon. I would love to have you retest and let me know if it works for you. if you run into any issues, please feel free to drop a line to me. I will keep this issue open for tracking purposes.

[plan44]

@nivi-apple Thanks for the detailed answer 😄

As both Homepod and AppleTV received an update today (HomePod has no way to obtain the exact version, AppleTV reports 16.0 (20J373)), I re-tested today - unfortunately, no change. The fix apparently hasn't made it into those updates.

Still I am a bit confused regarding your explanation:

Earlier the bridge aggregate node was on endpoint 0 same as the root node and our code was enumerating bridges based on that. The beta release you have has this version of the code. The matter spec changed the bridge aggregate node to endpoint 1 (rather a non-zero endpoint) and the new code has adapted to that.

For the bridge-app example, this change occurred quite some time ago on June 10th (3522f9a - Bridge app test updates (#18858)). Since then, the bridge app had the Matter Bridge (now called: Matter Aggregator) device separated at endpoint 1.

But the bridge-app was working ok for quite a while with tvOS/Homepod betas between June and August 23rd. Only after that, it stopped working in the way I am describing above (endless subscription attempts every 30 seconds).

So clearly the homehubs were able to work with the new specs-compliant bridge endpoints between June and August, but not any more. Has something happened that reverted them to expect the pre-June endpoints again?

[plan44]

😄👍💯- With todays beta updates, tvOS 16.1 (20K5041d) and iPadOS 16.1 (20B5045d) the bridge works again, and completely smoothly for the first time! Big joy for me, finally able to continue detail smoothing for real! Thx for fixing this!