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.
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?
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.
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:
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.
I think it applies to other types of Edge drivers too (like Zigbee), and in my opinion, causes great burden on third party edge driver developers, which need to answer hundreds of “please add this fingerprint” messages, update code and driver version only to enable someone to use it, loosing focus on develop new functionalities.
Smartthings should offer an “advanced configuration” option, both when adding a new device and when changing the driver of an already installed device, which would allow the user to freely choose the driver (among those installed on the hub) and the profile according to those available in the chosen driver.
A specific (or generic) fingerprint match should be only used to automate onboarding and configuration for known devices and inexperienced users, presenting a list of “compatible drivers”, but shouldn’t be a limitation to try, use and test a driver.
This is an advantage that we have back in the DHT days.
Ideally, there would be no need for profiles at all and during device installation, the capabilities of the device would be learned dynamically and the corresponding capability handlers would be loaded. There is a little bit of that happening in some of the more recent updates to Matter drivers (switch, lock, button), so it seems technically feasible that it could be done for other protocols. Unfortunately, it would require a fairly large re-architecting of the existing method of onboarding Z-Wave and Zigbee devices and I suspect there is little appetite to make such sweeping changes.
The Z-Box Hub does it this way. Z-Wave only, but if that fits one’s requirements it works pretty well. I’ve been playing around with one of these hubs at one of my locations for about six months now and it works very well with most newer devices…
Right: it wouldn’t sell refrigerators, TVs, or laundry equipment!
Unfortunately, that’s no small task either given how the platform is currently architected. Additionally, allowing people to pick any old driver willy-nilly will increase support issues since folks will end up with drivers that have capabilities defined that aren’t supported by the device. That’s what already leads to the message “This device hasn’t updated all its status information yet. Check again later.”
I don’t see why. onboard as a thing or with the “best” match as it is today. And then give the option to change driver/profile in the screen that is presented to the user to change name, room, etc. if driver changed, run all the installation handlers again: init, do configure, etc…
Its just a matter of let the user choose from a list of all installed drivers
Thats why is an “advanced option” with a large “if you don’t know what you doing, don’t change this. ”
And a simple check if the profile chosen match with the capabilities reported by the device, to adviced that the device may not work. They already have this logic in the developer area with the “Edge driver builder” tool:
Also, People already call support and come to forum when cant use their devices because the fingerprint are not in the drivers. Some don’t even know how to find the fingerprint.
This process can be made simple if guided through the app.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
15
This approach would only work for the simplest of devices with single and unique endpoints. Anything more complex and it would fail as the driver would need to do the heavy lifting.
Why? My idea is that the user can freely chose the driver among those installed in the hub, and then choose the profile among those available in the driver.
I mentioned the “edge driver builder tool” just to exemplify that it is possible to add some logic to “recommend” the best choice or “alert” that the selected driver/profile choice will probably not work.
The whole architecture needs a major overhaul and refactoring.
Even the Matter drivers are becoming a mess - they added temperature and humidity support in the switch driver, only because one device/profile has buttons and sensors.
Stuff like this doesn’t feel right:
And that’s just one example and not even the worst. So we have fingerprints and in some drivers fingerprints in the init.lua.
An improvement would be to define the sub driver (if there’s any) in the profile or maybe the fingerprint.
But, letting user choose freely the driver and than the profile among the ones specified in the chosen driver address many of the problems quoted for supporting new devices and can be made without any architectural change.
This could be done as a short-term alternative while a more radical change in architecture is discussed/implemented (if that ever happens).
Have you ever found yourself wishing you could use two drivers for one device at once? That one device that functions as a sensor with one driver and as a switch with the other driver? Waiting for someone to create a driver that merges both clusters and both capabilities and adds the fingerprint?
The directory structure of the stock edge drivers gives a hint what the real problem is: they should have created subdirectories/driver modules for clusters and/or capabilities.
But the probability of this architecture refacturing occurring in anytime soon is remote.
I´d prefer to ask now for a functionality change that doesn´t require a great overhaul.
This does not mean that a bigger change should not be implemented.
Occurred to me now that they even don´t need to change anything in the mobile app if they don´t want, avoiding confusing inexperienced users.
Just make the free selection of driver/profile available through the AWA and correctly run all the lifecycle handlers needed on driver change.