The matter-button driver is one of the few that can dynamically identify endpoints and build the child devices without a static profile being defined. I’d be curious to see driver logging from when the device is being added to see why that is not occurring. I’d also be interested in the deviceTypeId for each endpoint. Could be that not every endpoint identifies as a button, hence, yet another case of composite devices not being easily added in the ST architecture.
More interesting is the deviceTypeId’s of the endpoints. Can you run a “smartthings devices -j” on the deviceId using the CLI and post the endpoints here? This is a snippet of what it would look like:
"endpoints": [
{
"endpointId": 0,
"deviceTypes": [
{
"deviceTypeId": 22
}
]
},
{
"endpointId": 1,
"deviceTypes": [
{
"deviceTypeId": 269
}
]
},
{
"endpointId": 2,
"deviceTypes": [
{
"deviceTypeId": 262
}
]
},
{
"endpointId": 3,
"deviceTypes": [
{
"deviceTypeId": 263
}
]
Alternatively, you can get the same thing from the Details of the device from the API Browser+ (which also converts the values to hex as they should be displayed).
In the “us network engineers are not surprised“ category, The solution that the three big organizations are leaning towards is… Hardware. Specifically, new network routers with built-in thread border routers. Because they don’t see any other way to actually deliver the compatibility they promised.
It might well be a solution. But it’s also going to be more expensive and more complex on the “inside the Black Box“ side than what matter initially promised.
Because these three organizations specifically created a standard and then didn’t enforce it. Sigh.
If they had created a rule about what exactly matter meant and then didn’t let anybody use the matter logo if they didn’t meet that rule, there wouldn’t be an interoperability issue. Because only interoperable devices would get to use the logo. Everybody else would still be in beta. Which is the reality of what we’ve seen over the last two years.
So they are promising a solution to the reliability and interoperability issue