It’s automatic, just like stock drivers or the hub firmware. I just warn about it when new features are launched because it can take hours to auto-update and someone may be reading that without having received the update.
Unenroll from the driver channel, but I don’t recommend it. Even if there are no new features there are internal improvements: since the hub firmware auto-updates and you can’t do anything about it, sometimes patches are needed so it keeps running in the new firmwares and offering good performance.
For readers’ peace of mind, despite the Playground name, I use the exact same driver version in all my devices and use most of the features on a regular basis so the chances of something breaking are very low. I even test extra use cases that I probably would not care about if the driver was exclusively for personal use like has been for months.
I am starting to implement the new driver’s autoStep on a handful of LIFX Matter lights for testing (which means I want to avoid smooth transitions, in order to prevent the hub from getting overwhelmed with events).
My understanding is that if you have Full dimming time = 5s (default) and you say autoStep 10, then every interval (what is the default interval???) the driver will calculate setting the brightness level to +10%. So, if the level starts at 0%, in theory the driver is going to change the brightness level +10% every 0.5 seconds or 20% every 1 seconds, each time generating one brightness event. But if the level starts at 80% (and the device setting “Full dimming time” is still 5s) then you are going to get two events at 90% and 100% every 0.5s, or you’re just going to get one event, 100% after 1s.
I believe I should avoid the “seconds 0.1” command because it will likely flood the hub, although I can experiment with it to see what LIFX specifically does.
Is there a practical limit to the “interval” command, in order to make sure the hub operates smoothly? And, does it work in 100ms increments or is there a different resolution?
If you set the interval command, will that override the “full dimming time” calculation? It seems that if I write autoStep 8 interval 0.8 then from 0% brightness it will take 10.4 seconds to reach 100% brightness (13 steps), which means that “full dimming time” will be disregarded.
autoStep does not use the Full dimming time in settings, that’s for the start/stop smooth dimming only.
It just auto repeats steps of the given size at the interval you indicate. In your example, autoStep 8 interval 0.8 will repeat a 8% step every 800 ms. That’s why it needs a maximum of 13 steps (100/8) and takes roughly 10 seconds (13 x 0.8).
If the interval is not provided it defaults to 900 ms and there’s a minimum (300 ms if memory serves but it’s pointless to auto repeat at that rate for multiple reasons).
By the way, the driver does not calculate brightness, it’s stateless and just sends native step commands to the bulb, just like if you manually used the Step dimmer level action. It just auto repeats that for you.
I am working with my LIFX lights with the Zooz ZEN37 and I have some good and bad news.
First of all it’s not really clear why not all button presses and holds register with my ZEN37. That is the first issue. It could be related to processing delays (see below) or it could be something else. That alone is super frustrating. There is an Eaton Z-Wave in-wall outlet that functions as a Z-Wave repeater in the room next door, and it appears that the Zooz ZEN37 remote sends commands reliably to SmartThings when in that room, but not in the middle of the target room.
autoStep seems to work, and I can get also to work with one Device ID only, otherwise the string input runs out of space. Reaction time is a little poor but not so poor that a user will get confused (assuming, of course, that ZEN37 commands actually make it to the hub). My experience is that once a user sees the lights change, then releases the button, there may be one more step but maybe not. (I set the step level to 9 and the interval time to 0.9 seconds.) I might try the Rules API at some point in the future. As a suggestion to @mocelet, maybe having an “als” keyword where you list only the first 8 or last 12 characters of the DEVICE_ID would help cram a bit more devices in.
Scene cycling with a Virtual Scene Switcher with 6 scenes works reasonably well, but I elongated the auto-cycling switching delay to 3000ms (when a user holds down the Scene Cycle button, auto-cycling is engaged). I programmed one button press to advance the scene switcher forward by one scene, and double-press to go backwards by one scene.
Great minds think alike! That’s a great suggestion and actually I’ve implemented it today which is even more funny but I’ve not published the update yet! I’ve been changing more internal stuff and want to test more things so I’ll probably publish it in one or two days. (Edit: why wait, it’s published now)
I went for the first block of 8 characters, before the first hyphen of the UUID. If someone has two devices with their first 8 chars equal, go buy some lottery!
Lol, okay. In your implementation, if there are multiple devices with the same 8 characters, does it pick the first arbitrary device, or does it select multiple devices? Just wondering.
The way it’s implemented is going once through all the devices registered in the driver and checking if the first 8 chars are in the “also”. So, if two devices happened to start with the same prefix, they both would be selected.
Edit: The actual probability for the first 8 chars to be unique across 50 lights seem to be 99.9999715% and for 100 lights 99.9998847%, or that’s what AI says according to the Birthday Problem formula.
New version 2025-11-24. Will take some hours to auto-update as usual.
Since the app limits the amount of characters, when using the Advanced input to target multiple devices using the also keyword, in practice you could not write multiple devices since device IDs are 36 chars long. The workaround was using the Rules API.
Now there’s another way which is writing only the first 8 characters of the ID, that is, the ones before the first hyphen. That should be random enough to identify a single device while keeping it short, but I guess it does not hurt to double check, in the AWA you can sort by device ID and quickly see if two devices start with the same prefix.
These two examples to target three devices (the one of the routine and two additional ones) are equivalent:
autoStep 10 also 3b916b24-0d21-4700-911a-d6650569931c,c0c8b96f-eb21-4bef-9b11-cbf51c44805b
autoStep 10 also 3b916b24,c0c8b96f
You can choose to write all the devices in long form or in short form, but you can’t mix both for performance reasons.
As a reminder, to target multiple devices they have to be using the same driver. Popular use cases for the also include the auto stepping, setting the same random colour to multiple lights or in general trying to minimize the popcorn effect.
By the way, I got this back from LIFX on 11/19/2025:
Thank you for reaching out. At this time, we don’t have an estimated date for the Matter 1.4 update. We’ll be sure to let you know as soon as it becomes available.
Quick question: is there a similar driver modification/custom driver to replace the standard SmartThings Zigbee dimmer driver?
I have some vertical blinds (Current E-Wand) where I want “held down” to start opening/closing the blinds, and “released/held up” to stop the blind movement. Unlike the LIFX Matter lights, the behavior of the device + standard driver appears to be that if you set the dimmer to a certain amount, the knob/blob on the SmartThings user interface displays a swirling animation and waits until the blinds move to the requested position, then then knob/blob stops swirling. I am wondering what to do about the automation part. Thanks!
Works great (edit: see note) and I’d say from the compliance point of view is the best I’ve tried.
Doesn’t flood the hub so you can use the smooth dimming features and has good transitions allowing both brightness and temperature unlike some of their Zigbee models.
Minimum brightness is a bit high which is a pity for wake-up and wind-down routines, but given it’s the 1521 lm model can’t complain. Looks amazing in the entrance with all that light and it’s FAST. The colour range is 2200K to 6500K, with the warmest temperature having a cozy orange-ish tone and the coolest temperature being a bit green-ish. Since I usually stay on 2200K-4000K no problem.
The following issues is me being picky, there’s room for firmware updates to fix behaviour of less typical features:
On Level is reset after a power cycle, fortunately the OnLevel Enforcer of the driver fixes that for you so it’s a non-issue.
The native Off with Effect command does not apply any effect, they just turn off the light. Trigger effect commands work great though. I guess nobody uses them since only this driver exposes them and it’s not even in Home Assistant.
My workaround for the lack of Off effects was writing the Off Transition Time attribute but that one is also reset after a power cycle. It works though, you can write it in the Advanced Input with the command write offTransitionTime seconds 2.5 for instance. You can write onTransitionTime and onOffTransitionTime attributes too.
Edit: Well… it went offline and now I can’t control it. My other Thread and WiFi devices are fine. I read similar stories in reddit, although it was using Apple Home. Guess there’s a firmware issue. And does not come back online after a power cycle. I believe it’s going back to the store… Oh, it came back. It’s too unreliable tonight, weird.
In the end got to the conclusion that the Thread reception was worse than the Nanoleaf light that was in the lamp before. If I had an intermediate Eve Energy plug connected, the KAJPLATS would keep the connection, if there wasn’t, it would disconnect frequently.
Given the Nanoleaf didn’t require any repeater and wasn’t that far from the Thread border router anyway, I ended up returning it. Plus, temperatures other than 2700K were not that good.
Can you update Matter Playground to support LIFX 2-Switch and 4-Switch devices?
I can add my LIFX 2-Switch and 4-Switch devices to SmartThings with Matter. From there, the default driver exposes Press, Held (start to hold down), Double press, Triple Press, Quadruple Press, etc. but does not expose a “button up” (end of hold) event.
When I switch from the standard driver to the Matter Playground driver, all events disappear: it’s basically a blank/useless screen for the device. There is no way to switch back from Matter Playground to the standard driver, so I have to delete the device.
It would be nice if your Matter Playground driver can expose the button release event (if it is possible at all). As far as I can tell, this is the only way to get the “gradual dim” and “gradual brighten” features to work on these products other than configuring it in the LIFX app, which apparently sends commands to the cloud.
I’m afraid not, that’s why the compatibility list only mentions smart bulbs on purpose. The driver is not compatible with multi-component devices or child devices and those switches are both a light and multiple buttons.
One of the advantages of the driver being built from scratch is that it’s better at some things than stock drivers. One of the disadvantages is that it does not support all the devices the stock drivers do.
SmartThings not allowing you to change the driver is weird though. Did you try with the advanced website or the command line for that matter? Maybe it was an issue with the app.
BTW, that means it’s not even working correctly with SmartThings stock drivers since those switches do not support those events. I guess it’s the same bug I reported for bridged buttons where stock drivers fail to read the max multi-press attribute, or a bug in the button…
That’s a great suggestion and actually I’ve implemented it today which is even more funny but I’ve not published the update yet! I’ve been changing more internal stuff and want to test more things so I’ll probably publish it in one or two days. (Edit: why wait, 
The IKEA KAJPLATS 1521 lm