[Edge] Matter Playground

[mocelet]

After the huge update in the previous comment to make smooth transitions piece of cake, I’ve pushed a small one this afternoon which is also related to transitions actually.

Long story short, I was not using the native hub handler for the Dimmer routine action on purpose so the driver could add a default transition. It was something that never left my internal version but now it’s gone for good and uses the native handler too so there’s less popcorn effect.

After all, with the new Advanced input introduced in the previous comment you can already set your own transition times for any action anyway. For instance, level 30 seconds 0.5 or the short form L 30 S 0.5 and you’re setting the brightness level to 30% with a 0.5 seconds transition. That’s quite useful for scenes by the way, you can now make scenes that include a transition time up to 109 minutes.

[mocelet]

Another trick of the new Advanced input is triggering native visual effects in Matter lights, subject to vendor implementation.

Off with Effect: I use it with my motion controlled WiZ lights and love the beautiful OffWithEffect SlowFade when no motion is detected. It quickly drops the brightness, stays there a few seconds and then fades to off. It’s great to avoid getting caught in the dark because it gives you time to wave at the sensor if necessary! Works great in WiZ . Nanoleaf was lazy and just turns off the light normally .

Trigger Effect: This family of commands like TriggerEffect Okay are useful for visual notifications since they have different patterns. Again, the effect depends on the vendor.

Full list of allowed effects here, they’re case insensitive and named after Matter spec.

offWithEffect dying

offWithEffect slowFade

offWithEffect fastFade

offWithEffect noFade

triggerEffect blink

triggerEffect breathe

triggerEffect okay

triggerEffect channelChange

triggerEffect finishEffect

triggerEffect stopEffect

I believe no smart home platform today exposes these effects so I’m sure some developer in the world will be happy to know that their effects are being used by actual users and not just QA testers.

[TapioX]

@mocelet

TriggerEffect Okay are useful for visual notifications

This is very effective.

The only problem is that if the light is off when the effect is applied, the light will remain on after the effect. I tested with a Wiz bulb (old firmware).

[mocelet]

@TapioX

I tested with a Wiz bulb (old firmware).

I can confirm it’s fixed in WiZ 1.35.0! Trigger effects not restoring the state was one of the bugs I reported a year ago while playing with unusual Matter commands. Since 1.35.0 introduced other bugs I may not recommend you to update them yet . Well, the main bug is the On Level but you can more or less fix it with the driver, at least until it rewrites it after a power cycle.

Nanoleaf also restores the state and the okay effect has some green and blue fades which are nice. They get some redemption there for the missing off effects.

[mocelet]

Small bug fix update, version 2025-11-10T21:30. Fixes a weird behaviour in the colour history since it reported both correct and incorrect values at the same time (like Hue 9 and Hue 33).

Turns out it was a bug with the default Matter handlers and borrowed the fix from stock drivers. Didn’t affect functionality so that’s probably why it’s been months there and I’ve never noticed . Default handlers are supposed to free drivers from the basic stuff so I like to use them, but sometimes they are not updated.

[mocelet]

New update 2025-11-11 brings the foundation for dynamic colour animations!

I’m not especially fan of distracting animations but I do enjoy when the scene doesn’t feel static and smoothly changes over time, even if it’s just a subtle animation that gravitates towards the same colour.

The Advanced input already had the tools to create colour animations, for instance:

• hue 60 sat 100 seconds 15 will transition to a nice blue shade.
• hue 80 sat 100 seconds 15 will do the same to a purple colour.

Loop those two actions with virtual switches or my scene switcher and you have a perfectly smooth blue-purple animation. And a boring one since it feels dull and repetitive!

Let’s make it more dynamic!

For that I’ve added a saturation randomizer, randomSat min-max, so you can cover different zones:

I tend to use the highly saturated zones with randomSat 75-100 (75% to 100% saturation which is a vivid colour) and randomSat 50-100 (50% to 100% saturation which is vivid-ish without entering the this-is-white territory).

That same loop completely changes now and looks beautiful in both my WiZ and Nanoleaf bulbs:

• hue 60 randomSat 50-100 seconds 15
• hue 80 randomSat 75-100 seconds 15

Mandatory warning: some bulbs can flood your hub when using colour transitions. WiZ 1.35.0 are fine, not so much older versions. Nanoleaf floods a bit but the hub seems to handle it.

Edit: I had the wonderful idea of testing the animation in 3 Nanoleaf lights at the same time, don’t do that, at least not with a V3 hub The flood was too much, the logcat has been minutes processing logs even after powering off the bulbs!

Update Nov 19th 2025: earlier versions of the driver used other attributes that have been deprecated and will be removed in future versions, if you used something like sat randomHigh replace it with the new randomSat 75-100. There are also new randomizers for hue, brightness and temperature.

