If I have a matter device, which including two device type: 0x0103(On/Off Switch) and 0x0107(Occupancy Sensor). Which driver will this device match? Thank you.
Hi @JOJOJO ,
Could you clarify what you mean? Are you planning to use one of the existing SmartThings drivers, or are you considering developing a custom driver for your device?
Hi @Luis_Humberto_Medina ,
I was curious about the rules governing how Smartthings Edge driver selects a driver for a device during initialization. For example, suppose I have a Matter device supporting two device types: 0x0103 (On/Off Switch) and 0x0107 (Occupancy Sensor). There are two corresponding drivers available, namely matter-switch and matter-sensor. Which driver will the device eventually be matched with?
Hi @JOJOJO,
Have you already installed either of those drivers? Typically, the hub first checks if you have any custom drivers installed that match the device, and if it doesn’t find a match, it will then check for SmartThings drivers. If both types of drivers are available, the hub should prioritize the custom driver.
Let me know if you’ve tried this or if you need more details!
As Luis points out, custom drivers take priority over the stock drivers if there is a fingerprint match in the custom driver, otherwise the stock driver will be selected. Matter composite devices are a bit of a pain. What capabilities a device has are determined by a statically defined profile. The method for the device profile to be selected has a hierarchy:
- Most specific - vendorId and productId
- Next most - vendorId only
- Least specific - one or more deviceTypeId’s determined from the device endpoints
So, take a device like the THIRDREALITY Smart Night Light that has a switch capability, lux sensor, motion sensor, dimmer, and color changing. Until a specific fingerprint was defined that matched the vendorId and productId, the device would only have the capability of the first non-root endpoint that matched, namely whatever was on endpoint 0x01. In the case of that device, it was deviceTypeID 0x10D Extended Color Light. This is because the specific combination of all the deviceTypeID’s found in all the endpoints was not specifically defined in the fingerprint definitions.
Compare the specific definition:
- id: "ThirdReality/WiFi"
deviceLabel: THIRDREALITY Night Light
vendorId: 0x1407
productId: 0x1088
deviceProfileName: light-color-level-illuminance-motion-1000K-15000K
to one based on deviceTypeID:
- id: "matter/on-off/light"
deviceLabel: Matter OnOff Light
deviceTypes:
- id: 0x0100 # OnOff Light
deviceProfileName: light-binary
So, this is a long-winded explanation to say that if the specific combination of deviceTypeID’s is defined in the fingerprints, it will match that profile, so something like this:
- id: "matter/colorTemperature/light/2"
deviceLabel: Matter Color Temperature Light
deviceTypes:
- id: 0x0100 # OnOff Light
- id: 0x0101 # Dimmable Light
- id: 0x010C # Color Temperature Light
deviceProfileName: light-level-colorTemperature
If there is not a combination that matches all the endpoint types, the profile chosen will be based only on the deviceTypeID of the first non-root endpoint that matches.
Now, in your specific case, 0x0103 is not defined in the fingerprints of the matter-switch at all. 0x0107 is found in the matter-sensor fingerprints, so likely, your device would be assigned the matter-sensor driver with the profile of motion-battery:
- id: "matter/motion-sensor"
deviceLabel: Matter Motion Sensor
deviceTypes:
- id: 0x0107 # Occupancy Sensor
deviceProfileName: motion-battery
To my knowledge, with the exception of the matter-button driver, no other driver can dynamically determine the proper profile of a composite device using deviceTypeID. The specific combination of deviceTypeID’s must be statically defined. This is one of the frustrating things about ST Matter device drivers.
2 Likes
Thank you for the response you provided, it was really helpful to me.
1 Like