[Feature] Vendor ID Specific Commissioning of Endpoints

[jvmahon]

[Feature] Vendor ID Specific Commissioning of Endpoints

[bzbarsky-apple]

You can detect the vendor ID of the commissioner. It's right there in the AddNOC command.

But this approach breaks completely as soon as a device is commissioned by two different commissioners, no? You can't have different PartsList on different simultaneous fabrics; that's a spec violation.

[jvmahon]

But this approach breaks completely as soon as a device is commissioned by two different commissioners, no? You can't have different PartsList on different simultaneous fabrics; that's a spec violation.

Yes, this is what I wanted to do. Since you are saying that is a spec violation, I guess the issue to be considered is whether this should be a spec violation, or if it should be permissible.

At present, it seems that the way Matter controllers are progressing, it is unlikely that all controllers will support all the endpoint types and features. So, either device makers have to program for the "least capable common set" or have devices that don't behave right on certain fabrics / controllers..

In an ideal world, controller certification would be "tougher" and require controllers to all implement at least a base set of features like Mode Select, OTA, Generic Switch. I doubt that will happen.

So, there is a problem for the technology and manufacturers - either (a) they have to limit capabilities to make the device work on the range of controllers consumers use, or (b) there needs to be some way to customize endpoints based on the vendor ID, or you end up with devices that create user interface problems (as is the issue being dealt with here for Google Home and the Generic Switch type).

So, the request is (i) consider allowing different PartsList depending on fabric, and (ii) add functionality to allow this to be programmed in a device (probably more on an "exception" basis -- i.e, always give full PartsList except if XXX).

[jvmahon]

I assume this is a "long shot" to get a change here, but I'm asking anyway due to the practical issue this solves (and for which there isn't really another solution that is apparent).

Thanks for considering this!

[bzbarsky-apple]

So a few things:

1. This isn't the right venue for spec change proposals; those need to happen in the CSA working group.
2. Consider what happens if devices hardcode these sorts of vendor checks and then controllers (which update a lot more often than devices) are changed to handle the situation better... but those devices continue to not work as well as they could with those controllers.
3. In general, it's hard for certification to test what UI looks like because the spec generally can't require anything about UIs... those are really context-dependent.

Speaking of item 2: I assume you've reported the relevant issues to the controllers that are not doing the "right thing" here?