Using Matter transitions (native fading) in SmartThings

Introduction

SmartThings has a “brighten or dim gradually” feature but it’s cloud-based and not that gradual since the minimum time is 5 minutes and it apparently updates the brightness once every 60 seconds.

:arrow_up: If that works for you, stop here: what follows is cumbersome, uses virtual switches, the advanced website and Rules API, but it’s potentially more visually attractive and smooth.

Matter lights have the ability to perform fades themselves when instructed, from 10 milliseconds to 108 minutes and, if the vendor did it right, the result should be buttery smooth (spoiler: it’s a hit or miss in each vendor and usually works better with times longer than 30 seconds, but it’s also a good opportunity to ask vendors to fix their stuff).

Creating Matter brightness transitions

Transitions are partially supported by the stock Matter drivers, only for brightness in the setLevel command. The second argument, that you can only see in the advanced website and is called “rate” is the transition time in tenths of a second. You can play with it to see if it works in your Matter lights. For instance, first turn on the light and set it to 100%. Then run the setLevel command with 10 and a rate of 600. It should gradually wind-down the light to 10% during 60 seconds. If level is 0% it should turn off at the end.

When that works, you may want to create a routine. SmartThings makes it hard by not exposing that argument to the user interface, you have to use the Rules API.

A simple rule to create a transition

I created a simple rule that will trigger when you turn on a virtual switch (I called it Start Fading) and will fade a set of two lights to 10% during 60 seconds. In fact, I’m so lazy that I created it as a normal routine and then copy-pasted and modified the auto-generated rule to add the second argument :rofl: You have to replace the device IDs of course.

[
  {
    "if": {
      "equals": {
        "left": {
          "device": {
            "devices": [
              "YOUR-VIRTUAL-SWITCH-DEVICE-ID-HERE"
            ],
            "component": "main",
            "capability": "switch",
            "attribute": "switch",
            "trigger": "Always"
          }
        },
        "right": {
          "string": "on"
        },
        "changesOnly": false
      },
      "then": [
        {
          "command": {
            "devices": [
              "A-LIGHT-DEVICE-ID-HERE",
              "ANOTHER-LIGHT-DEVICE-ID-HERE"
            ],
            "commands": [
              {
                "component": "main",
                "capability": "switchLevel",
                "command": "setLevel",
                "arguments": [
                  {
                    "integer": 10
                  },
                  {
                    "integer": 600
                  }
                ]
              }
            ]
          }
        }
      ],
      "sequence": {
        "then": "Parallel",
        "else": "Parallel"
      }
    }
  }
]

About temperature or color transitions

Commands setColor and setColorTemperature do not currently support transitions in stock drivers, I guess at the very least they could add a second argument to those commands like they did with setLevel so they’re on par.

6 Likes

Hi @mocelet

The rate argument of the smartthings setLevel command corresponds to the transition time parameter of the zigbee MoveToLevelWithOnOff command used by the default libraries.

It exists for level, color temperature and color (hue and saturation)

Therefore, what you explain is also valid for zigbee bulbs, in case anyone might be interested.

The problem is that they are not mandatory functions or parameters for zigbee manufacturers, I don’t know about matter.

They also require specific hardware in the bulb, more expensive and complex, which allows moving level, color temperature, hue and saturation at a variable rate.

My zigbee light multifunction Mc driver has custom transition times implemented in preference settings.

Not all manufacturers support it and in this case it will move with the times established in their hardware.

You can’t change the values ​​from routines.

3 Likes

It’s pretty much like in Zigbee, the parameters are mandatory, but being able to move at a variable rate is not. This is from the spec:

If the device is not able to move at a variable rate, this field MAY be disregarded

Having said that, I believe every Matter bulb in the market implements it and every consumer a little bit interested in automations expects it. Some have bugs though (many brands can’t do properly transitions less than 30 seconds) or are not smooth as required by spec (continuous change), or may flood the controller with reports.

The stock Matter drivers implement it for setLevel but not for setColor or setColorTemperature.

1 Like

I am!

Just today, one of my neighbors installed a Zigbee bulb (I only have Thread bulbs) but they didn’t pair it, so now I have a Zigbee bulb to play around with. Two weeks ago they had a M/T bulb that was showing up multiple times per day, but I didn’t want to ask for the QR code.

They’ve turned it off now, maybe because it was haunted. Trying again tonight.

3 Likes

I made WiZ Matter RGBW E27 Bulb fading testing using your example Rules API rule.

WiZ Bulb fading is smooth and it works great.

WiZ Bulb is emitting a lot of switchLevel events. It sends each percentage value of dimmer two or three times.

If there were many Bulbs and they were dimmed at the same time, the operation of the hub could be disturbed by these dimming values.

1 Like

Yep, it reports every unit change (in Matter, like in Zigbee, it’s not a percentage but 0 to 254), so at least it’s a finite amount, no more than 254 reports in total spaced during the transition time, so if it’s a wind-down routine of 30 minutes it’s not really a problem. With colors (can’t do that with stock drivers) it’s worse, it’s an almost infinite flow of hue/sat values and the hub just can’t keep up, becomes sluggish and takes quite long to catch up.

Wrote a whole post about that time ago:

And also reported it to WiZ, they are aware and I’ve reminded them a few times these months.

My Aeotec hub is not particularly powerful, so it struggles even more with some transitions. In Home Assistant they decided to stop recording in the database attributes like brightness because any transition, even if it’s not especially spammy, would be a lot of useless data.

1 Like