[mocelet]

Quick tip if you use colour loops to create animations like the ones in the previous comment. It comes in handy to create a routine to automatically stop whatever does the looping when the light is off or when you are done with the colours.

In the screenshot it’s the stop action of the virtual scene switcher but could be a virtual switch or anything that needs an action to stop the loop.

[mocelet]

Making the light warmer or cooler

You may have noticed the relative control action for temperature colour is not in the usual kelvin but mired. We’ll see why it’s better in a moment but if you don’t know where to start, try this:

• Warmer: Step temperature mireds: 30
• Cooler: Step temperature mireds: -30 (yes, minus!)

That would be 12 steps from 2100 K (1.000.000 / 2100 = 476 mired) to 6500 K (153 mired), a typical range in smart bulbs. If you want less steps, aim for a number between 30 and 60.

Why mired?

• It’s better for steps since it’s a visually linear unit and allows for better control. A 30 mired step always feels like the same visual change, a 300 K step feels huge in warmer temperatures but not so much in cooler temperatures.
• It’s the native Matter unit and allows the driver to remain stateless and be more reliable since it doesn’t rely on the SmartThings history. Unlike an absolute temperature, a relative step cannot be converted without knowing the current temperature. A 30 mired step may be just 100 K from a warm temperature but 700 K from a cool temperature.

[mocelet]

New advanced feature. Available from Version 2025-11-14

It is well known that some lights do weird things with On Level attribute so you can’t use it for what it is intended. Nanoleaf rewrites it when you turn the light off and WiZ rewrites it after a power cycle to name two examples.

@TapioX shared with me a workaround copying values with a rule and a virtual number device and gave me an idea to build an On Level enforcer right into the driver.

Meet the On Level enforcer

This is a WiZ light, after a power cycle, replacing my previous -1 with a 25 and then the driver detecting the change and writing -1 again.

And here’s a Nanoleaf that changed the value to 203 when turning it off and the driver restored the 91 I set before to test.

How to use the On Level enforcer

To enable, just run this command in the Advanced input or in the AWA (runCommand). It only needs to be run once for each light.

• feature enforceOnLevel value enabled

To disable, when vendors fix their bugs, use:

• feature enforceOnLevel value disabled

How it works

• While the feature is enabled, the driver stores in a persistent field the On Level value set in the capability, that is, the app or the routine action Write On Level.
• When a report from the light arrives, it processes it as usual and changes the capability value but then checks if the value is different and it was not the user doing it. In that case it will write the old value to the light, reverting the change made by the light.
• To prevent infinite loops where a stubborn light or other platforms may react by changing the value, the driver will not enforce the value again if it already enforced it within the last 3 seconds.

[SeanTek (Sean)]

@mocelet, I’m trying to figure out how to enable gradual brightening and dimming via holding down a button, using the current technology, with LIFX Matter bulbs, while minimizing virtual devices. (LIFX floods the hub when doing a native transition, so we need to do stepwise dimming.) In addition to the LIFX Matter light (running your driver) and the Zooz ZEN37 scene controller (running the Zooz driver), I believe I have it down to two virtual devices: one Scene Switcher for brightening, and one Scene Switcher for dimming. Each Scene Switcher goes into Auto-Cycle On mode when a button is held down (repeatedly triggering through scene 1, up to a maximum number of times specified in the settings) and Auto-Cycle Off mode when the button’s held (released) event occurs.

Since my hub is getting full, I would like to reduce the virtual devices. I devised this combination and want to see if it will work. Suppose that the Scene Switcher runs in 10% brightness increments. In that case, we can combine the two Scene Switchers into one Scene Switcher with scenes 1-20. Cycle mode is is set to “Linear. Will not loop”. Switching delay is set to personal preference, but in my case I observe reasonable results for 800ms to 900ms.

There are two routines: one routine that says that when the scene is less than or equal to 9, then step -10%. Another routine says that when the scene is greater than or equal to 12, then step +10%. When the dim button is held down, a routine first sets the target Matter lights to step -10%, then sets the scene to 10 (which does not trigger any dimming, since scenes 10 and 11 are not preconditions to any step dimming action), and then starts “Auto-Cycle [ < ]“.

The idea is that immediately when a button is held down, the first thing the hub ought to do is step-dim the lights. Then, it starts auto-cycling from scene 10 down to scene 1, which means that additional step dimming will occur 9 times, each time reducing the brightness by 10%. There is no harm in the Scene Switcher running too many times because once the brightness gets to 0%, additional step dimming calls will just have no effect.

Repeat logic for brighten button but +10% on each step. On button held down: step +10%, then set initial scene to 11, then turn “Auto-Cycle [ > ]”.

For both dim and brighten buttons: when the button is released, set “Auto-Cycle [ STOP ]”.

