First, let me address this concern:
By the way, my Matter device is still being tested, so it has not passed CSA's Matter certification and Apple HomeKit certification. Could this be the reason?
No. At this layer of the API, your accessory is an abstract object that the framework is manipulating, which makes the protocol layer irrelevant. You'd see exactly the same behavior with any accessory you managed through Home.app, even non-HomeKit accessories like HomePod.
However, as long as you configure the 72nd action, the app will prompt that the operation cannot be completed, as if the available space is occupied.
Is that error dialog coming from Home.app or some other app? That screen doesn't quite match Home.app and, more to the point, I wouldn't have expected us to return a generic error like "Unable to complete the operation" for basically ANY operation. Having said that:
What is the reason for this?
...the answer is almost certainly that you've hit one of HomeKit's existing internal limits, probably the limit on HMActionSet's per home. The actual limit is "100", however, there are system defined action sets and the mapping from Home.app's interface to the HomeKit API is not straightforward, so I suspect there are another 28 HMActionSet's "in play" that you aren't aware of. In terms of verifying the specific issues, the two things I would look at are:
In terms of your questions here:
May I ask what the reason is?
Basically, "all" of HomeKit's objects have SOME kind of limit, primarily to provide an upper bound that can be tested and validated against. From an engineering perspective, those limits can seems somewhat small, however, keep in mind that the limits here are often bound to the overall user experience and the user experience will generally collapse fairly badly WELL before you'd hit most of these limits. For example the accessory limit is currently ~1000 and the room limit is ~50, but I don't think Home.app is all that usable in either case.
If it is a limitation of Apple Home, is there any solution.
So, on the user side, basically "all" of these limitation are per Home so the limitation can be side stepped by creating additional homes. On the user side, I'd also expect this to happen somewhat naturally as the user tries to create a more "manageable" overall experience. In practical terms, a person with 50+ rooms is very likely to create additional homes ("West Wing", "East Wing", "Guest House") simply to make the entire process more manageable.
On the app side, the issue to be aware of is how the practical user experience works out, not just the raw numbers. Looking at your configuration as an example:
Each of my switches has 12 buttons, and each button supports three functions: single click, double click, and long press. Therefore, a total of 252 actions can be configured for 7 * 12 * 3
In practice, it's difficult to imagine a user remembering even 36 separate actions for a single switch, much less multiple "sets" per switch. Systemization of the actions changes that somewhat (for example, its "on/off/something else on 12 different accessories" ont "36 different actions"), however, it's still somewhat unlikely that a user would end up with multiple switches which each had totally different configurations.
However, what IS likely here is for a user to have multiple switches which either exactly duplicate each other (for example, when a user is placing the "same" switch configuration at different ends of the room) or having specific configurations which are replicated across multiple switches (switches 1-10 vary, switch 11/12 "always" do <insert action>).
You can scale that case up by using "user defined" action sets, which are then shared across multiple triggers. In Home.app, I believe you'd do this by defining a scene as the automation target instead of specifying individual accessories.
The next limit you'll then run into is here:
Therefore, a total of 252 actions can be configured for 7 * 12 * 3
...as the trigger limit is ~250. You should be able to workaround/mitigate that as well by using multiple HMCharacteristicEvent with the same HMEventTrigger instead of creating individual triggers.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
