Issues with Routines and WiZ Lights using Matter

More specifically scenes, routines that adjust brightness and colour. The result may not be the one expected and only happens using Matter integration, cloud one works fine. Might be on WiZ or not, I don’t have other brands to test.

There are two issues:

  • If a routine turns on a light with a given brightness / colour, the last state of the light flashes briefly before changing. In other words, it’s like if you turn the light on first and, after that, you change the brightness / colour.

  • If using WiZ rhythms, a feature where the light automatically changes the brightness/colour depending on the time of the day when it receives a “On” command without brightness/colour information, it might just completely ignore or override the brightness defined in the routine.

Tested in the latest WiZ firmware, currently 1.31.0.

I wonder if it’s on WiZ or SmartThings, might be both! Looking at the Matter driver logs it looks like indeed there are separate actions for On and brightness control, so the light actually turns on first, explaining the flash of the last state. I guess sometimes it also sends the On command after the brightness change, explaining why the brightness set in the routine is lost if WiZ rhythms are enabled.

Have you made routine so that you didn’t select anything in Turn on or off?

Zigbee lights turn on without separate turn on command.
I didn’t have any Matter light.


Wow, thanks! I would have never thought you could unselect something from that list :sweat_smile:.

It’s actually better, and for a moment I thought it did it for good!

The WiZ rhythms issue is still there, I guess I’ll just disable them and mimic the feature with routines.

The last state flash in particular has improved a lot. It’s not gone and may not even be the last state anymore, but it’s less annoying. You can definitely notice the brightness and colour changes are done in two steps, so at first you may see the new colour with the last brightness or the new brightness with the last colour. I think that’s why it’s less annoying though, it resembles more the final light.


Yeah, not very user intuitive. Radio buttons typically are “select one of ‘n’ items” and I was quite surprised as well when accidentally “unselecting” a radio button! OTOH, check boxes typically allow multiple selections–which isn’t appropriate in this situation either! :yum:


Turns out without a explicit “Turn on” it sometimes won’t turn on. I believe it happens with colours only but haven’t done much testing.

This is actually tricky, looks like Matter, just like Zigbee, can’t turn on a light with BOTH brightness and colour attributes at once. It’s always a two-step process. There are commands to change Hue and Saturation, there are commands to change the Level, but none that does both.

My workaround so far is increasing the fade-in of the light to 1 second so the last state is shown less time. My second workaround, so it’s not annoying in my wake-up routine, is setting the brightness to the minimum before turning it off in the sleep routine.

The Zigbee 3.0 standard only contemplates a combined command for level cluster, as MoveToLevelWithOnOff.

This command is what smartthings uses by default to set light levels.
This causes the light to turn on when it is off and receives a level >0 command and turns off when it receives a level =0.

But not all light bulbs or RGBW controllers turn on with this command, for example Gledopto, they require an additional on command to turn On the light.

The default handlers of the lua zigbee libraries for setting colortemperature and setColor(hue & sat) include an additional On command before setting the color temperature or color (hue and saturation).

In my drivers I have tried sending the On command after establishing the hue and saturation and in some bulbs it does not work, however for level and color temperature it works well.

This is why adding an On command to routines is usually redundant.

Turning bulb on with an On command will set the last level, color temperature and color values stored on the device.


Thanks, in the Matter driver they don’t send the On, but they set the masks so a colour change forces an On too. However, in my WiZ lights sometimes it will just ignore the colour if an On is not sent first. Unfortunately I don’t have more brands. Unrelated note, when specifying a transition time in the move to level it will flood the hub with messages and make it extremely slow.

Back to the topic, the last level or colour is always going to be there since you can’t set both attributes at the same time. So, best case scenario, at first you’ll see the last level with the new colour or the last colour with the new level. It’s better than seeing the whole last state but still not ideal.

Feels like an important omision in the Matter specification.

Yes, this is the same i see in some tuya bulbs rgbw.

The device sends reports of the level value until it reaches the target value, but I have not seen the hub slow down, it is just a few seconds of transition messages.

1 Like

Is it “a few messages” or a whole lot?

With WiZ the frequency is crazy high, just did a quick test with a transition time of 2 seconds. In that time it sent 100 events and generated 600 lines of logs! The hub is exhausted during that time emitting events for the switchLevel component and things like that and you can notice the driver responds with huge delay to any other command.

I use a transition time of 5 sec on an Osram Classic bulb and to go from 80% to 0% it emits 5 or 6 messages
Now I don’t have access to the CLI to count them, but the history shows this.

1 Like

5 or 6 is reasonable, I would have around 300 in that time :rofl: Guess I’ll write WiZ support to let their dev team know. Although I would expect that to be part of the Matter certification, I wonder if there’s a rate for updates while transitioning in the specs or not.

1 Like

I don’t know if it has to do with the attribute’s report interval configuration.
In Zigbee smartthings lua default, the device minimum reporting interval for the currentLevel attribute is 1 sec.

In Matter I don’t know how to configure it.
I think it is called subscription instead of configuration, but I don’t see in the libraries how the minimum and maximum intervals are established in the subscription, the device may have it established?

1 Like

Thanks for looking, don’t worry, I’ve also looked at the specification and there is no mention of anything to configure intervals, reports or similar. But I’ve learned a lot about things Matter lights can do that are not exposed in SmartThings unless you create a custom driver. Well, just like Zigbee, they both look quite similar.

Meanwhile I’ve added a time check to ignore reports that are too close and not emit them. At least now I can test things without the hub asking for mercy or the logcat taking ages to catch up.

That’s going it some. The published guidelines are that devices shouldn’t normally emit more than one event per minute except for user interactions.


I’m moving the unrelated message flooding thing to a support post, Matter has indeed a way to configure reporting intervals but either SmartThings is not setting it or WiZ is not complying:


Now that I got my hands on a Nanoleaf Matter light I can confirm it’s a problem on WiZ side.

Nanoleaf does it right when it comes to starting with low intensity even if the last state was 100%, not like WiZ which would “flash” the last state and then bring in the correct intensity.


Found more basic issues with WiZ and Matter, this time using the stock driver with SmartThings. It’s related to the last state, but worse: it may ignore the brightness level if it was off.

Steps to reproduce in the SmartThings app with current 1.31.0 firmware:

  • Turn on the light
  • Use the brightness slider to pick 100%
  • Turn off the light
  • Now use the slider and pick 20% for instance, without explicitly turning it on.

Expected: the light turns on at 20% brightness.

What happens: turns on but you can see the light is at 100% and will stay there.

Funny thing is the value is correctly reported as 20% and the slider will show 20%, the bug in on WiZ and the light physically not being at the reported brightness.

If you start from a lower brightness level, turn it off, then use the slider to pick a higher level, then it turns on as expected at the correct brightness. And, if the light is On, the brightness slider works as expected.

I wonder if SmartThings can communicate with Signify / WiZ to notify the issues, after all WiZ is the brand with more Matter lights certified for SmartThings. The problem is WiZ Matter implementation though, the SmartThings driver is fine.