There is a little corner case where a user holds down the Dim button, and then while continuing to hold it down, presses and hold the Brighten button. The behavior is more-or-less as expected: the light will dim a bit, then brighten continuously until the user releases either one of the Dim/Brighten buttons. When one of the buttons is released, the brightening should stop.

Does this approach sound correct/the best, at least until LIFX stops flooding the hub with color change notices?

[mocelet]

New Auto-step dimmer feature . Available from version 2025-11-16.

While this custom driver offers native start/stop smooth dimming for Matter lights, some bulbs like Nanoleaf or LIFX will flood the hub and the automation to stop the dimming will never run on time.

For fans of the start / stop behaviour I’ve implemented an auto-step feature so you don’t need other workarounds like buttons with auto-repeat Held or the virtual scene switcher.

It’s an Advanced input routine action:

• autoStep 10 starts brightening at 10% steps
• autoStep 0 stops
• autoStep -10 starts dimming at 10% steps

Would look like this, Toggled up being whatever your button uses for the held Release:

What if… I want to change the repetition interval? Sure, half a second looks good?

• autoStep 10 interval 0.5

What if… I want the steps to have a short smooth transition? There you go:

• autoStep 10 interval 0.5 seconds 0.1

What if… I want the light to stay at the minimum level when decreasing instead of turning off? Be my guest:

• autoStep -10 interval 0.5 seconds 0.1 without onoff

Tweaking all these options it’s possible to start / stop a smooth-enough dimming even with flooding lights that prevent using the native Dimming routine action.

@SeanTek

Does this approach sound correct/the best, at least until LIFX stops flooding the hub with color change notices?

Not anymore . Make sure the driver has auto-updated to the new version.

Actually, if there are many lights, your scene switcher workaround is not a bad idea (I left some suggestions here) since you ensure all the lights get the exact same number of steps. When individually running autoStep for each light there’s the possibility that some lights end up with one more step since they’re individual timers. Granted, I tried with two lights and they were always at the same level. But that’s why, when having a button with auto-repeat, it’s better to use the button auto-repeat feature and the normal Step dimmer level actions.

[mocelet]

@mocelet

When individually running autoStep for each light there’s the possibility that some lights end up with one more step since they’re individual timers.

This was bugging me SO much.

The problem

If you had to use the autoStep because you had no workarounds left and really wanted the start/stop behaviour, for multiple lights it would look like this:

Same for the stop, three autoStep 0 .

Apparently there’s nothing wrong, but that launches three timers that may not be in sync so the steps will generate popcorn-effect 99% of the time and, worse, the timers may not stop at the same time and a light could end up with an extra step, especially if the interval is short.

The effective but visually ugly workaround

Version 2025-11-17 adds a little trick:

• autoStep 10 also DEVICE_ID

Now a single autoStep can control additional lights as long as they use this driver, specifying the device ID you can find in the advanced website (AWA). You can add more than one device, comma separated with no spaces (sorry I don’t want to mess with the parser now…)

• autoStep 10 also DEVICE_ID1,DEVICE_ID2,...

The advantages are clear: only one timer so no sync issues or risk of not stopping at once and the commands to step are sent virtually at the same time. While that doesn’t guarantee no popcorn-effect, the difference is noticeable and most of the time the steps are perfectly in sync.

Now it would look like this:

Which is not that ugly after all and if you want to change the options like interval time or transition time you only have to change it in one place, not in three.

Now there’s no advantage on using buttons with auto-repeat or the virtual scene switcher other than not having to deal with device IDs or text inputs. In fact, now autoStep is the best workaround for emulated dimming (at least technically).

Update Nov 24th 2025: Since device IDs are too long for the text input of the app, now you can write the IDs in a short form so they fit.

[Andreas_Roedl]

Found the Easter egg in your driver!

[SeanTek (Sean)]

LIFX responded:

Thanks for reaching out.

Our Matter products are certified on Matter 1.3, and the dim-event behavior you’re seeing comes from the Matter SDK rather than custom LIFX code. The SDK improvements included in our 4.110 update should already help with this, and we’ll keep updating the Matter stack as newer versions become available.

So, “expected behavior for now but maybe we’ll fix it later”?

[mocelet]

@Andreas_Roedl

Found the Easter egg in your driver!

@SeanTek

So, “expected behavior for now but maybe we’ll fix it later”?

In Matter 1.4 it’s prohibited to send more than one report per second, and even I think that’s too much if you have multiple lights. I guess they just don’t have any Matter developers and use the software offered by vendors like Espressif or Realtek with no modification at all.

At least the reference Matter 1.4 SDK limits the report flooding so any Matter 1.4 bulb using that code as is should be fine:

src/app/clusters/level-control/level-control.cpp

[mocelet]

