Questions About the "Matter-Switch" Driver

I have some questions about the driver for Matter lights. Will probably have more in the future should I keep playing with it.

I’m curious about the need for around 2000+ lines in the fingerprints.yml, mostly WiZ products that don’t really require it because they target the generic Matter cluster fingerprints just fine (I tested with mine deleting all those lines).

Also, the multiple profiles that only change the colour temperature ranges because some lights start in 1800K, others in 2200K, others in 2700K, etc.

Correct me if I’m wrong: they’re no longer needed and it’s a legacy thing.

  • Three weeks ago a patch was included so the temperature range is set directly by the driver upon receiving the limits from the light itself. Does it mean the range in the profile is overridden? And, even if the default profile says 2200K and the light reports 1500K it will be set to 1500K?

  • Most lines in the fingerprints file are not needed either except for outliers as long as the Matter device reports the clusters correctly. Outliers being that Sengled light that apparently does not report the color cluster while being a colour bulb.

Have another bonus question, I see there’s a creation of child devices. I assume that’s for outlets with multiple “plugs” or multiple switches. Is that the case too for lights that are connected via a Matter bridge, to be more specific: are bridged lights child devices? (edit: I guess not since the part to build the child devices does not run if the device is a bridge).

That’s all for now, thanks!

P.D: Another one, let’s say you want to create a custom presentation for the setLevel method that takes two arguments, the level and the transition time. Is it possible for a custom capability presentation to ask for two arguments at the same time? In all the examples I see you can specify the command and the display type, is it possible to include two display types for those two attributes?

3 Likes

Getting a Nanoleaf also answered this. The generic profile I’m testing is 2200K-6500K but the Nanoleaf can go down to 2100K.

The driver indeed changes the range in the detail view so it displays 2100K-6500K. However, it does not change it in the routine conditions or actions, which reads 2200K as set in the profile.

To avoid having multiple profiles changing just one value it’s better to just set a range that covers most lights (something like 1800K-9000K). In the detail view it will have the correct supported values. In the routine conditions it does not matter and in the actions the user should know if the light is capable or not. Setting a value higher than supported just results in the max supported value.

2 Likes

A post was merged into an existing topic: Tapestry THPZ1 Zigbee Presence Sensor—Help Needed

Wrong thread? @Luis_Humberto_Medina

Yes, it was.

I’ve moved it to:

Tapestry THPZ1 Zigbee Presence Sensor—Help Needed

3 Likes

Question 1:
What is the rationale behind having over 2000 lines in the fingerprints.yml file, particularly for WiZ products which seemingly don’t require them as they target the generic Matter clusters just fine?

Response:
The extensive content in the fingerprints.yml file serves the purpose of providing comprehensive support across various devices. While WiZ products can function adequately with generic Matter clusters, the fingerprints ensure optimal compatibility and device recognition within the SmartThings ecosystem. Additionally, they facilitate device labeling for a seamless user experience in the SmartThings app.

Question 2:
Are the multiple profiles that only change the color temperature ranges considered obsolete, given that a recent patch was included to set the temperature range directly by the driver upon receiving the limits from the light itself?

Response:
The multiple profiles with color temperature names are still required to handle devices that do not provide usable min/max color temp values. These profiles will be used in fingerprints for devices like this, and we already have examples of devices that do not provide usable values for the color temp min/max.

Question 3:
How does the recent patch affect the color temperature profiles in the configuration file? Are they overridden by the limits reported by the light device, even if they differ from the default values in the profile?

Response:
Correct, the values the driver emits override the limits in the profile.

Regarding your doubt in the postscript.:

we’re confirming with the engineering team but it seems there’s no option to send two arguments in a single command, but you can set two attributes and ask the user to input those two values in detail and automation view. The capability commonsmall09402.multiargcap is an example of this configuration for your reference.
However, you would need to validate in the handlers of those commands if you have both values to send the command to the physical device. For example:

local function setAttrOne(driver, device,command)
  log.info(util.stringify_table(command))
  device:set_field("attrOne",command.args.value)
end

local function setAttrTwo(driver, device,command)
  log.info("setAttrTwo handler on")
  device:set_field("attrTwo",command.args.value)
  local attrOne = device:get_field("attrOne")
  local attrTwo = device:get_field("attrTwo")
  if (attrOne~=nil and attrTwo~=nil) then
    --send command to the device
  end
end

Then, in the handler of the messages of the device (Zigbee/Z-Wave or Matter handlers), you can update the status of each attribute of the capability.

1 Like