@mocelet

Now a single autoStep can control additional lights as long as they use this driver, specifying the device ID

Turns out additional means 1 or maybe 2 at most

False alarm, it’s an artificial limit of the SmartThings app, you can happily write a lot more additional target devices using Rules API

"commands": [
  {
	"component": "main",
	"capability": "panelorange55982.advancedControl",
	"command": "runCommands",
	"arguments": [
	  {
		"string": "autoStep -10 interval 0.5 seconds 0.1 without onoff also c0c8b96f-eb21-4bef-9b11-cbf51c44805b,c7808b59-76c9-42b7-9053-612203f769ae,lorem-ipsum-dolor-sit-amet-consectet,lorem-ipsum-dolor-sit-amet-consectet,lorem-ipsum-dolor-sit-amet-consectet,lorem-ipsum-dolor-sit-amet-consectet,lorem-ipsum-dolor-sit-amet-consectet,lorem-ipsum-dolor-sit-amet-consectet,3b916b24-0d21-4700-911a-d6650569931c"
	  }
	]
  }
]

I’m using the feature with a spare button and some Nanoleaf lights that flood the hub. While I usually switch scenes, a full control of brightness / temperature / colour in a button can be useful. I still prefer the native smooth dimming but so far I can only use it with WiZ lights.

[mocelet]

New update, new randomizers. Available from Version 2025-11-19

Few days ago I made an introduction to colour animations and a way to randomize the saturation to make the colour more alive. I’ve edited that comment because I’m deprecating the old way in favour of this:

• randomSat 80-100 is a random high saturation between 80% and 100%.

• randomHue 55-85 is a blue-ish colour with a random shade that can get a bit purple, perfect to gravitate towards the same colour .

• randomLevel 60-80 for a random brightness between 60% and 80%. Why would you use this? For an animation simulating a candle .

• randomTemp 2200-3500 for a random colour temperature, if your light has no colours you can have some fun too.

Dynamic blue example

If you loop with virtual switches or the scene switcher a single Advanced input action like randomHue 59-69 randomSat 95-100 seconds 10 you’ll have a nice smoothly changing blue that rivals dynamic modes in some vendors.

I use this strategy for my WiZ lights and I prefer it to the built-in modes!

Again, mind some lights will flood your hub when using animations.

Targeting multiple lights with the same action

If you want to set the exact same random colour in multiple lights you can use the also DEVICE_ID like in the auto-repeat steps feature introduced some comments earlier. With this new update, pretty much everything in the Advanced input can use multiple targets to reduce popcorn effect and apply random values equally.

For instance

• randomHue 0-100 sat 100 also DEVICE_ID

will set a completely random saturated colour to the light where you run the routine and also to the light with the given device ID as long as it uses this driver.

[mocelet]

Fun use case. Multiple colour scenes step by step

Back when I created the scene switcher last year I thought it would be fun to create a few colour scenes. Soon I realized all my scenes were essentially a base colour and a slight deviation, like the center light cyan and the ones at the sides green.

The very first versions of the driver were aimed at creating random scenes preserving the colour variations just by pressing a button. Later I realized I didn’t need them to be random, just wanted to shift the colour.

And with this simple Step colour hue action I have a lot of colour scenes by pressing a button, and preserving the offsets I like.

The base scene most of the time is not needed unless I’ve manually changed colours in the app for whatever reason and need to reset the offsets between lights.

Getting it a step further

The steps can be enhanced by adding transition times, for that you need either the Rules API () or the Advanced input action in the app ().

For instance stepHue 12 seconds 0.1 adds a 100 milliseconds transition. Adding seconds or the short form s automatically creates a transition to every input and would look like this:

There’s a whole family of step commands like stepLevel, stepTemp, stepHue and stepSat that I didn’t introduce before.

All the steps allow positive and negative steps plus transition times using native Matter smooth transitions. They are all stateless (the light does the step and does not depend on SmartThings history), except hue steps longer than 25 seconds (Matter limit), where the driver checks the current colour, calculates the target colour and creates a regular transition up to 109 minutes instead of the native step.

[SeanTek (Sean)]

Somewhat basic question, but how do I see or ensure that I have a particular driver version? How does the driver version stay updated, and what if I don’t want to get updates because I don’t want new functionality or (more importantly) I want to ensure that what I have working doesn’t break?

My Hubv3 is running two @mocelet drivers. According to AWA on the web app:

• Matter Playground: 2025-11-21T09:27:55.881779776
• Virtual Scene Switcher: 2024-04-18T16:30:43.915614934

These are the latest, right? I did not do anything in particular to update or not update them.

[marcos.scheffler]

Drivers are updated automatically whenever you stay subscribed to the channel. you can try unsubscribe from the channel and still use the drivers, then they will not be updated.